Convergence of Software Engineering Productivity in Changing Organisations
Module 1 of 6 Intermediate 40 min

Why Engineering Productivity Always Finds Its Level

What you'll learn

  • Why engineering productivity settles at a stable level — the productivity baseline — rather than trending indefinitely upward or downward after disruptions.
  • The four structural forces (team topology, cognitive load, communication overhead, and decision-making latency) that govern where that baseline sits.
  • Why gains from new technology are absorbed and stop compounding over time, while structural changes can permanently raise the baseline.
  • How to distinguish a temporary disruption-and-recovery pattern from a genuine, lasting shift in what your organisation can sustainably deliver.

Why this matters

You have probably been promised that the next framework, the next platform, the next tool will be the one that finally moves the needle permanently. And in the short run, something usually does move — velocity picks up, incident rates drop, deployment frequency climbs. Then, six to twelve months later, you look at the numbers and the gains have quietly eroded. Teams are busy, things feel different, but the output has crept back toward where it always was.

This is not a failure of ambition or execution. It is convergence — the observable phenomenon that engineering productivity seeks its structural level despite disruptions. Understanding it is not defeatist; knowing that productivity will converge tells you where to aim your interventions. If you know that technology adoption alone will converge back to the baseline, you can stop over-investing there and focus on the structural changes that actually raise it. That shift in attention is what this curriculum is about, and this module is where the logic starts.

Core concept

Engineering organisations are not simple input-output machines. They are complex systems governed by structural constraints — constraints that do not bend easily to technology upgrades, enthusiasm, or management pressure. The central claim of convergence theory is this: productivity is not on an indefinite upward trend; it oscillates around a structural attractor.

That attractor is the productivity baseline: the stable level of engineering productivity an organisation settles at, determined by structural constraints. This is where productivity is when the organisation is neither in disruption nor actively improving its structure.

The four structural governing forces

Four factors set where the productivity baseline lands:

  1. Team topology — who owns what, where the boundaries sit, and how work flows between teams. Misaligned boundaries create handoff overhead and rework. Aligned boundaries reduce coordination costs and enable faster, more autonomous delivery.

  2. Cognitive load (team) — the total mental demand placed on a team by its domain scope, tool complexity, and coordination overhead. Every team has a finite cognitive budget. When that budget is consumed by extraneous process friction, there is little left for the valuable learning that actually moves things forward.

  3. Communication overhead — the cost of keeping people aligned across team boundaries. This cost scales super-linearly as team count and dependency density grow. It consumes engineering time invisibly and relentlessly.

  4. Decision-making latency — the delay between a decision being needed and it being made. In organisations with unclear ownership or over-centralised authority, decisions queue up, blocking downstream work and eroding flow.

These four forces are not friction to be reduced by working harder or communicating better; they are structural constraints. They behave like physical dimensions of the organisation. A team cannot sustainably produce above the ceiling these constraints impose any more than a pipe can flow faster than its bore allows.

This ceiling is the structural ceiling: the maximum sustainable productivity level achievable given the organisation's current team structure, cognitive load distribution, and communication patterns. The productivity baseline trends toward the structural ceiling over time. When the two align, the organisation has reached equilibrium — a dynamic stability where small disruptions cause temporary deviation but the system returns. ("Equilibrium" is used here to emphasise that dynamic stability; "productivity baseline" remains the default term throughout this curriculum.)

Adaptation absorbs innovation

Introduce a new technology and something real happens at first. Teams experience reduced boilerplate, faster feedback, lower incident rates. That initial boost is genuine. But it is also temporary.

As the technology becomes familiar, it is absorbed into existing workflows and mental models. The gains flatten — not because the technology stopped working, but because the underlying structural constraints reassert themselves. Teams are still communicating across the same boundaries, still carrying the same cognitive load across too many domains, still waiting for the same approval chains. The technology has been integrated into the old structure, not around it.

This is the adaptation absorbs innovation principle: new technology becomes "normal" and stops yielding gains. As one influential analysis from the 1980s put it, most technological improvements address accidental complexity rather than the essential, irreducible difficulty of software work — a distinction explored in depth in Module 04. The structural forces governing the baseline are part of that irreducible difficulty.

The baseline can be raised — but only one way

There is an important nuance here, and it is essential to state it clearly so the module does not leave the wrong impression: the productivity baseline can be raised, but only by changing structure, not by waiting.

Some disruptions do result in a productivity level above the prior baseline. This happens when the disruption is accompanied by genuine structural change — new team topology, reconfigured ownership, reduced cognitive load through better service boundaries, or flattened decision paths. In those cases, the organisation converges to a higher baseline.

