As an engineer, I have my preferred toolset. I love using AWS CDK for infrastructure. I like full-stack TypeScript. I want every piece of work tracked and discussed in GitHub. These tools make me fast, confident, and productive.

But as I’ve stepped into a tech leadership role and started hiring incredibly talented engineers, I’ve noticed something: they don’t always share my preferences. And that’s not a problem, it’s the point.

Some of the engineers on my team prefer Terraform over CDK. They prefer FastAPI in Python over Express.js in TypeScript. They want to use Notion for task tracking. They work faster with those tools. They’re more comfortable with them. And they’re just as capable, if not more, of delivering excellent software.

I could pull rank. I could say, “We’re using CDK, TypeScript, and GitHub workflows, period.” That decision might make a product slightly better from my point of view. Maybe 5% better. But at what cost?

Enforcing my stack would have meant taking ownership away from the people I hired to build and run our products. They’d spend their days working in tools they didn’t choose. They’d be less excited, less invested. That tradeoff, 5% better tooling (maybe) in exchange for 50% less buy-in, isn’t worth it.

Your Role Changes When You Become a Leader

This is a critical mindset shift for any individual contributor stepping into tech leadership: your job is no longer to be the fastest or most productive person on the keyboard. Your job is to hire and lead people who are better than you at shipping code, because your job is no longer shipping code. Your job is building a team that delivers business value by creating products and services customers will pay for.

How your team gets there is not your concern. If you feel the need to proscribe every tool and framework to them, you’ve either hired the wrong people, or you haven’t given them the trust and ownership to do the job you hired them for. Either scenario is a failure of leadership.

As a technology leader, you need to let go of your ego around tools and frameworks. The goal is not to use your favorite stack. The goal is to build the right team and enable them to move fast and confidently.

When they ask for your input, share your perspective. For example:

“I prefer CDK. It does complile down to CloudFormation, which takes longer to deploy than Terraform, however the overall code footprint is much smaller. Every line of code is a liability, so I’d rather have less of it.”

But make it clear: that’s context, not a mandate. They’re closer to the problem. Let them own the solution.

Trust the People Doing the Work

Tools evolve. Best practices change. The engineers doing the work are in the best position to choose the right tools. And they’ll be the ones maintaining the system long after your preferences have aged out.

So hire smart people, give them clarity, support them, and get the fuck out of their way.