Armchair Architects: Can architecture prevent you from shipping your org chart?

Welcome back to the Azure Enablement Show with the Armchair Architects. So, do you know who Melvin Conway is? If you don't, you should. He came up with something called Conway’s Law, which talks about how the organizational structure could impact the things you build. So, the question that we're going to try to answer today is, can architecture prevent you from shipping your org chart?

 

One thing you may not know about this series is once upon a time, we wanted to call it “Arguing Architects” because we thought there'd be all these cool arguments that we would get into. It turns out that we have done some arguing, but it hasn't been all that. The good news for you is we've been talking about the subject we're about to discuss and we have an argument already brewing. So let me see if I can set that argument up. Today we're going to talk a little bit about Conway’s Law and how it applies to architecture. I think it would be super useful if people would describe Conway’s Law. We're talking about the law from Melvin Conway, so anybody want to set up what that is?

 

What is Conway’s Law?

 

It's more like an adage for me rather than absolute law, but I think the way that I've become familiar with it, but from an architecture standpoint. It's basically those systems that you design, the applications that you design, and you produce mirror your organizational structure. Or it's the converse in which your organizational structure causes you to produce experiences, apps and software that look like the boundaries of your organizational structure.

 

That matches what I understand it to be, my recollection is his canonical example was if you have two teams that are building a compiler, they will build a 2-pass compiler as a result. If you have three teams building a 3-pass compiler, they will build a 3-pass compiler. But what does this have to do with architecture? So, queue us up with that, Eric, and then we'll get into the meat of our discussion.

 

I think the first thing to think about for me is that Conway’s Law isn't necessarily a bad thing. The question is whether or not you're subject to it or did you actually do it purposefully. So, from an architecture standpoint, we all want systems that are componentized. They fit together, they represent the best patterns and software implementation paradigms but at the same time, we don't want to have to struggle to force these components to fit together. We also don't want to have a struggle in which a customer or an end user is having difficulty utilizing our system primarily because of the way it was designed and stitched together. Which is a function, according to Conway’s Law, of how the resources associated with producing that application were organized from an organizational structure point of view.

 

Shipping your org chart is bad architecture and zero leadership.

 

Only I have this recollection, you have something to say about that? It might be human nature what you're describing that says “hey, if you're organized to use the example, you get a 1, 2, 3 pass compiler depending on how many teams you got involved.” For me, that's just bad architecture and zero leadership because ultimately, architecture is a leadership function. If you have a red thread that is designed to guide people of what you want to achieve, how you want to achieve it, but gives enough wiggle room for teams to make decisions, not in the all up case, but for their specific pieces that fit into a specific environment. You don’t necessarily do a reorganization every time you have a conflict or something changes. You effectively say, “OK, let's go reorg”, and oftentimes organizations do this. But for me it's simply a function of lack of architecture vision. How do you effectively go and talk about this and how do you make sure that everybody's on board and knows what their parts are but what's also common. The thing is commonality has to be established and you go from there. And unfortunately, organizations often tend to say, “well this will only work if they work for a single leader.” That person then can go and derive the direction. Again, that's one way of doing it. But if you look at a complex environment like cloud computing plus edge computing plus IOT, how do you organize yourself to bring all of this together?  Which is where the world is moving today. So, you can't rely on reorganizing every time something changes. You must establish leadership, and leadership can and should be established through architecture.

 

Do you think what Melvin Conway is trying to say is “if you don't pay attention, this is what's going to happen.” Because it sounds like what you're suggesting is that people choose to set up their organization as one step in what they're going to build. I got the sense that there was a bit of intentionality in not what he's trying to say. He's not trying to say in order to get a 3-pass compiler, get yourself three teams. So, my only question is do you think that this is when you talk about leadership do you mean somebody who is conscience of what they want, versus falling into Melvin Conway's described pattern?

 

