Lessons From Leading 100+ Engineers Across 50+ Products

Thirteen years of building and leading engineering teams across 50+ products has taught me that the hardest problems are rarely technical. Here are the lessons that took me the longest to learn.

Hire for judgment, not just skill

The best engineers I have hired are not always the ones who ace technical interviews. They are the ones who ask good questions, think about trade-offs, and understand that code exists to serve users and businesses — not the other way around.

Technical skills can be developed. Judgment, curiosity, and ownership mentality are much harder to teach.

Process should serve the team, not the other way around

I have seen teams drowning in process — daily standups that last an hour, sprint planning that feels like bureaucracy, retrospectives that produce action items nobody follows up on. Good process should make the team faster and more confident, not slower and more frustrated.

The right amount of process depends on the team, the product, and the stage of the company. Start minimal and add structure when you feel specific pain, not because a framework says you should.

The best leaders make themselves unnecessary

Early in my career, I measured my value by how much the team needed me. I was the one who knew the codebase best, the one who made the critical architecture decisions, the one who stayed late to fix production issues.

Now I measure my value by how well the team performs when I am not in the room. The goal is to build systems, standards, and people that can operate independently. If removing you would cause the team to collapse, you have not led — you have created a dependency.

Communication is the multiplier

A team of excellent engineers who communicate poorly will always lose to a team of good engineers who communicate well. Invest in clear documentation, structured decision-making, and regular alignment — it compounds over time in ways that no technical improvement can match.

Ship, measure, learn

The most important thing any engineering team can do is ship. Not perfectly, not with every edge case handled, but consistently and measurably. Every day spent polishing without user feedback is a day spent optimizing assumptions instead of validating them.

Build the culture of shipping first. Quality, at scale, follows.