When an Engineering Delivery Problem Isn’t a Team Problem

The request for assistance with the transformation of a mid-sized engineering organization seemed very much like one I had come across previously in my role as an organizational coach. The company had grown quickly; many engineering teams had become numerous. New products had been launched, the platform capabilities had been expanded, and the common services had increased as a result. To an outsider, the organization looked mature and the technology stack was regarded as being of a good standard. Meanwhile, the delivery figures conveyed a different story (which is the very reason why leadership had wanted a transformation).

At portfolio level a typical initiative appeared remarkably simple, but once the work had begun it passed through a number of specialist groups: business analysis was carried out separately from development, architectural decisions needed the involvement of another part of the organization, and dependencies on shared capabilities were negotiated together with the priorities of other teams.

Although no single step appeared to be particularly dysfunctional, the delay built up between the steps.

This also provided a solution to one of the paradoxes we had been encountering. Although individual teams might display good performance, the entire initiative could still be delayed. When someone only looks at team-level velocity or sprint completion, they won’t obtain a full picture. Each part of the system might be locally efficient yet end-to-end delivery could still be very slow.

The business aspect of the company didn’t achieve the results they had hoped for either. Even with detailed planning, the roadmaps ended up performing poorly. Business initiatives which at first seemed simple ended up taking years rather than months. Each new release added another layer of dependencies, and as a result the engineering manager found that they were spending more time negotiating priorities than they were helping the teams to grow. The feeling I most frequently heard during the first week wasn’t frustration but exhaustion: although people were busy all the time, they had difficulty pointing to any real progress by the end of the day.

​

Why Agile Transformations Don’t Always Fix the Delivery Issues

Leadership believed the answer was somewhere in the way teams worked. Perhaps Scrum wasn’t being applied consistently enough. Maybe backlog refinement needed attention. Planning could certainly become more disciplined. Additional coaching might help.

Those were reasonable hypotheses, but they weren’t the ones I intended to test first.

I have witnessed a sufficient number of transformations to be aware that delivery difficulties do not necessarily start at the point where they are noticed.

At team level, the symptoms are usually easy to spot:

• Sprint commitments repeatedly move to the next iteration
• Estimates prove unreliable
• Refinement takes longer but doesn’t produce more clarity
• Priorities change while work is already in progress
• Teams spend increasing amounts of time waiting for decisions or arranging dependencies
• Retrospectives bring up the same impediments several times without really resolving them
• Work in progress is accumulating and teams get used to spillovers

Finally, someone decides that the team should become more predictable, communicate more effectively, or improve its Agile practices.

The diagnosis may at times be correct, but I have also observed exactly the same symptoms in competent and experienced teams operating within a system in which priorities clash with one another, in which there is no clear decision authority, in which dependencies are built inside the organizational structure, or in which teams are responsible for only part of the overall end-to-end outcome. Organizations tend to first notice the symptoms in teams, even though the causes do not necessarily reside there.

Investigating the Organizational System Behind Software Delivery

Rather than implementing new practices, during our first weeks we simply concentrated on understanding the organization before attempting to improve it as shown in figure 1.

Fig. 1: Systems and the constraints that shape them: The team as part of a larger organizational system.

Seeing the Organization From Different Perspectives

During the investigation, we looked at documents and governance, as well as planning artefacts, role descriptions, operating procedures and delivery processes.

At the very start, it was necessary to talk to people and find out the way they saw the environment in which they were operating. Executives spoke about strategy and growth, and team leaders talked about dependencies.

The business people spoke of continually changing priorities, while the developers never referred at all to Agile; instead, they talked about interruptions, having to wait for decisions, frequent context switching, and spending more time co-ordinating their work than actually building software.

It seemed as though each person was describing a different organization. Yet all of those views were correct; as figure 2 shows, each individual was observing the same system from a different point within it.

Fig. 2: Different perspectives on the same organizational system.

Instead of asking why teams were slow, we began asking different questions:

• Who really decides priorities?
• When priorities change, who absorbs the cost?
• Where does work wait?
• Which conversations happen every week that shouldn’t have to happen at all?
• Who carries responsibility without having the authority to make decisions?

Using Cynefin to Understand Different Types of Organizational Problems

