Your Delivery Platform Is Tier-Zero Infrastructure

On 10 September, GitLab released critical patches for its Community and Enterprise editions. The most serious issue, CVE-2026-85706, was assigned a CVSS score of 10.0. Under certain conditions, an unauthenticated attacker could use the repository commits API to read arbitrary files from a GitLab server. One day later, the US Cybersecurity and Infrastructure Security Agency added the vulnerability to its Known Exploited Vulnerabilities catalogue based on evidence of active exploitation.

The immediate response is straightforward: affected self-managed installations should be upgraded to GitLab 19.1.8, 19.2.6, 19.3.2 or later, and potentially exposed systems should be investigated rather than treated as safe simply because a patch has now been applied.

The more important leadership lesson is broader. Source-control and delivery platforms are no longer developer tools at the edge of the estate. They are tier-zero infrastructure: systems whose compromise can provide a route into much of the organisation.

The development platform has become a control plane

A modern GitLab instance may hold source code, deployment credentials, CI variables, container-registry access, infrastructure definitions, release approvals and integrations with cloud platforms. Even where secrets are stored elsewhere, pipelines often possess the identity required to retrieve them. The platform also records architectural detail that can make subsequent attacks faster and more precise.

This concentration is intentional. Integrated delivery platforms reduce hand-offs, improve traceability and make secure defaults easier to standardise. But integration also changes the blast radius. A vulnerability in the platform is not equivalent to a defect in an internal productivity application; it can undermine the machinery used to build, verify and deploy everything else.

Engineering leaders should therefore stop classifying source control as ordinary SaaS or routine internal tooling. Its recovery objectives, access model, patching expectations and incident playbooks should resemble those used for identity providers and production cloud control planes.

Patch speed is an organisational capability

Critical advisories often expose the gap between a documented patch policy and the organisation’s real ability to act. Teams may know which version they run but still require days to identify owners, negotiate downtime, validate plugins, test runners and obtain change approval. During active exploitation, that operating model is the risk.

A mature response begins before the advisory arrives. Maintain an authoritative inventory of self-managed engineering systems, their public exposure, owners, versions, dependencies and recovery procedures. Define an emergency change path with named decision-makers and explicit authority to trade short-term availability risk for containment. Rehearse upgrades and restoration from backup. If the platform cannot be patched rapidly without organisational theatre, the problem is architectural and operational, not merely procedural.

Managed services alter this equation but do not remove responsibility. The vendor may patch the underlying service, while customers still own tokens, integrations, runner isolation, audit monitoring and the consequences of excessive privileges. The strategic choice between managed and self-hosted platforms should include patch latency and security staffing, not just licensing cost and data residency.

Assume compromise, not just vulnerability

Once a flaw appears in a known-exploited catalogue, upgrading is necessary but insufficient. Leaders should ask what an attacker could have read before remediation and what that information could unlock next.

That means reviewing relevant API and web logs, looking for indicators described by the vendor and security authorities, and preserving evidence before it ages out. Credentials accessible to the platform should be mapped and rotated according to exposure and privilege, rather than resetting everything indiscriminately or assuming nothing leaked. High-value secrets should be short-lived wherever possible, retrieved at runtime and scoped to the smallest useful set of repositories, environments and actions.

CI runners deserve particular attention. Shared, long-lived or broadly privileged runners can turn a repository-platform incident into a cloud incident. Ephemeral runners, restricted network egress, workload identity and environment-specific permissions make lateral movement harder. Protected branches and approval rules remain valuable, but they cannot compensate for a compromised control plane with access to the underlying secrets and automation.

Measure containment, not compliance

Executive dashboards frequently report patch compliance as a percentage. That is useful, but it can conceal the systems that matter most. Ninety-nine per cent compliance is unimpressive if the remaining one per cent includes the platform capable of deploying to production.

A better leadership view combines asset criticality with exposure and response time. Useful questions include:

