TL; DR: A concept originally coined in the late sixties is now taking the business world by storm. Conway’s Law, an adage that stresses the importance of team communication to produce successful products, is transforming how we view work and how teams should organize to make incredible ideas a reality.

Confused teams. Siloed information that takes too long to reach people who need it. Leadership that doesn’t consider critical feedback from key stakeholders. High-performing software development teams know that great products don’t result from disorganization and poor communication. 

While ensuring communication, transparency, efficiency, and best practices is challenging in every field, the demands and complexities of software development require distinct and well-defined frameworks to produce results — like the theory behind Conway’s law.

Conway’s law says that how teams communicate has a big impact on what they design. In practice, this relatively straightforward theory can have big implications for digital product development. Let’s explore what it is, how teams employ it, and how it can help optimize outcomes in software projects.

Conway’s Law explained

Let’s back up. Computer scientist Melvin Conway’s original idea, published in 1967 in one of the most important IT magazines at the time, states that organizations create system designs that mirror their own internal communication structure. Because communication structures have important implications in system design, then, they should be a relevant criterion when organizing any system.

Conway’s original article didn’t go as far as stating that the product resulted from communication structures, but others took the next leap. Computer scientist Fred Brooks went on to call it Conway’s law for the first time in 1975. Later, a group at MIT and Harvard Business School went on to show that an organization’s governance and culture set the space and limits to the work that results, validating Conway’s law and the idea that organization and product are closely related.

So, here’s the takeaway: teams create software mirroring their communication patterns of processes. For two software modules to integrate correctly, both sets of developers need to speak to each other effectively. An architectural decision can affect how a team works and the other way around. And that makes sense. 

How Conway’s law works: Two case studies

Conway’s Law doesn’t simply make sense on paper or a screen: organizations can ensure they’re building products when their processes and communication channels are clearly stated. These two case studies of big tech companies illustrate how this concept impacts outcomes in software development. (CBInsight)

Apple uses an organizational structure known as unitary organizational form. Their main objective is “that the company should be organized around functional expertise rather than products.” In other words, instead of dividing their company into product categories, they prefer to organize it into disciplines. The end result is a unified experience where no product steers away from the company’s vision and feel.

There’s no single way of following Conway’s Law, as GitHub’s case shows. According to the CB Insights report above, the company is “intentionally structured like one of the open-source projects the service hosts: decentralized, autonomous, and asynchronous.” What does this mean? There’s no entry time, and work is self-directed. Instead of having daily stand-ups, people use only chat or email. 

Although this latter concept may seem a bit extreme to many leaders, bear in mind that GitHub is a tool created for developers based on decentralized collaboration. In that sense, GitHub successfully mirrors the product they offer. They allow their teams to work collaboratively and in a decentralized manner. 

At Blankfactor, great communication fuels great collaboration

An understanding and application of Conway’s Law helps prevent common communication issues. It emphasizes training, best communication practices, proper documentation, and encouraging feedback in leadership positions. That’s why we invest in developing all of these areas across the organization at Blankfactor — and why we promote them when we go on to train teams at our partner organizations. 

Our engineers, product managers, UX designers, and other tech talent are versed in more than technical skills. We know it all starts with communication, and employ those best practices from end to end of the delivery process. We listen to our clients to deeply understand their business needs, developing cutting-edge technical solutions hand-in-hand with our partners. Then, we take ownership of a project. We actively provide input, seek out feedback, and work to ensure our clients see the best possible outcomes. 

Great communication means great collaboration, and teams produce great products by working together effectively. That’s how we help companies innovate, scale, and transform — fast. 

Partner with a high-impact engineering team

From data and digital engineering to product development to enterprise AI, we deliver the tailored digital solutions you need for your business. Ready to see engineering impact and faster time-to-value? Contact us today for a 60-minute solution session.

Was this article insightful? Then don’t forget to look at other blog posts and follow us on LinkedIn, Twitter, Facebook, and Instagram.

Author