Reckoning with the force of Conway's Law

Episode transcript

Birgitta Böckeler: Welcome to the ThoughtWorks Technology Podcast. My name is Birgitta Böckeler. I'm a technical principal with ThoughtWorks out of Berlin, Germany, and I'm co-hosting this episode with Mike Mason.

Mike Mason: Hi, Birgitta. Nice to be with you today.

Birgitta: Today we actually want to talk about Conway's Law. When we recently got together to create the new addition of the technology RADAR, we had a conversation about Conway's Law and the Inverse Conway Maneuver in particular, and the experiences we've all had with that and applying these ideas over the years, and to talk to us about Conway's Law and the Inverse Conway Maneuver today are our colleagues, Martin Fowler, and James Lewis. Martin, can you introduce yourself and maybe briefly mention what your relation to this topic is?

Martin Fowler: Well, I'm Martin Fowler. My relation to this topic is, I've been working in software for decades, so Conway's Law has been a constant companion to me.

Birgitta: Then James.

James Lewis: Hey, I'm James Lewis. I'm, as Birgitta says, a colleague of everyone here, and I've been interested in Conway's Law from the perspective of how to best or more effectively structure teams for flow to effectively get stuff done, essentially.

Birgitta: Then I'd say we'd best start with maybe clarifying what we mean by Conway's Law. James, do you want to give it a stab and quote the definition?

James: Oh, I'm not even sure if I can remember the definition. I think Martin's probably got that off pat. Martin, could you give that again?

Martin: Yes, well, I've got it up on the screen here or at least a statement. Basically, the law comes from an article that this guy Melvin Conway wrote back in 1968. It was published in Datamation, which was a significant magazine for the data processing world in the '60s. He wrote this whole article about how organizations design and basically summed up the thesis of this article by saying, organizations that design systems are constrained to produce designs, which are copies of the communication structures of these organizations.

Basically, the way a development team organizes itself will constrain the shape of the system that comes out. I always learned the example is based on if you've got a single team creating a compiler, it will create a one-pass compiler. If you divide the team into two, you'll get a two-pass compiler. That's essentially the essence of how it-- your modular structure will reflect the team that created it.

Birgitta: What I was always wondering is when the more conscious application actually started to apply it to software architecture. Obviously, in the last 10 years, there's been a lot of that, but did Conway actually write this in the context of software architecture specifically or more broadly? Do either of you know?

Martin: My impression is that it was written with at least some background in software architecture, but he does very specifically state that this is true of systems in general and his current writing on it, so it says you see it in terms of the way society's structures are a mirror of the government and of organizational forces that create them. In terms of how they've been consciously used, as I said I've been in the software business for ages.

Conway's Law for me has been the background, a thing that's always been there. It was quoted under the name Conway's Law by Fred Brooks in his book, The Mythical Man-Month. The Mythical Man-Month has been one of those books that's been one of my sort of cornerstone foundational books since I started in software development back in the '80s. As a result, Conway's Law has always been around because it was quoted in that book and it's therefore been part of the landscape.

Birgitta: I actually just learned that from you. I just pulled out my physical copy and looked it up in the index and it is in there indeed. Then obviously, I guess the craze about it started maybe the first time I heard about it was in the context of microservices. Maybe James and Martin, it's your fault when you wrote that article together and started mentioning it and then after a while, you couldn't go to a software conference without people mentioning Conway's Law, right?

James: That's true. Then of course, actually, Mel Conway started going to conferences again. He was invited back onto the conference scene in the last 10 years. He's been talking more about his current projects. It's certainly sparked a big wave of interest. I think going back to this idea of using Conway's Law or not fighting against the information flow, aspect of how we structure ourselves and, therefore how software architectures end up looking.