• How quickly can we identify every affected instance and accountable owner?
• Can we patch tier-zero engineering systems within hours when exploitation is active?
• Which credentials become reachable if the delivery platform is compromised?
• Can we rotate those credentials without bringing delivery to a halt?
• Do we retain sufficient logs to determine whether exploitation occurred?
• Can we rebuild the platform from a trusted state rather than merely restore a potentially compromised backup?

These are not questions for the security team alone. Platform engineering owns much of the implementation, application teams own integrations, and engineering leadership owns prioritisation and risk acceptance. The response has to cross those boundaries before an incident forces it to.

The strategic conclusion

CVE-2026-85706 will be patched and eventually disappear from weekly engineering news. The architectural condition it exposes will remain: software organisations increasingly concentrate code, identity, automation and production authority in a small number of delivery platforms.

That concentration creates leverage, but leverage works in both directions. Treating the platform as tier-zero infrastructure does not mean slowing delivery with indiscriminate controls. It means engineering for rapid patching, limited privilege, observable access and credible recovery. Those capabilities protect the delivery system while allowing teams to move faster with justified confidence.

---

Source note: GitLab’s critical patch release was published on 10 September 2026. CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalogue on 11 September based on evidence of active exploitation. The GitHub Advisory Database entry summarises the affected and patched versions.

AI Coding Agents Are Becoming an Engineering Management Problem

This week’s $200 million funding round for enterprise coding-agent company Factory, reportedly valuing the business at $5 billion, is another sign that AI-assisted development is moving beyond autocomplete. The emerging product is no longer simply a faster way to write a function. It is an agent capable of reading a codebase, planning changes, editing several files, running tests and preparing work for review.

For web developers, that shift is significant. Modern applications contain far more than JavaScript components: infrastructure configuration, analytics, accessibility rules, automated tests, deployment pipelines and security controls all sit within the same delivery system. An agent that can reason across those boundaries may remove hours of repetitive work. Dependency upgrades, test scaffolding, documentation, migration preparation and first-pass bug fixes are increasingly realistic candidates for delegation.

But the more interesting challenge belongs to engineering managers.

Productivity cannot be measured by lines of code or pull requests created. If agents increase the volume of proposed changes without improving outcomes, they merely move the bottleneck from development to review and quality assurance. Teams may appear faster while senior engineers spend more time checking unfamiliar code, QA faces a growing regression surface, and technical debt arrives at machine speed.

The management response should not be to ban agents or allow unrestricted experimentation. It should be to redesign the workflow around clear boundaries. Low-risk, reversible tasks can be delegated first. Every change should still pass the same tests, security checks and architectural expectations as human-written code. Draft pull requests are useful because they allow agents to prepare work without pretending it is ready to merge. Small changes remain easier to understand, validate and reverse.

Ownership also needs to stay human. An agent can produce an implementation, but it cannot carry organisational accountability for a production incident, an accessibility failure or a poor product decision. The engineer requesting the work must understand the change well enough to defend it. The reviewer must evaluate behaviour and intent, not simply accept a green pipeline. Managers should resist creating a two-tier environment in which generated code receives lighter scrutiny because it arrived quickly.

The best adoption metric is therefore not “how much code did AI write?” Better questions include: Did lead time fall? Did defects increase? Was review time reduced or displaced? Are developers spending more time on valuable decisions? Can the team recover safely when an agent makes the wrong assumption?

AI coding agents are becoming a serious part of software delivery, and the investment market is betting heavily on them. Their lasting value, however, will not come from replacing engineering discipline. It will come from amplifying teams that already have clear standards, reliable automation and strong technical leadership.

The competitive advantage will not belong to the company with the most agents. It will belong to the team that learns where autonomy helps, where judgement matters, and how to preserve both speed and trust.

Source context: Reuters, 15 September 2026.

The road to CAIO

The Engineer Who Stops Owning Only the Code

For much of a software engineer’s career, progression appears straightforward.

Junior Developer. Developer. Senior Developer. Perhaps Staff or Principal Engineer. Engineering Manager. Head of Engineering. CTO.

Artificial intelligence has introduced another destination: Chief AI Officer — CAIO.

At first glance, it seems like a role intended for machine-learning researchers, data scientists and people who have spent their careers building neural networks.

