Show Notes
Andy introduces you to a paper on socio technical systems and muses about how it connects to the early days of software development. This is our first try at a quick format for when one of us is away on vacation. Please, tell us what you think!
A Socio-Technical Critique of Scientific Management: http://moderntimesworkplace.com/archives/ericsess/sessvol2/37TRASOC.pdf
Transcript
Andy: welcome to another episode of the TTL podcast Today. You’ve got just me, Andy Mon-Chaio is off on vacation. And so I’m gonna do a short episode on a paper that I’ve been reading and just walk you through some of the things I think are interesting in it. And I hope we will get through this pretty quickly.
The paper that I’m gonna be talking about is by Eric Trist. It was written in 1971 for the Edinburgh Conference on the Impact of Science and Technology, and it’s called a Sociotechnical Critique of Scientific Management. Now, this paper is not really report on any particular study.
It’s more of a overview of things that have been happening at this point in 1971. Since about 1911. So he starts off by telling us a little bit about what scientific management is. For those of you who don’t know, it’s by Frederick Taylor. It was his approach to how to manage factories in about 1890s to about 1911 and a little bit later, and it really picked up as the way that most of the way that we think about management anymore is really influenced by it.
It’s the idea that managers are there to design the jobs that people do. That the people themselves are really just there to control the machines. That the machines define what happens and that you can design their jobs by observing and engineering. It is the profession that turned into kind of industrial engineering in terms of setting up how the factories would work, and that approach to management is something that Eric Trist had spent most of his career working to understand and find better ways of doing.
So this paper is a bit of an overview, as I said. But the thing that I found most interesting in it is after going through a bit of a history of where we’ve been, what has been done, what a sociotechnical system is, which I will get to in a second , he gets onto a few things that were learned.
The things that are learned, I think are still relevant today because he is working at this time when information technology was starting to take over. And so for us working in software where our jobs are all day, working with these information technology systems, I think he’s got some interesting insights with this change that was occurring and how that affected what work is.
So a sociotechnical system, to go back to the title and what his Eric Trist’s domain is, a sociotechnical system, is the idea that you can’t simply design the technical system and ignore the social system just as much as you can’t simply design the social system and ignore the technical system.
Sociotechnical thinking is the idea that both have to happen in conjunction, that if you wanna optimize the whole, you have to optimize them as well as their interaction. The social part, as well as the technical part.
Now, where he takes this is that,
Over several attempts. Multiple attempts at building sociotechnical systems as the way of approaching job design, a way approaching management. What they end up with is the idea that there’s a few kind of core aspects that were needed. And those aspects are that they needed an optimum variety of tasks within the job.
Too much variety can be inefficient for training and production, as well as frustrating for the worker to quote the paper. However, too little can be conducive to boredom or fatigue. Okay. I think we know that if as software engineers we’re just given tasks to do that are very simple, very just handed down to us, we’ll get bored after a while.
However, if we spend all of our time in debates and design sessions and all of that, we’ll also get frustrated. So we want an optimum variety of things going on.
Something I think that we’ve also learned quite a bit in software development practices is you also want, quote, a meaningful pattern of tasks that gives to each job a semblance of a single overall task. We talk about this a lot about with things around how do you tell a story about how all of this work comes together.
We’re working on these little bitty, itty bitty details. How does that come together into something that’s important for the customer or important for the project that we’re working on? Another thing that they want is optimum length of work cycle. Too short a cycle means too much finishing and starting too long a cycle makes it difficult to build up a rhythm of work.
How long is your iteration is the way I would think about this anymore. ? What is your work cycle? Then the next point they’ve bring up is that some scope for setting standards of quality and quantity of production and a suitable feedback of knowledge of results. So you have to have some standards set for what the quality and quantity is.
But they also say quote, workers are more likely to accept responsibility for higher standards if they have some freedom in setting them and are more likely to learn from the job if there is feedback. They can neither effectively set standards nor learn if there is not a quick enough feedback of knowledge of results.
It’s really hard to learn if you don’t know what’s gonna come out of it and if you never learn what’s gonna come out of it. The next point that they have is the inclusion of the job of some auxiliary and preparatory tasks. You want some sort of boundary work is what they start talking about.
There’s this idea of work at the boundary. You’ve got your main task and then you’ve got how it interacts with everything else, and you want people involved in that. I found this paper really interesting. It gave me another way of thinking about a lot of the things that we do already in, in our processes for building software in the way that we might set up teams and.
I think it’s also just a really fascinating look back in the past as this transition to information technology was happening the way that they perceived that transition. I hope that you’ve enjoyed this.
and I’d really love to hear what you think of this. Should I get more in depth into this paper? Let me know, till next time, be kind and stay curious.
Leave a Reply