I think we published the article in 2014, but actually, prior to that, there were many discussions amongst ourselves in the RADAR group or on the tab about microservices or about this idea of breaking things up into smaller bits. In fact, our colleagues I think on the tab talked about using Conway's Law earlier than we did in the 2014 article. I believe Martin, that was-- was that Johnny Leroy you were saying? Who coined the phrase Inverse Conway Maneuver?

Birgitta: Yes, Johnny Leroy and Matt Simons. They wrote an article in 2010, already, about this idea of using this power of the law to your advantage by thinking about your architecture and then organizing your teams accordingly so you would get that architecture.

Martin: It was certainly a major feature around microservices. The name microservices makes a lot of people think small services, funnily enough, but there are many characteristics of microservices that James and I identified in our original paper. One of the key ones is organizing around business capabilities and the idea that you have a team, and it's partly inspired by the Amazon two-pizza teams, which are both small, but also focused on a particular customer interaction.

Very explicitly, Conway's Law is part of that, in fact, we quote Conway's Law in the article because of the fact that that's very definitely part of that notion and that force is to try and recognize that power of Conway's Law and make use of it.

James: I've been quite interested in post-2014 and the further work and thinking around microservices, I think I talked a bit about something I call the organizational design onion, which was this idea of you have the small teams organized around business capabilities but then actually also grouped according to Dunbar's numbers. This it's a reinforcing thing where you're not just thinking about Conway's Law and the fact that the information flow between people is going to influence software architecture, but also the number of people that you can safely interact with or that you can interact with on a daily basis. Scales as the series of Dunbar's numbers, I think it's like 5, 15, 50, 150, 200 and 400, and so on.

Actually organizing you're creating an organization that is sympathetic then to this idea of how many social connections you can keep in your head. There's almost like these reinforcing, I think layers, if you like, of this Conway's Law, which is about how people-- how information flows between people when they're doing something like knowledge work or anything else, Martin said anything, but also then this reinforced with keeping the teams small enough that is very, very high bandwidth information flow, if you like.

Birgitta: I think originally it was almost like a blunt resurgence of this idea and this seems to make sense. Then over the last 10 years or there have been lots of more nuanced observations now like the thing that you just mentioned James or this cognitive load idea, in general, that has been popularized by the Team Topology's book. That not only should a team only have a certain set of people to interact with not too many stakeholders and not too many people they need to know but also the amount of topics they have in a team and so on. There's been lots of things that evolve this idea and more nuanced ideas about the core thing right?

James: I'd even go further than that now because there's quite a lot of evidence that points to the fact that the deeper the hierarchy of an organization, so essentially the further information has to flow between elements of an organization within an organizational design, the slower an organization proceeds and in fact, the less effective an organization is at doing the thing that it's there for which is making money, saving lives, or whatever it is.

That's another impact of this idea of Conway's Law or further extension of that. It's not just information flow between people on the team which influences software architecture but it's information flow just in general in the company through hierarchies that actually impact on things like revenue and profitability and so on. It's extended. Maybe I'm going beyond the remit of this podcast talking about that, but interesting.

Mike: No, I think it's relevant. I'm curious there's been two different characterizations of the use of Conway's Law so far. One has been this Inverse Conway Maneuver thing where you are aware of Conway's Law and you set up some pieces of your organization so you get a particular outcome. Both of you have also talked about the force of Conway's Law and not pushing against it or not doing something that naively would run into Conway's Law being a limiting factor. Are those both the same thing? Are they different do you have an example of how people really should be thinking about this?

Martin: I don't think of them as necessarily different but just two ways of-- Conway's Law, it says you have this force that's always going to be there. A lot of what we see out in the industries is people ignoring that and trying to come up with architectures or just not really thinking about the organizational design and trying to pretend it isn't there, and as a result, you get this mismatch where people are trying to do something in software design and their organizational design is pushing against it and the result is a lot of friction and problems.

Then you've got another stage might be then the aware software architect who is aware of the fact that Conway's Law exists and therefore designs the software system in such a way that it reflects what is happening on the organizational level. My great example of that is a friend of mine 20 years ago, who was made software architect of this big program, and there were six teams in different cities all over the world.