That assumption misses what may become one of the most important aspects of the role.

A successful CAIO does not necessarily need to be the person who can build the best model.

They need to be the person who can answer a much bigger question:

How should this organisation use AI to become better?

That creates an interesting career opportunity for experienced software engineers.

The journey from Senior Developer to CAIO isn't about abandoning engineering. It is about repeatedly widening the boundary of what you consider your responsibility.

---

Stage One: Senior Developer — Make the Software Better

A Senior Developer is primarily responsible for execution.

You understand the system beyond the ticket in front of you. You recognise technical debt, challenge poor architectural decisions, mentor less experienced engineers and understand how changes affect production.

Your questions evolve from:

"How do I implement this?"

to:

"How should we implement this?"

You begin experimenting with AI in much the same way developers previously adopted Stack Overflow, IDE tooling, automated testing and CI/CD.

Perhaps you use an AI coding assistant.

Then you discover that it can generate tests.

Then documentation.

Then review code.

Then investigate failures.

Eventually, you stop thinking about AI as a chatbot.

You start thinking about it as another participant in the software-development lifecycle.

That shift matters.

The skill to develop

Become exceptionally good at AI-assisted engineering, while remaining sceptical enough to verify its output.

The goal isn't maximum AI usage.

The goal is better engineering outcomes.

---

Stage Two: Staff or Principal Engineer — Make the Engineering System Better

The next transition is subtle but important.

You stop optimising your own productivity and start asking why the entire team isn't benefiting.

Perhaps ten engineers all use AI differently.

One generates tests.

Another reviews pull requests.

Someone has built elaborate personal agents.

Another refuses to use AI entirely.

Nobody measures whether any of it actually works.

This is where technical leadership becomes important.

Instead of saying:

"Here's how I use Copilot."

you ask:

"Where should AI exist within our engineering lifecycle?"

You might identify repeatable stages:

Plan → Build → Test → Review → Deploy → Observe

Then determine where AI provides genuine leverage.

Perhaps an agent examines a draft pull request and identifies missing tests.

Another evaluates coverage.

Another checks implementation against acceptance criteria.

Humans remain accountable for the outcome, but increasingly repetitive cognitive work becomes automated.

Now you aren't simply using AI.

You're designing an AI-enabled engineering system.

The skill to develop

Learn AI workflow architecture.

Understand agents, context, evaluation, model limitations, security boundaries, human approval and observability.

Most importantly, learn when not to use AI.

---

Stage Three: Engineering Manager — Make the Team Better

Engineering management introduces another dimension: people.

An AI transformation fails surprisingly quickly if it is treated exclusively as a technology project.

Engineers worry that automation will replace them.

Some developers become dramatically more productive.

Others blindly trust generated code.

Some avoid AI because they don't understand it.

Management may hear extravagant productivity claims and assume development should suddenly become twice as fast.

The Engineering Manager has to establish sensible expectations.

That means introducing standards.

Which tools are approved?

What information may be supplied to models?

When must humans review output?

How do we measure whether an agent actually improves delivery?

What happens when an AI-generated change causes an incident?

You begin moving from AI tooling toward AI governance.

And you learn perhaps the most important lesson on the path to CAIO:

AI transformation is primarily organisational transformation enabled by technology.

The skill to develop

Learn change management and measurement.

Don't report:

"80% of developers use AI."

Report outcomes:

"Median pull-request cycle time fell 18%, while escaped defects remained unchanged."

Executives care about the second sentence.

---

Stage Four: Head of Engineering — Make Engineering Better

At Head-of-Engineering level, the boundary expands again.

You are no longer optimising one team.

You are looking across an engineering organisation.

Different teams have different workflows, technologies and risk profiles.

Individual AI experiments become organisational capabilities.

You establish principles rather than individual prompts.

You may create an AI engineering strategy covering:

• approved tooling;
• security and privacy;
• SDLC integration;
• agent architecture;
• evaluation;
• procurement;
• training;
• governance;
• productivity measurement.

