How I work

A business need arrives from a stakeholder, and from that point it is mine. Not the ticket — the outcome. In practice that means I would rather spend two days arguing about whether we are building the right thing than six weeks delivering the wrong thing on time.

It also means I write the specification myself when the target is unclear. Handing a vague brief to a team and calling it delegation is how you get three sprints of rework and a demoralised team who did exactly what they were told.

Structure follows the work, not the org chart. When a capability is missing I build the function rather than distributing the gap across people who already have full-time jobs. That is why this department has Product Owners and Product Designers: the work needed them, and asking developers to absorb product thinking in the margins was producing exactly the results you would expect.

I manage through team leads and I protect that boundary in both directions. A lead whose decisions I overrule in front of their team is no longer a lead. A lead who cannot say no to me is not much use either.

Predictable beats fast. A team that reliably delivers what it committed to is worth more to a business than a team that occasionally delivers twice as much and occasionally delivers nothing.

Which is why a sprint here is not one hundred per cent features. Capacity is explicitly split: most of it to planned work, a reserved share to support, and a reserved share to technical improvement. Pretending a sprint is all features does not remove the support work — it just makes it invisible until it becomes an incident, and makes technical debt permanent because it never has a slot.

The sprint boundary is real. Work does not enter mid-sprint unless it meets a written definition of critical: production down, revenue affected, or a legal obligation. Everything else waits, and because the criteria are written down, waiting is not a negotiation about tone of voice.

A gate that is a form to fill in is theatre. A gate that is an automated check is a gate. Every stage from intake to production has a condition, and where a machine can evaluate that condition, a machine does — static analysis, security scanning, non-functional checks on staging, post-deploy monitoring that can roll back without waiting for someone to notice.

Incidents get a blameless post-mortem that closes with a preventive control, never with a name. This is not kindness, it is self-interest: teams that expect blame hide problems, and hidden problems cost more than the original fault. The part people skip is the follow-through — a post-mortem whose actions are never delivered is a document, not a process.

Velocity is not a productivity score, and treating it as one is how you lose a team. The delivery metrics exist for two reasons: to make forecasting honest, and to show when a team is under strain. Commitment accuracy, velocity stability, defect escape rate, the ratio of planned to unplanned work — every one of them is a signal about the system, not a grade for a person.

Anything that measures individuals gets used against them eventually, whatever the original intention. So the reporting I built for management deliberately aggregates: where time and cost went by project and epic, where delivery risk sits, where quality is drifting. If a specific person is struggling, that is a conversation, not a dashboard.

AI is part of how this department works, and I set the direction rather than leaving it to individual enthusiasm. Concretely: AI-assisted review inside the code review step, and a design system encoded for LLM use so a concept becomes a working prototype in hours instead of days.

The standards matter more than the tools. What has to be verified before it ships, what never leaves our infrastructure, and where a confident-sounding answer is not good enough. I hold those standards to my own work too — I built our internal reporting application with a coding agent, and reviewed every line that touched credentials.