His statement was, "I've made my first architectural decision, there are going to be six major subsystems, no idea what they're going to be, but there's going to be six of them." That's showing the awareness. What the inverse Conway maneuver talks about is going almost a step beyond that and saying, "Well actually, let's alter the development organization and alter it in such a way as to produce the kind of software architecture that we have in mind." This is usually-- when I've run into this, it's because people say, oh we want to be more responsive to our customers.

Therefore, let's create teams that are smaller and customer-focused rather than the activity or skill-based organizational structures that says let's put the frontend people and the database people, and the analysts all in separate organizations. That causes this very poor speed of responsiveness to the need to build things. Because you've then got a whole load of complicated communications of hierarchies.

Instead, let's have a small focused team that has the analysts on it, the database person, the frontend person, the backend people, and they can all communicate with the customers and get things going, which is, of course, also part of the agile thinking. The whole agile thinking is to, say, break down the traditional activity-oriented barriers and instead have a poly-skilled team. This is exactly what Scrum talks about with its poly-skilled teams, what Extreme Programming talks about by saying let's get everybody together in small groups going with the customer, so that all fitted very well.

Of course, we're then with a microservices which very then firmly said we'll also get your systems organized so you don't have things like big shared databases to coordinate things. All of this stuff, it's all to me different ways of looking at that same essential topic, which is driven by the strength of Conway's Law itself.

James: Of course, just to develop that comment on that, rather, develop that further. I think we forget it was absolutely the norm to structure an engineering organization, or IT organization according to activities and also according to technology layers. We would design an architecture and architecture would be designed, which would be data services, a web tier, and a database tier. You had people who worked on the data services and you had people who worked on the web and people who worked on the database. Every single time you needed to get anything done you wanted to add a form into the web, into a web form, a field into a web form rather, then you'd have to make the change to the field in the web form.

You'd have to make a-- add a field into whatever data service that the frontend was talking to, and then the table. That would involve, I remember there was one client where the question was asked, how long is that going to take then? And they said, and how would you do that? We said, so it's going to take about three, four, five, six months. First of all, we need to get a project manager to work out how long it's going to take and pull a team together to work out the number of months it's going to take to coordinate across the different teams in these layers which is, of course, and maybe this isn't the right place to do this.

This idea of pace layering will-- some bits go faster than other bits is of course a nonsense. It's for the same reason because most of the time if you make a change it's going to touch many aspects or many layers "of your pace layering."

That was, I think, the real thing, the real huge step with microservices in a sense was this, as Martin says, the focus on business capabilities to focus on poly-multi-skilled teams who aren't focused on layering and technology, but in fact are thinking about solving the business problem in the whole, in the large, rather than the minutiae of — I don't know a RESTful or a — heaven for forbid — Death Star SOAP service.

Birgitta: I think that's when you get beyond this and have accepted, okay, maybe this layering by technologies is not a good idea. Now I want to have these more cross-layer teams, and I think then is actually when it starts becoming really interesting, because now how do you actually shape those so that they have minimum dependencies to each other? I've recently run into that on the opposite side of Inverse Conway Maneuver because, in general, it's about sympathy between the architecture and how the organization works or how the domain works.

Domain-driven design thinking and all of those things. So if you start by looking at how is our product structured, and then we want the architecture to be similar to that because then we'll also have less dependencies and it will be easier for our product people to work with that and then it almost becomes a cycle. You look at how is the product structured? How is the domain structured? That's how the architecture should be. Then maybe some things don't work out technically that well, so you cannot feed that back into your model how you structure the teams, and so on. Then it becomes a cycle.