Without structural change, it converges back to where it started. The disruption-recovery pattern brings you home, not forward.

Brief examples of what structural change looks like (these are explored in depth in Module 03): redesigning team boundaries to align with value streams, reducing the number of domains a single team owns, creating a dedicated platform capability to absorb shared infrastructure concerns, and decentralising decision authority for routine technical choices. These are not process tweaks or cultural campaigns — they are changes to the architecture of the organisation itself.

Concrete example

Apex Engineering is a 200-person software engineering organisation inside a mid-sized financial services company. In Year 1, Apex migrates from a monolithic payments platform to a microservices architecture — a substantial technical change that the leadership team expects will meaningfully accelerate delivery.

In months 1–4, velocity drops 25%. Developers are learning new deployment pipelines. Debugging has become distributed and harder to trace. Communication overhead spikes as teams coordinate across service boundaries that didn't exist before. This is painful but expected — there is a real learning cost.

By month 8, velocity recovers close to its prior level. The engineering director looks at the numbers and sees almost exactly where they were before the migration. Not catastrophically below — but not above, either.

Why? Because the team structures did not change. Developers still own loosely-defined slices of the system rather than end-to-end service boundaries. The same five teams that collaborated heavily on the monolith now collaborate heavily across microservices, with added coordination cost from the service boundaries. The structural forces — team topology, cognitive load, communication overhead — are essentially unchanged. Velocity has converged back to the productivity baseline because the structural ceiling was not raised.

This is not a failure of the microservices migration. The migration may well have improved system resilience, deployment flexibility, and long-term maintainability. But it did not raise the productivity baseline, because it did not change the structure that governs it.

This is the disruption-and-recovery pattern that Module 02 will name and shape precisely. For now, the key observation is: Apex's velocity dipped, recovered, and converged — exactly where convergence theory predicts.

Analogy

Imagine a river flowing through a network of channels and dams. If you add more water — new investment, new tools, extra engineers — it flows faster initially. But it quickly settles to a level determined by the width and depth of the channels, the height of the existing dams, and the slope of the terrain. The channels and dams are the organisational structure. They determine the sustainable steady-state flow.

Adding water does not change the channel dimensions. Reengineering the channels does.

That is why technology adoption without structural change is adding water to an unchanged channel system. The level rises briefly, then settles back. The water has found its level — the level the channels allow, not the level you wanted.

A complementary illustration: think of a car engine in different gears. When you shift from third to fourth gear, there is a moment of disengagement before the new gear catches and the RPM settles. The car does not permanently run faster in fourth; it runs at a stable RPM set by the gear ratio and the engine's characteristics. Change the gear ratio — change the structure — and the sustainable RPM shifts. Technology is not a gear-ratio change; it is, at best, fuel quality. Better fuel helps at the margins. Only a different gear ratio moves the steady-state.

Going deeper

The convergence phenomenon connects to a long-running debate in economics: the productivity paradox. Economists observed in the 1980s and 1990s that massive investment in information technology had not produced the expected macro-level productivity gains. Robert Solow captured the puzzle in 1987: "You can see the computer age everywhere except in the productivity statistics."

The resolution that emerged over the following decade is consistent with convergence theory: firms that invested in IT and restructured their organisations and processes around it did see sustained gains. Firms that adopted the technology without organisational redesign saw the gains absorbed and flattened. The technology was necessary but not sufficient. The structural changes were the differentiating factor.

This pattern reappears with each technology wave — enterprise resource planning systems in the 1990s, cloud migration in the 2010s, AI-assisted development now. The initial gains are real. The question is always whether structural redesign follows, or whether the organisation absorbs the technology into its existing shape and converges back.

Conway's Law adds a precise mechanism to this story. The principle states that organisations design systems that mirror their communication structures. This means team boundary misalignment creates architectural friction that exerts a constant drag on productivity. Every microservice owned by a team that still communicates across five other team boundaries is a microservice that has not actually reduced coordination cost. The structural ceiling is partly a function of this alignment — or misalignment. You cannot escape Conway's Law by adopting a new architecture; you escape it by redesigning the organisation alongside the architecture.

Common misconceptions

Misconception 1: "New technology will permanently boost our productivity."

This is the most common assumption going into a major tooling or platform adoption. The initial boost is real, and it is worth something. But without structural change accompanying the technology, productivity converges back toward the baseline. The technology becomes normal. The old constraints — team boundaries, cognitive load distribution, communication overhead — reassert themselves. The mistake is not adopting the technology; it is expecting the technology alone to permanently raise the baseline.

