3 short lessons I learned in tech leadership

Knowing what to work on is more difficult than figuring out how to make it work.

Let’s be real. Most projects I’ve been on have not been on the bleeding edge of computer science. Though I’m no stranger to using modern approaches, it’s mostly been best practices and proven tech to solve a specific problem for a specific audience.

The tools are the same. What matters is how you apply them to the project at hand.

That said, figuring out what you should build is much more difficult.

When you know the what, the how is usually simple.

Business rarely understands tech. Tech usually ignores business.

Different incentives. Different skills. Different mindset.

To be a good engineering leader, you need to know both sides. And you need to be able to bring the business side closer to the developers.

The job of the software engineer is not to write code. It’s to solve a problem for the customer. Yes, that often includes some code or automation.

But code is a means to an end, not an end in itself.

Siloses will form naturally because like attracts like. You need to actively design your organizational structure to achieve the desired effect.

Backend/Fronted and Product/Engineering are terrible split points, but plenty of companies do this.

I would not recommend it.

How you design your organization will have a massive impact on the way things are done.

Often, the best way to improve performance is not by implementing better processes.

It’s by changing the organizational structure and communication. The rest will fit into place.

Yours,

Taj