Oddly Influenced

Welcome to oddly influenced, a podcast about how people have applied ideas from *outside* software *to* software. Episode 29: Trond Hjorteland on Open Systems Theory, a form of industrial organization more radical than Agile and with perhaps more potential.
——

This episode has a bit of a backstory. I stumbled across a review of Agile by the Australian academic Merrelyn Emery, winningly entitled “A Patchwork of Contradictions and Confusions: Inside the Software Industry”. It is specifically about Agile, and – as you can guess from the title – Dr. Emery is not super-fond of it.

Her alternative is Open Systems Theory (or OST), 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.

But it seems mostly unknown in the software world. Dr. Emery appears to believe that’s because we’re all a bunch of damn fools who deliberately failed to seek out proven social technologies right in front of our faces. Having read some of the source material, I’m more inclined to blame lousy explanations of what it actually is. Whatever the virtues of OST people – and I believe there are many – they are not – as far as I can tell – effective popularizers.

Fortunately, there’s a software person, familiar with Agile, who took it upon himself to learn OST. That’s Trond Hjorteland, who truly heroically read the relevant literature in historical order from the 1940’s onward and even journeyed from Norway to Australia to learn from Dr. Emery herself (and from others in that tradition).

So it seemed sensible to invite Trond on the podcast and find out what this OST thing really is.

I’m glad I did, because – while it superficially seems like Agile – OST is actually considerably more radical. That is, OST for software would be like the tradition-breaking parts of Agile, but with even more tradition-breaking practices and attitudes added on. Naturally, that appeals to me.

The structure of the podcast is roughly like this: it starts with some preliminary descriptions which might make you think “there’s nothing new here”. Then there are descriptions of how so-called “DP2” organizations differ from Agile.

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.

That makes it discouraging. Actual “employee empowerment” seems a distant prospect in this age of tech layoffs and the obvious glee with which large companies look forward to replacing programmers with Large Language Models trained on open-source repositories. So, toward the end of the episode, I made sure we’d discuss how people might apply some of the ideas down at the leaves of the organization tree.

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. He’s also going to have to write shorter descriptions of technologies like the “search workshop” (described later). I’m encouraging him to do that, and have offered to be an editor. I encourage you to also encourage him.

A technical note. My skills as an interviewer continue to be sub-par, and it shows. I have a lot to learn about asking questions in a way that makes a conversation flow smoothly, especially when I’m surprised by the answers. As a result, I’ve had to do a fair amount of moving pieces around and inserting awkward voiceovers. Sorry about that.

I’m also using a new, more powerful, audio editor. I’m liking it. But with great power comes great opportunity to shoot yourself in the foot. And a steep learning curve. That’s affected this edit, and certainly delayed this episode. Again, I apologize.

≤ music ≥

Brian Marick
To start out, you've got a talk on YouTube that I watched this morning. It has an interesting twist in that you start out with displaying a little graphic of a team. And you put adjectives and descriptive words right next to the people. As you talk about what those words mean, we're primed to be thinking that you're describing an Agile team, but you're actually describing a team from socio-technical systems design from something like the 1980s.

Trond Hjorteland
Well, actually, before that.

Brian Marick
So you have learned about socio-technical systems and something that is called open systems theory. 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, starting in ’99. What I do recognize that what we tried to do back then is very similar to what the socio-technical system designers discovered in other industries. And that goes back to the first discovery, in 1949, if I remember correctly. It was in, of all places, the British coal mines. So 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.

Trond Hjorteland
So, in those coal mines, they – not the researchers themselves, but actually the people working there – defined “socio-technical” because they recognized that they needed to optimize both for the social part of the work and also the technical.

Trond Hjorteland
The core thing that sort of what drew me into [socio-technical systems] is the self organization and the democratization of work, which is something that I really recognized [as being similar to Agile]: we're taking charge of our own jobs. We don't allow for people outside who potentially know less than us to decide and describe how we should do our work. We self-organized in a certain way. It was actually the team themselves that decided let's do it, let's try Scrum. It looks cool. And let's try some XP and do some pair programming. It was all about us figuring out better ways to manage.