Over a period of several weeks we had gathered interview notes, stakeholder maps, governance documents, the observations from the workshops, and a large number of recurring patterns.

The different types of problems gathered during the investigation were not all the same. Cynefin enabled us to tell the difference between cases where cause and effect were fairly clear, between those which required expertise and analysis, and between those influenced by a number of interacting factors for which the outcomes could not be predicted in advance. It also served to remind us that an organization doesn’t fit neatly into a single domain: it is possible for various kinds of challenges to occur in different domains at the same time and for those challenges to change as the circumstances do.

Fig. 3: Introducing cynefin and how systems shift and interact.

Using Estuarine Mapping to Find Where Change Is Possible

The next stage was to interpret all the findings. This was the point where I introduced the Estuarine Mapping. The metaphor behind it is simple: an estuary is neither a river nor the open sea. It is a landscape where different forces constantly interact. Some parts barely move for decades. Others change shape with every tide. Organizations behave much the same way.

When applied to an organization, this consists of examining its underlying foundation: the constraints, structures, actors, habits, technologies, policies, and other factors that influence the way the system operates. We categorized these elements based on two practical questions: how much energy would it take to make such a change and how much time would that change require?

Certain constraints within this organization (for example regulatory requirements, the way funding is arranged, the mandates of the executive team, and some aspects of the existing technology environment) would not be likely to change within the time frame we were dealing with. On the other hand, various elements people had come to regard as fixed were in fact much more flexible: the boundaries of ownership, the routines involved in making decisions, the methods used in planning, the coordination procedures, or the way in which work moved between teams.

From an Ideal Target State to a Realistic Space for Action

The purpose wasn’t to create another catalogue of organizational problems. It was to find the space for action. Instead of asking “What should the organization look like?”, we started asking: Given the system we actually have, what can we meaningfully change?

This had a similar effect on the way we constructed the transformation backlog: an issue could be significant yet still not a suitable place to put our efforts at that time. On the other hand, a constraint that appeared to be rather minor could be worth addressing since altering it might have an impact on a number of other parts of the system. There were instances in which we could act directly on a constraint, but in other cases the better approach was to modify something nearby and then observe how the system reacted.

This is an important difference from designing a target operating model and then measuring the gap between current and future state. Estuarine Mapping starts with what is present, not with what theoretically should be present. The aim is to identify where change is possible, make interventions there, observe what happens, and use that information to decide what to do next.

This change caused us to move away from having a long list of desirable improvements and instead adopt a portfolio of interventions based on the reality of the organization; it additionally laid the foundation for the following question: if many of our delivery constraints were structural, then which particular aspect of the organizational design was causing these constraints to be reapplied again and again?

Fig. 4: Estuarine Mapping Framework and example.

In the image, organizational constraints and other elements of the substrate are mapped according to the energy and time required to change them. This separates relatively fluid elements from those that are more stable or effectively fixed within the transformation horizon, helping identify the real space for action rather than designing interventions around an ideal future state.

The map caused us to divide the problems which people disliked from those which we could realistically affect. Some of the constraints were clearly beyond the range of this change. With respect to others, they at first appeared just as unchangeable, but after talking about them it became obvious that they were mainly kept in place by habit. For instance, various coordination mechanisms had come about because the organization had developed around specialist functions; people had become used to making up for this kind of structure by means of meetings, escalation procedures and unofficial agreements. No one had intentionally designed this level of complexity.

This distinction turned out to be important, for without it, our transformation backlog could easily have become a catalogue of everything people disliked about the organization. Mapping energy and time horizons forced us to make choices about where intervention was worthwhile.

How Organizational Topologies Revealed the Real Delivery Problem

The delivery problems that everyone complained about were not the responsibility of any one team but rather existed between teams.

That was when Organizational Topologies became a language for describing what we were already seeing.

The framework helped explain something we had already observed during the investigation. The organization operated predominantly in a Resource Topology: expertise was deep but distributed across functional units, teams owned parts of solutions rather than complete outcomes, and prioritization and sequencing decisions largely happened outside the delivery units. What had initially looked like a collaboration or execution problem was increasingly looking like a consequence of organizational design.

