Stabilizing an engineering team through organizational change

I was asked to step into an engineering team during an organizational transition. The team’s makeup was changing, delivery expectations stayed high, and there was little room for a long reset: work already in flight still had to move, and new initiatives were close behind.

Raising velocity was the visible goal. The more important one was a team where engineers understood what mattered, owned meaningful outcomes, surfaced risk early, and could deliver without constant intervention from a lead.

Transitions expose problems that stay hidden while a team is stable. Ownership blurs. Decisions wait for the wrong person. Meetings multiply because information isn’t moving, engineers end up responsible for tickets instead of outcomes, and the lead compensates by getting pulled deeper into day-to-day execution.

Adding process tends to make all of that worse. The challenge was to make delivery more reliable while taking coordination overhead away.

• No pause in delivery: existing commitments and upcoming initiatives continued through the change.
• A team whose composition was changing while the work went on.
• Any new practice had to remove friction, not add ceremony.

I led the team through the transition — how work was owned, how the team spent its time together, and how risk surfaced — while staying hands-on in design reviews, debugging, and releases.

1. 01Find where work actually gets stuck

   Before changing how the team operated, I looked at where work was stalling and why, instead of arriving with a new operating model.

   TradeoffIt means living with some friction a little longer. Fixing the wrong thing first costs more.

2. 02Make ownership explicit

   Engineers took on areas of responsibility rather than collections of tasks. Owning an area meant owning the outcome: coordination, technical decisions, validation, and follow-through.

   TradeoffOwnership without context is just a bigger ticket, so it has to come with the why as well as the what.

3. 03Delegate decisions, not just work

   Engineers got the context and the authority to make calls themselves, so decisions didn’t have to queue behind the lead.

4. 04Make synchronous time earn its place

   Status moved to async updates, standups included. Meetings were kept for decisions, design work, collaboration, and genuine blockers.

   TradeoffAsync only works if people write things down. Without that, the team loses visibility instead of saving time.

5. 05Surface risk before it becomes a deadline

   Delivery conversations moved from whether a ticket was “in progress” to dependencies, uncertainty, carry-over risk, and what could stop the team from finishing.

6. 06Stay close to the technology

   Leading didn’t mean stepping away from the architecture. I kept reviewing designs, debugging problems, supporting releases, and working through hard technical decisions with engineers.

The team came out of the transition with clearer ownership, more predictable delivery, and less reliance on the lead. Engineers began taking broader responsibility for releases, technical decisions, and outcomes rather than waiting for decisions to flow through the lead.

It kept delivering significant production work through the organizational change instead of waiting for the environment around it to become stable first.

The broader pattern became repeatable: create clarity quickly, reduce dependency on the lead, and build enough ownership that the team becomes more autonomous over time.

The team’s results became part of a broader organizational experiment. Leadership selected the team to pilot a new locally owned product model — a team composed and operated locally, intended as a proving ground for extending the approach to additional teams and managers if it succeeds.

That brought another substantial transition. Most of the engineers from the first phase moved off the team, and a new group joined with a different mix of platform and full-stack experience. I remain the team’s lead. The question is no longer whether the original team could stabilize and deliver; it is whether the operating model — explicit ownership, protected focus, decisions delegated with their context — can transfer to a significantly changed roster. That phase has just begun.

• A lead should increase the capability of the system around them, not become the system everything depends on.
• In a transition, clearer ownership fixes more than extra process does.
• Moving status out of meetings gives the time back to the work that needs people together.