Trond Hjorteland
The idea of [socio-technical systems] evolved since ’49, into Open System Theory.

Brian Marick
We're gonna have to start defining some terms. I'm going to start at the beginning. I have heard the term “system thinking” or “systems science” all my life, and I have never had any sort of idea what it is, and how it differs from “non-system” [thinking].

Trond Hjorteland
A simple way of explaining is that it's a way of framing things. So basically our way of modeling. One way of looking at a system is looking at the whole and looking at the parts, and seeing how the parts relate to each other to form a whole. So, for example, if you look at an organization, you can look at it as the [people], the organization as a whole, and all the parts [people] relate to each other in, say, in a hierarchy, a formal hierarchy, or informal hierarchy, or whatever.

Trond Hjorteland
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.

Trond Hjorteland
And then you also get into what is called emergence: there's something happening here that is not obvious from the parts. So for example, if you look at your organization, if you look at what all the contributions by a person are, you will see that the output of the organization can’t explained by the individuals’ outputs. You actually have to look at how they interact and that's the outcome.

Brian Marick
Now we transition to the difference between systems and open systems.

Trond Hjorteland
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.

Trond Hjorteland
And I think most people can recognize there is an immediate environment, which is your competition, your industry, the market that you're in. So what Open Systems Theory says is that you have to go further, that you have to look at the social field as well. Imagine [you] have a wide social system, that is, you and me work in the world, right? So when when workers come in the office door, they actually [bring their] social system with them.

Trond Hjorteland
The idea is that the system is actually forming the environment. And the environment is actually affecting the system. So it's a two-way interaction.

Brian Marick
My understanding, having read some of this stuff, is that there are three systems that they talk about. The first two have the catchy names of DP1 and DP2, then there is laissez faire, which is the description that Marilyn Emery gave to Agile: laissez faire.

Trond Hjorteland
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. If you remember back to that ’59 experiment, that was done in the mines, that was the people in the mines that actually came up with this stuff.

Trond Hjorteland
And Fred Emery discovered [in] a national experiment that was going on in Norway in the ‘60s, called the Norwegian Industrial Program, he discovered the design principles DP1 and DP2. DP1 is what we recognize as bureaucracy and hierarchy. And it's a hierarchy of personal dominance. If you imagine a factory, an assembly line, you would have different tasks that people do: W, X, Y, Z, for example. And then you will have people A, B, C, D do those tasks. And you want to make it as simple as possible to replace those parts easily. And those parts will be people. So you will deskill people to the lowest level, so you can easily and cheaply replace them.

Trond Hjorteland
But when you do that, people don't see the whole thing. They only see it a little part of what they are working on. So then you need supervision, you need somebody that controls the whole. Which means that the people at the bottom, they have no control, they have no coordination, and they have no definition of the goal. The goals are happening at least one step above the people doing the work. This is the extreme version of an assembly line: for example, putting washers on bolts: one job, one man kind of thing.

Trond Hjorteland
And 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. And you don't want to look bad, right? Because if you look bad, you're gonna get your pay cut, or maybe you get fired in certain countries, or you're definitely not gonna get that raise or go up in the hierarchy.

Trond Hjorteland
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.

Trond Hjorteland
So 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. So one person would be able to do more than one job. So the redundancy was in the number of things that one person can do, which means you don't have to replace the person. You just have to replace the work he or she does. By doing that, [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.

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

Brian Marick
Awkward transition here because I sidetracked us before Trond could talk about laissez faire.

Trond Hjorteland
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, where they studied groups and how they reacted to leadership. So DP1 had a dominant leader. DP2 was when there was a democracy, where the leader was coming down and discussed with [the team] and they agreed on how to do things.

Trond Hjorteland
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”. They reused that term to explain the situation where there is no clear definition, there's no formal DP1 or formal DP2.

Voiceover
We’ll finish up the background with a review of 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. Because of how I asked questions, discussion of the motivators got smeared all over the interview. I’ll consolidate them here. The first three have to do with the individual. 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, which is what it sounds like, though there will be some discussion later.

