top of page
  • Writer's pictureMike Freislich

Combat the negative side-effects of Conway's Law using Flight Levels

Work System Topologies and Flight Routes vs. Org Charts

In my experience, all organizations struggle to find the right balance between structure and unbounded creativity or innovation. If we focus too much on unbounded creativity, we might lose touch with what is being worked on, what will be delivered and when it will be delivered. If we focus too much on structure and hierarchy, this can cause detachment from purpose, decision-making bottlenecks and an abundance of unproductive meetings.

Conway's Law is a principle named after the computer programmer Melvin Conway, who introduced it in 1967. Conway stated,

"Organizations which design systems, are constrained to produce designs which are copies of the communication structures of these organizations."

Put plainly, Conway's Law suggests that the design of a system (such as software or any complex product) will mirror the communication structures of the organization that created it. If an organization has multiple teams working on a product, the interfaces and modules of the resulting system will reflect the ways these teams interact - the flow of operational information.

In their book, "Team Topologies", Matthew Skelton and Manual Pais introduce some novel ways to think about organizational design in software development. They suggest that if you allow your Human Resources or Organizational Design people to control the org-chart, then due to the effects of Conway's law they become the accidental architects of the products that result from the organizations efforts. They go on to suggest that it might be a better approach, given Conway's law, to decide on the architecture that would best suit the product, and design the organizational structure based on that - this technique is dubbed, "The Reverse Conway Maneuver".

This got me thinking about what we do in Flight Levels Systems Architecture. First, in Flight Levels®, we don't constrain our thinking of structure to only that of software development organizations. We don't focus specifically on the detailed technical architecture of products (unless it arises as a key factor in design for a specific organization), but we do focus in-depth on the communication pathways that generate value for the organization and it's customers.

Communication pathways, analogized as Flight Routes in Flight Levels®, represent the flow of value through an entire value stream, often crossing multiple organizational silos and bridging the hierarchy of an organizations decision-making constructs. "Communication structures" mentioned in Conways law are typically exposed in the way that an organization expresses it's management structure on an org chart, together with how meetings and decisions happen. This is the very structure that will constrain how problems are solved by the organization, and if defined poorly for the products and services provided, will serve to confound the flow of value.

Flight Routes detail how work traverses the organization as an operational necessity, despite the org chart definitions and existing meeting cadences. In Flight Levels, we look at different types (levels) of decision-making, namely: Operational (Flight Level 1), Coordination (FL2) and Strategic (FL3). It should be noted that while one could map existing org-chart hierarchy layers to Operational, Coordinative and Strategic, this is not the intention of Flight Levels. The levels (1 2 and 3), are not a hierarchy. Rather they speak to the kind of decisions and work that is happening. For example, strategy thinking doesn't only happen in the executive suites of an organization. Strategy might exist for a group of companies, a company, a product, a technology, a team or even an individual. So strategy can and should happen anywhere in an organization. Thus we could find Flight Level 3 systems at all layers of hierarchy.

A Flight Levels System can be described as a group of individuals with a common purpose, the interactions they have to make and track progress towards their mutual goals, and a visible board that contains the work items and necessary indicators and information needed to synchronize their efforts.

When designing a Flight Levels Systems Architecture we seek out all of the potential, value-driven coordination points where specific groups of people, regardless of their position in the org chart, would do well to coordinate their efforts. In other words we are seeking out all potential FL2 systems that might exist in the organization. Typical FL2 candidates are customer facing Products and Services, Platforms (widely used internal products), Enabling Functions (e.g. HR and Legal) and Pop-up systems (e.g. a temporary coordinative effort such as responding to new legislation like GDPR).

While each of these potential systems on it's own represents coordination, the real picture (a work systems topology) comes together when we look at the inter-connectedness of these FL2 systems. In other words, how are are the products, services, enabling functions and so on connected, specifically where it comes to communication and operation. If we take care about how work flows across and between these systems, this is a powerful tool to define more appropriate interactions and meetings that involve the right people at the right time, breaking down the knowledge and decision-making silos that otherwise cause contextual obfuscation, delays and misunderstanding of product intent. We are examining the ecosystem of the organization itself, to create harmonious interactions that keep our eyes on the prize of value generation spanning all layers of the org chart.

When we place emphasis on the communication structures that promote getting work done and organize our interactions (company wide) around delivering value to our customers, we begin to notice a great many potential areas for improvement. While we consider the whole organization, or a significant vertical within it during the design process, the intent is to work iteratively, incrementally and scientifically in terms of change management. A big bang approach seldom ever works. We think big, so that we can act small in the right area of the business to leverage the greatest benefit. Once realized we can adapt our understanding of the whole, and find the next area to evolve.

An important note: It is not necessary to change the org chart in order to change the way that organization-wide communication is structured. Rather we need to change the way we visualize strategy, coordination and operational work and redefine the behaviors and interactions that surround it. Org chart evolution may happen over time as a result, but is likely not the first responsible step.

In summary, with Flight Levels Systems Architecture, we are examining the architecture of the eco-system of value generation, with a view to aligning intra and inter team and product communication to the leanest and most direct approach to getting the results that we need. In this way we can bypass many of the burdening constraints applied by existing organizational structure, and reap the benefits.

25 views0 comments

Recent Posts

See All


bottom of page