Conway’s Law In 1968, Melvin Conway wrote the paper “ ”. One of his observations in that paper (among numerous interesting ones) was declared Conway’s Law. Conway’s Law states — . How Do Committees Invent Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure Conway talks as much about the software that is produced as he does about the organizational structure producing it. Much has been written in support of micro-services architectures, using Conway’s Law as a base premise and justification. These articles focus on Organizational design at the team level. They propose small teams that work on independent small services. I do not have any qualms with these recommendations. They do, often, ignore the impact the larger org structure can have on the software being produced. If team structure determines the design of the software and interfaces, the broader org structure determines the quality of customer outcomes achieved. Conway’s Effect on Products Consider the structure of an organization as shown below. The first thing to notice is that the customer (on the left hand side of the drawing) has no direct line to the development team. The vice-versa is true as well. Customer has to go through Product or Support to get to development. Development teams themselves have to go through either Product, PMO, Operations or Support to get feedback from customers. Conway’s Law, when applied to this setup would mean that since developers are a one or two layers removed from the customers, the features and products they produced are likely to be one or two steps removed from the real needs of the user. Each group has multiple masters. Product is directly responsible for satisfying feature and enhancement requests from Customers, Sales and Support. Product is also responsible for providing structured requirements and priority updates to the Development teams as well as PMO. This forces the Product department to create a mixed set of priorities which most likely is not directly representative of the priorities of the customers. Development teams, already one step removed, receive this mixed list of priorities. For the dev teams though, this is just one “customer”. They also have to satisfy directly received tickets from Support, provide timelines to PMO, deployment requirements to Operations all while satisfying the overriding directives from Architecture. Each group also has its own objectives and incentives. Sales wants flashy items to sell, Customer Support wants low time to resolution on calls, Product wants maximum number of complete features, Development wants new technology and maintainable code and Operations wants easily deployable, portable and stable products. Everyone is pulling in slightly different directions, with customer satisfaction, delivery of customer value and fulfillment of customer outcomes lost somewhere in the middle of the tug-of-war. All this is happening, while each member of each department is doing their best and working hard to achieve the department’s objectives. The lack of alignment sets Conway’s Law into motion. The result of this is usually a confused (or an increasingly confusing) product. The separate departments push their separate agendas onto the end product. The product, as a consequence, has lots of features, but most of them are incongruent and rarely used. With the teams developing the product being a couple of layers removed from the customers, this feedback rarely makes it back to them. Even if it does they are already on to the next thing on some other department’s priority list. The competing and misaligned priorities for each department leads to the actual customer priority being lost in the shuffle. Each department firmly believes they are doing the best thing for the customer and the misaligned priorities result in customer’s best interests being only half-fulfilled at best. Conway’s Effect on Process It is not just the priorities that are mismatched, the departments have different capacities and speed of production as well. This would mean finished work sitting between departments in queues waiting to be picked up. It could also mean departments being starved for work as they are waiting for deliverables from other parts of the system. Instead of the process enabling a lean flow of value to the customer, the value generated sits in queues despite everyone doing there best to achieve their department’s goals. The structure and mismatched capabilities make flow very hard to attain. If we restate Conway’s Law in terms of process, it would fit perfectly — . Any organization that follows a process will inevitably produce a process whose structure is a copy of the organization’s communication structure Even within, what is supposed to be a cohesive team, the separation of concerns persists. This is usually because the departments themselves are not in alignment on objectives, priorities or incentives. We can try to solve this be moving folks from the product and operations teams onto the development teams. This can at times work, but as long as the individuals serve separate masters and have varied incentives, bad, inefficient processes will emerge. If BAs and PMs are made a part of the development team, but still serve a separate product department, they are receiving mixed signals. Many times, not always, they tend to act as teams within the larger team. Due to this, there is a “not my job” and “over the wall” mentality that develops on the team. High level requirements are the PM’s job, writing stories is the BA’s job, writing and testing code is the developer’s job and deploying the code to production is the OPS person’s job. Even within, what is supposed to be a cohesive team, the separation of concerns persists. This is usually because the departments themselves are not in alignment on objectives, priorities or incentives. One quick note on DevOps. If you put a person from the operations team onto the dev team and all that person does is OPS work with no interaction with the devs, it does not mean that you are “doing” DevOps. For DevOps, developers take on operations responsibilities and operations folks help out with development. With separate objectives and incentives, the queues will still exist. Value will still sit in these queues and becomes stale. Stories and features would be coded and tested weeks or months after they are written. The same will happen for deployment activities. Finished work will not make it to customers months after it was done. This would cause disappointment for any customers of this process as their wait times keep increasing. An increase in inter-department wait times leads to increased mistrust among already segregated departments. Departments do not believe that their partners are moving fast enough and push more and more work downstream. Sales does it to Product, Product to Development and Development to Operations. The overriding belief becomes — “in order to get more done, we need to push more work onto them”. This is where Little starts helping Conway. Little’s Law In 1961, John Little provided mathematical proof of the queuing formula that has come to be known as Little’s Law. In the development world, it is commonly expressed as follows — Here Lead Time(or Cycle Time) is the amount of time it takes for a work item (task, story feature, initiative etc.) to get done. Work In Progress (WIP) is the total number of items in progress. Throughput is the number of items getting done per unit of time (per day, per week, per month etc.). Little’s Law is a truth of nature. It is mathematical fact and is inescapable. The simple conclusion from Little’s Law is that if we have a consistent speed of getting things done, the amount of time it takes to do each thing, is directly proportional to the number of things we are working on. In other words, if we want to get things done faster, we need to work on fewer things. One important thing to remember is that this applies at every level of granularity. It applies at the story level, the feature level and the initiative level. Conway and Little — Putting the WAR in softWARe since 1960s. As we have already discussed, one of the consequences of an organization splintered along specialization departments is sibling departments pushing more and more work onto each other. Unfortunately, according to Little’s Law this only makes things worse. The more things we take on , the longer each individual thing takes. As opposed to delivering individual bits of value to the customer, we work on everything and deliver nothing. Since everything takes a long time, we try to subvert the process by having “fire lanes” and high priority expedites. Unfortunately, these are not exempt from Little’s Law. They only increase the WIP. Also, because we have done nothing to increase our throughput, all this does is increases our cycle times for each deliverable. Increased cycle times, fuel more frustration, greater mistrust and increased friction between departments. Once again, the customer and, as a consequence, the company comes out as the loser in the struggle. Conway And Little Are Your Friends So far we have only explored the negative effects of Conway’s Law and Little’s Law. The fact is that these two are our friends. They can help us design our organizations for success and then execute on the design. First let us define what success means, then design the organization around that definition of success and finally establish flow to become successful. Conway will help us design the organization and Little will help us establish flow. What if we took a very simple definition of success — Achieve positive outcomes for the customers. This would require creating alignment between all the moving parts of the organization. The sketch below is how I would propose we create an organization to achieve success. In this organization every team is actually cross-functional. Every team member can be involved in every activity. Product owners can bring developers along for customer interviews. Devs can break down stories, BAs can test, and we are actually doing DevOps where developers are taking care of operational needs as well. Each team has every capability needed to get requirements, create functionality, deliver code to production, receive feedback and support the product. A team is responsible for that entire life-cycle of that particular piece of functionality. Everyone on the team is able to get user feedback and help in reacting to that feedback. Each team is a fully cross-functional startup. They are able to move fast and support each other when things start to back up. There is no segregation of responsibilities. Sure there are “roles” that signify expertise, but people are encouraged to help in every part of the process. There is a singular objective for the entire team — Help customers achieve positive outcomes. The team can be as large or as small as needed to achieve this objective. They report into the same department. They are all incentivized to do the same thing — deliver customer value. We get rid of hand-offs and work with continuous customer validation of the artifacts produced. There are no competing masters, just a team being able to take care of customer needs all by itself. Unlike Little’s Law, which is mathematical fact, Conway’s Law can be (temporarily) escaped. You can keep the traditional structure and drive alignment across departments. Since that is root of the problem, once cross department alignment is achieved everyone will naturally act as a single team. The problem is the energy required to maintain the cross department alignment. As soon as these departments start having their “all team” meetings, department objectives, execution standards and their own bonus plans, Conway will again take over. The decision to make is — Do we go through the pain of formalizing a cross functional org structure or do we continuously spend the energy to maintain alignment across departments? Conway just helped us set up an organization and establish a process (at a very high level). We can still run into problems if we do not pay attention to Little. In order for us to establish flow and quickly deliver value for validation, we need to go back to Little’s Law. We need to continuously observe the amount of work flowing through these teams. The teams should take on only as much work as can flow through their process. As Little’s Law tells us, with stable throughput, the more things we work on, the longer things will take to get done. Little’s Law makes us focus on being productive as opposed to being busy. It is likely that in the organization proposed here, there would be large teams. Also, teams would not consider something done until the customer has validated it. These two things combined will have a tendency for teams to take on more work than they should. In order to achieve regular validation and delivery of functionality, Little tells us that we have to resist this urge. Work on as few things as possible, so that each individual work item gets delivered as quickly as possible. This will get the energies of the entire team focused on getting those few work items delivered. As soon as one item is delivered, the team can figure out the next highest priority and start working on that one. Thus, creating a stable, predictable system that delivers functionality regularly and is not derailed easily by external pressures and changes. Little’s Law makes us focus on being productive as opposed to being busy. When things do change in terms of priority, very few items are put at risk. In fact, if the team is delivering things regularly(hourly, daily, weekly…), nothing might be put at risk. This is because the new highest priority can be picked up for work as soon as the next (currently active) item is delivered. Thus, we can use Little’s Law to eliminate a lot of waste due to changing priorities. When we work on very few items, they do not wait in queues between departments or individuals. As we are working on these together, these queues either do not exist or are minimal. Conway and Little have together helped us eliminate the waste that accumulates due to valuable work sitting in inter-department queues. This Is Hard It is, primarily because this type of thinking requires people to give up power. It simplifies the structure where the “product design, development and delivery” team has all the power and most hierarchies are dead. If the folks in the organization are attached to wielding control and personal authority, this would be such a hard change that people might not even attempt it. Just as listening to Conway would be hard for power addicted managers, listening to Little will be hard for the individual contributor superstars. There is no individual glory anymore. There are no martyrs and heroes. The teams work together, across erstwhile functional boundaries to do the best for our customers. There is a good amount of giving up of personal egos that has to happen here. Everyone has to accept a flatter organization where we are all working together to achieve our most important goal — Positive Customer Outcomes. Here is the other hard thing. If you notice, I have eliminated PMO and Architecture from the second org sketch. It is possible that entire departments would be eliminated and handed “demotions” to be a part of the value delivering teams. It might just turn out that Little will eliminate the need for PMO and Conway would encourage us to turn Architects into developers that work towards customer outcomes. There is a good amount of giving up of personal egos that has to happen here. Everyone has to accept a flatter organization where we are all working together to achieve our most important goal — Positive Customer Outcomes. Conway and Little can be lethal for traditional power structures and individual glory. But, on the other hand, they can save your organization as opposed to killing it.