* And variety. Not doing the same thing over and over again to the point you get bored.

Now, Trond will take it from here with the social motivators:

Trond Hjorteland
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.

Trond Hjorteland
[It] shows up again and again, that a DP1 team has bad scores on these. The ones higher up in the hierarchy have better scores, because they are more in control. But the people on the bottom have terrible scores. And when they do redesign, work in DP2, [then] do a reiteration on the scores, they are way better, and it’s not just a little bit.

≤ music ≥

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

Brian Marick
The closest you came, you said, was on a particular project. But it wasn't quite there. What was missing? And is that typically missing?

Trond Hjorteland
I think we were quite self governing. 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.

Trond Hjorteland
So we had the control. But we didn't have the coordination, real coordination that goes all the way to the market and back. We didn't have that. So we didn't see the angle of the whole thing. We didn't own the goals either, because somebody else told us: your goal is to produce this component that's going to do this [thing] for some customers. So we were lacking both coordination and control… Control, we had. Coordination and goal setting, we didn't have that.

Voiceover
To expand on that: in her paper on Agile, Merrelyn Emery said that Agile lacked coordination. Because I am focused on what happens inside the team – which ought to be *full* of coordination – that puzzled me. Trond explains:

Trond Hjorteland
So as I said, when the group self organizes, they take charge so that they are controlling the work themselves. What Agile did is similar to what the coal miners did, they sort of took charge themselves. They took control of their own work. But while working in shifts, or something like that, like they do in the coal mines, they also needed to coordinate [with] between the shifts. And 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. That is what she's claiming is missing.

Brian Marick
Would it be fair to say that what's missing is not coordination within the team but coordination between teams?

Trond Hjorteland
Correct. What we can do is try to reimplement the coordination efforts. Because what we have ended up doing with the coordination between teams, for example, we do “flight levels” or SAFe, we try all this stuff we strap on. And what we do then, which is really, really curious, is that we introduce control, again: from the top onto the teams. So we take away autonomy. So you take away control from teams because they need to be coordinated, right? So that they need to give up some of some of their own control and autonomy in order to be coordinated. So they have to give it up. They're not redesigning it themselves.

Brian Marick
So, for example, 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, however it is you do that. And you tell us what we need to know. That's control in that it drives the work, but it's not control of how the work is done. It's control of the “what”, control of the goal.

Trond Hjorteland
Exactly. So that's probably where Merrelyn is maybe missing a little bit because she doesn't know IT that much. Well, she has some experience but not detail at the level that I could bring to the table. So she probably didn't know that we were good at coordinating within the team. And we also had sort of an agreement with somebody above and it's not a *personal* dominance. It's more of a work, design dominance or what we’re gonna work on. So it's not as strict as you probably would find in a classic bureaucracy in a manufacturing setting.

Trond Hjorteland
So we probably give away that coordination. Easily? I dunno. But by doing that we actually create what you mentioned earlier: laissez faire.

Trond Hjorteland
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 Hjorteland
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. But again [referring to omitted conversation], people have to design [their team and solutions] themselves. You hear Marty Kagan talk about something called empowered product teams. That looks to be very similar to what DP2 is describing.

Voiceover
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.

Brian Marick
It seems that in most teams, learning is not an explicit part of what the team is about. It is something you do when you have a chance. And teams don't really have the autonomy to say, “Oh, we're not learning enough. So we're going to slow down

Trond Hjorteland
Yeah, exactly. Spot on.

Trond Hjorteland
That is actually a central part of the redesign. 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.

Voiceover
Here’s a snippet of conversation that illustrates more about real autonomy and also about learning.

Trond Hjorteland
I've been on a team where there was a lot of personal conflicts. There were two people getting in fights. [People say] “No, no, this is never gonna work, we have to throw him out”. But that's a problem. Management controls it and said, “Okay, we have to pull you out. Because you're not functioning in the team.” But if the team were choosing to do this themselves, they will probably have managed that quite nicely.

Brian Marick
Surely it must be the case that people don't always get along happily. And so there has to be some mechanism for conflict resolution... Of course, that's another skill that you want to learn.