At this stage, another important change occurs.

Other departments become interested.

Product asks whether AI can accelerate discovery.

Customer service wants automated assistance.

Marketing wants content generation.

Finance wants document analysis.

HR wants internal knowledge tools.

The problem is no longer an engineering problem.

It is becoming a company problem.

The skill to develop

Learn to translate between technology and business value.

Every proposed AI initiative should eventually answer:

What improves if we do this?

Revenue?

Cost?

Speed?

Quality?

Customer experience?

Risk?

If none of those moves meaningfully, the organisation probably doesn't need the AI project.

---

Stage Five: AI Transformation Leader — Make the Organisation Better

This is the bridge many future CAIOs may cross.

The title could be Director of AI, Head of AI Enablement, VP of AI Transformation or something entirely different.

The title matters less than the scope.

Your responsibility now crosses organisational boundaries.

You begin building an AI portfolio.

Instead of approving every interesting experiment, initiatives can be assessed against common criteria:

Business value × feasibility × risk × strategic importance.

A flashy autonomous agent promising modest savings may rank below a boring document-processing workflow saving thousands of staff hours.

This is where technical judgement becomes commercial judgement.

You also work increasingly closely with security, legal, finance, HR and executive leadership.

Questions become harder.

Should customer data ever reach an external model?

Who owns AI-generated intellectual property?

How do employees challenge automated decisions?

What happens when a supplier changes its model?

Should the organisation build, buy or partner?

How dependent should the company become on one AI provider?

These aren't programming questions.

They are executive decisions requiring technical understanding.

The skill to develop

Learn enterprise AI strategy, economics, governance and risk.

---

Stage Six: Chief AI Officer — Make AI a Business Capability

Eventually the scope reaches the organisation itself.

The CAIO's job isn't:

"Introduce more AI."

It is:

"Ensure this organisation extracts sustainable value from AI while controlling the associated risks."

That distinction is critical.

Sometimes the correct CAIO decision will be to invest aggressively.

Sometimes it will be to experiment.

Sometimes it will be to wait.

And occasionally it will be:

Don't use AI here.

The CAIO owns the portfolio rather than every implementation.

They connect corporate strategy with technological capability.

They understand enough about models, agents, data and software architecture to challenge technical proposals.

But they also understand finance well enough to challenge an AI project without measurable returns.

They understand governance well enough to recognise unacceptable risk.

And they understand organisations well enough to know that issuing everyone an AI licence isn't transformation.

The progression is therefore not:

Developer → AI Expert → CAIO

It is closer to:

Developer → Systems Thinker → Technical Leader → Organisational Leader → Business Leader

AI is the domain.

Leadership is the progression.

---

The Career Ladder

A useful way of thinking about the journey is through the question you are responsible for answering.

Senior Developer

How can AI make my engineering better?

↓

Staff / Principal Engineer

How can AI make our engineering system better?

↓

Engineering Manager

How can AI make this team more effective without compromising quality?

↓

Head of Engineering

How should engineering adopt AI consistently and safely?

↓

AI Transformation / Director of AI

Where can AI create measurable value across the organisation?

↓

Chief AI Officer

How should AI change the way this company operates and competes?

Each promotion expands the noun.

My code.
Our system.
My team.
Engineering.
The organisation.
The business.

---

Start Before You Have the Title

The most valuable part of this career path is that you don't need permission to begin it.

A Senior Developer can measure whether AI-assisted testing improves coverage.

A Staff Engineer can design an AI-assisted development workflow.

An Engineering Manager can establish team standards.

A Head of Engineering can coordinate adoption across teams.

Someone eventually notices that the person repeatedly answering the organisation's AI questions has effectively become its AI leader.

That creates a very different career strategy from chasing a title.

Don't wait to become Chief AI Officer before thinking like one.

Find one measurable problem.

Introduce AI where appropriate.

Establish safeguards.

Measure the result.

Document what happened.

Then increase the scope.

Do it for yourself.

Then your team.

Then engineering.

Then another department.

Then the organisation.