The objective wasn’t to declare Resource Topology “bad” and Adaptive Topology “good.” Different organizational designs optimize for different things. The useful question was whether the topology we had was capable of producing the outcomes the organization now expected from it.

It enabled leaders to realise that fragmented ownership wasn’t merely causing communication problems; it was in fact affecting planning, decision-making and the delivery process as well (fig. 5.)

Fig. 5: Organizational Topologies in theory and practice.

The upper part introduces the three common Organizational Topologies: Resource, Delivery, and Adaptive, and the different conditions each creates for ownership, decision-making, and value delivery. The lower part maps what we observed in this organization specifically: a predominantly Resource Topology in which expertise was distributed across specialist functions, teams owned parts of an outcome, decisions frequently happened outside delivery units, and work moved through hand-offs and queues. The comparison makes visible why individually capable functions could still produce significant coordination overhead and slow end-to-end delivery.

Redesigning the Organization for End-to-End Delivery

The changes that followed reflected that diagnosis.

It is impossible to create the transformation backlog using Organizational Topologies without carrying out Elevating Katas (which are a combination of actions and practices designed to make the change sustainable). Together we concentrated on:

• Shifting from a Resource Topology toward a Delivery Topology.
• Clarifying end-to-end ownership around value delivery rather than functional expertise.
• Reducing fragmented ownership across teams.
• Introducing clearer accountability through RACI workshops.
• Introducing organization-wide release planning as the primary synchronization mechanism.
• Standardizing the delivery lifecycle across teams.
• Defining common working agreements across teams.
• Introducing multi-team backlog refinement where appropriate.
• Reviewing recurring systemic blockers instead of treating them as isolated issues.
• Shifting leaders from operational firefighting toward system stewardship.

Fix Recurring Systemic Constraints, Not Just Their Symptoms

A systematic approach can be used when examining all the aspects of the organization that are not serving their purpose: for instance, if a team keeps having to wait for requirements to be clarified, the issue might not be that the requirement itself is unclear, but rather that ownership of the requirement is shared among a number of different roles and no one has the final authority to make a decision.

In a similar way, if the same kind of dependency between teams interferes with multiple releases, solving it each time by holding another coordination meeting only deals with the immediate problem but doesn’t address the fundamental organizational dependency. Other recurring patterns that we investigated included work having to wait for approvals, priorities changing after development had already begun, decisions continually being raised with the same small group of people, and teams being slowed down by specialist knowledge that was held elsewhere in the organization.

Whenever the same kind of obstacle keeps reappearing, it is worth considering what aspect of the system is causing it to be continually recreated.

Building a Transformation Backlog Around What You Can Change

Next to that, a useful consequence of looking at the organization as a system was realizing that transformation did not mean changing everything we had identified as problematic. During the assessment we found many things that could potentially be improved, but they differed significantly in how much influence we had over them, how much energy changing them would require, and how relevant they were to the delivery problem we were trying to solve.

This served as a key filter for the transformation backlog, since some constraints had to be accepted at least for the moment, others could be dealt with, and some were worth looking into because a minor change could have an effect on a number of ongoing problems at the same time.

For instance, we might continually enhance the coordination between teams each time a dependency arose, or we could investigate why the same dependency was constantly being recreated. We could ask individuals to make their ownership more clear, or we could alter the way ownership was allocated. We could improve the planning meeting, or we could reexamine the reasons why planning and decision making had originally been concentrated in such a small number of people.

This also meant that not every finding from the assessment became an action. That was intentional. The purpose of the investigation wasn’t to produce the longest possible transformation backlog. It was to identify where changing the conditions around the work had a realistic chance of changing the outcomes.

In practice, this made the transformation more selective than many transformation programmes I have seen. We weren’t trying to make the organization conform to an ideal model. We were looking for places where enough movement was possible to create a considerable difference, and then observing what happened before deciding where to intervene next.

How Organizational Design Changes Leadership and Culture

The cultural dimension was also gradually affected by these organizational changes. Earlier on, when the transformation took place, discussions among leaders mostly focused on working out which team was to blame for a delay or on deciding where extra capacity was required. Once ownership had become clearer and the dependencies more obvious, the nature of these discussions changed. Leaders then spent less time overseeing individual teams and more time looking at the conditions that affected the entire delivery system.

