Why technical background matters in engineering management

This blog post first appeared on Medium on Aug 27, 2020.

When in 2006 I started my career in the tech industry there was a shared opinion spreading into the software engineering community: poor software engineers eventually become managers.

Despite never liking the patronising attitude of the self-declared “real” engineers, I have to say that their opinion was supported by more than just a sense of entitlement. The reality was that most of the managers they worked with were ex-engineers had little hands-on experience in the field or people had a background in non-techonoligical fields, rather than a technological one.

My hope at the time was that, with the natural evolution of the industry, new leaders and managers with a stronger technological background would have emerged to benefit the discipline with a more holistic approach.

Unfortunately after more than 10 years the factual situation hasn’t change much; what has changed instead is the engineer’s point of view. Nowadays it’s commonly accepted, and sometimes highly valued, to have software engineering managers without or with limited hand-on experience. After all they can always take a MOOC on web development or read some books, it will be enough for what they need. I strongly disagree with this.

One of the most important skill of managers is to understand the needs of the two sides and communicate them effectively to the other one.

Software managers work in a middle ground, between the business side and the technical side. One of the most important skills of managers is to understand the needs of the two sides and communicate them effectively to the other one. Understanding the impact of the decisions requires a deep level of understanding of the two contexts.

For example let’s say the engineering team wants to use a brand new language for a new project. Fine, innovation is important and desirable, but what does it mean to use a new language?

It’s important to understand what are the real benefits of the choosen language in relation to the value we need to deliver. What is the language learning curve and reconcile it with the team’s capability and the labor market offer. In addition the team will need to set up a new development environment, new tools, new libraries, new runbooks, new CI/CD, new practices and maybe new infrastructure to support the different environment.

Does a manager, with little or no hands-on experience, have the necessary skills and knowledge to realise all those implications?

Now the question is: does a manager, with little or no hands-on experience, have the necessary skills and knowledge to realise all those implications? How is this manager going to support the choice with the external stakeholders, if they need to? And how harmful can it be to present it without realistic expectations?

The same is true from the other side. For instance, technical debt is one of the most difficult things to understand for non-technical people. Regardless of how you picture it, non-technical people always tend to underestimate it’s complexity. In order to understand a technical debt you need to know the nature of it and what is the implication that it brings, especially if we talk about architectural debt.

…at the end of the day it’s the manager that needs to communicate to non technical people the implications…

But how managers can really understand that if they have no knowledge of code patterns or design patterns? Many will answer that they need to trust engineers. Yes, trust is fundamental, but at the end of the day it’s the manager that needs to communicate to non-technical people the implications of that choice. In order to do that you need to have a clear understanding, otherwise you end up repeating what someone else said, without having the real knowledge to support your position.

I strongly believe that to be an effective manager you first need to build up a solid and deep knowledge of the technology, meanwhile investing some time in soft skills and management. Without the necessary technical knowledge the risk to make ego-driven decisions rather impact-driven one is really high and it will result in bad performances for you team and the company.