Leadership is leverage

Technical excellence is a poor measure of a project’s success.

In my experience, it doesn’t even correlate that well.

I’ve seen well-architected projects without users and projects cobbled together from sticks and mud that still made a lot of money.

The bad trade

It was usually on those pieces of technical garbage that I was trying to push for reducing technical debt and improving architecture.

My pleas fell on dead ears.

Them: How will spending 6 months refactoring make us money?

Me: Errr … it will be more stable. Easier to develop. With fewer late-night emergencies.

Those were only issues to me. Management was happy to throw an extra engineer to fix problems at night and another sysadmin to restart a service when it breaks.

And even though I disagree with the methods, 10 years later, I can appreciate the approach.

I was mistaken for pushing for a partial rewrite that would take too long and bring too little.

But I was thinking like an engineer and not applying business thinking to focus my technical expertise.

The hindsight of experience

There are two ways to scale as an engineer, and both involve increasing the impact of your work.

In one word: leverage.

You can either become an expert in the technical domain or go into management.

The more people work for you and the more you can influence the company’s direction, the higher the leverage.

You can write the best code, but you’re just one human at the end of the day.

A leadership decision, on the other hand, impacts many people, and the right choices can make a massive difference.

Your leverage increases, and so does your responsibility.

That’s why you get paid the big bucks as a [a type of] leader.

The leader’s path

Not everyone likes or wants to go down this path. It’s nice to be just a grunt in the machine.

You get your tasks, tick them off, build some cool stuff, get paid well, and enjoy your vacation. You see some things that could be done better, but why bother?

I’ve done the leadership → individual contributor twice in my career to enjoy the carefree nature of this type of work. And that’s okay.

But sooner or later, I see problems that I want to address—problems that cannot be fixed with code.

Problems that have to be fixed with processes, tools, and people.

If you are a bit like me and want to improve things beyond the code, the leader’s path is for you.

Just know there’s a whole set of skills to acquire to do that effectively.

Yours,

Taj