This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
So, welcome everybody to another episode of Software-Architektur im Stream, this time with Andrew, and we are going to talk about Anarchy. And before we actually start, a short shout-out to AgileMeets Architecture, so this was supposed to be an episode that we should have done before AgileMeets Architecture to promote the event.
We didn’t manage to do that, so now it’s sort of a post-event stream about the subject that you gave a presentation about at AgileMeets Architecture.
So thanks for Agile Meets Architecture for bringing us together.
Before we start, can you say a few words about yourself, Andrew?
Yeah, thanks Eberhard.
So yeah, I’m Andrew Harmel-Law.
I’m the, as it says on the screen, I’m the author of O’Reilly’s Facilitating Software Architecture, but I’m also, my day job is as a director at ThoughtWorks UK.
So I used to be a technical principal, and now I’ve been around at ThoughtWorks for too long so now I’m a director.
But I still do basically a consultant who goes and helps companies solve hopefully complicated architectural and org design and org, that kind of problems, so that’s what I do.
And I was really looking forward to this episode because we are talking about anarchy and how it might be something that we could also apply to software development.
And I think this relation between how we structure society and also how we structure projects, that is something that I find always interesting because, you know, at the end of the day, it’s always about people working together on different scales, but there should be some common principles.
So I’m really looking forward to this.
So let’s start off with sort of the more or less obvious question.
So what is anarchy actually?
So at least in German, there is this, you know, chaos and anarchy.
It’s almost like those are synonyms.
And I’m not sure, yeah, so what is the definition?
So it’s a good point.
Can you move your microphone a little bit?
Yeah, sure.
Yep.
Hello?
Is that better?
Yeah, good.
Yeah, it’s a good question.
In fact, this is a great question.
So there are two meanings to anarchy and it kind of depends on your standpoint.
So one of them is the kind of, if you look it up in various dictionaries and things, there is the definition which means a state of disorder, I’m reading this off the screen to make sure I get it right.
A state of disorder, which is people do associate as like a synonym of chaos.
And it’s associated with the absence, like it says, or non-recognition of authority.
So that’s one thing.
The second definition, which is the one I’m interested in, is kind of like you mentioned, Eberhard, right?
So it’s like the fact that there is an organization, but it’s an anarchistic organization.
So it doesn’t recognize a centralized, fixed kind of hierarchical structure.
And instead, it’s a voluntary, self-organized structure, which I think is very close to software.
Maybe it’s not how we do it, but it’s how we’d like to do it.
That’s why I got very interested in this kind of thing.
That’s the anarchy I’m interested in.
It’s like self-organization and the structure that results from all that kind of stuff.
Very interesting.
So it’s voluntary, I think.
That’s one of the main points.
Are there any other aspects to it?
There’s four, which I’m now going to try and remember.
So it’s voluntary, it’s short-lived, which I think is really interesting.
Maybe we talk about that as well.
It is functional, which is the key thing, which again, is where I became very interested in it.
So it should be, the structure should be doing a job.
And this is where the temporary thing comes in, because things change, right?
So the world changes, our software changes.
So if something does a job, then it’s functional.
If it stops doing a job, like this organizational structure, this anarchistic structure, then it should go away and change.
And it’s small, which is also very interesting, because then you get to the question, maybe we get to this later, yes, but does it scale?
Which is the classic question.
And it scales, but it doesn’t scale like we think of scaling.
So that’s, again, is a very interesting thing.
And again, these are why I became interested, because we worry about scale, we worry about software.
We know that our software follows our human organizational structures based on Conway’s Law and all this kind of stuff.
So that’s why I thought there’s a lot of things in the anarchist literature, which might give us clues as to why things happen like they do for us or why they don’t work and etc.
So it’s interesting.
So maybe one of the questions is, what is wrong with other organizations?
I mean, we have, I mean, there are software projects.
So there is a sort of standard way to organize projects, it seems.
So what’s wrong with how we usually do that?
So it’s a great question.
So I think, so the first point I would make is maybe the standard way we organize things isn’t wrong.
Because if it’s working, if it’s functional, and it’s working for you, then that’s good.
The kind of signals of when it’s maybe not working, and in my experience, it very, very, very infrequently works.
There are signals where you kind of know things, right?
So for example, if you’re working in teams and you have agile ceremonies, but it doesn’t feel like the standup is actually doing the things that you thought a standup should do, right?
Or you’re doing demos at the end of a sprint, and it doesn’t feel like the demos are actually making any difference.
Or you’ve read the agile man, you know, you’ve read the done scrum training, and it says, you know, the team commits to something for a sprint, and then maybe, you know, you can’t, you have to abort the sprint if things change.
And you hear that, but it never happens, right?
All of those kind of things.
Or you’re being told you’re in a self organizing team, but you’re not allowed to actually self organize.
Or you think you’re in an autonomous team, right, or a self kind of managing team, and you come up with some idea that you think is important, or an architectural decision that you think is going to be key, and maybe change the game completely.
And then it gets stuck in 17 layers of architectural review boards, and architects who you’ve never even heard of from another part of the organization are telling you no.
Or you think that you can flow, you know, you’re building software, and you think you can ship it down to production.
And you know, you’ve done everything you can in your power to flow, and it still has to go through all of these sign offs, etc, etc.
So you know that there’s this theory of how things could be like agile DevOps, product centric, streamlined teams, blah, blah, blah, all of the words we use.
And yet you look at your organization, and you’re like, it doesn’t feel like that.
And those to me are the kind of they’re the symptoms of this other minds or not other mindset.
One of the there is one kind of predominant model of how we organize and structure groups of human beings.
And it’s a it’s a hierarchical top down kind of model, which has come from a from a certain, you know, historical background, but now it seems to be the only way we think about things, right?
If you join a company, you just assume there will be a hierarchical or chart and all of these kind of things.
And seeing that there were alternatives, and that one of those alternative approaches was called anarchy, and it had a set of patterns and things that was what became very interesting to me.
It’s like, what are the alternative ways of doing these things?
So would you argue that there is a contradiction between a hierarchical organization and a self organization?
It’s self organizing organization?
Yes, I think I would.
I think so.
So what?
Although so this is yes, so short answer, yes, long answer, hierarchy isn’t necessarily bad.
And it’s interesting.
And we might get into this as well later on.
There’s kind of layers of groupings of people like teams, effectively, right?
So in an anarchistic organization, it’s definitely like a team, you think of things as teams, or it’s a nice way of thinking about things like groups of people collected together to do a function, do a certain job.
It is natural, and you can see this in the Conway paper as well.
Things will organize along two different different kind of when you let things self organize, they will organize along two different ways.
They’ll organize horizontally, whereas the problem will split up into pieces, right?
Bounded context, or for a domain driven design land or whatever.
And they will also kind of split in a hierarchical sense.
So you’ll have people who are closest to the problem and closest, you know, dev teams probably building stuff, who are close to a subset of the business context or something, if this is software, or even just a business organizational problem that the organization is solving, right?
They’re close, and they’re doing things and they have a shorter time horizon.
And they have control over their piece, but maybe not control over other things.
You’ll then have other teams, which are maybe less controlled, less hands on with the day to day.
So they’re not writing code, they’re not shipping products or whatever.
But their job is to think strategically further out, think about how teams might coordinate, worrying about whether or not three teams doing the same thing is a good thing or a bad thing.
Maybe it is a good thing, right?
Because like some companies have this strategy where they want different teams to do the same thing.
Other company organizations don’t.
So you have some amount of layering of other groupings of people who are further away from the day to day doing of things, but they still have a functional value because they’re looking forward, they’re doing more strategic, longer term, broader scope type things.
And it kind of if you squint looks like hierarchy, but they’re all peers, no one can tell anyone else what to do.
The problem with hierarchy, the big thing is, is that if I am above you, I tell you what to do.
That’s the kind of the big thing, right?
And so therefore, you only have autonomy at your own level, you can’t, if you need to go higher up, then you can’t.
And that to me was very interesting.
Trond Shortland reminded me of this a lot at the start, because I kept saying hierarchy is bad.
And Trond would definitely say hierarchy is not bad, but it’s what’s the point of being higher up or lower down.
So that’s, that’s what I’ve realized is, is quite interesting.
I have to admit, one of the reasons why I was asking that question is because in the slides that you presented at German architecture, the military was shown as like the sort of original hierarchical organization.
And even though that’s obviously true, there is this idea of autonomous teams in a way also present there, because at least in Germany, and that is why or in the German army, there is this idea of Auftragstaktik, mission type tactics, I think it’s called in English, where you would give someone not an order to do this, but rather to talk about what they should achieve with whatever they come up with, come up with as a plan.
And that is a level of self-organization in a way, which means that even in these strictly hierarchical organizations, there is self-organization.
I think it’s an important point.
And that’s why I’m talking about it, because you would assume that, you know, military is just about mindlessly following orders, but really it shouldn’t be and, or it’s not.
And it’s interesting how they educate people about this also at scale.
I think it’s, yeah, it’s very interesting, because, and you’re right, like the military figured it out.
Because as soon as it came out of kind of like Napoleonic times, things became so dynamic that like you said, and in the military, like functional, if a group is functional, that means like we’re alive or dead, or we, you know, like the stakes are really high, which, you know, makes sense for everybody.
They rapidly realized that you can’t come up with a big plan and tell everyone what to do, because that’s not how it works.
So yeah, I think it’s very interesting that one of the examples of what we think is this big hierarchical thing is kind of, even they figured out as time moved on, that this doesn’t work for most of the circumstances.
It’s very interesting to see.
The other one was, there’s a Paul Goodman quote, which is, the system was designed for what to say, for disciplining armies, I think in peacetime is maybe the key point, bureaucratic record keeping, tax collection, and I think organizing like the Catholic Church.
And again, things have changed, right?
And these are, this is pre-industrial revolution, when a big thing wasn’t even that big.
Right now we think, you know, like some, like a small German company might not be very big, but before the industrial revolution, companies were way smaller.
Now we have global multinational corporations, like the scale of what is big now is spectacularly big.
So yeah, it’s very interesting.
So let’s dive deeper into these four characteristics of anarchistic organizations.
So first of all, you said that those anarchistic organizations are based on the fact that people are working or are doing the things voluntarily.
So I mean, at the end of the day, software development, as we do it, I mean, for both of us, it’s a job.
And at the end of the day, a job is about making money.
So it’s not that voluntary after all.
So is that still something that sort of works, or is there already a fundamental problem in this regard?
It’s another great question.
So one of the things that I learned about anarchy, so again, I’ve gone on a journey with anarchy.
So at the start, I thought it would be like utopian, and it would be brilliant, and everything would just work.
And I’m not saying this to point out that you’ve figured out the fatal flaw.
But another thing I thought was that anarchy gives everyone the opportunity to participate and do all of this organizational design and structure things and figure out how it works.
But it doesn’t, or it gives everyone the opportunity, or more like it gives anyone the opportunity.
What it does is, however, there is some organization, and there will be a specific function of within an organization, like anyone can participate in that organization design, that doesn’t mean that everyone needs to participate, which I think is very interesting.
So you’ll end up typically, especially in a software organization, which is where I’m kind of focused and most knowledgeable.
You’ll end up with teams that are building and shipping software.
And those teams will still have roles where they want people to do stuff.
And so most of this stuff, most of the thing, and people could turn up to those jobs, and they could do that work, and they could, you know, using Agile principles, just build and ship software, which is good, and it works fine.
So then I don’t need to worry about all of this crazy hand-waving anarchistics, or, you know, self-organizing, or whatever you want to call it stuff.
I just turn up and do my job, and someone, some product manager tells me what I need to build, and I build it.
And there are people who do that, and that is perfectly fine, because, you know, people have different needs, and their lives change, and, you know, they’ve got families and stuff, and they don’t want to have all of this extra stuff.
The cool thing about anarchy is, is it, if you adopt it as a practice or a philosophy, it lets, if other people do want to step up, and in my experience, there are always some people, and there are always more people than you think, who do have at least an opinion, and maybe want to get involved, and maybe want to more than get involved, lead and direct all of this kind of stuff.
And that’s the key thing.
So it lets those people do all of this kind of stuff, and it lets them learn, it lets them collaborate, and it gives them a kind of set of patterns and mindset for approaching all of these kind of things.
And that’s the key thing.
So it is kind of, it does mean that anyone can participate, but it doesn’t mean everyone has to participate, and you will end up with these kind of typical things.
What also has struck me is I’ve, because I’ve been experimenting with this in various organizations, so I, before ThoughtWorks, when I was at Capgemini, we experimented with this just as how we ran a team, and one of the problems I thought we would have would be, there were a bunch of my jobs, because I was the manager of this 98 person team, I thought there would be jobs which I had to do, which nobody else would do, so I’m like, okay, I’ll do the jobs which are staffing people on projects, collaborating with salespeople, God bless salespeople, right, but like, it was not my favorite job, and a bunch of other stuff, which if nobody else did it, it would have to be done, because we’d need to win work, and then put the right people in the work.
What was surprising to me was there were people who had very strong opinions of this stuff, and they really wanted to do it.
So I was like, okay, cool, if I can, you know, I’m still, because we did a kind of a small scale version of this adoption, so we didn’t make all of Capgemini UK anarchistic, because obviously that would be completely, would never happen, but they knew we were running it like this in this team.
So I was still the person who was responsible, but I devolved all of accountability, sorry, I was accountable, and responsibility went to all of the people, and they figured out how to do better staffing, and it worked far better, and they figured out how to do better engagement with the salespeople to win better work, et cetera, et cetera.
And so I think sometimes it will fall back on certain people, and they’re the people we kind of call like the glue roles, or the glue work, this stuff becomes more explicit, which again I think is a good thing.
So maybe there will be people who are like, someone needs to do this, and if it’s not going to be anyone else, it’ll be me.
The surprising thing in all of my experience is that when people do engage with this, and the people who want to, and you give them the autonomy as well, right, it’s not like it’s not delegation, it’s not like I have a problem, you fix my problem, it’s like, or sorry, I have a problem and have come up with a solution, you need to do the jobs.
It’s I have a problem, who wants to solve this problem in a clever way?
That autonomy and empowerment, which is very Netflix, you know, the Netflix culture deck, that makes things a lot more enticing to people, because they’re like, okay, cool, I can genuinely be innovative, and I know what the problem is, but I have the freedom to solve it.
That when you present it like that is a very opens up a lot more engagement than I than I ever anticipated, because not everyone has the same.
Like some people just like to turn up and write Node.js, you know, types of code, right.
But other people are like, I really want to, I don’t know, approve training requests or something.
So it’s very interesting.
Yeah.
So what you’re basically saying, you know, I think is that voluntarily means that you have to choose your position and your role and what you want to do.
And I think the other point, which is also quite important, once you start to delegate and to make people find their own roles, you will be surprised what they actually sign up for.
And that’s…
Yeah.
So I wouldn’t use the one key thing, actually, I wouldn’t use the word delegate because delegates kind of like, so the word I eventually figured out was devolve, because I come from Scotland.
So, and that’s got like the devolved parliament.
I think powers are devolved in Germany, right?
It’s definitely a thing in Spain.
I know this.
So, yeah, that’s a key thing, right?
If you, if you devolve, then you’re like, I’m giving you the power that comes with this scope to do, to come up with your own solution.
That changes the game.
Delegation is like a, is a close, but still problematic type thing.
It’s like, I’ve defined the problem, now fix it.
Devolution is like, here’s a bunch of stuff, resources and human beings and money and blah, blah, blah, and then go and solve it.
That becomes very interesting when you do that.
Okay, cool.
So the other characteristic that I want to talk about is how those organizations are temporary.
So, I mean, there is a huge, my understanding is that there is even like scientific evidence that says that things should be stable, or at least that’s what our industry seems to prefer.
So if you say that instead we should have some temporary things, which probably boils down to changing teams and who does what and which team I belong to, that seems like a contradiction.
And I mean, the belief that we have is quite fundamental.
So concerning the stable teams, so can you, can you talk about that contradiction and how it can be resolved?
Yes, it’s another great question.
So it’s like, it very much is a contradiction.
And this is, so number one, it was one interest, why I was very interested to see the anarchistic thing, because the anarchistic tradition is, if you read all of the history, it’s been around a very long time.
You can see it coming from many different, if you read David Graeber, he would argue it’s been around for thousands of years, etc, etc.
So I was interested in the fact that we have this kind of rule of thumb, which like you say, like long live teams, etc, etc.
And therefore this thing is saying what seems to be the opposite.
So I was very skeptical as well.
And there’s two…
And so what I’ve kind of first interrogated was, is why do they say temporary?
The reason they say temporary is because there is this natural tendency among human beings, especially nowadays, I think, maybe, where, you know, like, anarchists would already point out, I said Paul Goodman would point it out, there is this default thing where we assume everyone has to organize in a hierarchical structure.
And Goodman, an anarchy, points out that that’s only one way of doing it.
There are others.
But as Goodman pointed out, that hierarchical structure and the fact we think it’s the only way means that we naturally, especially in Western societies, we tend towards the fact that I identify myself with my job role and therefore, you know, I’m the one-to-one mapping of all this kind of stuff.
And then I’m like my progression and my recognition of my worth as a human being becomes related to this.
So therefore, suddenly me and who I am and what I do in a company becomes very tied to, like, me doing that job and my sense of worth as a human being.
And our anarchy would argue that that’s a bad thing.
They would be like, as soon as it becomes an identity, you know, you become identified with it or whatever, your value in an organization or your value as a human being is related to this, then you will fight to keep you being you doing that role, whether or not you stop being the best person, right?
Or even if you’re still the best person, but you’re the only person, because, you know, one thing that we talk about in teams, which is the least controversial bit, and then I’ll kind of go into the more controversial bits.
We know that you have like a bus factor in teams.
If there’s one person who knows about something, that’s bad, right?
We don’t want that one person to know about something.
We want more than one person to know about it.
That person is the swamp guide in the big ball of mud, right?
They’re the person, they’re the Alberto Brandolini’s dungeon master.
We know that that’s bad.
That’s like the anti-pattern of someone being around forever.
They’ve been around in the company for 20 years.
They’re the only person who knows how to change the code.
Don’t change the schema for the database unless you speak to this person, and they become a gatekeeper.
So that kind of never moving thing is bad, right?
You want that kind of thing to be at least spread around.
So if you think that the person might disappear, then that gives you an incentive to spread this knowledge across a team as opposed to within an individual.
The other thing is, which I think we don’t talk about enough, I agree you do want someone to be around long enough.
You don’t want to have so much change that nobody ever stays around for 10 minutes, and they never get to become an expert, because you do want them to become an expert in things.
But what you want is to focus on the team having that expertise as opposed to one individual.
For the reason, obviously, of the bus factor, the biggest example of the bus factor is like, we never talk about the fact that we move around companies.
So even if I build the longest-lived team, we build a long-lived team.
Management failed to give us a pay rise, even though we all think it’s a pay rise, and we all leave.
So therefore, we’ve all left the team, but we’ve left the company as well.
So I think preparing for something being short-lived, even if it’s long-lived, is good.
The last thing which I learned which was really interesting is – and this again comes from like another example of kind of an anarchistic way of organizing.
In the UK at least – I think they’re in Germany, they’re definitely in North America – there’s a religious organization called the Quakers who are very non-hierarchical.
They have a bunch of rules, and one of the rules is no one can hold a position for more than three years, because the same thing – psychologically, human beings – and they’ve been around since the 1760s, I think.
They know that if someone’s been around for longer than a few years, three years, they will become vested.
There will be a vested interest in them maintaining that thing, and they’re like, you can’t do this for more than three years, which I think is interesting.
It goes to like a deep human psychology, and it’s like, right, if they figured it out in 1760, despite all of the technological changes, we still know that it’s bad.
So if we acknowledge things change, we acknowledge we want people to build expertise, but we don’t want to rely on individuals, then that’s kind of how I balance it.
So it’s a balance.
It’s not like keep people moving all the time.
That’s bad, right?
So again, it seems to be about rules, so I would be supposed to shift rules and do different things at different points, and the bus factor that you talked about, so that’s the number of people that would be killed by a bus, or go on vacation, and then bring the… Yeah, sorry, winning the lottery is the nicer version of it.
It’s like, if you win the lottery, I’m definitely not coming back to work tomorrow.
Actually, maybe I like my own code, but maybe I’m probably not coming back to work.
And this is the thing, actually, the final point, which I forget to make a lot, is you don’t need to move someone between teams.
You could just move around the team, right?
You could move from being someone who’s focusing on product, someone who’s focusing on quality, someone who’s focusing on the code, someone who’s focusing on the runtime stability.
All of those things are good, because then you grow in everyone a holistic view of the skill sets, which, as a team, and this, again, Trond Pjortland would remind me again, he’s got an article which is like, one of the failings he argued controversially was that Agile over-focused on the individual when the manifesto tried to focus on teams.
He’s like, if you think of the unit as a team, then it’s different, right?
The team just has one or more human beings in it, and they have capabilities.
That kind of, it’s a very small mental shift, but it makes a big difference to how you think about things.
And then you rotate people within the team, right?
Or the team rotates people itself.
So it’s very interesting.
Yeah, and the prospect or whatever would be the number of people that you need to remove from the team to bring things to a halt.
And oftentimes it’s one person, because there is that one person who, as you said, has that knowledge about specific things and nobody else has it.
And the other thing that I find interesting and important is that you’re basically saying the way to solve it is to shift positions and make people do different things at different points in time.
And I would totally agree.
And I have this, it’s important to me because I have this strange occurrence where people are basically saying, okay, so in our team, if any person goes on vacation, it’s impossible for the other persons to do that job.
And then it turns out that there is that one piece of code or even that one system that this one person works on, and that’s how they organize work in general.
And what they see as a solution is to write some documentation.
And I find it funny because I recommend what you’re saying, like work together on stuff, pair programming and so on.
And they’re like, no, no, you need to have documentation and then it’s fine.
And I don’t know, there was some basic misunderstanding.
It seems to me there is some basic misunderstanding about how things work in software development at that point.
It’s true.
Actually, if people are interested, Heidi Helfand’s Dynamically Teaming talks about this.
It’s a whole book about this, which is really, really good.
Because that’s where I first realized that long live teams are good, but it’s a team, not a long-lived human being doing a job like you just said, Eberhard.
So Heidi’s got loads of information in this kind of stuff, which is good.
And we also had this episode from Ertramin’s Architecture with Svetlana and Priscilla, where they also talked about how they do this dynamic reteaming and so on.
And I found it quite interesting because it’s very different from what Scrum says about those five people plus me, or seven people plus minus two, and then you would stick to the team and keep it stable.
Yeah, precisely.
Okay.
And the other characteristic that you were talking about is how the organization is small.
So I assume it’s a small team like this, probably this metric number of seven people.
Yeah.
And we all know that there is just so much that you can do with seven people.
So usually quite a few projects are larger than that.
Yeah.
So how do you deal with that in an anarchistic way?
Yeah, it’s another great question.
And this is the big, the small scale thing is another thing where people are like, yeah, it sounds awesome.
It sounds utopian.
Anarchy sounds fine.
As soon as you’re more than seven people, then it turns into chaos, not anarchy.
And, again, anarchists know this.
And their big thing is like, right, you do need to come up with some, you need to self-organize some structure, and anarchy has ways of going about this.
And specifically, actually, STS, which is the kind of the, we talk about socio-technical systems, but there’s a bunch of work by, I can’t remember their names.
I’m going to remember who their names are.
The, well, the Emery’s, who specifically speak about socio-technical approaches to larger scale organization design.
And this kind of has kind of influenced team topologies and all of this kind of stuff.
There are ways to go about this kind of stuff to figure out what, if we have the basic teams and we’ll have multiple teams and we want them to be independent and autonomous and all this kind of stuff, we get that, but then there’s some other layer of teams or some, you know, some other type of teams that have a different scope.
STS give you approaches.
One thing, one’s called searching, which talk about this.
And there was another talk.
I can’t remember what it was called, but there was a talk, Agile Meets Architecture, which I was very excited about.
So this year where the presenters were sharing an example of how they used team topologies approaches to figure out what the structures of these different teams would be and how they would focus them and what they would do.
The point being is like the other thing I’ve learned is that small, again, because we like, like you’re kind of saying, Eberhard, right?
We like things to be simple and we like them to be so simple that we read like Agile Dogma and it tells us it’s not small teams, it’s like five plus or minus two, or sorry, seven plus or minus two.
And we think that always needs to apply.
What we do, what we forget to do is go, in my circumstances, does that make sense, right?
That was a number that was come up with by the, I think the Scrum people or the XP people, I think it’s Scrum, and a specific thing was a specific set of individuals and a specific kind of state of software at the time, et cetera, et cetera.
If you remember that there’s another principle which is functional, but the groups must be functional, if your test is, is this group functional?
Is it doing something?
Then maybe the group can be smaller, maybe the group can be larger, as long as you’re checking to see that the group is doing what it needs to do and is serving a purpose to the overall direction and goal of the organization.
And if you have that, then some of these teams might be smaller, some of them might be longer, sorry, might be larger.
And I think that’s another interesting thing.
It’s like when, you know, how do we know what the right size is?
And that’s another thing which I’ve learned to kind of – I learned from – I used to know a bunch of people who worked at Netflix.
And one of the things which was in the book, Netflix do this, and amazingly I got very interested, things that you don’t think you’ll get interested in.
I got very interested in human resource management and like HR.
I don’t know what it’s called in Germany, but like the – it’s called – yeah, human resources in the U.K. and personnel I think in Germany, not in Germany, in America.
There’s a book by the chief people officer of Netflix, and she describes how they structured their organization, and they tried to have as little structure as possible.
The way they make sure that it has as little structure as possible is they are constantly doing experiments to remove things.
So the classic example is how much of our expenses policy can we remove and still have an expenses policy where people don’t abuse it?
It turns out if you trust people, you can have an expenses policy, which I think used to be spend the company’s money as if it’s your own.
Here is the email address to send your spreadsheet.
I thought that cannot possibly be true.
No one would trust people like that.
Then I went – I’ve been to open space conferences in North America, and I have seen Netflix employees going, okay, I can’t really think – we shouldn’t go to dinner there because I would not go there for dinner if it was my money.
I should go here for dinner, and then I will take a photograph of the receipt just like everyone else does, and then they will claim their share of whatever.
They will be making those decisions without a policy.
They’ll just decide those things.
So that’s really interesting.
So the experimenting with removing things I think, again, is something we don’t do, and it’s very fundamentally agile.
We’re like we love to add code, but we should delete code.
Kent Beck talks about deleting tests when they’re not giving you any confidence and all this kind of stuff.
You can apply the same thinking to organizational design.
You’re like if we didn’t have this team, we’re very good at adding teams.
There’s a problem.
We’ll fix it.
We’ll add a new team.
If there’s a job needing to be done, we’ll add that person.
We don’t experiment with removing those things.
I think if you experiment with removal – and maybe it’s a bad decision.
Maybe it’s a disaster, and you put that person back again immediately.
But you can experiment, and I think that’s very – because we don’t – human systems, organizations are complex and adaptive.
There is no – this is why it’s patterns of anarchy as opposed to download this org chart.
This tells you how to be an anarchist organization.
You need to experiment and find your anarchistic system, which is why it’s hard, but why I think it’s exciting when you get it to work.
I just got a message from Martina from our stream team, and she was saying the books that you’re probably referring to are the New Rules book about Netflix and the culture of reinvention.
We should probably mention that Netflix originally was a shop that was sending around DVDs, right?
Yeah.
Like by mail, and it emerged into that stream nowadays.
Yeah, and they used to be – they had their own – like everything, right?
They were very – because this is what’s most interesting about Netflix.
They went – they evolved like all companies.
They used to have a lot of IBM servers in a bunch of data centers, which they owned.
They were the ones who decided to move to the cloud.
They took some big decisions, and if you read books like No Rules Rules, and there’s another one called Powerful, which is also by Patti McCord.
So Patti McCord is this HR director, which is about her time at Netflix.
And another thing would you be like – this used to be – Bruce Echol used to ask this question all the time.
I know you say everyone is empowered at Netflix, but that means I could decide to do something which might break the whole company, like stop shipping DVDs and start streaming.
Surely only the CEO can make that decision, right?
So Reed Hastings.
And what’s interesting is there are lots of examples, and they talk about some of these in the book.
Obviously Reed Hastings makes some of those big decisions.
Sometimes he gets it wrong, and they talk about mechanisms, again, patterns of kind of organizing for organizationally learning and not bringing in a culture of fear when things fail because you want people to experiment.
But also there are examples where people not at the top of the hierarchy have done things, and there’s been a clear way of taking – being autonomous and taking accountability for things.
So it gives – if people are interested, I definitely recommend reading those books because we go, yeah, that sounds amazing, but surely it can’t work.
And there’s a lot of – admittedly only one company, but there are other examples where you can see, okay, and then you can imagine what might work in your circumstances.
It’s very – because the culture is different.
A German company will do this differently from an American company.
A British company would definitely do this differently than an American company, but it doesn’t mean it wouldn’t work.
Again, it’s patterns of anarchy, right?
Like the patterns would manifest in different ways in different cultures because the culture has an impact on – it’s human beings to human beings, right?
So there will be a set of expectations which will come with the human beings when they enter in the office, like you said, right?
Some people expect to turn up and write some code.
Other people are like, right, I need to – So there is no one-size-fits-all.
So we were talking about the size and how it’s about small groups, and you basically made the point that it’s rather about not having too many rules.
From the slides, I took a note about emerging federations.
So is that also something that helps concerning scaling the whole thing?
I mean, the natural way to scale it seems to be hierarchical.
Okay, so you made the point that you might remove some of the rules and that might be a step to have less rules also on the sort of global level of an organization.
Emerging federation sounds different.
So is that also something that helps?
Yeah, yeah, yeah.
So exactly.
So emerging federation is – it sounds a bit overcomplicated, and it’s maybe where the anarchy bit gets a bit theoretical.
And a lot of anarchist thinkers prefer to think about the small groups and things that just appear.
In the small, the emergent federation is basically – the simplest thing is, if you think about it, when we build a bunch of microservices, at some point it gets to a certain scale.
We know because we’ve built our microservices.
An anti-pattern is to suddenly whack a gigantic ESB in the middle, right, which is basically just imposing a hierarchical layer on top, and therefore we have all of this stuff.
It will solve our problem to begin with, but very soon we’ll be cursing the existence of this ESB because it’s imposing a bunch of things which remove everyone’s autonomy.
The alternative which you can do is – and this is why it’s emergent – you can start figuring out what some of these higher-level, probably like saga-implementing, longer-term business transaction-encapsulating level of microservices, which might sit in different kind of levels of like bounded context, whatever I’m kind of using.
I love domain-driven design, so it’s kind of how I think about it.
But you’ll end up with these different things because if you look at an organization, there will be these longer-term, broader-scale kind of jobs to be done, but like with a transaction outside of a technical layer, right, it won’t be a database transaction.
It’ll be a business transaction.
It’ll be like, this is the start point.
This is the end point.
Here are a bunch of things to be done.
If you look for those, but not just in a software perspective because that’s what software teams would do, but also from a kind of organizational perspective, those are the things that emerge.
And then you say, I think this is a thing.
We can maybe spin up like a one-person or two-person team to kind of fill this hole in and see if it’s providing a function.
And the function should be fundamentally how well is the organization doing its job, right, which in the case of a software organization is shipping valuable products and delivering a stable and cost-effective service.
If it’s delivering that value, then that’s really good, right?
And then we’re like, okay, cool.
And then those teams can look to figure out are there other things they can do or is there other kind of inefficiencies which the teams are telling them are existing, which they can fill in, some gaps they can paper over.
And to the previous point, is there anything they’re doing that they need to stop doing because they’re just adding overhead or whatever?
That’s this kind of emergent thing.
So it emerges again from the work and the flow of work and the general organization.
Something STS talks about, which is socio-technical systems, and Anarchy talks about is like not everyone but what you do need, and people will have this, is a general view of the overall system.
What is the organization and what is its purpose?
In a hierarchical organization, we devolve the responsibility for that to the executive, to the CTO and the CEO and the board of directors and things.
And this is what I think is interesting as well.
Even though we devolve responsibility to them, every single person has an opinion as to how the organization should be structured.
So if you ask me, I could have redesigned every client I’d ever worked for, and it might not be good, but it’s like here is what’s wrong, here’s how you fix it.
So people have this, but they’ll have a very specific, their viewpoint only view.
If you devolve it and have this kind of emergent thing, then people are more – because it’s easy to have an opinion if you’re not at stake.
If you’re at stake and you could affect it, then you’re like, okay, cool.
Now I need to balance things.
Now I need to – we need to balance running fast and breaking things with customer service and maintaining our credibility and all this kind of stuff.
Again, more responsibility goes down to more groups of people, but there will be people who will be willing and excited to take on that kind of responsibility and use this kind of continual opportunity to change and affect things, which I think is really interesting.
So sounds in a way as like if you throw the right problem at the organization, they will figure out how to answer to that, and they will have some emergent collaboration between different smaller teams, and there you go.
And it’s interesting.
So there’s another thing that this is kind of in the book, but it disappeared from the book.
So the book is, my editor, Rita, described it as a love letter to two other authors.
So it’s a love letter to Christopher Alexander, and it’s a love letter to Don Reinertsen.
So Don Reinertsen wrote The Principles of Product Development Flow, which is like complex adaptive product development systems.
And then obviously Christopher Alexander is where we get the idea of design patterns from.
Design patterns, if you read it, feels very top down.
It’s like, here are some patterns for the organization of areas, then for organization of towns, then for organization of regions in a town, then for organization of buildings, and then rooms, et cetera, et cetera.
At the end of the book, there’s this whole piece where he talks about, there’s a thing called the principle of repair.
And this, I think, is only a few paragraphs in my book.
He’s like, there is this top down force, right?
People need a house, or someone needs a factory, so they build a factory, or they build a house.
But then people work in factories, people buy the products that factories make, people live in houses, and there’s this back pressure up from people living in that environment that are like, right, this isn’t working as well as we thought.
So it’s smaller, but there’s more of these things.
So again, if you’re sensing the organization, and the best way to sense an organization is have as many people in the organization paying attention to the organization and saying, this is or this isn’t working.
If you have a mechanism to listen to them saying, this isn’t working, this isn’t right, and you give them a formulation to take those thoughts and to try experiments to improve or adapt, and again, the adaptive emergent way of designing things.
If you give them a format to do that, because we do in software already, right?
But if you give them a way to do that for organizational design, you can sense and respond from like the running system as well as like this high level, this is where we’re going, I’m going to top down command everyone to do things.
And again, it’s something we don’t talk about.
And we know in code when it goes wrong, because we end up with technical debt and rot and all this kind of stuff.
Last key point is I once asked, because I was interested about Netflix is to if they run so fast, how come they never have technical debt?
The reason is they’re constantly rewriting microservices.
I don’t know what they do now, but this was like 10 or seven or eight years ago.
So they knew what the microservices needed to do.
They would throw them out and they’d rewrite them because they were micro, which is why they love microservices.
So the organization, the business need would still be there, but they just rewrite the code and they would rewrite it based on this new information from what this service now needed to do, right?
They’d written it so it would scale to like 100 TPS and now it needed to scale to 200 TPS or 1000 TPS.
They could constantly re-evolve and replace bits of their software.
And they were doing the same with their organization.
And I think that’s very, if you give people the ability to do that, I think it’s really, really interesting.
Which again, is also about, you know, not giving lip service to some organizational idea, but rather make sure that the organization evolves.
So this all sounds pretty convincing and I mean, you just gave the example of Netflix and I mean, obviously that’s a very successful company.
However, I would argue if you have managers, if you have shareholders, those are people whose job description more or less is to control things.
And also, I mean, that’s a problem that we have probably have in our industry.
So if someone outsources the development of some piece of software to some company, then they are also quite well-incentivized to control this stuff because you need to keep an eye on it.
It costs a lot of money and you need to track progress and see whether it actually works out because it’s very important and there is a very good reason why you would do that.
So I would argue if you’re a manager, if you are a shareholder, so if you are higher up in the traditional hierarchy, your job is basically to control.
So if you let anarchy happen, it means that you’re out of a job.
And if you are a customer for some outsourcing, then it takes a lot of trust to give up control and the problem is…
So I was wondering how you deal with that.
So is there still a way to sell this idea to these people or how do you deal with these kinds of circumstances and incentives?
It’s a great question.
So number one, probably don’t use the word anarchy.
I’m using the word anarchy because it sounds interesting and then people sit up and listen.
Maybe the actual reality is less exciting than people thought.
But if you’re selling it internally, anarchy probably won’t open many doors, although it does help me go in and speak to people because clients are like, okay, we’re paying some money for Andrew.
So maybe, you know, they seem to have an interesting opinion on things, but if I was a permanent employee of many of my clients, this would not be the way to get management buy-in.
But calling things self-organizing, self-managing, self-sustaining, that feels like buzzwords that they like or maybe they do or don’t like, but you’re very right.
Because of the dominance of the hierarchical thing, everyone who is in some senior level of the hierarchy will have got there by playing by the rules of the hierarchy whether they like it or not.
Some people do.
Many, in my experience, don’t, but they do it anyway because that’s how you get more money and recognition and learn more skills.
It does take a brave kind of person to say we’re going to do it differently and trust is exactly the thing.
So some people might be thinking this sounds very much like trust-driven organizations and trust organizations and TEAL organizations.
It does.
Lots of my inspiration came from TEAL organizations.
And in the book, the core of the book is a thing called the Architecture Advice Process, which is basically just the advice process from Reinventing Organizations by Frédéric Laloux.
What’s interesting to me is, and this is, I think, the last chapter of my book, doing any of this stuff right, like we all know the way for an agile transformation to fail is to do it big bang.
The way for a DevOps transformation to fail is to do it big bang.
The way for a product management transformation to fail is to do it big bang.
And you can do this in the small, and that’s kind of what I talk about in some of my other talks.
It’s like how can I incrementally adopt this?
Maybe secretly, right?
Like there used to be, people used to say it’d be amazing if Scala was used more all over the place, but no one wants to adopt Scala.
And lots of the things I used to hear was, not that I’m a massive fan of Scala, but like you can use it for your test, right, because no one cares what your tests are written in.
You can adopt this individually, kind of anarchistic ways of thinking, and see that it just makes things better.
You can do this.
This can scale.
And I was lucky at Capgemini, but I was explicit about it when I did this as a team, the manager of a 98-person team, because I was like, I’m going to do this, I’m going to make no attempt to change anything elsewhere in Capgemini, and Capgemini had no inclination to let me change anything else.
And I kind of said, I’m going to explicitly, all of your expectations of me and this team will not change, right?
So the external, how we present ourselves to the outside world will not change.
Internally, we’re going to change a lot.
The reason one human being can manage 98 people is because I wasn’t managing anyone.
The team was self-organizing.
I was just the person.
If anything went wrong, it was my neck that got trodden on.
But things didn’t go wrong because suddenly everybody was stepping up and doing things.
So there is kind of ways of doing this thing, and you can do it secretly and then kind of slowly share things and make it clear to people that it doesn’t have to be a complete adoption or whatever.
You can find it.
The last point I make in the book is, in the start, I think, chapter 17, one of the things we forget but is actually in our favor, there’s already a cultural difference between IT departments or technical software departments and the rest of organizations, because they know we think differently because the world, and now with AI, everything works differently, right?
So there already is an expectation that we’re a bit different and we think differently and we do things in different ways, and we use words like scrum and stuff, which make no sense to everyone else.
So we already kind of have this ability to be different within a software delivery part of an organization, and as long as we stay within some kind of guardrails or build trust as we grow outside those guardrails, then we should be fine.
The way you grow outside those guardrails is the way, like, for example, at Capgemini, we were a very happy team that was one human being was technically running 98 individuals.
We were well-staffed, and we seemed very happy with the work that we were doing.
That’s because we were self-organizing, right?
But the company didn’t care.
They were just like, oh, you seem to be highly utilized and happy, and recruiting is going really well, and retention was really good, and, like, absences from illness were down, et cetera, et cetera.
So because we were just happier, right?
Because we were doing better work.
So yeah, I wouldn’t sell it like, let’s do anarchy, but it should be like, we should have a more responsive, more best-fit organization to be able to react and respond, especially in the world of LLMs and stuff now.
You want something that can react and respond, right, because in the course of this conversation, some new technology, like Claude Code 73 has probably dropped, and all of our lives have changed.
Did you call it Anarchy at Capgemini, what you were doing?
I mean, there has to be some name for it.
I think I just called it.
What did I call it?
I didn’t call it Anarchy.
Well, so it was interesting.
This was interesting.
There were a few people who I really trusted in human resources, so I kind of went to them and said, I’d like to try these experiments.
So I came up with all these words.
And what was interesting was, they were aware of Laloux.
They were aware of the theories of organizational design.
They were there.
Yeah, exactly.
Right?
Because this is the thing.
This is all about there.
They would be traditionally the people who do the org design, et cetera, et cetera.
They just didn’t get the opportunity to do it, because everyone was like, no, hierarchy is how we organize.
This is how we structure ourselves.
So they were like, kind of, I thought I would have to convince them, but they were more like co-conspirators.
And they were like, right, here’s the things that we expect from you that will make sure no one gets in trouble.
But then after that, just go and do whatever you like.
So I think we just called it self-managing and self-organizing, or something.
The best bit was, there was a quote where, in the review process, where we had to say, this is how everyone’s done this year, you know, the performance management process.
The manager of another team, when I stepped up to present the 98 people, because we peer reviewed each other, right, because we were non-hierarchical, and we were trying to be anarchistic about it.
So I came up with this, kind of, pre-existing, peer-reviewed thing, and the manager of another team said, that’s not a team, that’s like another sub-organization, because there were so many of us.
But we just, so we could see how it was.
People could see.
They didn’t understand it, because they hadn’t, you know, they didn’t fit with their hierarchical way of thinking, but it, yeah.
So picking the right words.
Like, this is a very consulting thing, right?
Like, I spent half my life as a consultant, not scaring people by using the wrong words.
So just as a remark, because I think this is a very different approach to something very similar.
So I did a conversation with Fred George, like 10 years ago, about developer anarchy.
And he basically sticked to that name, like he would really call a developer anarchy.
And in that conversation, he said he was like a hand grenade that was thrown inside the development organization.
And one of the rules was that no one would, everyone had to write code.
So there would be no one who wouldn’t write code, which is quite harsh.
I’m not sure whether I would feel comfortable with in such an organization.
And then things, like, changed dramatically, and that is what he was hired for, like to do that fundamental change, which means that before that, everything was really broken, and he was asked to change that.
So if you have that kind of position, and if you have that kind of opportunity, there is a different way of doing it.
It’s just that, well, you have to be, you have to have these kinds of circumstances.
Fred George, by the way, is one of the original sort of people who coined the term microservices with Adrian Cockroft from Netflix and your colleague, James Lewis.
So these seems to be like the three original people who came up with that.
And if you speak to these people, because yeah, Adrian Cockroft, I followed for a long time, because when my first job was at Sun Microsystems, which could have been described as, I’ve described, I was speaking to someone and they said, oh, Sun was the original anarchistic organization, which was interesting, because I didn’t know it, it just felt like chaos when I was there.
This is before the dot com bust.
But he was there, and then he went to eBay, and then he went to Netflix and all these kind of things.
But that kind of mindset, whatever you call it, and James has got it too.
And it’s in the Agile Manifesto, if you read it, there is this kind of implicitly behind the scenes, and it’s an open source, like Daniel Pink, with autonomy, mastery and purpose, which basically could be described as like what you get when you do anarchy, or that’s the benefits of anarchy.
He points out that open source shouldn’t work if we do everything hierarchical and we have to be paid.
But it does work.
So there’s obviously other motivations that go on.
All of these things are very closely orbiting around, or anarchy is orbiting around these things.
It’s just another way of looking at it, which is why I was, I wondered if I took this lens, it was like, if we look at these things through this lens, what do we get?
It’s interesting.
It’s also interesting being for working for Capgemini, where you’re definitely not paid to go in and throw grenades, and then still work.
Sometimes the clients expect us to like go in and tell everyone that they’re idiots, and that they don’t know how to do pair programming.
It’s just different styles, right?
And sometimes it works, like, the art is figuring out what framing of the words and the approach is going to work for the circumstances, I think is the key thing.
So we sort of already have discussed that, I guess, but do you have some additional advice on how to make this work in at your place, I mean, at the place of the listeners or watchers?
Yeah, so this is so I would, number one, I would, I would say be curious, and may hopefully you are if you’re already dialing and listening to this.
And don’t trust me, right?
Because again, I’m aware, I’ve tried to say that this isn’t a utopian, there are complexities, it’s not easy, you don’t get anything for free, there is no one size fits all or anything.
So you do have to do work.
But I’m very enthusiastic about this.
So I’m, you know, I’m maybe overselling it.
So what you should do is, I would encourage you to, to try things, try and experiment and try it just on your own, right?
Just kind of say, or within your team, if you if you’ve got a team of people who you think might be willing to do this, you can pick some, you know, experiments of what you might do.
And typically, what I would do is identify some kind of constraint, which is coming from hierarchy.
And it doesn’t need to be let’s run our entire 98 person team using anarchist principles, right?
It could just be like, let’s allow anyone to make an architectural decision.
That’s a pitch for my book, there’s a 560 page book that I wrote called facilitating software architecture that tells you how to do that.
But it could be like, you know, let’s rotate the technical leadership or let someone you know, instead of when this person goes on holiday, let’s make this person always stand in for them.
Let’s figure out how we can rotate it or, you know, lots of different small little things you could try and then figure out because it’s an experiment.
You don’t just need to do the work, but you need to say this will have succeeded if these things happen.
And then run the experiment or take inspiration from Netflix and remove something you’re like, right?
If we remove this thing, what does it still happen?
Does it get better?
Does it get worse?
And start playing with your org design, like how you organize, that’s basically what org design design is right within your scope of what you control and see what happens.
And it’s really, really interesting.
And that’s how you build if you wanted to build this across your organization, someone would say, yeah, but how is this going to work?
If you could point to what you’ve done, then that’s a good thing.
Which is, by the way, I mean, the entire opposite of just adopting Scrum as it says in the book.
So, final question, what’s, I mean, we are now at the dawn of the age of AI, so what’s the impact of AI on this?
I think, so I think, I think because I’m very health, hopefully healthfully skeptical about AI.
I mean, interestingly, in 1997, my final year psychology project was to write some neural networks and stuff and basically model word meaning, which now is very prescient.
So I’m very interested in what this could do.
I think it could be, we could use it in two different ways.
As an architect, but also someone who’s interested in org design, and I think this is what, what anarchy preaches.
And maybe this means that LLMs are going to drive something good.
LLMs are very powerful if we are conscious of what we are asking them to do, and we’re critical of what they give us.
So I think Simon Wardley says somewhere, it’s like, you know, if you take, if you use AI to give you options, Gregor Hope definitely talks about this, right?
You know, like architects sell options.
If you use them to create options and think around subjects, et cetera, et cetera, et cetera, for you and kind of help you, help you do things, you could do experiments with like using LL, AI and figure out how you can integrate LLMs into your workflow and all these different things.
As long as you are skeptical and as long as you maintained, you’re clear about what you’re giving up and where your autonomy is and what you’re deciding to do and what you’re not deciding to do.
I think anarchy is good because at an organizational level, it makes, anarchy says, think about what the organization is.
Think about what power you have, what power you don’t have, how the structure is serving you and not serving you.
Same thing for architecture, right?
Architectural decision-making still should be your decision or the code, the decision you do to make code look one way or another, that’s still your responsibility irrespective of whether that LLM does it or not.
Consciousness about that.
So you get the LLM to maybe do the typing and generate 20 different options, but you’re still the one selecting and driving and focusing.
So I think hopefully the additional consciousness of this stuff, being aware of it is good.
And it means we’ll get the best out of these tools.
If we don’t, and we just go, redesign my organization, I need a new door model, that will be carnage.
So hopefully it’s good.
Okay.
Thanks a lot for the interesting discussions and for answering all the questions.
I will add links to the article that you did on Martin Frohler’s page about scaling architecture and also to your book, Facilitating Software Architecture, and also to your slides from the Agile Meets Architecture conference.
So thanks a lot again.
Have a great weekend and talk to you soon.
Yeah.
Thanks, Eberhard.
Thanks, everyone else for joining.