Engineering Manager – How can you use your technical skills to become a better technical manager?

For the last 20 years, my career in software development has been shaped to some extent by all three of my direct supervisors, who had strong technical backgrounds. This illustrates the indispensable role that talented software developers play in the industry’s success. If I may make a bold guess, you might already be a manager. Yet, you were undoubtedly a skilled programmer/architect/system engineer not too long ago (or maybe it was some time ago, but still, it feels like yesterday? 😉). Unfortunately, what we often aren’t told when transitioning to a managerial role is that it is not simply the next step in your career built on your technical competency – it is a new career path where you need to develop a new set of skills. Your technical background remains crucial but is no longer about your hands-on technical expertise.

Let me share my story with you. Many years ago, shortly after starting my career as a software developer, our company faced challenges with a project falling behind schedule. My teammate and I were assigned there. Delivery deadlines were already set; however, specific components remained unassigned. What is more, we lacked prior experience with digital TV or this project’s setup, but we were entrusted with a task aimed at designing and developing subtitles components there. Our holiday plans had to be cancelled so that we had even the slightest chance of delivering PoC by the tight, originally planned deadline 😉. That’s when I first met the program manager. Let’s call him Andrew. As the person leading this program, he was in charge of coordinating multiple fields like software, electrical, and mechanical engineering. In response to the urgent situation, Andrew came in person to our location. He directly consulted each team leader on their progress and provided them with subsequent assignments.

Upon returning to the company mentioned earlier after a few years, I had completed my project management studies and acquired several years of international experience. I transitioned from a project manager to an engineering manager role, leading a team comprising almost 20 people. My goal was to empower the existing three teams and their leaders to work autonomously, take decisive actions, and solve problems effectively. During the same period, another program was in the midst of a firefight. My team was assigned to functionality that had not yet been started. Do you spot the pattern? There was a daily war room for all component leaders, where they provided task updates and received urgent assignments for the next 24 hours. This time, oversight came not from the program manager but from the Global Product Director.  The individual I am referring to was Andrew. While I focused on supporting my team through intense challenges and simultaneously developing my other two teams, I asked myself, “What is the GLOBAL program director supposed to do?”. I firmly believe that direct task execution is the responsibility of the team’s direct leader. Andrew had been involved in managing major crises for 10 to 15 years.

Here, we have a clear example of micromanagement, but this article is not meant to be about it. Instead, it is about advancing your career based on the skills that have already proven successful in your previous roles but might not be as crucial now. You may find yourself in a situation where the organisation fails to deliver expected results, prompting your necessary guidance. However, this should always be the exception rather than the rule. When addressing issues at the lowest level, you demonstrate your technical expertise and supremacy over other leaders, but unfortunately, by doing so you also move away all middle-level leaders from their roles. Also, your responsibility includes supporting individuals to help them grow as new leaders. There’s a difference between understanding a problem and directly resolving it. As you advance into higher managerial roles, your focus shifts towards making the right technical decisions that fit business needs without getting into bonnet details. Taking actions that could be delegated to your subordinate may earn you immediate recognition but can hinder their development for the next career level.

I have met managers who believe they should be able to perform every task their team handles. However, when your team comprises various roles such as programmers, testers, and system engineers, it is simply not possible to excel in every domain. Also, if you would like always to do your team’s job, you limit your ability to transition into different areas of the organisation that require different expertise. And by the new area, I understand also moving to managerial role. If you get promoted, your next team will consist of managers like yourself, not programmers. Your current work should align with your career plan and prepare you for the next step, rather than keeping you tied to your current position. Sometimes, your career advancement might be blocked if no one can take on your existing duties. Your technical skills might allow you to solve issues quickly, giving you a sense of efficiency and accomplishment. However, whenever you resolve a problem yourself, you prevent your team from finding a solution. Engineering managers are responsible for ensuring delivering results. It is the team that shall work towards these very results, and the manager’s role is to guide them to success, not to do their work for them. Your level of engagement should vary based on your team’s experience. Sometimes, you will only need to hold your horses and give them room to step up, other times, you may need to provide guidance and offer tips to help them find a solution. One thing is sure – each time you invest your energy in helping your team come up with solutions, you build an organisation that can tackle issues.