So, I think that's what I mean by it. Meaning if you don't have leadership across the board and you don't work as a virtual team then reorg is oftentimes the only way to do it. But even if you reorg, if you still have no leadership, you still can go all over the place because you have sub teams, you have smaller units that effectively go and deliver things. We call these things now function teams and you still have to have very clear guidelines, very serious strategy . I'm not so sure that reorging all the time to make sure that you effectively go and build this effective delivery model is efficient in today's world of distributed workforces, hybrid workforces, all these other things. So, you still have to do a lot of communication, a lot of sharing, a lot of drive in order to really make sure you don't get a Frankenhole delivered, but rather a system that actually works.

 

Is your team organized for optimal performance or are you victim of Conway’s Law?

 

I feel like we're kind of letting our viewers down because there's not much of an argument happening yet. I completely agree. The idea that you need to reorg to produce a quality software product. I don't think that that's what we want architects to take away from this session. I think what we want people to take away from the session is understanding that if you have a sub optimal software product that you have to look after, manage and steward, as an architect, you do need to look at the way in which the teams are organized and figure out are they working optimally or are we victim of Conway’s Law? In that a suboptimal organizational structure, or one that just exists in nature, is producing this thing that is not meeting the requirements. It's not delighting the users of the platform. And then the question becomes, well, is it feasible or realistic to reorganize and completely bash the entire organization structure to reimagine it based on the way you want things to look? Or is there a way in your organization might be mature enough for virtual teams and a matrix-based approach to building software. Regardless of organizational boundaries, some teams or some customers have a culture in which that's not necessarily going to happen. Hard reorg structures are the way to get things done: co locating people, putting them together, having them report to a single leader might be one way of building the outcome that you're looking for. Another one might be virtual teams in which people can set aside their organizational boundaries, their leaders and work towards a common goal with autonomy and freedom. I think it's a balancing act that we have to figure out. What I hope people take away from it is there's a spectrum of things you can do. You can push the v-team approach. You can put the organizational requirements at the center, you can focus on the outcome and the user experience that you want from your customers or at the same time you can actually design an organizational structure based on the software that you want to build or the solution that you want to construct. So, I think that there's multiple things you can do, but we're not saying that you should do those things. There's a confluence of considerations whether or not you're subject to this law.

 

There is not a one-size-fits-all approach to figuring this out.

 

So, you're not saying we should just create a single monolith and it solves the problem. We no longer need to worry about Conway’s Law if we're all in one group, one team.

 

I was just going to follow up, and I completely agree. I don't think that there is one-size-fits-all. Just like there's not one solution architecture that fits all. It’s going to definitely be a balancing act based on what it is you're trying to do and what it is that you're focused on. I was talking to a colleague of mine, Peter Provost, and we were chatting about Conway’s Law and kind of lamenting about how v- teams don't necessarily always work here and maybe we actually need to have leadership alignment. I think that there are situations where that's right and situations where that's wrong.

Then we started talking about the inverse Conway’s Law which is the term when you design your org structure based on the output that you want. So, I don't think that there's a one-size-fits-all approach to figuring this out. I think just being aware of it is what's most important.

 

Conway’s Law is going to happen.

 

I look at this architecture, it can help, that’s one of the key things that I want architects to take home is Conway’s Law is going to happen. We're just all humans and everybody is trying to get the Gold Star home to Mommy, those kind of things. So incentive structures and all those sorts of things are important. Architecture and architecture leadership that says “here is what we want to achieve, here's how we want to achieve it. Here are the core building blocks that we really want to drive the core, here are the principles and stuff like that.” In fact, we can help you overcome this effect, which is real and is not going to go away. Inverse Conway’s Law is something that Microsoft does all the time, and I'm sure you have seen this in your organization, wherever you are. Sometimes it works or oftentimes it doesn't work because suddenly you see an element that you thought was not in scope is in scope for this solution and what are you going to do? Are you going to add more to this piece? Sometimes again, that's what people do, but it gets very clumsy and very slow because every reorg resets the team. You have to rethink; how do I motivate everybody? How do I make sure that everybody's on the same page? So, Conway’s Law is real and does have impact, but architecture is one of the elements that can help.

 