Trond Hjorteland
Yeah exactly. I think the team needs to learn that. So probably we need some some extra skills on how to do conflict management. But curiously enough, what the experiments have shown, again back to the 40’s or so – [there’ve] also probably been some since also, but that's the one I remember – is that 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.

Trond Hjorteland
So when people self-organize, they stop thinking about themselves, primarily. They probably [think about themselves] in the beginning, but when you see it: we have a common goal, and we want to reach it, and you know that you can only reach it if we work together. Things change. You're not submitting yourself to the majority, but you see yourself as part of a bigger thing.

Trond Hjorteland
It kind of helps that I come from socialist Norway.

Brian Marick
Yeah… It definitely has that Scandinavian feel to it.

Trond Hjorteland
What Open Systems Theory says is: if you want an optimized sociotechnical system, DP2 is the only way to go. But that doesn't mean that DP1 can't have a place. I don't know if you are familiar with David Graeber and David Wengrow’s /The Dawn of Everything/. They have a story where Native Americans actually switched between what I interpret as DP1 and DP2. When they were hunting bison, they would be DP1. Because then you would have to be controlled, it has to be ordered. People can't just come up with crazy ideas. They have to follow orders. And if they didn't, they were thrown in jail, basically.

Trond Hjorteland
[But] when they were finished hunting, they went back to the camps [and DP2]. They were discussing things and working together. If there was a chief, the chief was only there to sort of manage things. They didn't have a controlling manner.

Trond Hjorteland
And then when they did the hunting again, they go back to DP1, but actually switched who was the boss, who was the chief. So if you were thrown in prison one year, you could actually be the boss next year. There's an interesting dynamic there.

Trond Hjorteland
And I think that's probably what's going to happen in a DP2 team as well. There's going to be leadership there but it's going to be more fluid, and it's going to be contextual. So say if you have some specific task. “You, Per, you know this best, you can guide us through this stuff.” “Yeah, sure, cool.” Next time we do something else, that could be Anne. It's more of a fluid thing. And people sort of share that more and subject themselves to an expertise. It’s not a role.

Voiceover
This emphasis on learning and multi-skilling has implications for career paths.

Trond Hjorteland
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. So a self-managing team needs to be complex enough that you have a career path within it to, say, at least six years. Just a rule of thumb, of course, but there has to be a desirable future for the people in the team. They shouldn't be doing the same job every day because that is one of the intrinsic motivators that people have: they want variety.

Brian Marick
One of the interesting things that I picked up from one or more of the papers is the relationship to pay. If I'm interpreting it right, people are paid not by how much they produce, but what skills they have, I guess because the assumption is, if you have a DP2 team, they will be deciding to practice the skills in an optimal way? So [productivity] is a side effect of producing such a team.

Trond Hjorteland
What's happening when people redesign, they redesign also the pay system. They probably need help for that, but they have some idea how to do this stuff. They realize that they can't compete between themselves because that is not good for the whole.

Voiceover
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. There’s a reason for that. Fred Emery, along with his partner Merrelyn, was the key co-designer of OST. In some of their early experiences, experts had designed work structures. That hadn’t worked well.

Trond Hjorteland
Even if the expert had the perfect design of how an organization should look, it usually didn't work. It fell flat. They couldn't understand: why doesn't this work? And also, if it does work, it doesn't [spread]: other people don’t pick up on it. And what they figured out was that was because somebody else is designing it. People are designing an organization that they are not part of. People have to do it themselves. The people who do the work know the work best. So they know how to reorganize.

≤ music ≥

Voiceover
If 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?

Trond Hjorteland
If you imagine a hierarchy again, you have all these bubbles of teams at the bottom. 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.

Trond Hjorteland
So the teams will work on a small timescale, the one above would work on a longer timescale, and the one on the top – the C levels – would work on strategy and work out towards the environment. So what they see is that when an organization reorganizes to these principles, a large organization ends up having three levels, but the levels are not dominance, they work on different time spans.

Brian Marick
That's interesting.

Trond Hjorteland
It's very interesting, actually.

