Operating model

The squad was busy but reactive. Work arrived as Slack messages, half-formed briefs and drive-by requests, and almost every decision of consequence travelled upwards before anything moved.

Talented people were spending their skill on underdefined problems and then waiting for permission to solve them. Mid-sprint scope changes were normal. Because the work wasn't visible, stakeholders read it as an output problem, and the standard remedy for an output problem is more oversight: more check-ins, more approvals, more reporting.

Adding process is the obvious fix. It's almost always the wrong one.

Individually, every symptom looked like a discipline issue: chase the brief, push back on the request, absorb the scope change. Zoomed out, they were one design flaw. The team had no defined interface with the business, so nobody could safely be trusted to decide, so everything escalated, so the team looked slow, so more oversight arrived. A loop that tightens itself.

The way out was to invert it. Give the people closest to the work the authority to decide, and then build only the structure that makes those decisions good ones: enough shared context that a designer or developer can judge a trade-off the way I would, and one quality bar so nobody has to guess what good looks like. Structure in service of autonomy, not instead of it.

So I designed the squad's interface with the business as a system: what comes in, what good looks like before work starts, who decides, and what "done" means.

Decision rights first, then the smallest amount of structure that made them work.

Decision rights. The principle, shared with our product and tech leadership: push every decision as far down the organisation as it can safely go. The person closest to the work has the most context, so the default is that they decide. The mechanism was decide-and-inform: the squad makes the call within its remit and communicates it, instead of queueing for consensus. Decision velocity was the metric, not meeting count.

Context over control. Autonomy only works if people can see what I can see. The strategy, the commercial targets and the reasoning behind priorities are shared with the squad rather than translated into tickets, and both conversion metrics are visible to everyone rather than reported upward. A team given the why, and the number, can be trusted with the what.

Cadence. A weekly rhythm with defined modes: product-owner time, design leadership time, protected focus time. The calendar became a designed artefact rather than an accident.

One team, two crafts. Designers and developers sit in the same squad with the same goals. Each has their specialism, but nobody hands work over a wall: everyone is responsible for the work, the outcomes and the metrics, not just their slice of it. A developer can challenge a design decision and a designer can question a technical one, because shared ownership means shared standing.

Visibility. Sprint demo reporting was automated with an AI pipeline from our ticketing system into shareable summaries, so leadership sees progress without anyone spending hours on status decks. The same principle as everywhere else in my work: automate the toil, keep the judgment.

People.Structured development for two senior designers, with performance reviews built on real evidence pulled from meeting transcripts and shipped work across the half, not memory and vibes. The coaching thread running through it: developing designers into systems thinkers. Not "make this screen better" but "what system produced this screen, and what does it connect to?" A designer who thinks in systems can be trusted with decisions, which is what makes pushing decisions down possible in the first place.

Every failure is an invitation to add process, and most of those invitations should be declined. The judgment calls:

• Less
  Resist the process reflex

  When something went wrong, the default question was whether the person had the context and authority to get it right, not what checkpoint would have caught it. Most answers were context, not control. Process added after a failure is paid for on every future piece of work, forever.
• Gate
  One gate, not many

  A single Definition of Ready checkpoint carries the quality load, and it sits before the work starts rather than in the middle of it. Everything downstream stays lightweight, because a gate at every stage trades speed for theatre.
• Speed
  Push decisions down, accept occasional misses

  The person closest to the work decides; leadership is informed, not asked. Faster decisions at the cost of the odd wrong call, and a wrong call you can reverse beats a right call that took three weeks.
• Team
  Shared ownership over clean lanes

  Designers and developers co-own outcomes, which costs some role clarity and buys a team where quality is everyone's problem. Specialisms define what you're best at, not what you're allowed to care about.
• AI
  Automate reporting, never judgment

  AI writes the sprint summaries and gathers the evidence. It doesn't prioritise the backlog or review the people. Toil is automatable; accountability isn't.
• Coach
  Coach the system, not just the person

  When a designer struggles, the first question is whether the system set them up to fail. Fixing intake fixed more "performance issues" than any feedback conversation.

The squad stopped being measured on activity and started being measured on two numbers it owns end to end: visitor to paid subscriber, and visitor to data service enquiry. That was the point of the whole exercise. Autonomy is only real when a team is accountable for an outcome rather than a backlog, and those two metrics are what turned "are we busy" into "are we converting".

It also settled prioritisation without argument. Any request now has to answer which of the two numbers it moves, which is why the conversation shifted from "when can you do this" to "is this worth doing". Mid-sprint scope changes dropped as a consequence, because work that couldn't answer the question never reached the sprint.

Decisions genuinely moved down. Designers coached to think in systems started making calls that previously escalated to me, the design-developer boundary softened into one team debating the same outcomes from different specialisms, and the squad was reframed from a delivery function into a group trusted to make product decisions. The visibility problem dissolved as a side effect, not as the goal.