How to use technical skills based on team maturity

Rookie pack (Interns, maybe?)

We may easily picture a team set up out of interns and some rookies. The easiest way to boost outcome delivery is, theoretically, to take on individual tasks that would need explaining. It would be completed faster than guiding interns through each step and addressing basic problem-solving, considering that they would need your help with basic problem-solving, as they are still learning to anticipate typical errors and understand good programming practices. Even aspects such as environment configuration and version control may be new to them. You could easily accomplish the work of three or four team members at the same time. The work is delivered on time half a year later thanks to your engagement. There is a catch though: while your team may admire you, the rookies will still need to learn how to manage the next tasks in the queue. Some of them may have gained insights from observing your work, while others might be looking into new opportunities, as they find reviewing someone else’s work less stimulating. They may be building their self-esteem in their rookie role and adapting to new challenges and opportunities. Perhaps you had to strive for your opportunity to demonstrate your capability with the first task, and now you are seeking another passionate individual who shares the same passion?

Now, picture this: The manager sipping coffee. Some young engineers are ready for promotion. They can deliver well-defined tasks by themselves, are full of courage to ask for help to do their jobs, and are looking for the next challenge. They are vibrant and engaged.

–        You might say, ‘These are no rookies.’

–        And I would respond, ‘But they were just six months ago.’

What changed? They definitely did not meet delivery expectations at the beginning. Their leader anticipated this and adjusted plans to accommodate lower velocity. Managers need to make decisions based on their knowledge and experience. He invested extra time explaining what technology and solution he chose and why he found it suitable. Each task required additional time for explanation, potentially involving the entire team. Based on his experience, the leader provided comprehensive solutions. Rather than handling tasks directly, he positioned himself “in the middle”, offering guidance to the team, reviewing lines for modification, fulfilling requests, and coordinating emails with the co-working team. Now, this team has advanced to the next level. The initial investment in slower delivery has resulted in valuable engineers who are faster with smaller retention. One more gain is that in emergency cases, we still have an extra workforce ready for firefighting – the manager himself. Every time he undertakes tasks personally, he becomes part of the default team velocity and cannot step in in emergency situations. This shift has also opened a growth window, so managers would no longer sit and sip coffee, and exponential delivery capabilities increased.

“If you are a leader, the people are your work.”

― Gerald M. Weinberg, Becoming a Technical Leader: An Organic Problem-Solving Approach

In this case, we have not only improved our working skills but also cultivated a culture where these individuals will, in a few years, continue this valuable learning cycle with their younger teammates. In both cases, the manager put to use his skills. In the first example, he has used them directly to deliver work. Here, his efficiency is strongly limited by the volume of work he can provide, as well as other managerial duties that diminish his available working hours. The second case shows us how teaching and growing others’ approaches stream an original technical skill set. As we concentrate on our team objectives, it is easy to overlook that the primary role of a leader is to lead and empower others towards achieving their goals.

Medium maturity team

A team composed solely of beginners is a very rare case. It’s more typical to have some members with moderate experience (approximately 4-8 years), with whom you work to tackle tasks from the backlog. The team is well-versed in their responsibilities, and you provide expertise in tackling the most intricate cases. They learn through observation, asking questions, and your guidance. While you review their tasks, who reviews yours? You review their tasks. But who does review your work?

Imagine yourself as an observer and planner. What if you decided not to handle the most challenging tasks? Instead of building code, you build up the scene where your team plays the main delivery role. That is a moment in a career when your team members may start showing interest in leaving their technical roles to take the leader path. It is the perfect time to delegate medium-level tasks, providing them a safe environment to learn from failures while you oversee. To achieve this, they need opportunities to experiment, i.e., handle difficult tasks, try to lead medium-sized initiatives, cooperate with other teams, and maybe with a project manager.

