Engineer-Led

The smartest person in the room is often the bottleneck. That was me, and it took burning out to see it.

As an engineering lead, I carried the whole picture in my head. I knew the shortest path from A to B, had mapped every contingency, and quietly steered engineers toward my solution in increments small enough to seem like their own idea. I called this mentoring. It was dictatorship with good intentions.

After burning out, I became a delivery lead — a role where I had no say in technical direction. I could only facilitate. It felt like a demotion. It turned out to be the best education of my career.

The engineering leads at my new employer seemed, at first, disengaged. They spoke last, rarely made decisions in public, and spent most of their one-on-ones talking about personal matters. But they gave me gentle feedback that reframed everything I thought I knew. They weren’t checked out — they were listening. They intervened only for major course corrections, and always quietly, never in ways that undermined the team’s ownership.

I learned to facilitate rather than solve. To set up the conditions for a team to fail, learn, and level up — instead of solving their problems for them. I kept my solution to myself and was surprised half the time when the team found a better one. A team cannot become greater than the sum of its parts when it’s bottlenecked by the smartest person in the room.

I eventually moved to a well-funded startup building from scratch. Everything moved faster than normal — like watching a timelapse of a flower opening. I could observe years of team dynamics compressed into months. And I saw, up close, the path to building an engineer-led company, along with every way to fall off it.

The core tension was clear: you have to centralise decisions until you’ve built enough trust to diffuse them. The trap is getting stuck in centralise mode. The leadership were brilliant technical people — but they remained chief problem-solvers and protectors long after the team was ready for more. Investors, used to optimising established businesses, had little patience for the slower work of building distributed ownership. Annual restructures kept resetting the trust that made diffusion possible.

My teams were largely shielded from that, so we could make real progress. We started with a principal engineer writing detailed stories and running ceremonies to walk engineers through them — exactly the pattern I’d been guilty of. So we began shifting it.

First, engineers wrote their own stories from a detailed plan. Then the principal moved to writing one-pagers: high-level goals and constraints for a stream of work, leaving engineers to plan the specifics themselves. They’d kick things off in their own time.

Keeping everyone in sync was the next problem. Different leaders pulling in different directions were pivoting engineers mid-stream. Finding time in calendars was hard. We introduced a weekly design review session — mandatory attendance from anyone with strong opinions. Engineers brought controversial topics for open debate, strongly argued and loosely held. Once a design was peer-reviewed and disagreements settled, we could move with confidence.

Since design decisions often impacted the roadmap, and involved the same people, we merged roadmap review into the same session. Kick off a stream: review the one-pager, haggle the MoSCoW, engineers go away and plan. Peer-review the plan the following week, haggle over milestones. Then only revisit the roadmap if something material changed. One room, one conversation, everyone aligned.

Following this structure, engineers could grow into leading bigger initiatives. They raised their own one-pagers. They had a forum for prioritisation and planning. The principal wasn’t the bottleneck anymore. We built trust, stayed aligned, and became greater than the sum of our parts.

That’s what engineer-led actually means. Not a flat structure or an absence of leadership — but leadership that creates the conditions for the team to lead itself.