Should the manager maintain a strong technical focus?
A Leadership perspective of technically strong managers
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
Having a highly technical IT Manager in the organization is without a doubt, a great advantage for decision-making. However, not everything has a straight simple conclusion. Despite IT being very technical, there could be some disadvantages and biases in terms of having a Manager who still clings heavily to the projects’ technical aspects.
This post’s goal is to provide a Leadership perspective on these kind of Managers, and go through their added-value and improvement points. Having a strong technical background is a huge advantage to understanding topics and situations that happen or the organization. It can provide a strong foundation, however some managers still hold to these technical duties, blocking other team members from rising in autonomy and responsibilities.
The Good Stuff of a Highly Technical Manager
Having a detailed understanding of the challenges and struggles being faced is without a doubt better than having to explain it to a non-technical manager. Simply put, they cut straight to the meat of the problem being solved. They have a clear understanding of the consequences and effort required to implement a change and the risks inherited from a given strategy. They don’t waste other people’s time, especially the expert engineers’ by translating the IT verbose.
Due to the lack of technical profiles in IT for many years, it has become fashionable to arrive at a meeting full of IT experts and say the famous words: “I don’t understand much of the technical part”. How annoying is it to hear these words at a meeting where critical decisions need to be made? A Manager with a strong technical background will never say that to their teams. If needed, they will prepare the knowledge gaps before important meetings.
Another big advantage is the level of credibility that transpired to the project team’s external stakeholders. Having a manager explaining in great detail a situation or describing a problem with the linked solution provides a level of confidence and credibility to any Product team, Client, or any other stakeholder. It shows the situation is being handled by someone who understands the issue, knows what the team is doing, and has control over the situation.
In regards to the project team, these kinds of leaders are the best mentors. They understand the technologies and the gaps the Engineer needs to address to improve their skills. They can have a detailed discussion about specific situations that happened and use the same level of technical language, and the ideas can be tackled in much larger detail.
The Improvement Points
Communication is one of the major topics of leadership roles. Unfortunately, the technical aspects of any project or skill take a lot of time to develop, and to go further on a technical skill set is typically to the detriment of developing soft skills. Having the ability to communicate with different types of stakeholders is a skill on its own. It requires practice and exposure to improve this skill. If a Manager is solving a problem hands-on, is for sure to detriment of their team’s ability to solve an issue or in lack of stakeholder management.
This comes also with another potential problem: The team’s low empowerment. There is nothing worse than having a team composed of 5 engineers, and all need to check with their Manager the details of their implementations. Having managers still coding and still directing how things should be done, is voiding the team of their autonomy and empowerment to come up with the solutions. To have a manager helping define the guidelines for the code, quality gates, or other aspects that involve the solution-making processes, is completely OK. However, a manager should not be the Code Police. The team should be autonomous to detect and correct the faults of their code and should be provided the resources and training. For the latter, it can be the Manager to provides the training, but it should come with the empowerment for a team member to pass along the practices with their colleagues.
One of the strongest improvement points is probably the need to acknowledge and improve the biases against other people’s solutions. The highly technical manager can be the decision-maker for a lot of crunchy problems. Highly technical managers can even propose good solutions for these problems. The biases come while addressing other people’s solutions, which might come in a different technology stack, a different approach to fixing a problem, or any different perspective. As an example, if I am on a call with 3 engineers and no one agrees with my solution, it is because: 1) I didn’t explain well and my solution’s added value wasn’t clear; 2) They are seeing something that I am not understanding yet; 3) My solution sucks. So if I push my solution forward despite not having a consensus, or at least some support from other engineers, why I am having a call with them if I don’t take their opinion into account? Are these calls even made? This might be a symptom of a lack of team empowerment.
A personal story
While I was in the process of transitioning from Technical Leader to Manager, I was asked by my Manager a set of tasks in regards to the team and the budget. This request coincided with an event regarding the application and I was performing a root cause analysis. After a few hours, my manager asked me about his request, which I didn’t have time to address and explained why. His answer was blunt and direct: My tasks are a reflection of my ambition. If I would like to progress to a management position I should have delivered what he has requested.
Be mindful that transitioning from a technical role to a managerial one is one of the toughest transitions in IT. With my experience today, I try to provide as much coaching and guidance as possible to my colleagues who are performing this transition. However, what I have learned in that moment is that I indeed should have personally made the task requested by my Manager, and delegated inside the team the root cause analysis. I could have provided value by reviewing the result of the root cause analysis, and I had people on the team able to do it. It was a matter of delegation.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur