Most founders and engineering leaders I meet share a dirty secret: their playbook is someone else's. They benchmark on competitors, cargo-cult processes from previous employers, and import org structures wholesale from companies operating at completely different scales and stages. It feels safe. It feels informed. But as Apple's CFO Kevan Parekh once said, when you benchmark on others, you risk getting get bad ideas. When you look inward at the details of your own business and team and solve from first principles, you build something worth having.

This resonated with me because I see it constantly in engineering leadership. Teams adopt practices because they read about them in a blog post from a company ten times their size, or because "that's how we did it at my last place." The result is layers of process that don't serve the actual team, and a leadership culture that optimises for looking like a good company rather than being one.

Your code review process is probably wasting time

Code reviews and Pull Requests are a great example. Almost every engineering team has mandatory review on every change because that's what you do. But have you actually asked whether it's working for your team? At a three-person startup, requiring review on every pull request often just means someone context-switches away from their own work to rubber-stamp a change they barely understand because they weren't involved in the decision to build it. The review adds latency without adding quality.

That doesn't mean code reviews are bad. It means you should be thinking about where your engineers are actually spending their time, and whether the review process you've inherited is creating value or just creating the appearance of rigour. Some changes genuinely benefit from a second set of eyes. Others would be better served by shipping immediately, backed by good tests and monitoring. The answer depends on your team, your codebase, and your risk tolerance - not on what Stripe or Google does.

Details are your job

There's a common trajectory for engineering leaders: you get promoted, you start "thinking strategically," and you stop paying attention to the details. The logic goes that you should trust your team, delegate, and focus on the big picture. And there's truth in that. But I've watched this advice get taken too far, to the point where leaders have no real idea what their teams are actually building, how long things take, or why things are slow.

The best leaders I've worked with and for have always been deeply across the details. Not because they don't trust their people, but because the details are where reality lives. Strategy disconnected from details is just hope. And when you're across the details, you earn the credibility to set the bar for everyone else. Your direct reports see that you care about the specifics, and they mirror that standard.

If you're leading a team and you can't explain the current state of your most important project without checking a dashboard or asking someone, you've drifted too far from the work.

Micromanagement is not a dirty word

Somewhere along the way, the industry decided that micromanagement is universally bad and empowerment is universally good. Like most binary thinking, this is wrong.

There's a version of "empowerment" that's really just abdication. You hand someone a problem, disappear, and call it trust. When things go sideways, you frame it as a learning experience. This isn't leadership. It's avoiding the uncomfortable reality that sometimes you are the most experienced person in the room, and your team would benefit from you showing them how to do something rather than watching them figure it out the hard way.

Early in a company's life, and honestly at many points after that, the best thing a leader can do is lead by doing. Write the code. Design the architecture. Run the incident review. Not because you don't trust your team, but because demonstrating excellence is more effective than describing it. Hold on to that as long as you possibly can. The moment you fully detach from the craft, you lose the ability to set a genuine standard.

The distinction between micromanagement and attention to detail is simple. Micromanagement is telling people how to do things you know less about than they do. Attention to detail is staying close enough to the work that your experience and judgment actually make things better.

Hire fewer, better people

The default scaling playbook for fast-growing companies is straightforward: more work means more people. Headcount becomes a proxy for progress. But I've seen small, talent-dense teams consistently outperform organisations three or four times their size. Not because they work harder, but because every person on the team is capable of operating independently at a high level, there's less communication overhead, and decisions don't get stuck in layers of approval.

The temptation to grow headcount quickly is strong, especially when there's pressure to ship more. But every hire that isn't genuinely excellent dilutes the average quality of your team and adds coordination cost. Two strong engineers who deeply understand the problem space will almost always outpace five average ones who need to be managed, aligned, and kept in sync.

Being relentlessly focused on hiring quality over quantity is one of the highest-leverage things a founder or engineering leader can do. It's slower. It's harder. You'll feel understaffed. But you'll also move faster, build better software, and spend less time on the management overhead that comes with large teams.

Think for yourself

The thread connecting all of this is the same thing Parekh was getting at: when you default to benchmarking on others, you import their problems along with their solutions. Every team, every company, every product is different. The leaders who build genuinely great engineering organisations are the ones who look at their own context, ask what's actually working and what isn't, and have the conviction to do something different when the evidence demands it.

Stop copying. Start thinking.