Martin: Yes, it's an evolution. We expect our architectures to evolve, at least we in this group, expect architectures to evolve. That also means our team organizations have to evolve and they have to evolve hand in hand. You can't separate the two. You'll constantly have to be thinking about that because you've got this, you know what's happening in the back of your mind. Conway's Law is that force is always present. Therefore, you have to work up both think about both sides of that force and make use of it instead of having to-- trying to fight it.

James: Then, of course, going back to, I think, back to the business capabilities I think they're used-- business capabilities, sometimes used interchangeably with the concept of domains from domain-driven design. For me, they can be subtly different. Business capability to me is not just the software-- the implementation of the software. It's not just the domain is realized in software. A business capability, going back to the old Microsoft definition, is the people, processes, and tools, where tools are the software that is part of that business capability that make up the stable parts of the business.

Now, this is an interesting thing with how products are going to evolve and how therefore the implementation of those products are going to involve. They should still be sitting in the context of a stable thing if you like.

It's still going to be an implementation of selling a product or delivering a product or fulfilling something or shipping something or one of these things. As an organization, we have to do. If you're a retailer, you're always going to have to sell stuff. That's what you do. The way you sell stuff is going to be different. The type of product you're going to build to sell those things is going to be different over time.

These days probably all your inventory is cough. I'm saying this to make Mike laugh in the background is probably on a blockchain, on a ledger. Of course, it is. With my tongue firmly in my cheek, I'm saying that, but the point of the capability is you're still going to have to sell stuff because you are a retailer, that's your business. Thinking about organizing your teams around those capabilities means that you've got a stable thing, which Conway's is-- Conway's Law you think is acting if you like to provide stability to the large-- to your enterprise architecture if you like, that's implementing those or part of those business capabilities.

Then, of course, within that, obviously things evolve, obviously, things-- and this I think is one of these-- one of the other things we've learned over the last, or reloads probably Martin will tell me is that things never-- Things are never stable. The idea of build it and you are done and we'll wipe our hands and then move on to the next thing, to the next project. Those days are gone. We should be expecting our product teams to be building products, learning, changing, reimplementing them, reimplementing the architecture underneath, et cetera, et cetera.

Birgitta: I find that interesting. I heard you talk about these business capabilities as the stable thing a while ago, and it was like a big aha moment for me in hindsight. Seems obvious, but, so if you compare that then to domain-driven design what I'm hearing you say, so the business capability is the abstraction level where you really feel like you're really having a safe bet. These are our like stable things, right? And then domain-driven design is in a way, it's always about this weariness of, "Oh, we might pick the wrong bounded context in the beginning, right?" But that's then an abstraction level that's much lower, right? There's constant and-- but you're supposed to feel a lot more confident about your business capabilities, yes?

James: I think so. There's a great diagram from back in 2010, I think there was a tool called Microsoft Vision, which is the enterprise architecture tool back then that some former colleagues of oursa, Ian Robinson and Jim Webber, showed me a long, long time ago, but they've got a diagram there which is level one capabilities, business capabilities, right? It's the same that every single company you walk into at the top level, it's the same stuff. You need to develop new products, right? You need to sell products or deliver products. Essentially there are a set of four or five things that every company has to do in order to run a successful business.

Birgitta: Or that every company that ship's product has-- that ships physical products has to do, or every company that like whatever business you're in has those specific capabilities.

James: If you're a bank, you have to do exactly the same thing. They're just a different set of products. If you're an insurance company, they're exactly the same thing. They're just a different set of products, right? So you still have to develop new loan offerings, new mortgage offerings. You then have to have some way of selling those mortgage offerings or selling those loan offerings, providing them to the public.

You have to have a way of managing the risk associated with those things, whether that's inventory that you're holding as physical goods or whether that's the inventory you're holding in terms of the investment of your customers in terms of the money you've led them or that they've given you for savings. Essentially at the macro scale, they're all the same. When you drill into those things, you then get different implementations depending on the sector, essentially.

