Where Accountability Bleeds: The Structural Reality of Large Organisations
Large organisations divide accountability deliberately.
Risk sits here. Product sits there. Delivery sits somewhere else. Architecture somewhere else again. Each function has a reporting line, a governance obligation, a definition of what good looks like from its own position. That division is the rational response to scale, complexity, and the control requirements that accumulate in regulated industries over decades. Dividing accountability into specialist functions is how large organisations make complexity manageable.
What that division does not create is a mechanism for what happens at the boundaries between the functions it produces.
Each specialist function is accountable for its own domain. That accountability is real, it is enforced, and it is what each function optimises for. The product function optimises for outcome delivery. The engineering function optimises for build quality and delivery pace. The risk function optimises for control and compliance. Each is doing exactly what the organisation designed it to do. The structure works as intended within each boundary it draws.
What the structure does not prevent is encroachment between the functions it produces.
Each specialist function has a defined accountability. What belongs to product, what belongs to engineering, what belongs to architecture, what belongs to delivery. Those accountabilities are not ambiguous in principle. They become ambiguous in practice because the structure that divided them did not create a mechanism for holding the boundary when one function’s work bleeds into another’s. Product shapes the solution. Engineering challenges the design. Delivery absorbs what product should own. Adjacent strategy pulls the programme in a direction the architect is accountable for navigating. Each of these is a function operating within or beyond its boundary in a way that lands in someone else’s accountability. The reasons vary. Genuine misunderstanding of where one remit ends and another begins. Misalignment between how the role was designed and how the work actually flows. The structural pressure each function is under to optimise for its own accountability, which sometimes means the adjacent accountability absorbs what the optimisation produces. The structure created the specialist functions. It did not create the mechanism for holding the lines between them. The encroachment is the natural output of that absence. It exists in every large organisation, permanently, regardless of how clearly each function understands its own remit.
The architect’s work touches every specialist function simultaneously. Technical decisions carry product implications, delivery constraints, engineering capacity requirements, programme sequencing dependencies, and strategic alignment obligations. Every boundary in the organisation runs through the architecture. Every encroachment at every boundary concentrates at the same point.
This edition is about that concentration. Not about the people producing it. Not about the roles that are failing to hold their boundaries. About the structural condition that produces the encroachment. And about what it means to work honestly at the centre of it.
The Boundaries and What Happens at Them
There are three boundaries where the encroachment concentrates for the architect. Each one runs in both directions.
The solution boundary.
The product function’s accountability is for the outcome. What the business needs and why. The architect’s accountability is for how that outcome is achieved technically. In principle the line between them is clean. In practice the product function, operating at pace and under pressure to drive the programme forward, arrives with the how already formed. The requirement contains the solution. The architect receives a constraint disguised as a problem. The space for technical design has already been narrowed before the conversation begins.
The architect does the same thing in the other direction. The technical view forms quickly. The implications of a design decision are visible before the product function has finished establishing what the outcome actually requires. The solution arrives before the problem has been fully owned. The product function’s accountability for the outcome is closed down before it has been properly held.
The same boundary. The same encroachment. From both sides simultaneously.
The delivery boundary.
The delivery function’s accountability is for programme coherence. Sequencing, dependencies, pace, risk. Inside that accountability sits the responsibility for holding the product function to its obligations: prioritisation decisions, funding commitments, product strategy. When that responsibility is not exercised, the ambiguity it leaves does not stay in the delivery function. It travels into the architecture, which has to absorb an incoherence it did not create.
The engineering function’s accountability is for building and operating what the architecture specifies. When the architecture introduces complexity that the team does not yet have the capacity or the skills to absorb, the rational response is to surface that constraint. The form that surfacing takes is a challenge to the architecture rather than a named resource or skill gap, because naming the gap directly carries a delivery risk the engineering function owns. The architecture becomes the stated reason for a constraint whose actual source is elsewhere.
The programme management function’s accountability is coherence of the plan. Dependencies, sequencing, reporting. Where that plan was built without full visibility of the technical complexity, the gaps in the plan’s comprehension land on the architecture. What the programme cannot account for, it attributes to what it understands least.
The architect’s accountability is for the integrity of the technical design across the programme. When that integrity is under pressure from the delivery boundary in three directions simultaneously, the rational response is to tighten the standards. More review gates. More sign-off requirements. More involvement in decisions that should sit with the teams closest to the work. The intent is coherence. The effect is that the architect’s accountability expands into the delivery and engineering territory in exactly the same way the delivery boundary has expanded into the architecture.
The strategy boundary.
Adjacent functions arrive with their own strategic directions and north stars. They are doing exactly what their accountability requires. The cost of that strategic operation, on the commercial and delivery obligations the architect is navigating, is not inside their accountability. It lands on the architecture regardless. The architect is accountable for a set of outcomes that are being shaped by strategic decisions made in adjacent functions that carry no accountability for the impact.
The architect’s accountability for standards and architectural integrity creates the same encroachment in the other direction. The standards that govern the technical design are the architect’s to hold. Holding them consistently across a programme where adjacent functions are making decisions that affect the design means inserting the architect’s accountability into territory that belongs to those functions. The standards overreach is the architect optimising for architectural integrity in the same way the adjacent function is optimising for its own strategic direction. Both are operating within their accountability. Both produce encroachment at the boundary.
What the Architect Is Navigating
The architect will always be in this position.
Someone will assume their accountability. They will assume someone else’s. The boundaries will move. The encroachment will come from every direction simultaneously and it will not stop. This is not a condition that resolves. It is the permanent operating environment of senior architecture work in a specialist organisation. The question is not how to fix it. It is how to navigate it honestly enough to keep doing the work.
The first thing the architect needs is intellectual honesty about what is actually happening at each boundary.
Not every encroachment carries the same weight. The product owner who arrives with a solution has narrowed the technical design space. The delivery lead who has not held the product owner to their prioritisation obligations has left an incoherence in the programme that will land on the architecture. The adjacent function pursuing its own strategic direction has introduced a constraint the architect is accountable for navigating without having been part of the decision that created it. Each of these is a different kind of encroachment with a different kind of consequence. Intellectual honesty means reading each one precisely. What is it doing to the architecture. What decisions does it constrain. What accountability has moved that should not have moved.
That reading determines the response. Not the encroachment itself.
Where the encroachment warrants challenge, the architect challenges. The product owner who arrived with a solution needs a conversation that reopens the outcome question. Not to reject the solution. To understand whether the solution reflects a genuine outcome need or whether the design space has been closed prematurely. That conversation is the architect doing their job. It is also the architect holding the product owner’s accountability for the outcome rather than absorbing it silently into a technical constraint.
The engineering lead whose challenge to the architecture is carrying a delivery constraint that has not been named needs a different conversation. Not a defence of the design. A precise question about what the constraint actually is. Surfacing it explicitly, in the right forum, changes what the engineering function is carrying. The constraint is no longer hidden inside an architectural objection. It is visible as a delivery accountability that needs to be owned and addressed.
The project manager who is attributing programme slippage to architectural complexity needs the dependency structure made visible. Not as a rebuttal. As a precise account of what the architecture depends on, in what sequence, and what the programme plan does not currently reflect. That account does not resolve the slippage. It names where the accountability for the sequencing decisions sits. The architect is not carrying the plan’s gaps silently.
The adjacent function whose strategic direction is shaping the programme’s technical obligations without carrying any of the commercial or delivery cost needs the impact made explicit. Not in the form of a complaint. In the form of a documented dependency that connects the adjacent function’s decisions to the programme outcomes the architect is accountable for. The impact is on the record. The accountability is not invisible.
Where the encroachment cannot be shifted, the architect names where the accountability sits and moves.
Not every boundary failure is recoverable through a conversation. Not every challenge is worth the cost it carries. Some encroachment will be absorbed. What gets absorbed and what gets challenged is the architect’s judgement call, grounded in an honest reading of their own accountability. Not every solution disguised as a requirement needs to be unwound. Not every standards challenge needs to be escalated. The architect who challenges everything loses the credibility to challenge the things that matter. The architect who absorbs everything has quietly allowed their accountability to be redefined by the functions around them.
The discipline is knowing which is which. What does the architect’s accountability actually require. Where is the encroachment genuinely compromising the ability to deliver the right outcome. Where is it a discomfort that can be carried without cost to the work. The architect who is not making that distinction deliberately is having it made for them by the accumulation of what they have let pass.
What intellectual honesty and that judgement do together is give the architect a workable position inside an unworkable structure. Honest enough to know what they are navigating. Precise enough to respond to what warrants a response. Clear-eyed enough about their own accountability to know when absorbing the encroachment is the right call and when it is not.
The accountability gap at the boundary between specialist functions is not a programme problem or a people problem. It is a structural feature of how large organisations divide and govern accountability. The specialist structure that makes complexity manageable at scale does not come with a mechanism for holding the lines it draws. The encroachment is what fills that absence.
The architect does not get to step back from the intersection. Every technical decision sits at the boundary of product, delivery, engineering, programme management, and adjacent strategy simultaneously. Every one of those boundaries will produce encroachment in both directions. Some of it will be challenged. Some of it will be absorbed. Some of the architect’s own accountability will bleed into the functions around them in exactly the same way.
What the architect carries into that intersection is the only thing they control. The honesty with which they read what is happening. The precision with which they respond to what warrants a response. The judgement about what to absorb and what to name. The clarity about where their accountability actually sits and what holding it honestly requires.
The structure will not change. The intersection will not be resolved. The architect works inside it, permanently, and the quality of that work depends on how clearly they can see it.