Re-orgs are expensive and painful, and not always successful.

 

I just want to underscore what Uli said. Reorging is expensive and can be painful. There is storming, norming and then performing cycles that you have to go through. It's not something where you can let me just put a bunch of people together for a short amount of time. It is painful and sometimes it works and sometimes it doesn't, but I really like your perspective. And again, I know I'm doing the opposite of arguing, but the perspective is that there's architectural truth that drives this entire process. And being aware of the law is important, but the truth of the architecture, the purity of the architecture is what will help mitigate all of these challenges associated with this law phenomenon.

 

I have to agree, reorging and I know this from experience, is this heavyweight thing in and of itself and I rarely see people acknowledging that it has a destructive kit component to it. In which it's breaking down certain networks of people working together and the things that they have worked out and negotiated and now you don't know who to go ask for X because that person is now off in some other place. It doesn’t sound like Uli you're suggesting that Conway’s Law, if you see it happening, is an indication of a failure of leadership. It sounds like leadership has a role. It's not that if you find yourself in a Conway’s Law thing, that means that you have a terrible leader. You're not suggesting that, because you said it's going to happen.

 

Clearly defined outcomes and guardrails can minimize the effects of Conway’s Law.

 

It is going to happen. It's human nature. In this case, I think broader than organizational leadership. Think about leadership that you have to drive a structure and strategy that says, “here's what we want to want to achieve”, to use Eric's term, “what's the outcome we want to drive?” If that outcome is clear and there's guardrails, principles, and all sorts of other things that people can rely on, and those are clear, then Conway’s Law should have minimal impact. I don't think you can ever completely get rid of it. But if you don't have clarity, then Conway’s Law is going to have immense impact because everybody's going to figure out what to do for themselves and that's what I mean with lack of leadership. The leaders are supposed to be the people that go out there, talk to the teams, make sure that everybody understands what we are trying to build, why are we building it, what are the key pieces that we want to achieve and so forth. And that everybody then says, “OK, and here is my role in this piece” so that they are part of a bigger whole, rather than trying to either overstretch their boundaries because they don't really understand what their part is and so forth, although they don't agree with it. Again, people should think through what they want to achieve, and how they were going to execute. And the better of the guardrails are, the better the visible architecture and the approaches, the better off you are, and you will minimize overlap and confusion and stuff like that.

 

I think that if there's one thing, I hope people walk away from this session is, does your organizational structure support your outcomes or does it denigrate or detract from your outcomes? If it detracts from your outcomes, then something needs to change, whether that's vteams or hard org structures, knowing what the costs of those things are. If it's in support of it, then congratulations, things are working well. Just keep an eye on it and make sure that you're not in a situation where eventually, overtime, it detracts from the outcome.

 

I would add one more test. Do you understand your role in a larger capability that's being built? Do you really understand how you work with others? What you are delivering, what other people are delivering? What dependencies are you taking? Who's taking dependencies on you? How does this all work? If you can clearly articulate this, as every member of your team should, then you are in great shape. If you can't, maybe Conway’s Law is at work and is starting to distract you.

 

Well, as I understand he was a smart guy. So, he may not personally be at work, but certainly his adage is at work. What's really cool about this is these gives me something to go off and think about in terms of how leadership and Conway’s Law interact. And it makes me think of what are the other adages that are in play that that we have to think about. I know we're going to be talking more about architectural leadership in future videos, so this seems like a really good place to end and then join people again in another episode. So, I want to thank you Uli and Eric. I would like to thank all of you for watching this episode of Armchair Architects not arguing architects alas, but Armchair Architects as part of the Azure enablement show.

 

To hear the whole conversation, you can watch the video at the link below.

 

Continue to website...