Chapter 7: Leadership Owns the System¶
The programme board in Chapter 1 did not design the system that produced the failure. It inherited it. The governance culture that treated risk registers as reporting artefacts rather than decision instruments had been established over years, across many programmes, by many decisions that individually seemed reasonable and collectively produced a structure incapable of acting on the information it received.
But the programme board owned that system. Not in the sense of having created it. In the sense that they had the authority to change it and did not. That distinction — between creating a system and owning it — is the foundation of what leadership means in Firmitas.
Leadership responsibility does not begin when a framework is installed or a plan is agreed. It does not end when a programme is handed to a delivery team. It persists for as long as the system operates and as long as the leader has the authority to shape the conditions within which the system functions. Frameworks, processes, and tools may assist. They do not replace leadership judgement. They cannot absorb leadership accountability.
What leadership actually means¶
In most organisations, engineering leadership is described in terms of influence, vision, technical credibility, and stakeholder management. These attributes may be valuable. They are insufficient.
Firmitas defines engineering leadership more narrowly and more rigorously: engineering leadership is the non-delegable responsibility for the health, alignment, and evolution of the systems that produce engineering outcomes.
That definition has three components worth unpacking.
Non-delegable. Leaders may delegate execution. They cannot delegate accountability for the systems within which execution occurs. The programme director who delegates programme management to a programme manager has not delegated responsibility for whether the programme management system is capable of surfacing risks and generating decisions. If the programme management system fails — if risk registers are filed rather than acted on, if escalations are received and not responded to, if commitments are made without honest assessment — that failure belongs to the leader who owns the system, not to the programme manager operating within it.
Health, alignment, and evolution. System health means the system is capable of producing the outcomes it is designed to produce — that feedback loops are functioning, that information is reaching the people who need to act on it, that the conditions for good work exist. Alignment means the human, organisational, socio-technical, delivery, technical, and economic systems are reinforcing rather than undermining each other. Evolution means the system can adapt as conditions change without losing coherence — that it learns from what it produces and adjusts accordingly.
The systems that produce engineering outcomes. Not the engineering outputs. The systems. A leader accountable for outputs can declare success when features are delivered on a milestone. A leader accountable for the systems that produce outcomes must ask whether the right things are being built, whether the conditions for building them well exist, and whether the organisation will be more capable of building the next thing than it was of building the last one.
Stewardship over control¶
There is a model of leadership that feels like accountability but is not. It is control — the belief that the closer a leader monitors execution, the more they can ensure the right outcomes. It manifests as frequent status reviews, detailed progress tracking, direct involvement in operational decisions, and the expectation that leaders will have answers to questions about specific tasks at specific points in a programme.
Control-based leadership assumes predictability. It relies on detailed plans, centralised decision-making, and compliance enforcement. In complex engineering environments, this approach creates the illusion of certainty while suppressing the learning and adaptation that complex environments require.
Firmitas replaces control with stewardship.
Stewardship means setting clear purpose and constraints, designing decision boundaries, enabling autonomy within those boundaries, monitoring system health, and intervening when systemic risk emerges. A steward does not dictate how every decision is made. A steward ensures that decisions can be made well — by the right people, at the right time, with the right information.
The difference is not subtle. A control-oriented leader in the programme of Chapter 1 would have increased the frequency of status reviews after the programme board noted the three red risk items, would have asked the programme manager for daily updates on the firmware specification resolution, and would have added resource to the integration phase when it became clear that the timeline was slipping. None of these interventions would have addressed the cause. The cause was that the decisions required to resolve the three red items — a client conversation, an independent component evaluation, a procurement approval — had not been made and were not being made because no clear owner with authority and urgency had been assigned to them.
A stewardship-oriented leader would have looked at the three red items and asked a different question. Not: is the team doing enough to manage these risks? But: what decisions are required to resolve these risks, who has the authority to make them, and what is preventing those decisions from being made this week rather than next month?
That is the question the programme board in Chapter 1 never asked. It is the question that leadership stewardship requires.
The non-delegable responsibilities¶
While execution can and should be decentralised, certain responsibilities cannot be delegated without undermining the integrity of the system. These are the responsibilities that define the leadership role in Firmitas — the things that frameworks and processes and programme managers cannot substitute for.
Purpose and direction. Ensuring that the engineering function has a clear, stable understanding of why it exists and what outcomes matter. Not as a slogan. As a reference point that teams can use to make coherent decisions under uncertainty, to prioritise when priorities conflict, and to evaluate trade-offs without needing to escalate every decision upward. When purpose is implicit or inconsistent, teams optimise for local signals — closing tickets, hitting deadlines, avoiding scrutiny — rather than for the outcomes the engineering function exists to produce.
System design. Shaping the organisational, delivery, socio-technical, and architectural systems so that desired behaviours emerge naturally rather than requiring heroic individual effort to sustain. The risk register that generates decisions rather than notes. The estimation process that produces honest three-point estimates rather than committed-date rationalisations. The governance culture that treats gap between commitment and honest assessment as a risk to be managed rather than a fact to be suppressed. These are not the product of good intentions. They are the product of deliberately designed systems — and system design is a leadership responsibility.
Trade-off resolution. Making explicit decisions when goals conflict, rather than pushing unresolved tension downwards. The engineering team that is told to deliver to the committed date, to the contracted scope, at the contracted quality, with no acknowledgement that these three constraints cannot simultaneously be met given the current conditions, has had a leadership failure delegated to them. They will resolve the tension — they have no choice — but they will resolve it invisibly, in ways that compound later. Leadership stewardship means owning the trade-off, making it explicit, and bearing the consequence of the decision rather than distributing that consequence silently through the programme.
Risk ownership. Ensuring that risk is surfaced, understood, and managed at the appropriate level rather than hidden or deferred. This is not the same as reviewing risk registers. It is ensuring that the governance structure treats risk information as a decision request rather than a reporting item — that when a risk is escalated, the response is a decision, not a note. It is also ensuring that the conditions for honest risk surfacing exist — that the human system makes honesty safe rather than expensive.
Sustainability. Protecting long-term system health even when short-term pressure incentivises degradation. Defending slack when it is politically uncomfortable to do so. Resisting the compression of timelines that destroys the capacity to absorb variation and learn. Treating technical debt as a programme risk rather than a background condition. Refusing to accept that burnout is commitment and permanent urgency is effectiveness. These protections are not natural products of commercial pressure. They require active, ongoing leadership decisions.
The illusion of empowerment¶
One of the most consistent failure patterns in engineering programme governance is the combination of empowerment language with centralised control behaviour. Teams are told they own the delivery. They are given autonomy over their ways of working. They are empowered to make decisions.
And then the priorities are changed without consultation. The architecture decision they made is overridden in a review they were not invited to. The estimate they produced is replaced by the number that makes the business case work. The risk they escalated is noted and the conversation moves on.
This pattern is not deliberate manipulation. It is the predictable product of a leadership layer that has genuinely adopted the language of empowerment without changing the governance behaviours that make empowerment real. The language says: you own this. The behaviour says: you own the execution of what we have decided.
Firmitas is explicit about what genuine empowerment requires. Teams must understand what they can decide independently, what requires consultation, and what is explicitly reserved for a different level of authority. Those boundaries must be clear, coherent, and stable enough to trust. Autonomy without clarity is not empowerment. It is ambiguity — which teams respond to by becoming risk-averse, by seeking permission for decisions they should be making themselves, and by deferring upward until the governance layer is overwhelmed by decisions it should never have been asked to make.
The leader who claims to empower teams while retaining centralised control over the decisions that matter has not empowered anyone. They have created the appearance of autonomy while preserving the substance of control — and in doing so have produced a team that manages upward rather than managing delivery.
Leadership as system integrator¶
Engineering leaders operate at the intersection of multiple systems. The human system and the organisational system. The delivery system and the economic system. The technical architecture and the team structure. Their role is not to optimise each system independently — local optimisation consistently degrades whole-system performance, as Chapter 4 demonstrated. Their role is to align the systems so that they reinforce rather than undermine each other.
Examples of misalignment that leadership stewardship must detect and correct:
A delivery system optimised for speed — short iterations, continuous deployment, minimal process — operating inside an organisational system that requires multi-week approval cycles for any change to a production system. The delivery system is doing everything right. The organisational system is making those things impossible. The misalignment produces frustration, workarounds, and the eventual abandonment of the delivery system’s practices because they cannot function within the organisational system’s constraints.
An architectural decision that assumes stable, long-lived teams in an organisation designed for high team turnover. The architecture distributes knowledge across team members in ways that make sense when those members remain together for years. When the organisation restructures annually, the architecture’s assumptions are violated, and the cognitive load on each new team configuration is unsustainable.
Performance incentives that reward individual output — features delivered, tasks completed, milestones hit — in an organisation that claims to value team outcomes, quality, and long-term system health. The incentive system is louder than the stated values. Teams optimise for what they are measured on. The stated values are aspirational. The incentive system is real.
Each of these misalignments is a leadership problem. Not because the leader designed the dysfunction — they may have inherited every one of these conditions — but because the leader has the authority to identify the misalignment and change it, and that authority is the definition of ownership.
When leadership abdicates stewardship¶
The cost of abdicating system stewardship is not immediate. It accumulates.
The programme board that noted the risk register and moved to task status did not feel the cost of that decision at the programme board. It felt the cost at month six, when the programme missed its delivery date by eight months. By that point the connection between the week-three governance decision and the month-six outcome had been obscured by the intervening programme narrative — the firmware rework, the architecture redesign, the delayed test environment — and the accountability had been distributed across the execution layer rather than located in the governance decision where it belonged.
This is the specific dynamic that makes leadership abdication so persistent. The cost is deferred. The cause is obscured. The people who pay the cost are not the people who made the decision. The people who made the decision draw the conclusion that the execution layer failed, not that the governance layer abdicated.
When leadership abdicates system stewardship, organisations compensate through three mechanisms, none of which address the cause.
Bureaucracy. More process, more governance layers, more reporting requirements — the organisational equivalent of adding more instruments to measure a problem rather than fixing it. The new process is operated by the same governance culture that produced the failure. It produces more information that is not acted on.
Heroics. Reliance on individual strong performers who compensate, through exceptional effort and personal commitment, for the structural conditions that make normal performance insufficient. This works until the hero leaves, burns out, or is promoted away from the function that depended on them. It does not build organisational capability. It builds organisational dependency on individuals.
Blame. Attribution of failure to specific people rather than to the system that shaped their behaviour. Blame provides emotional resolution without improving system behaviour. It discourages the reporting of future problems, because the lesson of blame is that surfaces problems receive consequences while hidden problems remain hidden until they become unavoidable.
None of these are solutions. They are the symptoms of a system in which leadership accountability has been separated from system outcomes — in which the people with the authority to change the conditions that produce failure have convinced themselves, or been allowed to convince themselves, that the failure belongs to someone else.
Leadership beyond roles and titles¶
Engineering leadership is not confined to formal management positions. Architects, technical leads, principal engineers, and senior practitioners all exert systemic influence. They shape architectural decisions that determine how easily the system can evolve. They model the estimation behaviour that others observe and calibrate against. They create or destroy the conditions for honest risk escalation through how they respond when problems are surfaced.
Firmitas is explicit that formal authority and informal influence are both forms of leadership — and that both carry responsibility for the systems they shape.
It is equally explicit that ultimate accountability sits with those who hold formal authority. Influence without authority cannot correct systemic misalignment. The principal engineer who has been saying for six months that the architecture will not support the required scale has done their job. The engineering director who has heard that and not acted has not done theirs. Leadership roles exist to absorb accountability, not to deflect it.
What this means for the programme in Chapter 1¶
The programme board in Chapter 1 did not fail because its members were incompetent. They failed because the governance system they operated within had not been designed to generate decisions from risk escalations — and they did not recognise that as their responsibility to change.
A programme board operating on Firmitas principles would have looked at the three red items at week three differently. Not as risks to be noted and mitigated — as decision requests, each requiring a named owner with authority and a deadline by which the decision would be made. The hardware-software interface ambiguity: who will have a resolution conversation with the client, and by when? The third-party component validation: who will commission and fund the independent evaluation, and by when? The test environment procurement: who will approve the early procurement budget, and by when?
Three questions. Three owners. Three deadlines. All of them answerable in the week-three programme board if the governance system had been designed to ask them.
The outcome would not have been guaranteed. The client might not have resolved the interface ambiguity quickly. The third-party component might still have proved unsuitable. The test environment procurement might still have taken longer than hoped. But each of those outcomes would have been known earlier, when they were still cheap to respond to. And the programme would have been run against reality rather than against a plan that had already diverged from it.
That is what leadership stewardship produces. Not certainty. Not the elimination of risk. The conditions under which accurate information reaches the people who can act on it, and those people act on it — while the cost of acting is still manageable.
The principle restated¶
Leadership owns the system, not the intention. Good intent does not compensate for poor outcomes. Effort does not excuse systemic failure. Activity does not equal progress.
The leader who says “we had good governance processes” while a programme fails in the way described in Chapter 1 has confused the existence of a process with the function of a system. Governance processes that do not generate decisions are not governance. They are the appearance of governance — and the appearance is more dangerous than the absence, because it prevents the acknowledgement that something needs to change.
System stewardship is active, not passive. It requires leaders to observe how systems behave in practice — not how they are intended to behave on paper — and to intervene when the practice diverges from the intent in ways that matter.
The programme board’s risk register review was intended to surface programme risk and generate management response. In practice it surfaced programme risk and generated mitigation plan requests followed by task status reviews. That divergence between intent and practice was visible. It was correctable. It required someone with authority to notice it and change the governance behaviour.
That someone was the leadership. That responsibility was theirs.
It still is.