Brian Marick
So the competition between Open Systems Theory is really something like SAFE.

Trond Hjorteland
It is. It's a whole organization turnover. It's not just a switch at the bottom. I think Peter Wagner said it's not only a radical redesign, it's a DNA switch. You can't do a little bit here and there, you have to do the whole thing.

Brian Marick
And I I admit that I know nothing about SAFE except that I've seen the really complicated diagram. Not read it. My impression is that is not a DNA switch for the people at the management and above level. It's DP1 variant 12.

Trond Hjorteland
Yes. Yes, that's correct. When we do these these large-scale things we try, like LeSS [or] SaFE, it is actually reintroducing or reinforcing the DP1. Which is fine. I mean, that could work. But then we have to realize that we can have problems at the bottom because they still think they are DP2. So there is confusion. The people at the bottom think they are in control, because they are Agile, right? They call themself autonomous, right? While people higher up, at the management level, or the product owners or whatever, they think that they are in control, they're calling the shots. They're saying, “Yeah, let's let them play around with this tech stuff. But I'm calling the shots here.”

Trond Hjorteland
There's always competition. There is never calm. And that lack of calm and order and control makes people feel bad.

Brian Marick
One of the observations of early Agile was that a lot of the Agile people seem to have been compulsive programmers, 10x programmers, cowboy coders, firefighters – who got old and want calm. They don't want an adrenaline rush. And we, our industry right now is very much favoring people who want adrenaline rushes.

≤ short music ≥

Brian Marick
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.

Trond Hjorteland
You know what, that is my biggest worry as well.

Voiceover
However, Trond points out that 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? It’s an old story.

Trond Hjorteland
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.

Brian Marick
And you only seem to get that when they're desperate.

Voiceover
Trond pointed out that, in a lot of organizations, self-organizing teams seem to disappear when the going gets tough.

Trond Hjorteland
If you have a team that has full trust and maybe there were good benevolent managers that gave them some powers, and everything was good. And suddenly that shit hits the fan and the manager says “you have to do that” and then starts the bossing around. Because they have to, because they are measured by it. It's their job, right.

Brian Marick
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, that when things are going bad, I, the boss, have to take control.

Trond Hjorteland
I'm so glad you brought that up. Because this is something that Marilyn highlights again and again. [You can’t say] “Oh, can’t we all just get along? We have an oral agreement. That’s fine, right? ”

Trond Hjorteland
No it’s not. When these organizations do this redesign, what they have to do is create a *formal* DP2. That's really important. It can't be just an informal DP2. What we have in Agile is very much an informal one. We agree that we're going to work like this, but it's not on paper, and the existing contract is still there. So it can be brought back up. So you have to formalize this. You have to bring in unions potentially, for example, and you have to redesign the employment contracts. And you write it explicitly. You don't say “here we work as DP2”. You have to say, “here, we put the control, the coordination, and the goal setting to the people that’re doing the work.” That should be in the contract because you can't you can't tweak that into something else. You can't manipulate that to be a DP1 again.

Trond Hjorteland
And then everybody has to sign it, management and everyone. And if somebody comes in and they want to redo the thing, they have to redo their whole contract. There has to be a consensus to go back.

≤ music ≥

Voiceover
Although companies large and small have applied OST, I’m going to guess that it won’t sweep the world. It’s pretty foreign to corporate culture, especially in the US and UK, which happen to make up 55% of my total listenership. So what can people without DP2-style autonomy do, down in the little bubbles at the bottom of the org chart? Well, perhaps they can try out some of the workshops that have been developed for OST. There’s more information in the show notes. A good first step would be to look at the intrinsic motivators.

Trond Hjorteland
I would suggest a survey on the criteria on your team. Remember, don't do this individually. Don’t, say, send out a survey, and then people fill it out, and then send it in. No, do it together in a room, the whole team. You go through every person so the person can explain “why do I score three here? Why do I score one? Why the score five?” It’s important that the team understands why the scores are the way they are, and then figure out “how can we change these scores? How can we make it better for people in the team?”