Questions like “Why did Team A fail to meet its commitment?” were gradually replaced by “What in our organization made this result likely?” This shift in perspective promoted greater collaboration between different functions, decreased the inclination to optimize in a local manner, and reinforced a common sense of responsibility for end-to-end delivery. The culture did not change as a result of us launching a culture initiative; it changed because leaders started to make different decisions based on a different understanding of how the organization functioned.

Organizational redesign was only one part of the work. In parallel, I worked with leaders on how they responded to the problems the new system was making visible. This was important because changing accountability on paper doesn’t automatically change the way decisions are made on Monday morning.

A common element of the coaching involved looking at actual delivery situations rather than talking about leadership in a general way. For instance, when a dependency became problematic, we didn’t just focus on how to remove the obstruction; instead, we asked ourselves why this specific dependency had needed leadership to get involved, who should have had the authority to make the decision, whether it was an unusual case or if we had seen this kind of situation before, and if it kept happening, what was the leader achieving each time -was he or she eliminating the constraint or assisting the organization in making up for it?

We did something similar with planning and accountability. Instead of immediately asking who was responsible when delivery slipped, I encouraged leaders to look at the sequence of decisions and conditions that had produced the outcome. Where had work waited? Which assumptions had changed? Where had responsibility and authority diverged? Which part of the problem could the team actually influence?

This gradually changed the role of leadership in the transformation. Leaders were still responsible for delivery, but less of their attention went into resolving individual incidents and more into noticing recurring patterns. Coaching became a way of helping them distinguish between a problem that needed solving today and a pattern in the system that would recreate the same problem next month.

Part of my role was also to challenge leaders on how their own behaviour contributed to the system we were trying to change. It is relatively easy to recognize that decision-making is too centralized; it is much harder to notice that you are the leader everyone still comes to for a decision.

The same applied to priorities: leaders could agree that teams needed more stability and then introduce a new “urgent” request the following week. Or they could ask teams to take more ownership while continuing to step in whenever an important decision became uncomfortable. In coaching conversations, I would bring these contradictions back into the room. What behaviour are you asking for, and what behaviour are you actually reinforcing? Where are you removing a constraint, and where are you unintentionally becoming one? This wasn’t about blaming leaders for structural problems; It was about accepting that leadership behaviour is part of the system too, and therefore one of the things we could work with.

Engineering Transformation Happens at Different Speeds

None of this occurred fast. The initial assessment took about two weeks, followed by roughly a month of deeper investigation, mapping, and designing the first organizational changes. It then took around six months before we could see the first meaningful changes in delivery: different patterns arising in how work moved through the organization, how dependencies were handled, and how decisions were made.

Culture changed on a far longer timescale. When I look back two years later, I am able to observe changes that could not have been asserted during those first six months. The nature of leadership talks have altered, taking on a more cross-functional character, and some of the behaviours which at first required conscious effort have now become part of the way the organization operates. Of course, there are too many factors involved in any kind of transformation to regard this as a fixed timeline. Nevertheless, this case made one important point clear to me: you can alter a process in weeks and start to change delivery patterns within months, but changing the organizational habits and assumptions underlying them takes a lot of time and calls for continuous reinforcement. As figure 6 shows, the visible behaviors, sitting above the surface, are how people make decisions, prioritize, collaborate, and respond to problems. Organizational structures and their underlying mindsets, however, sit deeper below it.

Fig. 6: The Change Iceberg: behaviour, structure, and mindset move at different speeds.

Conclusion: Change the System, Not Just the Teams

Looking back, that’s probably the biggest lesson from this transformation: engineering teams are often asked to solve problems they didn’t create.

It’s natural to improve the estimates, the ceremonies or the communication when delivery is slowing down. In some cases those actually are the correct actions to take.

However, before changing the way teams work, it’s worth asking a different question: Is the organization’s design causing the behaviour it wishes to see eliminated by teams?

In this case, that question changed the direction of the entire transformation. I suspect it would change the approach for readers as well.

References

https://thecynefin.co/about-us/about-cynefin-framework/

https://cynefin.io/wiki/Estuarine_framework

https://www.orgtopologies.com/made-method