5 Misconceptions of Being in Management (at Least for Techies)
Dispelling some misconceptions that can deter techies from pursuing a career path in management
Management seems to be a bad word for techies
I’ve spent 19 years working in the tech industry and 10 of those have been in a leadership / management role. One thing that I’ve noticed throughout my career is that a lot of techies aren’t big fans of the word “management”. Most technical people, especially software developers, usually end up at a crossroads in their career where they have to decide to continue their career down a management path or pursue a more technical path such as architecture. From my experience, more often than not, developers would pick a technical career path than decide to continue their career through management. Some have even told me that they’d rather stay in their team lead roles rather than be promoted to manager. When I discuss this career path choice during one on one sessions I find a few misconceptions often come up. Here are the 5 most common that I’ve come across and hope that I can dispel them for anyone in the tech industry currently thinking about their long term career development.
#1: Becoming management means you’ve given up on being technical
I remember the first time a member of my team stated that during a one on one discussion about their career development. While I didn’t react externally, internally I was a bit offended. I never viewed my transition into a management career path as me giving up on being technical. I acknowledge that I don’t write code anymore as part of my role and spend a fair bit of my time in meetings about strategies, coordination, HR, and other “non-technical” discussions. However, I strongly believe that no one can effectively manage or lead a team of technical people without being able to earn their respect. The only real way to earn respect from technical people is to exhibit an ability to get technical when needed. My view is that if you want to be a good manager of technical people, to an extent, you have to remain technical. While I don’t code as part of the daily job, I do still code on personal projects and still read up on technology developments. Only bad engineering managers would give up being technical.
#2: Those in management just care about looking good and make decisions about technology that are “safe” for their jobs
A former co-worker once told me about a head of IT at a previous job that wouldn’t allow Linux based computers at the company despite developers strongly advocating for it as a productivity booster for them. The rationale wasn’t due to some sound technical reasoning but simply because the head of IT wasn’t really experienced with Linux and was afraid allowing it would expose his lack of experience with it. I would make the same statement here as I did for misconception #1, only bad technical managers would be guilty of this misconception. Good technical managers are always making decisions about technology based on technical reasoning and the business context at the time. I believe this misconception is often fueled by the fact that a lot of managers don’t spend the time to explain the “bigger picture” and reasoning behind their decisions to their teams. Given that lack of additional knowledge it’s perfectly reasonable they think management is picking option A over option B “just cause” as opposed to the fact option B has tripled their licensing costs. I encourage those in management positions to take some time to explain key decisions to your teams. If you work for a manager who doesn’t then I would encourage you to try asking. Sharing of “bigger picture” enables both management and their teams to better understand situations and align.
#3: A leader of a technical team must be experienced on all the technology their team uses
This misconception is the exact opposite mentality as the first one listed. In this case, there is a misconception that in order to properly lead a technical team you must be experienced in everything the team uses or tasked to build. An example of this misconception came up a little while ago when I was talking to someone I have been encouraging and pushing into a lead role on one of my teams. They felt they couldn’t lead effectively because they had no real experience with front end development, which is something her team also needs to work on as part of the product they are building. I explained to this individual that having no front end development experience takes nothing away from the strong software engineering principals she exhibits. Sound engineering mindset and principals are always applicable regardless of programming language or technology in use and is what is really needed to lead a technical team. People sometimes get too wrapped up in buzzwords and the latest en vogue technology to realize that more often than not it’s just an iteration of classic approaches to solving problems. As an example, how is “Micro-frontend architecture” different then the old Portal container paradigm from the early 2000s? You don’t need to fully understand all the technical details or have direct experience with what your team does in order to effectively lead. A strong engineering mindset and an ability and willingness to learn is all you really need.
#4: Management means you have to deal with a lot of politics
I will concede that there can be politics you have to deal when progressing through a management path, especially when money and egos are involved. However, I will say it isn’t necessarily something you are guaranteed to experience. I would also argue that going down a pure technical track doesn’t necessarily save you from having to deal with politics either. Organizational politics are fundamentally a result of human interactions and it doesn’t distinguish between those in management versus individual contributors. In my opinion, it is also very easy to miscategorize disagreements between parties involved in a decision as being politically motivated. Sometimes a disagreement can happen because the parties involved are truly motivated to find what they believe is the best solution for the organization. It has nothing to do with being a power grab or any other common motivators for people to play political games. The perception that a lot of politics happen in management is because there are a lot of decisions being made and as I noted earlier, disagreements don’t necessarily mean political games are being played. At the end of the day, politics are the result of company culture and I believe if you find a company with the right culture then organizational politics won’t be much of a concern.
#5: People management sucks
There are definitely challenges having to manage people, especially for techies who are so used to being “in control” and “logical” when dealing with systems. Human behaviour can be unpredictable and illogical and that is what helps discourage technical people from pursuing management. However, I want to address this misconception by offering an analogy that people management is not too different then writing an advanced program or building an advanced system. In both cases you are trying to achieve an objective by building something using tools you have available to you. Sometimes it’s “green field”, meaning you get to build brand new code/system or in the case of people management, pick the people to form your team. Other times you’re inheriting code/system and need to assess and update it to enable you to achieve your objectives. That is similar to when you inherit an existing team that you have to assess and make adjustments if needed to enable you to do what you’ve been tasked to do. When it comes to the unpredictability of human behaviour versus the predictability of computers, I would say that there are examples of systems which can be just as unpredictable and therefore as challenging to manage. Just think of needing to troubleshoot a highly distributed and concurrent system in which an error occurs randomly and each time it causes a negative impact. Its random nature along with high concurrency can make it very tough to identify and address the root cause. If you view people management using this analogy then does it really suck that much more than developing advanced software / systems? You know, things that techies love doing.
Some misconceptions dispelled?
Hopefully I was able to dispel some misconceptions about management and help those thinking about which path to take when it comes to technical career development.
Originally published at http://realtimerevisions.com.
