(2023-04-10) Marick Interview Trond Hjorteland On A Radical Approach To Organizational Transformation

Brian Marick Interview: Trond Hjorteland on a radical approach to organizational transformation: Open Systems Theory, a form of industrial organization more radical than Agile and with perhaps more potential.

an approach to industrial organization that has a long history. It’s a research tradition dating back to not long after World War Two. It’s one informed by many on-site observations, and it’s been refined via lots of research into organizational transformations.

Fortunately, there’s a software person, familiar with Agile, who took it upon himself to learn OST. That’s Trond Hjorteland.

while it superficially seems like Agile – OST is actually considerably more radical.

Unfortunately, OST is one of those transformations that requires “buy-in from the top” – and not just the sort of pretend buy-in you get from the typical “roll Scrum out across the enterprise” transformation, but real commitment.

Trond is a consultant, and – going forward – hopes to make his living helping organizations succeed at OST transformations. I think he’s going to need to be the popularizer that OST hasn’t had. In particular, he’s going to have to write a book.

I think that your thesis is that Agile has failed, which I agree with, and moreover, that it was destined to fail. Because we didn't know the things that researchers in socio-technical systems and Open Systems Theory knew. Is that fair enough?

Trond Hjorteland: Yeah, it is a maybe a little bit more blunt than I would put it because I have enjoyed agile for my professional career

goes back to the first discovery, in 1949, if I remember correctly. It was in, of all places, the British coal mines.

what they noticed there was that due to the complexity of the introduction of new technology, the teams were doing worse and worse. But some teams were actually coping better with the new technology than others. And what they saw was that the teams that did better did some self organization.

A wonderful thing that Russell Ackoff coined was: [a system] is not the sum of the parts. The system is the product of the interactions, that's the output of the system. So it's not the parts itself, it's how they interact.

You don't see the system as closed, you see it as open: it's exposed to the environment. So instead of focusing on the parts and the whole, you focus on the system and its environment. And what Open System Theory says is that you can't enclose them. Your organization is always exposed to the environment.

when when workers come in the office door, they actually [bring their] social system with them.

If you look at the system itself, that can take on what Fred Emery defined as two design principles. That's “DP”: “design principles”, as easy as that.

[Both] these models are based on what they have seen. It's not something they had created in the academic world.

design principles DP1 and DP2. DP1 is what we recognize as bureaucracy and hierarchy. And it's a hierarchy of personal dominance... that is also a system where there's competition. When you're working at the bottom, the only way to get ahead in the world is going up, becoming a new supervisor. Everybody is fighting for the same role.

So he coined that as redundancy of parts. For a system to be resilient, it needs to have some redundancy. And the redundancy in that type of model is the parts: you can replace the parts easily, right? People are doing dumb jobs, you can easily replace them cheaply.

what they discovered in the mines, and everywhere else in the world later on, was there was something called DP2. So what happens there is people self-organize. So instead of there being one person, one job, [people] are grouped together in what are called “multi-skilled teams.” And then the redundancy wouldn't be of the parts, but it would be of the function. (cross-functional?)

the workers] also get a picture of the whole. They understand the whole task, which also means that the supervision is low, no longer needed. Which also means that the control and the coordination and the goal setting moves down to the team. (Agility, Context, and Team Agency)

In DP1, all those three (coordination, goal setting, control) is at least one level above. In DP2, it's in the team.

You had people where there is a situation where there's neither of them, neither DP1 nor DP2. That's what they called laissez faire. And when I say “they”, it's actually not the Open Systems Theorists. This goes back to the ‘40s in experiments by Kurt Levine. (Kurt Lewin?)

And then there was a failed experiment where there was a leader coming down thinking democracy means everybody can do whatever they want, and then left. And the team just went ballistic. They had no coordination. There was no control. Their work was terrible, and they didn't get along well, there was infighting and it was actually worse than DP1. So that's “laissez faire”.

OST’s list of six intrinsic motivators... which may be different from other similar lists you’ve seen. Some of the differences between OST and Agile come down to the motivators they address

They are:

• “elbow room”. That’s having control over your work, a “place” where you don’t feel you’re being told what to do.
• continual learning
• And variety
• Mutual Support. You want support from a team
• and you want to feel there is a meaningfulness to what you're doing, that you're actually creating some social value.
• *And that you have a desirable future, that you will actually have a career path, that this is taking you somewhere.

Now let’s move into how DP2 is different than a typical Agile team. It starts out sounding familiar…

The closest you came, you said, was on a particular project.