Because the journey from Senior Developer to Chief AI Officer isn't ultimately defined by how sophisticated your prompts become.

It is defined by how large a problem the organisation trusts you to own.

Your Roadmap Is Wrong Until It Includes Hidden Engineering Work

Most engineering roadmaps begin with visible product outcomes and then allocate people as though every available day can be converted into feature delivery. The plan looks credible until incidents, support, maintenance, onboarding, security updates and cross-team dependencies consume the capacity that was never acknowledged.

This is often described as unexpected work. Much of it is entirely predictable. The uncertainty lies in timing and volume, not in whether it will exist.

Capacity is not headcount

A team of six does not provide six full-time units of roadmap capacity. People attend planning, reviews, one-to-ones and organisational work. They take leave, support colleagues, respond to production and maintain existing services. Specialists may create constraints that average headcount conceals.

Start with historical evidence. Review how time was actually spent across several months: planned product work, operational support, defects, platform maintenance, discovery and unplanned requests. The objective is not perfect timesheets. It is a realistic range for recurring demand.

Separate demand categories

A useful plan makes four forms of work visible:

• Committed outcomes: product or business results the team is expected to deliver.
• Operational obligations: support, incidents, compliance, security and lifecycle maintenance.
• Enabling investment: testing, delivery tooling, observability and architecture needed to sustain future work.
• Contingency: capacity reserved for uncertainty rather than pre-allocated optimistically.

These categories expose the trade-off when new work appears. Without them, enabling investment silently disappears and operational load is absorbed through overtime or missed commitments.

Plan with ranges

A roadmap should express confidence. Near-term work can carry tighter estimates and clear dependencies. Later work should describe outcomes, assumptions and ranges rather than false precision.

Use scenarios. Show what is likely with normal operational demand, what becomes possible if dependencies arrive early and what will move if incident load or staffing changes. This gives leadership options before the organisation is under pressure.

Protect the constraint

Team capacity is often limited by a particular skill, system owner or approval path. Adding more general work can increase queues around that constraint rather than improve throughput.

Identify where work repeatedly waits. Spread knowledge, simplify ownership or sequence initiatives so the same specialist is not critical to several commitments at once. A roadmap that ignores its constraint is a wish list.

Price interruption honestly

Small requests are not free. Each carries clarification, context switching, testing, release and follow-up cost. Create an intake path and decide which existing commitment changes when urgent work enters.

The phrase "can we squeeze this in?" should trigger a trade-off conversation, not invisible expansion of the plan. Leaders build trust when they explain the consequence clearly rather than accepting everything and missing several dates later.

Track confidence, not only status

Red, amber and green reporting often describes current activity while hiding declining confidence. Ask teams to report whether the outcome remains achievable, what assumption changed and which decision is needed.

An amber item with a clear recovery choice is healthier than a green item protected by optimism. Escalation should be rewarded when it creates time to act.

A roadmap is a resource decision

Planning is not the art of filling every week. It is choosing where limited engineering attention will produce the greatest outcome while preserving the ability to operate safely.

Once hidden work is visible, the roadmap may look smaller. That is not reduced ambition. It is a more honest agreement between engineering and the business, one that allows teams to deliver what they commit to without sacrificing system health or relying on permanent heroics.

Architecture Guardrails Beat Architecture Permission

As engineering organisations grow, leaders often create architecture review boards to prevent inconsistency and costly mistakes. The intention is sound. The failure mode is predictable: decisions queue behind a small group, teams prepare presentation theatre and reviewers become accountable for systems they do not operate.

The alternative is not architectural anarchy. It is to replace broad permission with clear guardrails, local ownership and deliberate escalation for genuinely consequential decisions.

Define the safe operating space

Guardrails describe the boundaries within which teams can decide independently. They might cover identity, encryption, data classification, observability, supported runtimes, public API standards and operational ownership.

A good guardrail is testable and connected to a risk. "Use approved technology" is vague. "Customer credentials must be stored in the managed secrets service and never exposed to build logs" provides an enforceable outcome while leaving implementation detail to the team.

Provide paved roads