All those things are stable and that's the crucial thing, but the other thing we need to think about as well, more or less, Martin, I can see Martin is squinting more or less because the boundaries are stable, but the implementation changes. I'll give you an example of that from a client I was at a while ago where they were talking about made-to-measure blinds. Initially, the way made-to-measure blinds were sold, blinds you have on your windows was that you'd go into a department store, you would arrange a time for someone to come into your house and measure those blinds, measure your windows. They would then fill in a form, take the form back to head office. They would fax the form somewhere. Someone would type that into a system somewhere. Because they were vertically integrated, they would then, the blinds would be built, would be manufactured in some factory somewhere. 12 weeks later, some person would turn up and fit them for you. Now that's selling made-to-measure blinds. That's how you provide those.

The capability to do so includes all the people as well as the software involved or the tools involved in providing that service to the customer. It involves the person coming to your house and measuring, it involves the person coming and fitting them, involves the factories essentially. That's the business capability of being able to sell those things. Now the interesting thing is, we don't have to do that now, you could still buy made-to-measure blinds, but you could use a laser measure it to measure the distance yourself.

You could take a photo of the window and scan it or send it to the retailer and they can work out based on photographic evidence instead of having someone measure it themselves, so that the way it's done is changing or changes. The fact that you are buying and they are selling made-to-measure blinds to you is essentially the stable thing.

Birgitta: Then to take it back to Conway's Law, so then that's also when you have one group of people who communicate directly with each other, who are responsible for that capability, it's a lot easier for them to be responsive to those changes than when you have that group of people also split up into layers or into different specialized departments or something.

James: Yes. Exactly that. Actually, what we see with our clients, in fact, is when they become-- the first step they take is to maybe reorganize the engineering department or the IT department along these lines. Along these business capability lines. Then the more advanced go on a step further on the journey and actually say, "Well, what we're going to do is we're going to bring not just the engineering department in to organize that way, but we're going to bring the engineering department and the business together into these capabilities."

You don't set the other side of, what was Martin's thing of the yawning, Chasm of Doom was that or Chasm of Doom from years ago. You don't sit the other side of the Chasm of Doom, from your colleagues in the business, but you sit together, you work as one team, and the communication is therefore much more effective again. That's Conway's Law in action again because it's about information flow. The rate at which you can get stuff done.

Birgitta: Yes. You can be responsive to the change that you described. Yes.

James: Yes.

Mike: We write about things, Johnny wrote this article back in 2010 and we put it on the Radar, the Inverse Conway Maneuver in 2014. A lot of this is within the ThoughtWorks bubble. James, you do a lot of time on the Conference circuit. What's your sense of how much adoption and awareness there is of Conway's Law in the industry?

James: I think Team Topologies has made it something that's at the front of many people's minds. Not just on the Conference Circuit but now most of the clients I'm not sure if it's the same for everyone on the podcast. Most of the clients I talk to now at least that's the-- It seems to be their leadership teams are reading team topologies and are talking about team topologies more so, actually, than folks who are "doing the real work."

There's a lot of interest amongst leaders and organizations now about team topologies and therefore I think by transferring if you like or inference if you like Conway's Law and the Inverse Conway Maneuver. People seem to be thinking a lot more about it than they have. I'm not sure whatever anyone else on the call, on the podcast thinks.

Birgitta: It's definitely at conferences of-- Like I said before, I've heard it mentioned a lot since the idea of microservices came up. It's almost to the point where sometimes also our clients, we mention it so much to them that at some point they almost get annoyed. You just see it everywhere. You see it everywhere once you realize it. I wonder so in the-- Conway's Law is a law but stuff changes around us. Technology changes.

Now we have all of this remote work which has a lot of impact on our communication structures. Are there any things you would say that have changed around the law that maybe changed how strong the impact is of the law in the architecture or changes the impact of the communication structures on the architecture or the other way around? Any changes over the last 10 years?