We decided how to do our work. There was nobody else doing the design for us. We were also part of deciding what's coming up, we did the full testing loop, … but we didn't meet the customer once. So we had the control. But we didn't have the coordination, real coordination that goes all the way to the market and back. (feedback)

Agile didn't do that. They didn't pull down the coordination. They pulled the power down, yes. But they didn’t coherently redesign the organization, so that it would actually support the coordination

what we're doing then is we are placing part of the job onto the shoulders of the product owners. We in our team are saying: You, product owner, go coordinate with other product owners

That's what I think is the problem with Agile: we have these happy little bubbles [where] we’ve tried to be DP2, because I think we all agree DP2 is something we want. But we put them in an organization where the rest is DP1.

Brian Marick: So the issue then is we have to get the product owners to form their own little DP2 groups.

Trond: Yeah, that's one option. But I would suspect if people were able to design it themselves, they would remove that role completely from outside the team, they would put that in the team.

You hear Martin Cagan talk about something called empowered product teams. That looks to be very similar to what DP2 is describing. (Cagan Empowered)

Something to notice here. If the product owner – or the product management role – is to be pulled down into a DP2 team, and DP2 teams favor maximum feasible redundancy of skills, we’re going to see people with product owner skills learn other skills, while programmers and testers learn product planning skills. It’s a good thing there’s a strong emphasis on learning. I contrasted that with typical programming teams.

You have to measure the skill matrix. So they have to figure out “what sort of skills do we need to reach [our] goals? What sort of skills do we need to manage the team for example, because [there’s] nobody else helping us now. We have to do it ourselves. (cross-functional)

even the hell raisers were reduced in a productive working group or DP2 organization, because they want to fit in. We have certain needs, and one of them is of course, we want to be self-governing to a certain extent, but we also want to fit in. So we need to fit in, because we're social animals.

Instead of having a career path that goes up in the hierarchy… you don't have a hierarchy to go up in anymore. So you have to figure out a new career path for people. And the way that most organizations have done this is by saying you have a skill-based career path. So the more skills you have, the more pay you will have.

They shouldn't be doing the same job every day because that is one of the intrinsic motivators that people have: they want variety. (interestingness)

So you can see that DP2 teams have control of – or at least strong influence on – a number of things, like learning and pay, that I think are seen as far outside the scope of even the most self-organizing of Agile teams.

product ownership is pulled down into the team, and there’s team contact with customers, and there’s no boss,… what’s left? What happens to the people who are currently in the management hierarchy?

But you also have teams above. These teams will actually do productive work on that level, they wouldn't control teams underneath them. So for example, at the middle level, you would have somebody doing strategy, for example, or coordination with the external vendors or whatever: something that goes on a different timescale.

a large organization ends up having three levels, but the levels are not dominance, they work on different time spans.

One of the things that alarmed me in what I read was a comment – and whenever I hear comments like this, I get this feeling of dread – which is that this isn't going to work unless there's buy-in in the executive suite. Which to me means it's hopeless.

Companies have transformed. In Australia, the home of OST, examples include telcos, weapons manufacturers, health care, shoe manufacturers, and more. Why did they give it a try?

What is in common here is that when they come and ask for help, they are in dire straits. They need to do something. If they don't do something, they're gonna end up out of business. But yes, you need buy-in from the top.

in a lot of organizations, self-organizing teams seem to disappear when the going gets tough.

One of the things that I noticed was: when you're doing this with the whole organization, it's actually encoded in rules and laws and compensation structure and contracts. That would presumably prevent or at least dampen that impulse

So what is a Search Conference like?

Well, it's not too dissimilar to workshops that we in IT do. I don't know if you're familiar with Event Storming or User Story Mapping session. It’s basically getting the right people in the room, and then letting them decide what's going on.

The first thing you do is figure out what your goal should be. If you don't have an end goal, you want to search for it, you want to search for where you want to be at some point.

you would start out by looking at the wider environment. And this is where the Open System Theory comes in, right? You figure out what change is happening outside the system.

Then the second step is looking at your system. Start with looking at the historical events of that system: what shaped it, what sort of things happened that made it what it is today?

And the third segment is when you integrate these two

The last step is creating the action plans in order to reach that desirable, achievable system.

And so the Search leads into the Participative Design Workshop.

The only reason you want to do a PDW is when you want to change from a DP1 to a DP2. That's the only purpose that workshop has. And you will do that for every type of group in your organization.

Remember those six [internal motivation] criteria? You do a measurement of these during that first section.

The second [section] is where you do what they call redesign.

And the third step is called “the practicalities.” When you change from DP1 to DP2, there will be nobody helping them in controlling and setting their goals anymore. And the coordination is something that the team must take over themselves. So they have to figure out how to do that.