Standards work best when the compliant path is also the easiest path. Reference services, infrastructure modules, pipeline templates and supported libraries turn policy into usable capability.

If meeting the standard requires extensive bespoke work, teams will seek exceptions or comply superficially. Platform investment should reduce the marginal cost of making a good decision.

Reserve review for high-cost commitments

Architecture review is valuable when a decision creates broad or difficult-to-reverse consequences. Examples include a new system of record, public contract, regulated data flow, cross-team platform, major recurring cost or technology outside the supported estate.

Routine service design should remain with the team that owns delivery and operations. This preserves speed and keeps accountability close to the consequences.

Make exceptions explicit

Guardrails cannot cover every workload. Teams need a documented exception process that records the constraint, compensating controls, owner and expiry. An exception should be a conscious risk decision, not a permanent exemption earned by persistence.

Review exception patterns quarterly. Repeated requests may reveal a weak standard, missing platform capability or a legitimate category that deserves its own paved road.

Use architecture records as communication

Teams should record decisions that affect future options or other groups. A concise architecture decision record can state context, choice, trade-offs and review trigger. The purpose is not bureaucratic approval. It is to make reasoning discoverable and prevent the same debate from restarting without new evidence.

Measure whether governance helps

Track review wait time, exception volume, repeated incidents and adoption of paved roads. Ask teams whether standards clarify decisions or merely add steps. If governance increases lead time without reducing material risk, it needs redesign.

Architecture groups should also measure how often their guidance becomes reusable capability. Repeating the same advice in meetings is evidence that the organisation needs automation, documentation or platform support.

Move authority with context

Central reviewers rarely possess more local knowledge than the team building the system. Their value lies in cross-organisational context, pattern recognition and understanding enterprise risk. Effective governance combines that perspective with the team's detailed knowledge.

The goal is not to centralise every answer. It is to distribute good judgement while creating a reliable escalation path for decisions whose consequences exceed one team's boundary.

Architecture guardrails let teams move quickly inside known limits and slow down where the commitment warrants it. That is a stronger control model than requiring permission for everything, because it aligns autonomy with ownership rather than separating the people who decide from the people who must operate the result.

Blameless Incidents Still Need Clear Accountability

Blameless incident management is sometimes misunderstood as avoiding judgement. In a healthy engineering organisation, it means removing fear and hindsight bias so the system can be examined honestly. It does not mean that ownership, standards or follow-through disappear.

An incident review that concludes "the process failed" without identifying who will change the process is not blameless. It is incomplete.

Separate fault from accountability

Fault asks who caused the event. Accountability asks who owns the response, learning and risk decision. Individuals can make reasonable choices within a system that produces a poor outcome. The organisation still needs named people responsible for restoring service, communicating impact and ensuring agreed improvements happen.

This distinction encourages disclosure. Engineers should be able to explain exactly what they did and believed without fearing punishment for an honest mistake. Leaders, in turn, must be able to require stronger controls when evidence shows that current practice is insufficient.

Reconstruct the decision context

A useful review does not begin with what everyone knows after the incident. It reconstructs what information was available at each moment, which signals were missing, what assumptions appeared reasonable and how pressure shaped decisions.

Timelines should include detection, escalation, diagnosis, mitigation, communication and recovery. Include delays and failed attempts. Those moments often reveal more about operational capability than the original defect.

Look beyond the triggering change

The change that triggered an incident is rarely the complete cause. Ask why it reached production, why safeguards did not detect it, why the blast radius was large and why recovery took as long as it did.

Contributing factors may include environment drift, weak ownership, ambiguous runbooks, missing observability, rushed approval or a dependency no team fully understands. Treating the final code change as the root cause hides the system that made failure likely.

Choose actions that alter the system

"Be more careful" is not an action. Neither is adding a checklist item that nobody can verify. Strong actions change defaults, automate detection, reduce blast radius or clarify authority.

Each action should have an owner, due date and expected risk reduction. Rank actions by impact. A review producing fifteen low-value tasks can create the appearance of rigour while the central weakness remains untouched.

Accept risk explicitly