Voiceover
The next workshop could be a Search Conference. This is a social technology that’s been around for a long time. Merrelyn Emery has two academic books on it, one from 1996 and one from 1999, and it’s been refined and tweaked ever since by Emery and others. However, a lot of practical knowledge today exists only in the heads of practitioners.

Voiceover
The search conference is a general-purpose way of producing a strategic plan for change.

Brian Marick
So what is a Search Conference like?

Trond Hjorteland
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.

Trond Hjorteland
One really interesting distinction between this Search Conference and others I've seen is that what we call the facilitator, and they call a manager of the process – it's really important that the manager stay out of the topic. He or she should not get involved whatsoever. The only thing that managers should do is keep the sections in the right order, and make sure that people don't run out of time.

Trond Hjorteland
Probably the biggest difference is that there is a very strict structured way to do it. You start at three in the afternoon on the first day, and then continue until nine. Next day, you start early and continue until nine. And then the last day is until three o'clock or something.

Trond Hjorteland
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. A common thing it’s used for is strategic planning: where do we as company want to be in X number of years?

Trond Hjorteland
Normally, 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. This should be a time range of six, seven years. It should be far enough ahead that you don't have to be an expert to guess what's going to happen. So anyone can join in. You want to build a community early on, something that everybody can rally around and see that they can join in.

Trond Hjorteland
When you start with the outside of the system and the wider social field, then you together decide what is the most desirable future? And what's the most probable future of the world, outside of the system?

Trond Hjorteland
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? Then you do a deeper analysis of the present system and look at what things do we want to keep? what things do we want to change? and what things do what do we want to add? Then you, again, look at the most desirable future of the system. So the same way as we did for the environment, but only in the scope of the system.

Trond Hjorteland
And the third segment is when you integrate these two. You started with the environment, then you continued with the analysis of the system, and then you need to integrate the system with the environment, with the change in the environment. And in that segment, you start with looking at the constraints. What sort of constraints do you have, and how should you deal with the constraints? And based on that, you then decide what is the most desirable and *achievable* future of the system?

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

Brian Marick
And so the Search leads into the Participative Design Workshop.

Trond Hjorteland
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.

Trond Hjorteland
The PDW is also a fairly structured process, similar to the Search Conference. Remember those six [internal motivation] criteria? You do a measurement of these during that first section.

Brian Marick
You had earlier suggested that six criteria thing as something people could do first. But normally that's done as part of the PDW?

Trond Hjorteland
You could do the six whenever it’s interesting to do, if you just want to have a temperature gauge of your organization and see how well are the people doing? You could do the six criteria for any reason, but in PDWs, it's required as the first step. That's the analysis step that you do.

Trond Hjorteland
The second [section] is where you do what they call redesign. What the participants then do is draw the workflow of how the work works today. So typically a value stream type of exercise. And then they would redesign that structure. And this really important: they redesign their organizational structure, not necessarily the workflow. The workflow probably works well today. You could adjust it at the same time, but the focus should be on how do people work together? So it's a redesign of the organizational structure. So that would be the second step.

Trond Hjorteland
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. And they have to go through the skills matrix. What sort of skills [are we missing]? What do we need to either hire in? or who should educate themselves on this skill?

Trond Hjorteland
And when you remove the DP1 there's no career path anymore – not the natural classical one anyway. So they need to figure out how to do that and how they should do payments and all that stuff. So you turn into a more of a startup kind of approach: we have to figure out all the technicalities how you should actually manage this.

Trond Hjorteland
And sometimes you will have a reiteration of the six criteria again and see how how would they change after we’ve done this restructuring. So we can measure if there is any progress, if there are any better scores. That's a good way to measure that you're actually moving in the right direction.

≤ music ≥

Brian Marick
Good luck with fixing the world of software. Having been there once myself it's a lot of fun when you think it's going to work and not so fun after it doesn’t.

Trond Hjorteland
Yeah that's the thing. It can be so much fun but it can also be so extremely frustrating. It’s a roller coaster of feelings every time I go to work.

Brian Marick
Okay, well, thank you and thanks to all the people who have listened to this.