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.

When I first started as a delivery lead, my fellow engineering leads seemed disengaged to me. 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 and spoke of servant leadership. They 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 solutions to myself and was surprised when the team usually found a better solution themselves. A team cannot become greater than the sum of its parts when it’s bottlenecked by the smartest person in the room.

I moved to a well-funded startup building everything 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 was 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.

For a time, our engineering leadership managed to shield my teams from marketing and sales pressure, 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.

Then the engineers wrote their own stories after the principal had provided a detailed plan. Our principal was still a bottleneck, so we moved to writing one-pagers/lean-canvas: high-level goals and constraints for a stream of work, leaving engineers to plan the specifics themselves.

Keeping everyone in sync was the next problem. Different leaders pulled in different directions and pivoted engineers mid-stream. There were tears. Finding time in calendars to resolve conflicts was hard. Instead 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 forward 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. The following week, we’d peer review the plan and haggle over milestones. After that we’d 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.

What we’d really built was trust infrastructure — the rituals and shared context that made it safe to distribute ownership. 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. I often wonder if I’d still be working there, had our senior engineering leaders done the same thing with their peers.