“The greatest contribution of a leader is to make other leaders”

– Simon Sinek

Today is the time to plan your team’s career. You help them identify what suits them best. This involves being attentive to their needs. Spend your time and energy setting up the right environment for their evaluation and development. Now is the moment to decide where your organisation will be in five years. Either you shape your team’s future or get surprised by it.

Hello, elite on the deck!

“One of the hardest choices for technical stars who become leaders is losing touch with the latest technology”

― Gerald M. Weinberg, Becoming a Technical Leader: An Organic Problem-Solving Approach

Imagine yourself with someone with over ten years of professional experience in their technical role. With extensive expertise and a matching career grade, they are one of the company’s most valuable assets. In general, we may assume that this person’s technical expertise should be superior to yours. This team member has spent their entire career advancing their technical skills while also balancing leadership duties. This suggests that roles should be reversed within the technical realm, and if this team member is present in this area, you should follow their guidance. What remains unchanged is your alignment with company and business priorities. What comes new to managers is the visibility of such a person. It is reasonable to assume that managing team-level tasks is a daily part of this employee’s role. You still need to seek growth opportunities; that is where collaboration comes in. By working together, you may address pilot programs, innovation, and areas out of reach for regular teams. These initiatives gain visibility beyond your current position, requiring higher approval and funding. They also act as a catalyst for both of you to achieve visibility among directors or VPs. Usually, these technical career levels are equivalent to manager+ roles, focusing on shared objectives and cooperative partnerships rather than traditional senior-junior relationships (or dynamics).

Impostor Syndrome

“Impostor syndrome, also known as impostor phenomenon or impostorism, is a psychological experience of intellectual and professional infraudulence.[1] It is “the subjective experience of perceived self-doubt in one’s abilities and accomplishments compared with others, despite evidence to suggest the contrary.”[2]

https://en.wikipedia.org/wiki/Impostor_syndrome

1.     Mak, Karina K. L.; Kleitman, Sabina; Abbott, Maree J. (2019-04-05). “Impostor Phenomenon Measurement Scales: A Systematic Review”. Frontiers in Psychology. 10. doi:10.3389/fpsyg.2019.00671. ISSN 1664-1078. PMC 6463809. PMID 31024375.

2.     Walker, Deanna L.; Saklofske, Donald H. (2023). “Development, Factor Structure, and Psychometric Validation of the Impostor Phenomenon Assessment: A Novel Assessment of Impostor Phenomenon”. Assessment. 30 (7): 2162–2183. doi:10.1177/10731911221141870. ISSN 1073-1911. PMC 10478341. PMID 36591960.

Why now and why in this context? From what I have observed, there are primarily two versions of imposter syndrome among good managers.

“I shall be a technical expert, but I can no longer do technical work that my team is doing.” This situation often arises after transitioning to a managerial role, where the team’s technical advancements mean you are no longer able to perform the hands-on work they do. Alternatively, it may occur when you are assigned new technical responsibilities or move into a different technical expertise area.

Others feel like, “I am an educated engineer. I have always been an engineer, and now I am expected to manage people. I am responsible for their motivation, while I was given only minimal training. Dealing with diverse soft skills was never part of my education.” That is certainly true, but it does not mean you are an imposter. The majority of IT managers initially worked as engineers.

So, how do you handle these doubts? My strong recommendation is to take simple steps. Try to review your activities as a manager. Do you care and lead your team in their career progression? Are you able to prioritize the work assigned to your team? Give them tactical direction on what solution should be selected. If your responses align with the current needs, then you are the right person in the right place.

Summary

In conclusion, transitioning from a technical role to a managerial position requires a shift in focus from direct task execution to empowering and growing the team. As an engineering manager, the emphasis should be on making the right technical decisions that align with business needs while also fostering the development of new leaders within the team. By investing time and energy in guiding and enabling the team to find solutions, an organisation can cultivate a culture of continuous learning and leadership development. The key lies in leveraging technical skills to mentor and elevate the team’s capabilities, ultimately shaping the future of the organisation.