On Technical Leadership

When I first moved into a leadership role, I thought my job was to make the best technical decisions. I’d review every PR, weigh in on every architecture discussion, and pride myself on catching bugs before they shipped.

I was wrong about almost all of it.

Your job is to multiply

The best technical leaders don’t write the most code — they create environments where everyone writes better code. That means investing in mentorship, documentation, and processes that reduce friction.

Context over control

Instead of making decisions for your team, give them the context to make good decisions themselves. Share the business goals, the user feedback, the constraints. Trust them to find the right path.

Protect the maker’s schedule

Nothing kills engineering productivity like unnecessary meetings. Be ruthless about protecting your team’s time. Async communication, clear documentation, and well-defined goals reduce the need for synchronous overhead.

Embrace uncertainty

You won’t always have the answer. That’s okay. What matters is that you create a culture where it’s safe to say “I don’t know” and where experimentation is encouraged. The best solutions often come from unexpected places.