# Aligning Software Architecture with Organizational Structure

**Podcast:** Software Architektur im Stream
**Published:** 2026-02-13

## Transcript

Welcome to this Agile Meets Architecture Pre-event.
We're really glad you're here.
If you haven't heard of Agile Mits Architecture yet, it's the conference that brings together agile software development and software architecture with thought leaders from both worlds.
We hope today gives you a taste of the talks, speakers and vibes.
The full schedule is out for a while, and earlier tickets end tomorrow.
Welcome to this event with Eberhard.
Everhardt, over to you.
Yeah, thanks a lot.
And thanks a lot for having me.
So my name is Iberhard.
I'm from with uh SVECTLAP.
We are a consultancy, and uh we have um people who actually make the impact in uh projects, and uh I'm concerned with uh software architecture primarily, and I will talk about architecture and organization.
Um to start off, like a fundamental problem of architecture, my opinion, is to come up with modules.
And if you think about that, uh modules is actually uh a term and a concept that is slightly older than I am.
So it's from uh the beginning of the 70s, um, and there is the famous paper by PANAS that talks about information distribution aspect of design methodologies.
And the point here is that already that paper, which is like 50 years ago, uh says that software architecture is about controlling the flow of information and uh which is a social problem, right?
The flow of information is a social problem.
So there's a strong relation between those two.
And the information distribution aspects basically say modules can be changed freely if they still meet the expectations from other modules, or I should probably rather say from other developers.
Uh and also other modules will use all the information about the module.
And therefore, the concept of information hiding is invented in that paper, which says, well, you will hide as much information as possible, because if less information leaks to other modules, then the result is that modules are easier to change because there is less information that other modules rely on, and there is more stuff that you can change because there is just less that leaks out.
This is a fundamental concept and it's applicable on different levels in software texture.
So if you look at a class, it has instance variables on the inside.
That's hidden information, like uh the balance of an account.
And then there is uh the public methods, um, like tell me the uh amount that is on that bank account.
And if you apply this principle of information hiding, then the data can be changed.
So the bank account can either store the balance as a money amount, or it can calculate the balance from all the transfers on the fly.
So it means that you can actually change the implementation quite freely because um it is hidden from the outside world and access is only allowed by public methods.
This also applies to cost-grained modules or microservices.
Then the data would be in the database.
There would be an interface, and you can actually use the same example.
So if there is a microservice that deals with bank accounts, you can have an interface that allows you uh to tell the um the uh balance of an account, and you can either calculate that on the fly with all the transfers stored in the database, or the alternative would be that you just store the balance in the database, so either the transfers or the balance.
And others won't notice whether if you change that.
So modules have a data model inside and an interface.
And I did an episode about that in software architecture in stream.
I'm afraid it's a German one.
You can uh look it up and take a look at it.
It's actually an old episode because it's a very fundamental concept, and I explain it in more detail there.
Um, which leads to the question so, what is software uh development all about?
Well, software development is about developing software in iterations, and that's sort of obviously true.
But there are other things that um are also concerned with software development.
So there is the development organization, there are the teams, the people who actually develop the software, and there is the domain and the user, and all of them change.
So the development uh organization changes, people uh join the projects, people leave the projects.
The same is true for the users and the domain.
They have new different ideas, uh, what should be implemented, and of course, the software also changes in iterations.
So it means there is an influence between the development organization, uh, the domain, the software, and uh also the software and the development organization.
And there is one thing, one let's say, case study that I would like to join to share with you.
It's something that occurred in a consulting project.
And in that consulting project, um, we were asked to do a review.
And one of the questions that we were supposed to answer was the question: is it a good idea if a project manager decides that three teams should work on one module?
And I would think if you look at it, it seems like a bad idea.
As I mentioned, modules are meant to limit knowledge.
So if multiple teams work on one module, they all need to understand that module.
Changes will influence the other teams.
And it's sort of not what information hiding is about, right?
We are in a way violating what this is about.
We should have one module for each team, because then those team are teams are largely independent because they don't need to understand the implementation.
They just need to understand the interface of whatever the other teams do.
But if we share one module, we actually share a lot of information.
Information hiding doesn't really apply, and we have a problem.
Now it turns out that there is uh Conway's law.
And Conway's law says that the architecture copies the communication structures of the organization.
And the idea is basically if you have uh some people in an organization, then those people uh will probably well stick together, talk to one another.
And uh, if I have something to do, if I have a task that is assigned to me, I will probably write some code and I will probably talk to other people that have tasks that are somehow related to my task, and then we will probably build one piece.
I will build one piece of the software, one module, the other person that I talk to will also build one module of the system, and therefore we will have uh interface negotiations and we will have an interface.
So if I talk to another person, this will be reflected in the code.
Now, if we apply that rule to the example that I just gave, then we have a problem because the problem actually what this actually means is that we have uh three um three different teams.
Uh so here is one, here is one, and here's one, and we have one module, and that is something that uh Conway's law says is not really possible.
Uh so the what comes out of this naturally is either that we have three teams and they each work on one module.
So we tell them, well, you know, build that system that deals with bank accounts and uh tells us something about uh the uh the amount that is on the bank account, and we have a large complex system that does all the transactions and so on.
And maybe we figure out a way to split that.
Maybe we have one team that deals with uh the UI, we have another team that deals with logic, then we have two modules here.
We have one for the UI and we have one for the logic.
Maybe uh we have uh a split where we say, well, these work on the transactions and these here work on the balance, whatever.
We might be able to come up with something to split it apart, or the other solution is that we are unable, or what happens is that we are unable to split that module, and it's just one module, one large thing, but then all of the teams work on it together, and this is probably what we are afraid of because then we will have uh a lot of uh communication overhead, and uh we will therefore have uh some problems.
What I'm basically saying here is Conway's law is like gravity.
It's not if you don't believe in in Conway's law, it doesn't happen.
It explains it, it is a natural process.
And if you have three teams that are supposed to work on one module, that's not going to happen.
Either they become one team and you will have a lot of communication between them, or somehow they figure out a way to split that module apart into three different modules.
So is it really a bad idea to have three teams working on one module?
I would argue that project managers should should probably have a say in who does what.
So there is a good explanation why some project manager might come up with that idea.
Maybe there is a deadline, maybe it helps to have more people working on that.
And now to uh come up as an architect and say, well, we are not going to do this because that's a bad idea from an architectural vision.
I don't see how uh that's a good thing because at the end of the day it means that the project won't be successful, and we have a problem.
Um so maybe adding people to the system to and have more people work on the system is a good idea.
Um, and you know, I I use this as an exercise, and usually people can easily think about reasons why we would have we are why we would like to have more people working on a specific thing.
And um if we don't allow the project manager to set a priority on one thing and to have more people work on one thing, what are they even good for?
Because setting a priority, putting a priority on something, that is something that uh I think project managers should be allowed to do.
And uh it's even their, I think, core domain.
It's what they they really care about.
So Conway's law, as I said, says that the architecture copies the communication structures of the organization.
Now there is the idea of the inverse Conway law, where we basically say, okay, we set up some team, we assign them some task like order processing, and uh then automatically we will get a part of the code that implements that part of the domain.
So we have a decision about modules in a way.
So what this basically means is instead of uh doing traditional architecture and saying, okay, we will have one part of the code that does the order processing, instead, we say we have a team that is assigned order processing, and then natural, because of the uh Conway's law, this will also result in a module.
Um, this is something that is related to microservices and modern architecture um approaches.
I would argue that architects shouldn't decide that by themselves, because this is about what who which team does what.
And as I mentioned before, this is something where we have other things that we should take into consideration, like priorities, where the focus should be maybe things that are that require more people to work on, and so on and so on.
And um we don't have the full control over the organization.
So therefore we as architects cannot really apply this inverse combat maneuver.
The other thing that I wanted to talk about and that also spreads a different light on uh uh on the inverse combat maneuver is uh team topologies.
So team topologies is an approach where we define how teams should collaborate.
It's not really that complex.
There are just a few patterns that you need to understand.
And it's sort of intuitive, I would argue.
Um, at least to me, but you know, uh you might be uh you might be different.
And uh it also gives more fracture planes than just domains.
So what the inverse combat maneuver in a way says is that we assign a domain to some team.
In real life, we do have teams that are responsible for some technical stuff, not for some business domain, like for example, building an iOS application that uh uses all the APIs that other teams provide.
And it also team topologies also covers more than just development teams, uh, which is also a difference to um the inverse combat maneuver and a lot of traditional thinking, because obviously there are teams that do well architecture or some kind of infrastructure.
So in team topologies, there are stream-aligned teams.
They are aligned to a stream of changes where we have some idea, some business requirement, and we implement that business requirement and put it in production.
And that stream of change, that's something that one team is responsible for.
Now, if we do that, that's actually a very complex task.
And therefore, we need to support those teams.
And therefore, we have enabling teams.
So enabling teams are specialized in some technical stuff like technical consultants.
So maybe an architecture team would be an enabling team that provides some guidance on architectural problems and how to implement them.
Then there are platform teams that might provide something like Kubernetes or CI server, CI CD server.
And finally, there are complicated subsystem teams, which are responsible for complex algorithms like, I don't know, customer scoring or whatever you have.
The interactions between those teams come in different forms.
So there is access to service.
From the cloud's perspective, there are different cloud service cloud services, and they all are provided as a service, which means they are either provided through a web interface where you can click, well, just click and get get a Kubernetes cluster, or they might also be provided with an interface.
And for the complicated subsystem team, we will probably provide some kind of programming interface where we provide some methods that could be called that provide some results.
And this is access service.
There's probably not a lot of communication.
This might also be what the platform team provides.
Maybe then it's a website where we say, okay, we want to have a Kubernetes cluster that we can then use.
Enabling teams, well, they are they do facilitation, so they provide some knowledge support with, I don't know, domain-driven design.
If they are an architect team with uh specific uh architecture problems, and if that takes more time and is more complex, then uh they might even join one of the streamaligned teams for some time to work with them on the problem.
So we could have a setting where we have some business domains like invoicing, order processing or delivery.
Uh, then we have uh, and those are stream-aligned teams which are responsible for providing uh that stuff in production.
Then we have delivery optimization, an algorithm where we put in all the orders and it spits out some optimized itinerary to uh deliver all those deliveries with an interface.
Then we have a Kubernetes or CI team that provides some kind of website or a different interface for all the stream aligned teams.
We have the architecture team which uh supports the teams or maybe even provides some further support.
Again, I did an episode about this.
There is also a lot of material at Teamtopologies.com.
And I think the interesting or an important part here is that team topologies define magnets.
So it's the goal that teams should work towards.
And which sort of raises the questions how many organizations actually implement team topology fully and by the book.
And I'm not sure because it's a magnet.
So quite a few teams are probably on the travel towards this goal, but whether they make it or whether they have already made it, that's a different question.
And I'm not sure whether that matters because at the end of the day, we have some state that our development organizations are in.
We are just looking for improvement.
So it's not being perfect and implementing everything.
It's just some like a uh we are traveling towards that goal, and uh we are trying to become better.
It's not that uh we just say, okay, we are going to do this and then we are done.
Team Topologies acknowledges that informal communications exist besides organograms, and I think this is important because this is usually where most of the problems actually occur.
I did talk about this these more soft aspects of software development in this episode.
And um the problem, or one of the things why I think team topology is actually a good idea, is because it talks about different fracture planes.
So what we could come up with is a UI team in India, and we have two streamaligned teams uh for order processing and delivery, one in Kaiserslautern and the other one in Hamburg here in Germany.
And the reason why we split it this way is probably because if we have uh people from India joining the teams uh from Germany, it's hard to do the stand-up because there are different time zones.
You will force the Germans to speak English, which might be a problem, and so on and so on.
So compared to the inverse convey maneuver, which basically says, okay, we are going to assign some uh domain, part of the domain to some team.
I think that's pretty unrealistic because in real life, I do see other factors taken into account, like the location of people or even their technical skills.
Another reason why I would probably have a UI team or might have a UI team is because there is an iOS uh UI, and uh that team would then have all the technical means to build that uh system.
Um they are still streamaligned, so this team would be able to well implement something in the UI and put it into production.
This team would be able to do something in order processing and put it into production.
So there is one part of the system that each of these uh teams are responsible for.
So these fracture planes are interesting because always splitting uh teams by domain is impossible.
So it is always um, and that means that also splitting modules by domain always is impossible.
You will have some technical uh modules, and therefore the inverse common maneuver, in my opinion, is well, uh something that sometimes just doesn't work.
Uh, and therefore, some team that works on a UI module might make a lot of sense.
Um architecture also splits into layers and enter uh and there is hexagonal architecture, which is a means how you can separate your systems from a technical perspective, which is something that you usually don't do on the team level, but still it means that there is more than just uh domains that uh influence what how and what an architecture look uh should look like.
So, what shall we do differently?
Um, in my opinion, the main point is that software development is a social technical activity.
Uh, the teams are the social side, the modules are the technical side, and uh you must consider both.
Um so, and one of the things that I notice where where I seem to think different about things is interfaces.
An interface to me is not just something that we have in the code, but it's also about communication.
It means that people actually talk to one another.
And if we look at information hiding, this is about uh one way to reduce cognitive load.
It's about trying to hide the implementation details and therefore to make it possible to build systems that are too large for one person to understand.
So if you look at the fundamental parts of architecture like interfaces and information hiding, those are things that um are motivated because of social problems, and this is why we organize our system in a specific way.
Um that's pretty much what I wanted to uh say.
There are a few things that I still uh want uh want to add.
So, one thing is if you thought this was interesting, uh feel free to uh drink a virtual coffee with me.
Uh so you can set up a meeting, and uh, in the meeting, I'm happy to discuss whatever uh problems you might have in your project or um otherwise.
Uh and you can just uh book an appointment here.
And uh the other thing um if you like the presentation, uh feel free to download the slides.
So one way of doing that is um to send an email to Armadinked in 2026 at evolve.com and you get a link to the OneDrive.
The other uh possibility would be to scan the QR code, which takes you directly to the OneDrive where you can download the slides.
Um the email is just uh used for sending out the download link, uh, and I will lock it for 14 days.
If you uh mistyped something in uh the address, uh then uh I would handle that manually, and therefore we can take the questions, right?
You're muted, or at least I don't hear you.
Yes, I was saying thank you so much, Eberhard, for the presentation.
Uh we already have one question from Lucien.
Uh do you see it, or should I read it out loud?
Let me see.
I think we can get rid of the slides for now, right?
Yeah, uh oops, like this.
And expand, and nope.
So uh Lucian is saying that you wrote about the hidden influence of developers and architects and the fact that managers usually decide team composition.
What concrete tactics can architects use to shape team structures without formal authority?
Yeah.
I think that's a great question.
And first of all, let me say that architects can probably not even decide by themselves what the code should look like.
I mean, if you think about it, I can come up with some diagram and some idea what the code looks like looks like or should look like, but really uh I need to talk to the developers, I need to get some feedback from them, I need to incorporate that feedback, I need to convince them, and so on and so on.
So, what I'm trying to say is uh even if I have formal authority as an architect over something like the code and what it looks like, and maybe even if I'm um if I'm officially responsible for the project from that side, it's still that things are not happening until I actually convince people.
And I think this also applies to uh managers.
Uh so and and which basically means if um I have a good reason why the teams should be set up in a specific way, like it obviously makes sense to have one team deal with one module.
I'm not arguing that, I'm just saying that there are other reasons things that you also need to uh to take into account.
The way to do this is to talk to managers and tell them, well, you know what?
If you do this, if you have three teams working on one module, I expect a lot of communication over it.
And I'm not sure whether it's worth it.
And then we have some discussion, and then we have to figure out what the right path is.
And as I mentioned, there might be reasons that why the manager would convince me to actually have those three teams working on one module, like a deadline, for example.
And maybe there is not too much communication over it at all.
Or but this also works the other way.
So maybe I'm able to convince that person.
And quite frankly, so I use this as an exercise, as I said, and usually I ask people whether they want to have the formal authority over the teams, what the teams should look like.
And the reason why I find this interesting is because that means that you're basically the only person that is responsible for the project, not just the architecture, but also like all the other stuff, like setting up the teams and so on.
And that's something that I don't want to do, uh, because it's too much um responsibility.
And uh this is something that I sort of don't really understand.
What I want to do is I want to talk to project managers and tell them or managers and tell them this is what I think should be done.
And then I want to have a conversation and I want to come to come some conclusion.
And um I feel quite comfortable if uh what what I advise is not implemented, uh, because otherwise I would have total authority over the project and total responsibility, and that's a role that I don't want to want to play.
And I might add that uh I do uh uh own a share in in SwagLab, but I'm not one of the CEOs, but so we actually have three CEOs, and I think it's a quite comfortable situation to be in, because uh the other ones are the ones who are officially responsible, uh the other shareholders, and uh I'm just a shareholder, and that's sort of by intention.
Um and uh obviously um we have open discussions where I'm able where where we convince one another and and have a common plan, but I don't see what would be different if I would also become one of the uh official CEOs of the of the company, and that's I think the same thing.
Hope that helped.
Thank you.
I hope that answered your question, Lucianne.
And um, if you have help follow-up questions or if we have any other questions, let us know.
Oh I I might add, because uh that's also something that is somewhat uh dear to me.
So if you download the slides, uh you will find a link uh to an episode that I did in uh for software tech to MStream where we discuss fearless change.
And uh fearless change and fearless journey are uh fearless change is actually a game, um and fearless journey is a set of patterns uh to influence an organization, even if you don't have uh the uh formal authority.
And that is another answer to the question that you just raised.
Uh so and and how shall I put it?
If you look at it, that's also what the team topology's book says.
Uh, there is so much informal stuff going on uh in an organization.
I probably that even dominates the formal stuff.
So uh the question which tactics you can implement, I think fearless change and fearless journey are are some of those.
Uh the main point that I'm trying to make is I'm not sure if you have the formal authority, uh how powerful that actually is, because you can just be ignored, and people might just do whatever they like, even though you're the one who is officially in charge.
And I think we all know how we can uh avoid doing something that we don't want to do, even though some managers said we are supposed to do it.
Um and that's sort of natural.
So in my opinion, I would argue the only way uh to get something done is uh to convince people or to to do these these informal things and and convince them.
And I I don't think that convincing just includes rational things, it's also uh clearly an emotional thing uh and and how people interact with one another.
Thank you.
We actually got a message on DM on LinkedIn, and uh, this is the question.
One second, let me show it on the screen.
What are some steps to actually improve architecture projects using what you have described, Eberhardt?
Um so to me, it's about some techniques that you can uh follow.
Uh and some of the things are maybe even trivial.
I mean, if you have some meeting, uh naturally what happens is that someone is, I mean, if if it's a meeting in real life, some person will stand at the whiteboard and will take the pen and draw stuff.
So, sort of by definition, you have one person that sort of drives uh the meeting.
Uh, and that person is very likely to sort of dominate that meeting.
Um, and obviously, there are um introverts and um other people, um and that leads to to some some challenges because obviously those introverts uh won't stand up and say, okay, I have a question, by the way, and uh this is uh something that that we should different should do different.
So, in my opinion, one thing that you uh should do as an architect is uh to be aware of these facts and uh to use but and and there are simple solutions to that.
So, one of the simple solutions is to use post-it and says uh and say, okay, uh write down in on a post-it the answer to I don't know whether you how we are going to solve that architecture problem.
So there is some architecture problem, and you want to have a discussion about that, so have the people write post-its.
Why?
Because that's in parallel, and it also uh means that you get the information from the introverts.
And um, this is about the informal things that I mentioned.
Um, and it's not a tactic, so it's not on the level of fearless change or fearless journey, it's just uh some some technique that you can use.
And I think that's one of the uh ways uh to have better results, to have a better conversation and to to uh to uh uh improve the situation there.
And that is something that I would encourage people to do uh and to to be aware of these facts that uh that are so so very important.
Um and there is also all the stuff around uh collaborative modeling like event storming or domain storytelling, which also by definition are things where you well collaborate, which means that you well collaborate, which means that other people are involved, and they use these techniques, right?
I mean, event storming basically means that there are people who have these um uh everyone has some some uh post-its, and you would write down the the business uh events on a post-it and stick it to a wall, which by definition means it's parallel, and introverts get their uh get a way to express um their knowledge, and it involves everyone, it all and it also involves people or can involve people uh who are not technical, uh so domain experts.
So, again, it's about a technique that is inclusive and um leads to uh a better shared model.
And I think that's uh one of the one of the things that you can uh do in that regard.
Because at the end of the day, and that's what what I tried to say in in this in this uh talk, um, it's uh it's a social activity.
The main problem that we have is that we we we have a team, and the team wants to collaborate and wants to build some piece of software.
That's the main problem.
Um, and this means it's all about communication and working together, and I think that's also why this this idea to have uh agile and architecture is as a common theme in in a conference makes uh sense because it's both about I would say uh people, um it's just that that's not so uh obvious to everyone.
It's rarely a software problem, right?
It's always a people problem.
Exactly.
And uh that is why um it's just it it just seems like a technical uh thing, but really it's about it's about people and how they collaborate.
What would be some stats if you can share that from your experience?
How often was it a people problem, and how often was it a software problem?
Um there is one thing that I still want to do an episode about that's uh the the loss of consulting by um I can't remember the name from the top of my head.
Uh so that's that's a very old book, uh Weinberg uh from 1985 or something.
And uh he says it's so so the first law that he introduces is um there is always a problem.
Uh and and I can relate to that because I have been to to kickoffs for for reviews where I was like, well, uh, you know, is it fine if we just write down that you don't have any problems at all and it all works out?
And you know, after we we did the review, it turned out that they really had severe problems.
And uh the the second point is uh no matter what it looks like at first sight, it's always a people problem.
Um and I would totally agree.
Um and I would encourage you to look up the the third rule.
And um that's from, as I said, it's from 1985, and uh that's from I I mean, I have I have to say that I wasn't around in the consulting business at that time, obviously.
Uh but um I believe that this was probably the start of what we are doing nowadays with consulting.
Uh, because I believe that beforehand uh developers and development organizations were basically pretty much in-house, and there wasn't probably probably too many people that would run around and do consulting.
So, in a way, from the very start, since we have that as a profession, uh it was clear that it's about it's about people, and that's still what it is.
And that's also why why we at Spec Lab uh believe that um the people are the main uh thing that we need to care about, and that's also why we have this different role.
Because if you just attack the problem from a technical perspective, which I can do uh with my software architecture background, it's quite likely that you you do have some influence, but it's you're much better off if you have some other people that can deal with uh problems from other perspectives.
Uh, because usually it's not like like one thing that that doesn't really work.
And in particular, it's it's most of the time people.
I think that would be actually a great way to wrap this up if we don't have any other questions, because that's the essence of agile meets architecture, right?
Look at the people and the software in the same time and see how the two can work together.
Yeah, and I think uh as usual you have a great lineup of of speakers.
So I'm really looking forward to the conference and to be and I'm really happy and and honored to be part of the of the lineup.
Happy to hear that.
If you do have other questions and that we haven't addressed uh during this uh event, please uh let them in the comments on LinkedIn and we'll uh we will pass them over to Eberhard.
Thank you all for attending.
Don't forget that uh the schedule is out, Earlbert and tomorrow, and um have a great rest of the day.
Thank you, Eberhard.
Oh, why wait?
We have one final question.
Yeah.
Let me see.
How would you run a six to twelve month experiment with inverse Conway in a big political enterprise?
What would you measure and what are the warning signals would tell you to stop or pivot?
Uh so I mean, uh I I mentioned that I do have these these virtual co uh coffee, so maybe that's a good point to to discuss in one of those uh one-hour courts, because I mean, obviously it's a it's it's a complex thing.
Um I have to admit that um if someone says I want to do this and that in a project, the first question that I tend to ask is, what is the problem that you're trying to solve.
So uh with inverse conway, I would argue, and that's actually already why why the question is is great, because I didn't really mention that.
Uh I think the the idea uh concerning inverse conway is that it improves productivity and that it allows us to have um well outcome with less communication.
Um however, that's sort of from an abstract point of view what this should be about, right?
I mean, basically the idea is you have one team and that one team deals with one part of the software and is able to uh implement something that makes business sense without talking to other teams.
That's sort of the idea.
And um also the idea is to not uh steer the or not define the architecture, but rather uh attack it from from an organizational standpoint because that might be more effective and leads to more self-organization, which again leads to more productivity.
Um so I would try to understand uh whether what the goal is.
Maybe that's the goal, but then the problem is that uh the architecture might not allow you to do that.
If you have a large, non-well badly structured legacy system, and you assign some domain to some team, they're probably not going to be able to uh work independently because the software is just too badly structured.
And then the experiment doesn't really make a lot of sense because uh the goal that you will that you want to achieve, more independence, more productivity, it's quite likely that you won't achieve that.
Um so that is why I think it's important to figure out uh the the reason, the goal, to figure out whether this is an approach that allows you to reach the goal, whether there are any problems on the way and to take care of those problems.
So maybe one of the alternatives uh would be to well attack the the legacy system, maybe to have just one team uh that deals with uh some domain uh that you can split apart from the other teams and that can actually work independently and so on and so on.
Um political enterprise means that you have to deal with well, people.
Um, as I mentioned, uh I would try to convince them, and this is actually helpful because if you can um spell out why you want to do that, that helps you to well think for yourself why you want to do that.
So the the this I think convincing other people is a helpful filter to separate ideas that really don't really make a lot of sense from ideas that actually do make sense.
So therefore talking to those people and trying to convince them is something that uh I think is actually helpful.
And um I would um therefore try to to uh well figure that out.
What I would measure, well, depends on your goals.
So I would try if you want to improve productivity, you have to have some means to measure productivity.
I did actually an episode about that, and that's and also a talk that you can find on my YouTube channel somewhere.
Uh so that in in English, there's an English recording there.
Um so maybe that is something that you would uh work with.
Warning signals.
Um I have to admit that um when I'm deeply involved in a project, I run around and talk to people.
So the early warning signs that I would see is people who actually say, Well, that wasn't a good idea after all.
And then I would try to talk to them and try to understand where they see the problems and try to figure that out.
I hope that that helps.
Thank you.
Thank you.
As I said, have a great rest of the day.
Thank you, Eberhardt, once again.
See you all at the General Mutes Architecture.
And thanks for the questions and uh hope to see you at the conference.