Misconception 2: "Scaling always reduces productivity per person indefinitely."

Some leaders assume that as organisations grow, per-person productivity will inevitably decline — a kind of organisational gravity. Convergence theory suggests a more nuanced picture. Scaling without restructuring does erode productivity, because the structural forces scale faster than output. But scaling with deliberate redesign of team topologies, communication patterns, and ownership can maintain or even raise the baseline. The problem is not scale itself; it is scaling the work without scaling the structure to match.

Misconception 3: "Convergence means we can never exceed where we started."

This reading of convergence theory is understandable but wrong. Convergence describes the default behaviour absent structural change — productivity returns to its prior level. But when disruption is accompanied by genuine structural change, the productivity baseline itself shifts. The organisation then converges to a higher baseline. Convergence is not a ceiling on ambition; it is an explanation for why ambition expressed through technology alone tends to disappoint. Express it through structure and the outcome is different.

Check your understanding

  1. A team adopts a new automated testing framework. In the first two months, bug escape rates drop and deployment confidence rises. By month six, the gains have largely plateaued. Using convergence theory, what is the most likely explanation?
Reveal answer The testing framework reduced a specific source of friction but did not change the structural forces governing the productivity baseline. The team's cognitive load distribution, communication overhead, and decision-making patterns are unchanged. As the tool became familiar, it was absorbed into existing workflows, and the structural constraints reasserted themselves. The gains were real but bounded by the ceiling the existing structure allows. To make the improvement compound, a structural change — such as restructuring ownership of test coverage or redesigning the review process — would need to accompany the tooling change.
  1. Apex Engineering's velocity recovers to its pre-migration level by month 8, but not above it. The engineering director is disappointed. A colleague argues: "Recovery is a success — at least we didn't lose ground permanently." Who is right, and what does convergence theory add to this conversation?
Reveal answer The colleague is right that recovery without a permanent decline is a successful outcome relative to the risk. But convergence theory adds a more precise lens: convergence back to the prior baseline is the *expected default outcome* when no structural change accompanies a disruption. The baseline is not a floor to aspire to — it is the attractor. A more ambitious goal would have been to raise the productivity baseline through structural change (e.g., redesigning team boundaries around service ownership) concurrent with the migration. The engineering director's disappointment is appropriate if the migration was expected to raise the baseline; it is misplaced if the migration's value was architectural, not productivity-level-shifting.
  1. Why do the four structural forces (team topology, cognitive load, communication overhead, decision-making latency) act as constraints rather than just friction?
Reveal answer Friction suggests something that can be reduced by effort, skill, or goodwill. Structural constraints are different — they are properties of the organisation's shape. A team that owns too many domains will hit its cognitive load limit regardless of how talented or motivated its members are. A team that must coordinate with six other teams to make a routine decision will absorb that communication overhead regardless of how well the meetings are run. These forces do not respond to effort within the existing structure; they only change when the structure changes. That is what makes them constraints in the convergence-theory sense: they bound the sustainable output ceiling, not just the day-to-day experience of work.
  1. Imagine an organisation that underwent a reorg two years ago and is now "back to normal." A new engineering leader joins and observes that velocity is stable but deployment frequency is low. She proposes a tooling investment to improve CI/CD speed. What question should convergence theory prompt her to ask first?
Reveal answer The key question is: has the organisation converged to a higher baseline than before the reorg, the same baseline, or a lower one? If it has converged to the same or a lower baseline, tooling investment is likely to produce another temporary boost followed by convergence back to the current level. Before investing in tooling, she should diagnose whether the structural ceiling has been raised — or whether team boundaries, cognitive load distribution, and decision ownership are the real constraints on deployment frequency. If the bottleneck is structural (e.g., a shared platform team is a dependency for every deployment), tooling will not move the ceiling. Structural change would need to come first, or alongside.

Key takeaways

  • Convergence is the default. Without structural change, engineering productivity will return to its prior productivity baseline after disruption — not higher, not permanently lower.
  • Structure sets the ceiling. Team topology, cognitive load, communication overhead, and decision-making latency are the four forces that govern where the structural ceiling sits and, therefore, where the productivity baseline lands.
  • Technology gets absorbed. New tools and platforms produce real but temporary gains. Adaptation absorbs innovation — gains flatten as the technology becomes normal and structural constraints reassert themselves.
  • The baseline can be raised — but only through structural change. Redesigning team topology, reducing cognitive load, and aligning ownership are how the ceiling moves up. Technology alone will not do it.
  • Convergence is not fatalism. Understanding that productivity finds its structural level tells you exactly where to intervene: not in the tool, but in the structure that governs it.

References