# Anarchistic Org Design for Software Teams

**Podcast:** Software Architektur im Stream
**Published:** 2026-04-10

## Transcript

So, willkommen everybody to another episode of Airsoft Architecture on Stream.
This time with Andrew and we are going to talk about Anarchy.
So, before we actually start, a short shout out to Azure Meets Architecture.
So, this was supposed to be an episode that we should have done before Azure Meets Architecture to promote the event.
Wir haben nicht das geschafft, aber jetzt ist es ein post-eventes Stream über die Subjekte, die du geöffnetstablet hast, Erdermitsarchitektur.
So, danke Erdermitsarchitektur für uns zusammenzubringen.
Vorher, können Sie ein paar Worte über dich, Andrew?
Ja, danke, Eberhard.
So, ja, ich bin Andrew Harmel-Loh.
Ich bin, wie es auf der Schreie sagt, ich bin der Autor von O'Reilly's Facilitating Software Architecture, aber ich bin also, mein Tag ist als ein Direktor an Thoris UK.
So ich war ein Technical Principal.
Ich habe jetzt schon ein Direktor, aber ich bin eigentlich ein Consultant, die geht und hilft, dass Unternehmen, die sich vielleicht auch ein Verständnis zu lösen, hoffentlich, kompliziertes Architektur und Org Design und Org, das Kind of Problem.
So das ist das, was ich.
Ja, und ich war wirklich glücklich, dass diese Episode, weil wir sprechen über Anarchy und wie es vielleicht etwas, was wir können, um zu software development zu tun.
Und ich denke, diese relation zwischen dem, wie wir soziale und auch wie wir soziale Projekte haben, ist etwas, was ich immer interessant finde, weil, du hast, am Ende der Tag, es immer über die Leute zusammenarbeiten, auf verschiedene Schäden.
Aber es sollte sich ein paar Sprachen.
So, ich bin wirklich glücklich, dass das.
So, um, let's start off with sort of the more or less obvious question.
So, um, what is anarchy actually?
So, uh, at least in, in German, there is this, you know, chaos and anarchy.
It's almost like those are synonyms and, um, I'm not sure you have.
So, so what is the, the definition?
So it's a good point.
Can you move your, your microphone a little bit?
Sure.
Yep.
Hello.
Is that better?
Yeah, good.
Um, Ja, es ist ein guter Frage.
In fact, es ist ein guter Frage.
So, da sind zwei meanings zu Anarchie und es kind of depends auf deinem Standpunkt.
So, eine ist, wenn du es in verschiedenen Dictioniken und Dinge betrachten, ist das Definition, die eine Stative Disorder ist.
Ich habe das Stative Disorder, das ist, wie es ein Synonym ist, und es ist mit der Absenzierung, oder Non-Recognition von Autorität.
So, das ist eine Sache.
Der zweite Definition, die ich in die Frage ist, wie du gesagt hast, Eberhard, ist es die Fakt, dass es eine Organisation ist, aber es ist ein Anarchistische Organisation, also es nicht so eine centralized, fixe, hierarchische Struktur ist, und instead ist es eine Voluntary, selbst-organized Struktur, die ich denke ist sehr close zu Software.
Vielleicht ist es nicht wie wir es, aber es ist wie wir es, wie wir es machen.
Das ist das, was ich sehr interessiert.
Das ist die Anarchie, ich bin interessiert.
Es ist selbstorganisation und die Struktur, die ausgesucht, das alles ausgesucht.
Sehr interessant.
So, es ist Voluntary, ich denke.
Das ist eine der Hauptsache.
Ist es eine andere Aspekte?
Es gibt vier, die ich jetzt nicht mehr so remember.
Es ist Voluntary, es ist Short-Lived, das ich finde, ist wirklich interessant.
Vielleicht können wir das auch mal.
Es ist...
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 organisational 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.
Und es scales, aber es geht nicht wie wir denken.
So das, wiederum, ist ein sehr interessantes Ding.
Und wiederum, diese sind ja ich bin interessiert, weil wir über die Frage, wir über die Software, wir wissen, dass unsere Software folgt, unsere humanen organisational structures, based auf Conway's Law und all diese Sachen.
So das ist, ich habe, da sind viele Dinge in der Anarchist-Literature, die vielleicht geben uns clues, wie sie passieren, wie sie für uns tun, oder wie sie nicht funktionieren, etc.
Das ist interessant.
So, vielleicht...
One of the questions is, what is wrong with other organizations?
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.
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...
We've 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.
Und dann wird es in 17 layers von Architektur-Review-Boards und Architektur-You've never even gehört von einer anderen Parten der Organisation.
Oder Sie denken, dass Sie das kann, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie können, Sie Und yet, du look at deine organisation und du denkst, es fühlt sich nicht so.
Und die, zu mir, sind die Symptoms der Other Mindset.
Oder nicht Other Mindset.
Es gibt eine predominant model von wie wir organisieren und strukturieren groups von Menschen.
Und es ist ein hierarchisch, top-down model, die hat come von...
von einem bestimmten, you know, historischen Background.
Aber jetzt scheint es die einzige Art, die wir denken über Dinge, wenn man ein Unternehmen denkt.
Wenn man ein Unternehmen denkt, dann wird man ein Hierarchal oder ein Chartier und all diese Dinge.
Und zu sehen, dass es da waren Alternativen und dass eine von den Alternativen Anarchen war, eine Art anarchie und es hat eine sette Patterns und Dinge, das war was sehr interessant.
Es ist mir, was die Alternative Ways von diesen Dingen?
So would you argue that there is a contradiction between a hierarchical organisation and a self-organising organisation?
Yes, I think I would.
I think so.
So 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, kind of layers of...
Gruppings of people, like teams effectively, right?
So in an anarchistic organisation, 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 organise along two different kind of...
When you let things self-organise...
They will organize along two different ways.
They'll organize horizontally, whereas the problem will split up into pieces, right?
Bounded context, so 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.
Und sie haben Kontrolle über ihre Piste, aber vielleicht nicht Kontrolle über andere Dinge.
Du hast dann auch andere Teams, die vielleicht weniger Kontrolle, weniger Hand-on mit der Day-to-Day.
So sie sind nicht schreiben, sie sind nicht schreiben, oder was sie.
Aber ihr Job ist zu denken strategisch, weiter aus, denken über wie Teams might Co-ordinieren, wöreng über ob ob drei Teams doing the same thing ist ein gut oder ein bades Ding.
Vielleicht ist es ein guter Ding, weil sie haben diese Strategie, wo sie wollen verschiedene Teams zu tun, andere Unternehmen oder Organisationen nicht.
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 that if I am above you, I tell you what to do.
That's kind of the big thing, right?
And so therefore...
You only have autonomy at your own level.
If you need to go higher up, then you can't.
And that to me was very interesting.
Trond Hjortland 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 what I've realized 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 Trond's Architecture, the military was Er ist die originalen, hierarchische Organisation.
Und obwohl das natürlich ist, ist das Thema Autonomist-Teams in einem Weise, also presentes da, weil, in Deutschland, oder in der Germanen Army, da ist dieses Thema Auftragstaktik, Mission-Type-Taktik, ich glaube, es ist in Englisch, wo man sich das Thema nicht in order to do this, sondern eher zu sprechen, was sie mit dem Plan zu erreichen.
Und das ist ein Level von Selbstorganisation, in einem Weg, das heißt, dass in diese Strictly Hierarchical Organisationen, es gibt Selbstorganisation.
Ich denke, das ist ein wichtiges Punkt, das ist, warum ich es darüber hinausgekommen.
Weil du würde sagen, dass die Militär ist, dass es mindestens über die Formen des Orders ist.
Aber wirklich, es sollte nicht sein.
Und es ist interessant, wie sie Menschen über das auch an scale educate.
Ja, es ist sehr interessant.
Und du bist right, die Militär figured es aus.
Denn als es kam aus Napoleonic times, things became so dynamisch.
Und in der Militär, wenn es funktioniert, das bedeutet, wir sind alive oder dead.
Die Stakes sind wirklich hoch, das macht Sinn für alle.
They rapidly realise 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 does it say, for disciplining armies, I think in peacetime is maybe the key point.
Bureaucratic record-keeping, tax collection, and I think organising the Catholic Church.
And again, things have changed.
And this is pre-Industrial Revolution, when a big thing wasn't even that big.
Right now we think a small German company might not be very big, but before the Industrial Revolution, companies were way smaller.
Now we have global multinational corporations.
The scale of what is big now is spectacularly big.
So 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, und es wäre toll, und es wäre toll, und es wäre toll, und es wäre toll, und es wäre toll, und es wäre toll, aber es wäre toll, dass Anarchy die Möglichkeit, die Möglichkeit zu participate und zu all diese organisational design und zu organisieren, und zu organisieren, und zu organisieren, und zu organisieren, wie es funktioniert.
Aber es gibt alle die Möglichkeit, oder eher wie es jemanden die Möglichkeit gibt.
Was es tut, ist, dass es, dass es ein Organisation, Und da wird ein bestimmtes Funktionen, in einem Organisation, wie jemand kann in das Organisation sein.
Das heißt, das heißt, dass jeder muss, das ich finde, ist sehr interessant.
So, du wirst enden, typically, in einem Software Organisation, die ich am Fokus und der Most knowledgeable bin, du wirst enden mit Teams, das sind und Schipping Software.
Und die Teams werden noch immer noch haben, wo sie noch haben, wo sie Leute zu tun haben.
Und das Teams werden noch immer noch haben, wo sie Leute zu tun haben.
So most of this stuff, most of the things, 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.
Weil, 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 that 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.
Und das ist die key.
Es lässt sich die Leute, die alle diese Sachen zu tun.
Und es lässt sie lernen, es lässt sie collaborate, und es gibt sie ein setzter Patterns und Mindset für die ganzen Sachen.
Und das ist die key.
Es ist das, es bedeutet, dass niemand kann participate, aber es nicht mehr alle haben, die man hat.
Und du hast diese typische Dinge.
Was also struck mich, weil ich habe ich mit dem Experimenten mit, mit dem in various organisations, 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 198-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 it was not my favorite job.
And a bunch of other stuff, which...
Wenn niemanden mehr hat es, es hätte sein, weil wir müssen uns dann gewinnen und dann die Leute auf den Weg bringen.
Was mir surprising ist, dass es Leute mit sehr starken opinions auf diese Sachen gab, und sie wirklich wollten es.
Ich war so, okay, cool.
Ich bin still...
Wir haben eine kleine-gültere Version von dieser Adoption.
Wir haben nicht alle Camp Gemini UK, Anarchistik, weil das nicht mehr passiert.
Aber sie wussten wir es wie das in diesem Team.
So I was still the person who was responsible, but I devolved all responsibility.
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 rolls or the glue work.
This stuff becomes more explicit, which again, I think is a good thing.
So maybe there will be people who will be 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 here is, 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?
Das Autonomie und Empowerment, die Netflix culturedeck macht, macht es ein viel mehr enttäusch.
Weil sie sich, okay, cool, ich kann wirklich sein, ich weiß, was ich bin innovativ, und ich weiß, was ich habe die Möglichkeit, aber ich habe die Freiheit, zu lösen.
Das, wenn du es so, das ist ein sehr, das öffnet sich ein viel mehr, das ist ein viel mehr, das ich erwähnte.
Denn nicht jeder hat die same, wie viele Leute einfach nur turnen und schreiben, und schreiben, nöden, Jess.
But other people are like, I really want to approve training requests or something.
So it's very interesting.
Yeah, so what you're basically saying, 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...
So I wouldn't use...
So one key thing, actually, I wouldn't use the word delegate, because delegate's 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.
And 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 devolve, then you're like, I'm giving you the power that comes with this scope to come up with your own solution.
That changes the game.
Delegation is a close but still problematic type thing.
It's like, I've defined the problem, now fix it.
Whereas 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.
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 teams 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.
Yes.
And I mean, the belief that we have is quite fundamental concerning the stable teams.
So can you talk about that contradiction and how it can be resolved?
Yes, it's another great question.
So 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 Der Anarchistische Tradition ist, wenn man all die Geschichte hat, hat man sich schon lange verhängt.
Man kann es sich aus vielen verschiedenen...
Wenn man David Graeber hat, würde man sich schon lange verhängt, etc.
Ich war interessiert in die Faktung, dass wir diese Rule of Thumb haben, wie du sagen, wie lange live Teams, etc.
Und deshalb ist das Ding, was das so etwas ist.
Ich war sehr skeptical, als auch.
Und es gibt zwei...
Und so, was ich 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 organise in a hierarchical structure.
And Goodman and Anarchy points out that that's only one way of doing it, there are others.
Aber als Goodman pointed out, das hierarchische Struktur und die Faktik, die es die einzige, die wir natürlich, in Western societies, wir tenden towards die Faktik, dass ich mich mit meinem Job role identify, und ich bin der 1-2-1 Mapping, und dann mein Progression und mein Wurf als ein Human Being wird, so therefore, mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich und mich Und Anarchy würde sagen, dass das ein bad ist.
Sie würden sagen, als es ihr identifiziert, oder was ihr, ihr Wert in ein Organisation oder ihr Wert als ein Human Being ist, dann wird es ihr, dann wird es ihr, wenn ihr das Rolle gespielt, wenn ihr das Rolle gespielt, wenn ihr das Rolle gespielt habt, oder wenn ihr die besten ist, oder wenn ihr die besten ist, aber ihr die only Person.
Denn eine Sache, die wir in Teams haben, die meist controversial ist, und dann ich gehe into die mehr controversialen Bits.
Wir wissen, dass du ein Buss-Faktor in Teams hast.
Wenn du eine Person wissen, dann ist das schlecht.
Wir wollen das eine Person wissen, dass etwas mehr als eine Person wissen.
Wir wollen mehr als eine Person wissen, dass das eine Person wissen.
Das Person ist die Swamp Guide in die Big Ball of Mud.
Sie sind Alberto Brandolini, die Dungeon Master ist.
Wir wissen, dass das ist.
Das ist die Antipattern der Person, die sich in der Firma über 20 Jahre alt ist.
Sie sind die nur Person, die weiß, wie die Code verändern.
Sie sind die Schema für die Database, die Sie sprechen.
Sie werden die Gatekeeper.
Das ist das nicht mehr moving.
Das ist schlecht.
Du willst das etwas zu sein.
Wenn du das Person nicht mehr verletzt, dann gibt es einen Anzettung für das Einzettung.
Das ist eine andere Sache, die ich nicht überlebt, ist, dass ich nicht genug darüber sprechen.
Ich glaube, du willst jemanden zu sein.
Du willst so viel change, dass niemanden immer für 10 Minuten bleibt und sie nicht mehr werden.
Du willst sie nicht mehr werden.
Du willst sie nicht mehr werden.
Du willst sie nicht mehr werden.
Du willst sie nicht mehr werden.
Du willst sie nicht mehr werden.
Du willst sie nicht mehr werden.
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 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 fail 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.
Ich denke, dass ich etwas nicht mehr als eine Schlechtelung habe, ist gut.
Die letzte Sache, die ich habe, die wirklich interessant ist, und das wieder kommt aus einer anderen Art, einer anarchistisch Art, in der UK, ich glaube, in Deutschland, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, in der Nächsten, die Quakers sind sehr non-hierarchisch.
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'll 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 it's bad.
Wenn wir uns die Dinge ändern, wir uns die Leute zu bauen, aber wir wollen nicht auf die Leute, dann ist das wie ich es.
Es ist ein Bounce.
Es ist nicht wie, dass es sich Leute moving all die Zeit ist.
Das ist schlecht, aber es ist ja.
So, again, es scheint zu sein, dass es um die Ruhigung, also ich würde supposedst, um die Ruhigung zu ändern und zu ändern, um die Bustfaktor, die du gesagt hast, das ist die Nr.
of die Leute, die ...
Ich würde mich nicht mehr zurückkommen.
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 Pjörtland 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, Wenn du die Unit als ein Team hast, dann ist es anders.
Die Team hat nur mehr Menschen in den und sie haben die Möglichkeiten.
Das ist ein sehr small mentaler Schiff, aber es machte eine große Unterschiede, wie du über die Dinge tun.
Und dann wird die Team veröffentlichung.
Es ist sehr interessant.
Ja, und die Buss Faktor, was die Nummer von Leuten, die du von den Team auslösst, um die Dinge zu holen.
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...
Es ist wichtig, weil ich habe diese strange occurrence, wo die Leute sagen, okay, so in unserer Team, wenn eine Person auf eine vacation geht, ist es unmöglich für die anderen Person zu tun.
Und dann ist es, dass das eine piece von Code oder sogar das eine Systeme, das eine Person arbeitet, und das ist wie die Organe in generell.
Und was sie sehen ist, ist die Lösung zu schreiben, ist die Dokumentation.
Ich finde es gut, weil ich es so gut, wie wir zusammenarbeiten, zusammenarbeiten und so weiter.
Und sie sind so, dass sie sich nicht mehr, dass sie eine Dokumentation haben und dann es ist gut.
Und ich weiß, es ist ein basicer Misunderstand.
Es scheint, es ist ein basicer Misunderstand.
Es ist ein bisschen, wie es sich an das Besteuerung an, wie es funktioniert und wie es funktioniert.
Es ist true.
Wenn Leute interessiert, Heidi Helfand's Dynamic Re-Teaming, die es über das ganze Buch, die ist wirklich, wirklich gut.
first realized that long-lived teams are good, but it's a team, not a long-lived human being doing a job, like you just said, Epphardt.
So Heidi's got loads of information in this kind of stuff, which is good.
And we also had this episode from Adramitz Architecture with Svetlana and Priscilla, where they also talked about how they do this dynamic reteaming and so on.
Das ist sehr interessant, weil es sehr anders aus dem was Scrums über die fünf, oder sieben, plus minus zwei und dann, dann, du kannst du die Team und dann, du kannst es bleiben.
Ja, genau.
Okay.
Und die andere Charakteristik, die du hast, ist, wie die Organisation ist, ist es so, ich assume, es ist ein Small Team, das ist wahrscheinlich das Magic-Number-Sieben-Präsident.
Und wir alle wissen, dass es so viel zu tun kann mit 7 Leuten.
So, und, you know, oft viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, viele, 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...
Wir sprechen über socio-technical systems, aber da ist ein Bunch of Arbeit, ich kann nicht mehr ihre Namen, ich kann nicht mehr die Namen, die Emmerys, die specifically sprechen über socio-technical approaches zu larger-scale organisation design.
Und das hat kind of influenced Teams Apologies und all of das kind of stuff.
Da sind es, was wir über das kind of stuff, um zu figure out, was...
Wenn wir die Basic Teams haben, wir haben verschiedene Teams und wir wollen sie zu beherenten und Autonomous und all diese Sachen, wir bekommen das.
Aber dann gibt es eine andere Reihe von Teams oder eine andere Team, die haben eine andere Scope.
STS gibt es, eine solche, eine ist called Searching, die wir hier haben.
Und es war eine andere Talk, ich kann nicht remember, was es war, aber es war ein Talk, Agile Meets Architecture, die ich sehr excited war.
The presenters were sharing an example of how they'd used Team Topology's 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, 7 plus or minus 2.
Und wir denken das immer nochmals.
Was wir vergessen, ist es, in meine circumstances, dass das Sinn macht?
Das war ein number, das war die Scrum-Pepäin, oder die XP-Päinigen.
Ich denke, es ist Scrum.
Und eine bestimmte Sache mit einem bestimmten Set-Diviseln und eine bestimmte Stadte-Software-At-The-Time, etc.
Wenn du das eine andere Prinzipien betreffend ist, dass die Gruppen muss funktionieren.
Wenn du das Test hast, ist das Grupp Funktioniert, ist es etwas, dass es etwas, dann vielleicht die Gruppe kann es smaller.
Vielleicht die Gruppe kann es larger.
Als ich das Checken, dass die Gruppe ist, was es tun, was es tun, und es serving eine purpose zu den overallen Direktur und Ziel des Organisationen.
Und wenn du das hast, dann sind diese Teams vielleicht smaller, sie vielleicht vielleicht larger.
Und ich denke...
Das ist eine interessante Sache.
Wie wissen wir, was die richtige Size ist?
Das ist eine andere Sache, die ich habe gelernt.
Ich habe ein paar Leute, die ich an Netflix habe.
Und eine Sache, die in den Buch Netflix ist, ist, dass ich mich sehr interessiert.
Das ist ein Thema, was ich in den Buch.
Und das ist, was ich in den Buch.
Und das ist, was ich in den Buch.
Und das ist, was ich in den Buch.
Und das ist, was ich in den Buch.
Ich habe sehr interessiert in Human Resource Management und HR.
Ich weiß nicht, was es in Deutschland.
Es ist ja, Human Resources in the UK 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.
And I thought that cannot possibly be true.
No one would trust people like that.
And 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.
We 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.
And they will be making those decisions without a policy.
They'll just decide those things.
And so that's really interesting.
The experimenting was removing things, I think, again, is something we don't do.
And it's very fundamentally agile, right?
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.
Oder wenn ein Job ist, dann werden wir das Person nicht mehr tun.
Wir versuchen nicht zu vermeiden, die Dinge zu vermeiden.
Und ich denke, wenn man mit dem Experimenten mit Removal ist, und vielleicht ist es ein Baden-Decision, vielleicht ist es ein Disaster, und du hast das Person wieder einmal wieder einmal.
Aber du kannst experimentieren.
Und ich denke, das ist sehr...
Weil wir nicht...
Human Systems Organisationen sind complex und adaptiv, richtig?
Das ist warum es Patterns of Anarchy ist, als ob das Org Chart zeigt, wie es eine Anarchistische Organisation gibt.
Du musst experimentieren und finden Ihre Anarchistische System, das ist warum es hart ist, aber warum ich es so spannend ist, wenn du es anstrengst, wenn du es anstrengst, wenn du es anstrengst.
Ich habe eine Message von Martina von unserer Stream Team und sie war...
Sie war es, die du wahrscheinlich referieren zu ist, die New Rules book.
Das ist es.
Das ist es.
Und die Kultur der Reinvention.
Ja.
Und wir sollten wahrscheinlich mention, dass Netflix originally war ein Shop, das war auf DVDs, right?
Ja.
Und wie bei Mail.
Und es emerged into that stream.
Ja, und es hat ihre own, like everything, right?
Das ist das, was das interessant ist, über Netflix.
Sie haben, wie alle Unternehmen, haben viele IBM-Server in ein paar Daten, die sie haben.
Sie waren diejenigen, die die Leute zu移ren, die sie zu移ren.
Sie haben diejenigen, die die Leute zu移ren, die sie zu移ren.
Sie haben sich die große Entscheidungen, die sich zu移ren, und wenn du eine andere, die Powerful ist, die auch von Patty McCord, die Patty McCord ist, die HR-Direktor, die ist all über ihre Zeit, bei Netflix.
Und eine andere Sache, würde ich sagen, Bruce Ecclteren, der sich das immer an, ich weiß, dass ich alles sagen, dass ich alles empärgerlich ist, aber das bedeutet, dass ich das alles machen könnte, wie es die ganze Unternehmen gibt, die die ganze Unternehmen gibt, wie es die ganze Unternehmen gibt, und die Unternehmen gibt.
Surely, nur die CEO kann das Gefühl machen.
So, Reed Hastings.
Und was interessant ist, da sind viele viele Ereignisse, und sie sind in den Buch.
Obwohl, Reed Hastings macht diese große Entscheidungen.
Manchmal wird er es falsch, und sie werden es falsch.
Und sie werden es wieder auf die Mechanismen, also auf Organisieren, für organisiertes Learning und nicht bringen in eine Kultur der Angst, weil man sich nicht zu experimentieren.
Aber auch, da sind viele, die nicht auf der top der Hierarchie haben, haben sich gemacht.
Und da ist ein klarer Weg, der sich auf die Autonomie und auf die Autonomie für Dinge zu tun.
So 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?
The patterns would manifest in different ways in different cultures because the culture has an impact on 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 a small...
And you basically made the point that it's rather about not having too many rules.
From the slides, I took a note about Emergent Federation.
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...
haben weniger Routes, also auf der globalen Ebeneffektion.
Emergent Federation ist anders.
Ist das auch etwas, was das hilft?
Ja, ja, ja.
So, exactly.
Emergent Federation ist...
Es ist ein bisschen über-Complicated und vielleicht ist es da, wo die Anarchie bit wird ein bisschen theoretisch.
Und es ist...
A lot of anarchist theoretisch...
Thinkers preferrätig zu denken über die small groups und die Dinge, die einfach nur in der 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, 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 this is 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 jobs to be done, but with a transaction outside of a technical layer, 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 a one-person or two-person team to 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, 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.
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 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 social technical systems.
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 organisation and what is its purpose?
In a hierarchical organisation, we devolve the responsibility for that to the executives, the CTO, the CEO, and the board of directors and things.
And this is what I think is interesting as well.
Even though we devolve it responsibility to them, Every single person has an opinion as to how the organisation should be structured, right?
So if you asked me, I could have redesigned every client I'd ever worked for.
And it might not be good, but it's like, here's 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, you know, we need to balance running fast and breaking things with customer service and maintaining our credibility and all this kind of stuff.
And it's, 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 it sounds in a way like if you throw the right problem at the organisation, 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, there's another thing that this is kind of in the book, but it disappeared from the book because the book is...
ist, meine Editora Rita, wie es ein love letter zu zwei anderen authors.
Es ist ein love letter zu Christopher Alexander und es ist ein love letter zu Don Reinertsen.
Don Reinertsen wrote, die Principles of Product Development Flow, die ist complex, adaptiv, Produkt-Development-Systems.
Und dann, obviously, Christopher Alexander ist wo wir die Idee des Design Patterns von.
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, etc.
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.
Und wieder, es ist etwas wir nicht über.
Und wir wissen in Code, wenn es geht, weil wir mit dem Code nicht gut sind, weil wir mit dem Code nicht gut sind.
Die Last key point ist, ich habe mich gefragt, weil ich mich interessiert, wenn sie so schnell, wie sie nicht mehr haben, die Grunde ist, sie sind immer re-riteren Mikroservices.
Ich weiß nicht, aber das war zehn oder acht Jahre alt.
So sie wussten, was die Mikroservices needed.
Sie wussten, was sie raus und sie wussten, weil sie sie raus, weil sie sie raus, weil sie sie lieben.
So the organization, the business need would still be there, but they'd just rewrite the code.
And they would rewrite it based on this new information from what this service now needed to do.
They'd written it so that it would scale to like 100 TPS, and now it needed to scale to 200 TPS or 1,000 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.
Das ist auch nicht über die Lipps-Service zu einer organisationalen Idee, sondern um die Organisation zu machen.
Das alles ist ziemlich überzeugt.
Du hast den Beispiel von Netflix.
Obviamente, das ist ein sehr erfolgreicher Unternehmen.
Aber ich würde sagen, wenn du manche, wenn du manche, wenn du manche, wenn du manche, wenn du manche, wenn du manche, wenn du manche, wenn du manche, Job description, more or less, is to control things.
Yep.
And also, I mean, that's a problem that we probably have in our industry.
So if someone outsources the development of some software, a piece of software to some company, then they are also quite well-incentified to control this stuff because, you know, you need to keep an eye on it.
It costs a lot of money.
und du musst, um die Projekte zu sehen, um das wirklich funktioniert, weil es sehr wichtig ist.
Und da ist ein sehr guter Grund, warum du das tun soll.
Ich würde sagen, wenn du ein Manager bist, wenn du ein Shareholder bist, wenn du ein Higher-Up in der Traditioner Hierarchie bist, dein Job ist zu kontrollieren.
Wenn du eine Anarchie machen soll, dann ist es, wenn du ein Job bist.
Und wenn du ein Customer für ein Outsourcing bist, then it takes a lot of trust to give up control.
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 by it.
But calling things self-organizing, self-managing, self-sustaining, that feels like buzzwords that they like.
Oder vielleicht sie oder nicht.
Aber du bist sehr richtig.
Die whole, weil der dominanz der hierarchischen Sache, alle, die in den senioren, in den hierarke, wird er bei der Regen, die sie haben, die sie in den Hierarke, ob sie oder nicht.
Some people do.
Many, in mein Erfahrung, don't.
Aber sie machen es irgendwie, weil das ist wie man mehr Geld und mehr Geld und mehr Geld und mehr Geld.
Es geht darum, dass es ein Mensch zu sagen, wir werden es anders machen.
Und Trust ist es genau das Ding.
So, lots of...
Some people might be thinking, this sounds very much like Trust-Driven Organisations, und Trust Organisations, und Teal Organisations.
Es geht darum, lots of my inspiration came from Teal Organisations.
Und 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 Organisations by Frederic Lelou.
Was interessant ist, und ich glaube, das ist die letzte chapter von meinem Buch, ist es, dass wir alle wissen, dass die Weg für eine Agile Transformation zu verlieren ist, dass es zu machen, die Weg für eine DevOps Transformation zu verlieren ist, dass es zu machen, die Weg für eine Produkt-Management Transformation zu verlieren ist, dass es zu machen, und du kannst das in der Smallen.
Und das ist das was ich in meine anderen Talks.
Wie kann ich incrementally adopt this?
Vielleicht secretly.
People used to say, es wäre toll, wenn Scala wäre, aber es wäre toll, aber es wäre toll, dass ich nicht so, dass ich ein Schala nicht so vieles zu verstehen war.
Ich habe nicht so, dass ich ein Schala nicht so, aber ich kann es für einen Test, weil ich es nicht so, was ihr Tests sind.
Du kannst diese individuellen anarchistisch-weise-weise-of-thinking- und sehen, dass es einfach machte Dinge besser.
Du kannst das, das kann ich scale.
Ich war Glück, at Capgemini.
Aber ich war explicit über das, als ich das Team hatte, als der Manager von einem 98-person Team hatte, weil ich mich nicht mehr so machen, dass ich nicht mehr so machen, was ich nicht mehr so machen, was ich nicht mehr so machen.
Capgemini hat keine Inklination, so ich mich nicht mehr so machen.
Und ich habe gesagt, ich habe es explicitly gesagt, all your expectations, mich und das Team und das Team nicht verändert.
So die externalität, wie wir uns vorstellen, das outside world nicht verändert.
Internally, wir werden nicht verändert.
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 of, 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, you know, software departments and the rest of organizations because they know we think differently because the world works.
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?
Aber die Unternehmen nicht mehr.
Sie waren einfach, dass sie sich sehr gut und gut und gut und gut und gut und gut und gut.
Und die Absenzen von Illness waren, etc.
Wir waren einfach, weil wir einfach mehr machen.
Ich würde es nicht sagen, wie wir es tun, aber es sollte ein mehr responsive, mehr best-fittes Organisation sein, um zu reagieren und reagieren, besonders in der Welt von LLM und jetzt.
Du willst etwas, das kann reagieren und reagieren.
In der Kursse dieser Gespräche, eine neue Technologie, wie Claude Code 73, hat sich wohl gebrochen.
Und wir haben alle unsere Leben verändert.
So...
Was das anerthiniert?
Was du anerthiniert anerthiniert?
Was du anerthiniert?
Ich meine, da hat sich ein Name für das.
Ich denke, ich habe es nicht anerthiniert.
Ich habe es nicht anerthiniert.
Es ist interessant.
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.
What was interesting was they were aware of Leloo.
They were aware of the theories of organizational design.
They were there.
Yeah, exactly, right?
Because this is the thing.
This is all about their, 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, this is hierarchy is how we organize.
This is how we structure ourselves.
So they were like, 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, the performance management process.
Der Manager von einem anderen Team, wenn ich in den 98en Team kam, kam ich an, das nicht ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team, das ist ein Team Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben, Sie haben Und er hat sich die Namen zu sagen, wie er wirklich ein Developer Anarchy nennt.
Und in der Gespräche, er hat sich gesagt, er war ein Handgranate, das war in der Entwicklung Organisation.
Und eine der Regeln war, dass jeder hat einen Schweren, so es gibt niemanden, die nicht schreiben, was ist ziemlich hart.
Ich bin nicht sicher, dass ich mich mit einer solchen Organisation fühle mich in.
then things changed dramatically.
And that is what he was hired for, 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 have these kinds of circumstances.
Claire George, by the way, is one of the original sort of people who coined the term microservices with Adrian Cockcroft from Netflix and your colleague James Lewis.
So these seem to be like the three original people who came up with that idea.
And if you speak to these people, because yeah, Adrian Cockcroft I've followed for a long time because my first job was at Sun Microsystems, which could have been described as...
Described?
Ich war zu jemandem und sie sagte, Oh, Sun war der Original Anarchistische Organisation, das war interessant, weil ich nicht wusste, es war wie Chaos, wenn ich da war.
Das ist bevor der .com bust.
Aber er war da, dann er war zu Ebay, dann er war zu Netflix und all diese Dinge.
Aber das Kindes-Mindset, whatever you call it, und James hat es auch, und es ist in der Agile Manifesto, wenn du es, da ist dieses Kindes-Implicit-Behind-The-Scenes, und es ist in Open Source.
Daniel Pink mit Autonomy, Mastery und Purpose, die eigentlich könnte man beides als was man get, wenn man anarchy macht.
Er hat sich die Benefits-Amerke.
Er hat sich das Open Source nicht funktioniert, wenn wir alles hierarchisch machen können, aber es funktioniert.
Also gibt es natürlich andere Motivations-Amerke.
All diese Dinge sind sehr closely orbiting, oder Anarchie ist orbiting around diese Dinge.
Das ist einfach eine Art Art, die ich mir auswählen, ist es eine Art, die ich mir auswählen.
Ich habe mich gefragt, wenn ich das Lens...
Wenn wir diese Dinge durch diese Lens sehen, was wir bekommen?
Es ist interessant.
Es ist auch interessant, wenn wir für Capgemini arbeiten, wo du nicht mehr bezahlen bist, und dann in ThoughtWorks, manchmal die Clients expect uns zu sagen, und sagen alle, dass sie sie nicht mehr als Pair Programme haben.
Es ist einfach nur unterschiedlich, und es ist einfach nur unterschiedlich.
Und es ist einfach, die Art ist, was die Sprache der Sprache der Sprache ist, was die Sprache der Sprache ist, was die Sprache der Sprache ist.
Ja.
So, wir haben schon schon schon schon erwähnt, aber du hast du noch etwas additionaler Wissen auf wie das funktioniert?
Ich meine, auf der Platz der Listener?
Ja, so ich würde, number one, ich würde sagen, be curious.
Und hoffentlich, du bist, wenn du schon schon schon schon mal aufklärtst.
Und nicht, du bist mir, weil ich, Ich habe versucht, dass das nicht ein Utopien ist.
Es ist nicht easy.
Du hast nichts für free.
Du hast keine One-Size-Fits-All.
Du hast es nicht.
Du hast es nicht.
Aber ich bin sehr enthäßig über das.
Ich werde über-Sellingen.
Ich würde empfehlen Sie, zu versuchen, zu versuchen, an experimentieren.
Und versuchen, es auf deinem eigenen.
Oder in deinem Team, wenn du ein Team hast, du kannst du das.
Du kannst du ein Experimenten.
Typically, what I would do is identify some kind of constraint which is coming from hierarchy.
It doesn't need to be, let's run our entire 98-person team using anarchist principles.
It could just be, let's allow anyone to make an architectural decision.
That's a pitch from 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...
Let's rotate the technical leadership.
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 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.
Was ist das noch passiert?
Was ist das noch passiert?
Und start mit deinem Org Design, wie du organisieren.
Das ist das, was Org Design ist, in der scope des Wissen, und sehen was.
Und es ist wirklich, wirklich interessant.
Und das ist wie du, wenn du das überwindenst.
Wenn du das überwindenst, würde ich das überwinden, würde ich sagen, wie ist das?
Wenn du das überwindenst, würde ich sagen, wenn du das überwindenst, dann würde ich das gut machen.
Das ist ein guter Ding.
Das ist das, was ich würde sagen.
Which is, by the way, the entire opposite of just adopting Scrum, as it says in the book.
Yep.
And therefore, I like it.
Don't do a big bank.
So, final question.
I mean, we are now at the dawns of the age of AI.
So, what's the impact of AI on this?
I think, because I'm very hopefully healthily skeptical about AI.
I mean, interestingly, in 1997, Mein finaler psychology project war es zu schreiben, um, write, um, neural networks and stuff and, 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 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 do things.
You could do experiments with using 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...
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 decision you do to make code look one way or another.
That's still your responsibility, irrespective of whether 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 org model, that'll be carnage, I would think.
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 Foller'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.
Ja, vielen Dank.