Not every contributing factor warrants remediation. The cost may exceed the likely impact, or a replacement may already be planned. Leaders can accept that risk, but the decision should be recorded with an owner and review date.

This is where senior accountability matters. Engineering teams should not quietly carry a known business risk because nobody wants to fund the fix.

Review the response itself

Examine whether incident roles were clear, stakeholders received timely information and responders had authority to act. Measure detection and recovery, but also look for cognitive overload, duplicated investigation and decisions waiting for unavailable leaders.

Runbooks and simulations should reduce those delays before the next event. Operational readiness is a practised capability, not a document stored beside the service.

Learning requires closure

Return to the action plan after thirty or sixty days. Verify that controls were implemented and that they would change the outcome of a similar event. Share the learning across teams where the failure pattern is transferable.

Blamelessness creates the conditions for truth. Accountability converts that truth into a safer system. Organisations need both: psychological safety to understand what happened and disciplined ownership to ensure that understanding changes how the company operates.

Technical Debt Is a Portfolio, Not a Backlog

Technical debt is often managed as a collection of tickets that compete unsuccessfully with product features. The backlog grows, engineers repeat that the system is fragile and leadership struggles to distinguish urgent risk from general dissatisfaction.

This model fails because technical debt is not one type of work. It is a portfolio of liabilities with different costs, probabilities and strategic effects. Managing it well requires classification and investment decisions, not a periodic appeal to "spend twenty per cent on tech debt".

Name the consequence

A debt item should describe the cost it creates. Does it slow every release, increase incident probability, prevent a product capability, create security exposure, depend on unsupported technology or concentrate knowledge in one person?

"Refactor the checkout service" is an implementation proposal. "Checkout changes require three days of regression testing and fail twice as often as other services" is a decision-ready problem. The second statement can be compared with other investments.

Separate debt categories

A practical portfolio might distinguish:

• Operational risk: weaknesses likely to cause incidents, data loss or prolonged recovery.
• Delivery friction: repeated manual work, slow tests, brittle environments and unclear ownership.
• Strategic constraint: architecture that blocks a planned market, product or scale requirement.
• Compliance and lifecycle: unsupported runtimes, expiring contracts, licences or regulatory gaps.
• Maintainability: complexity that raises change cost or knowledge concentration over time.

These categories support different decisions. Operational risk may justify immediate remediation. Delivery friction may be best addressed incrementally. A strategic constraint should be sequenced against the roadmap that makes it relevant.

Quantify without pretending to know the future

Exact financial estimates are rarely possible, but relative evidence is valuable. Record incident history, hours lost, affected services, deployment delay, support burden and the number of upcoming initiatives exposed to the problem.

Use ranges and confidence levels rather than invented precision. A debt item with high impact, repeated evidence and a clear remediation path should outrank a theoretically severe concern with no plausible trigger.

Choose a treatment

Not every debt item should be repaid. Leaders can remediate it, contain it, accept it for a defined period or retire the affected capability. Sometimes the correct decision is to stop investing in a low-value system and isolate it until replacement.

Every accepted item needs an owner and review trigger. Acceptance without a date, threshold or accountable person is simply neglect expressed politely.

Fund debt through the work it affects

Some remediation belongs in dedicated platform or reliability investment. Other debt should be included in the feature that encounters it. If a new commercial capability depends on changing a brittle subsystem, the enabling work is part of the feature cost, not an unrelated engineering preference.

This makes trade-offs visible to product leadership and prevents delivery plans from assuming that old constraints can be ignored.

Report movement, not backlog size

A growing debt register may indicate better discovery rather than declining quality. Track exposure instead: critical unsupported components, recurring failure modes, hours lost to friction and strategic initiatives blocked. Show which risks were reduced and which were consciously accepted.

The objective is not zero technical debt. A company that takes no debt may be moving too slowly. The objective is an understood portfolio aligned with business appetite.

When technical debt is described through consequences, evidence and treatment choices, leadership can govern it like any other investment. It stops being a vague argument between engineering and product and becomes a disciplined conversation about risk, speed and future options.