Why technical background matters in engineering management
When I started my career in the tech industry in 2006, there was a shared opinion within the software engineering community: poor software engineers eventually become managers.
Despite never liking the patronizing 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 who had little hands-on experience in the field or came from non-technological backgrounds.
At that time, my hope was that, with the natural evolution of the industry, new leaders and managers with a stronger technological background would emerge to benefit the discipline with a more holistic approach.
Unfortunately, after more than 10 years, the factual situation hasn’t changed much; what has changed instead is the engineers’ point of view. Nowadays, it’s commonly accepted, and sometimes highly valued, to have software engineering managers without or with limited hands-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. Well, I strongly disagree with this.
One of the most important skills of managers is to understand the needs of both sides and communicate them effectively to the other.
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 both sides and communicate them effectively to the other. Understanding the impact of decisions requires a deep level of understanding of both 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 the real benefits of the chosen language are in relation to the value we need to deliver. What is the language learning curve and how does it reconcile 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 new infrastructure to support the different environment.
Does a manager, with little or no hands-on experience, have the necessary skills and knowledge to realize all those implications?
Now the question is: does a manager, with little or no hands-on experience, have the necessary skills and knowledge to realize 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 its complexity. In order to understand technical debt, you need to know its nature and what implications 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 can managers 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 who 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 while investing some time in soft skills and management. Without the necessary technical knowledge, the risk of making ego-driven decisions rather than impact-driven ones is really high, and it will result in poor performance for your team and the company.