Martin: I think one of the interesting things is as we improve our remote communication structures across space and then particularly with pandemic when everybody was forced into more of a remote-first organization where everybody is at their own on their kitchen tables working with other people. That definitely has an effect because physical proximity makes a big difference to communication patterns. If you've got a team of people just having two teams on the same floor and different floors of the same building has a really significant effect on how they communicate, let alone putting them into buildings next door to each other on the same campus or buildings in the same city or teams in different cities. As you move people around, it really affects the communication flow. The question is, to what extent does both the presence of communication tools like Zoom that we're using to help make this podcast happen at all have and also the effect of the forced movement to remote first working during the COVID pandemic?

How is that going to affect communication patterns? Because whatever effect it has on communication patterns will ripple through into software architecture decisions. Conway's Law tells us that and I don't think there's any evidence to say that that won't change. What does change I think, is the way in which people work because of this now, greater comfort with remote working, greater demand for work from home and things of that-- as that's going to have a lot of interesting effects and we still don't really know how that's going to flow out.

I think we're still fairly sure that working remotely leads to less rich communication than working in the same close proximity, however good our technologies and working styles are, it's not the same. To what extent those trade-offs are going to impact across organizations, it's still, I suspect, too early to tell.

James: I seem to remember that there was a follow-up piece of research done by MIT. I think it was called a test of the mirroring hypothesis, which is the other name for Conway's Law. They found that the open source projects, in particular, you can see Conway's Law in action when you looked at large open source projects. I think they looked at the Linux Kernel as one example. You can sort of see how the limits can work developed in a way that was in accordance with Conway's Law, if you like, individual people working on individual parts of it, and then submitting those changes centrally et cetera.

On the one hand, we do know that Conway's Law that, obviously, it holds, as Martin says, it's just the law, it's just the way things work for open source projects previously. What I think I totally agree with Martin on is we don't know what's going to happen now that we're in this weird hybrid world, where we're not just sitting working on our own little bit of kernel code, and then submit a pull request to the project committers, but instead we're working on our own little world, whilst also with some form of richer bandwidth communication. I'm not sure. I think we'll just have to see how it pans out.

Birgitta: I guess as we'll then also-- it might be interesting to see companies who work differently even in this hybrid remote setup. I see some companies who are very comfortable with more asynchronous communication where there's lots of stuff going on in the chat, or they're looking at more ways to asynchronously coordinate. Then other companies who are having a harder time doing that and who still do a lot of synchronous communication just on different tools and doing it remotely.

I wonder if that also has somehow an impact either on architecture or on code basis, maybe. When you maybe start pairing less or something like that. To wrap it up, we reflect a little bit on Conway's Law, Inverse Conway Maneuver and more nuanced things we learned over the past 10 years. How would you summarize the state of the union when it comes to Conway's Law, Martin?

Martin: Well, the way I would summarize it up is that if you're going to be-- want to be a competent software architect, you have to be aware of Conway's Law and thus have to be interested in the design of software development organizations. Unfortunately, you may think your job is only about technical stuff, but no, it's about people and about organizations and the way they work because that's going to have a huge impact upon any software architecture. Whenever you, as you build and as you evolve your software architectures, you've also got to evolve a team organization hand in hand. You've got to be paying attention to both sides of that.

As a way of suggesting help is a couple of books that I can recommend. One we've mentioned already Team Topologies, that's had quite a lot of interest recently and really very much embraces Conway's Law. They have whole chapters on Conway's Law to open it out and another one I'd mention as well, that covers very similar ground is Agile IT Organization Design, which was written by a colleague of ours, ‪Sriram Narayanan‬. That also looks at very much similar kinds of topics. If you're going to be a software architect, you've got to also be an organizational designer as well, you may not like it, but I'm afraid that's the way it goes.

Birgitta: Cool. Well, thanks Martin and James for joining Mike and me in this conversation. See you next time.

James: Thank you. It's been fun as always.

[music]

[END OF AUDIO]