Conway's Law states that "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
It was first posited by Melvin Conway in the 1960s, and it's a hard constraint on software, networks, and other formal technical systems. What it says is that code is generated by human systems, and these limit how it will work. All software contains the same patterns and relationships that exist within the social systems of the organisation that created it. There's now good empirical support for the hypothesis, too with a paper published the Harvard Business Review finding that closed-source software produced in a single location tends towards a single, monolithic codebase, whereas distributed open-source projects tend towards modularity.
Large organisations typically have support structures around those actually producing code or designing systems. There's management, procedure, and a whole host of other things which act to align the creation of something more tightly-coupled that would otherwise be the case. On a volunteer-led open-source project, this support structure is largely or entirely absent. There's no project manager to get everyone in a room, or set of coding standards which make it easier to write a complex interface. At best, there's a mailing list, or a forum, with perhaps a wiki to provide a bit of structure. It's therefore much easier to break the code into smaller pieces which can be tackled by individuals or a very small group.
Conway's Law has a really important implication for IT projects, and indeed for anything which results in the development of a formal system. That is, for things to work properly, your organisational structure must reflect the architecture of the system you're producing. This has some major implications for the static org chart that exists in many, many organisations. It suggests that cross-functional teams with a single goal are likely to produce far better products more efficiently than those who are part of separate, single-function teams. It also means that if you want the kind of tightly-coupled, low hand-off cost process which is the hallmark of something like Six Sigma, you need to make sure that there is the social structure around the process is just as robust.
Failing to do this results in two very unpleasant outcomes. The first is that the production of the product will cost more for a given quality than it would from an organisation in which architecture and structure were aligned. Tensions which exist between groups will result in a product who's structure does not systematically fulfil its design goals. This will make the thing harder to develop, to fault-find, and to maintain. The second, perhaps subtler, but equally troubling outcome is that product will reflect the concerns of the organisation and those in it, rather than those of the end-user. This results in a system with unnecessary functions, inexplicable behaviours, and other quirks which lead to considerable user dissatisfaction. It's not possible to engage in user-focused design unless the organisation itself, its social structures and culture, are also user-focused.
There's an important corollary of Conway's Law which also has considerable influence over the end-user experience. The affective state which a product generates in its users will be a reflection of the affective state of the people who created it. In other words, a happy team makes products which make customers happy, and a miserable team makes products which make customers miserable. We've all experienced using something finely crafted and well thought through. Perhaps it was a car, or a really well made meal at a high-end restaurant. Whatever it was, it was the product of a high degree of team cohesion, and a lot of intrinsic motivation to deliver a product that was truly great. That just doesn't come about with an unhappy team.
It's also the case that if you want long-term engagement with your customers, you're going to want long-term engagement with staff. People build a relationship with and develop an attachment to the products they use, even if you develop business tools. Particularly if you develop business tools. There's abundant evidence that happier employees are good for the bottom line even of you don't produce the kind of systems we're talking about. They make customers happy. If you're selling a business application and you can make your customer's users happy, they get a nudge along the way in their own workplace happiness and all the benefits that brings.
Whether you're in charge of a whole organisation, or simply taking the lead on the smallest project, you need to be mindful of Conway's Law because it can radically affect outcomes. Even if you're simply contributing, by forging better social links with your colleagues you can create a more cohesive product and deliver something which end-users will enjoy. Ultimately, again, this demonstrates how important a happy, positive working environment is. This isn't just because it's the right thing to do (although it very much is), but because it's the only way to make things that people will actually want to use.
It was first posited by Melvin Conway in the 1960s, and it's a hard constraint on software, networks, and other formal technical systems. What it says is that code is generated by human systems, and these limit how it will work. All software contains the same patterns and relationships that exist within the social systems of the organisation that created it. There's now good empirical support for the hypothesis, too with a paper published the Harvard Business Review finding that closed-source software produced in a single location tends towards a single, monolithic codebase, whereas distributed open-source projects tend towards modularity.
Large organisations typically have support structures around those actually producing code or designing systems. There's management, procedure, and a whole host of other things which act to align the creation of something more tightly-coupled that would otherwise be the case. On a volunteer-led open-source project, this support structure is largely or entirely absent. There's no project manager to get everyone in a room, or set of coding standards which make it easier to write a complex interface. At best, there's a mailing list, or a forum, with perhaps a wiki to provide a bit of structure. It's therefore much easier to break the code into smaller pieces which can be tackled by individuals or a very small group.
Conway's Law has a really important implication for IT projects, and indeed for anything which results in the development of a formal system. That is, for things to work properly, your organisational structure must reflect the architecture of the system you're producing. This has some major implications for the static org chart that exists in many, many organisations. It suggests that cross-functional teams with a single goal are likely to produce far better products more efficiently than those who are part of separate, single-function teams. It also means that if you want the kind of tightly-coupled, low hand-off cost process which is the hallmark of something like Six Sigma, you need to make sure that there is the social structure around the process is just as robust.
Failing to do this results in two very unpleasant outcomes. The first is that the production of the product will cost more for a given quality than it would from an organisation in which architecture and structure were aligned. Tensions which exist between groups will result in a product who's structure does not systematically fulfil its design goals. This will make the thing harder to develop, to fault-find, and to maintain. The second, perhaps subtler, but equally troubling outcome is that product will reflect the concerns of the organisation and those in it, rather than those of the end-user. This results in a system with unnecessary functions, inexplicable behaviours, and other quirks which lead to considerable user dissatisfaction. It's not possible to engage in user-focused design unless the organisation itself, its social structures and culture, are also user-focused.
There's an important corollary of Conway's Law which also has considerable influence over the end-user experience. The affective state which a product generates in its users will be a reflection of the affective state of the people who created it. In other words, a happy team makes products which make customers happy, and a miserable team makes products which make customers miserable. We've all experienced using something finely crafted and well thought through. Perhaps it was a car, or a really well made meal at a high-end restaurant. Whatever it was, it was the product of a high degree of team cohesion, and a lot of intrinsic motivation to deliver a product that was truly great. That just doesn't come about with an unhappy team.
It's also the case that if you want long-term engagement with your customers, you're going to want long-term engagement with staff. People build a relationship with and develop an attachment to the products they use, even if you develop business tools. Particularly if you develop business tools. There's abundant evidence that happier employees are good for the bottom line even of you don't produce the kind of systems we're talking about. They make customers happy. If you're selling a business application and you can make your customer's users happy, they get a nudge along the way in their own workplace happiness and all the benefits that brings.
Whether you're in charge of a whole organisation, or simply taking the lead on the smallest project, you need to be mindful of Conway's Law because it can radically affect outcomes. Even if you're simply contributing, by forging better social links with your colleagues you can create a more cohesive product and deliver something which end-users will enjoy. Ultimately, again, this demonstrates how important a happy, positive working environment is. This isn't just because it's the right thing to do (although it very much is), but because it's the only way to make things that people will actually want to use.
Comments
Post a Comment