Pitfalls When Transitioning from an Individual Contributor to a Technical Manager

Common issues to avoid when making the leap to manager

Paul Chiu
Paul Chiu
Jun 5 · 8 min read
Photo by Histuan Horvath⁵ from Pexels

The transition from an individual contributor to manager is not always straightforward, it’s an experience that can be fraught with uncertainty. Even if your organization has training programs, good mentors, and you have a good idea of what you want to achieve, the differences between theoretical and practical application can still be daunting. In this piece, I’ll outline a few issues I have experienced or observed which can compound problems and send new managers down a vicious cycle that spoils the management experience. These issues include the responsibility virus, not recognizing management works on different systems, and appreciating group dynamics.


The Responsibility Virus

In Alan Watkins’ book 4D Leadership¹, he cites Roger Martin’s (2003) writings about ‘the responsibility virus’. The responsibility virus is a phenomenon where someone promoted into a leadership position, in an attempt to improve outcomes, becomes involved in work that should instead be delegated. The viral aspect of this phenomenon is the impact such actions have on all parties involved.

Imagine the following scenario: You are promoted from programmer to technical manager. You are presented with a deadline that concerns updating an area of the system only you can deliver within the target deadline. You then step-in to fully deliver the changes for the team. You are hailed as a hero by upper management. The project is deemed a success and the team moves on to the next problem. Unfortunately, this is the beginning of the technical manager practising ‘over responsibility’.

If over responsibility only impacted the manager practising it, that may be acceptable in the short term. However, the viral aspect of this phenomenon is that the team may become complacent, informally decide that area of the system is not their concern, or perceive that they are not to be trusted with working on that area of the system. Any of the aforementioned possibilities may result in members of the team being less likely to take responsibility the next time a similar change is needed.

Should the practice of over responsibility not be addressed, the manager will find themselves dealing with more issues on top of their actual responsibilities leading to effects highlighted in Watkins’ pressure performance curve:

Pressure Performance Curve (source: Watkins¹)

The pressure performance curve shows that although the manager may find themselves feeling more productive than ever — their heroic performance not only brought about success but also reinforced that they still technically have ‘it’ — eventually the manager will become overworked and overwhelmed. Even more concerning is that such behaviour can be encouraged by upper management as it demonstrates the technical manager going ‘above and beyond’ the call of duty.

If the responsibility virus is to be avoided, a manager must refrain from yielding to the business’ requests and instead negotiate a more realistic timeline whereby the coaching and training of the team to complete activities themselves can be achieved. Allowing time for training and handover should be a natural part of transitioning an individual contributor to a manager. The team may also realise that they are actually short on resources and need to hire a new engineer. Identifying such issues and having a discussion within the broader organisation will help highlight constraints that may hinder the team’s ability to meet the organisation’s expectations, with the ideal outcome being receiving support from the organisation to overcome said constraints.


Recognising Management Works on Different Systems

In Ray Dailo’s Principles² book, he writes:

Great managers are not philosophers, entertainers, doers, or artists. They are engineers. They see their organisation as machines and work assiduously to maintain and improve them.

If you were previously a software engineer, it may be difficult to recognise that you are actually doing the same job as a manager, but with different systems and tools. There are two aspects to making the mentality shift. The first being that as a technical manager, although you are still responsible for delivering system changes, you no longer achieve it by committing code. The second is that as a technical manager you can still practice engineering, however, you are now engineering a strong delivery team rather than a robust software system.

To understand your team as a machine, I find it helps to take the view from a technical manager’s manager’s perspective. Generally what your manager wants is for a task to be delegated, then for the task to be delivered at an agreed upon time and quality. Therefore, to the manager’s manager, the team may as well be a black box where the input is tasks and the output is a software feature. As a technical manager, a key part of the role is engineering a team that can achieve desired outcomes given the resources and constraints the organisation has put in place.

Keeping track of outcomes, resources, and constraint are all part of engineering practice. Just as when writing code you would want to know what requirements, platform, programming language, and system resource constraints you are working with, in a management context you need to know whether the organisation’s expectations are realistic given the team you have. For example, if the organisation wants the team to build out the online infrastructure for a new service using infrastructure as code and your team is full of front-end developers, it’s your job to request resources with infrastructure provisioning experience, or highlight the risks associated with training your team to achieve the desired goal.

In addition to external stakeholders, internal considerations and requirements should also be met. If you have team members that want to go into management, it would be useful to recognise and mentor them as your second in command. This will let you go on leave without needing to worrying about who will take over and at the same time enable the professional development needs of a team member. Understanding what motivates your team is key to ensuring the longevity of the working relationship, which can be achieved by having effective, regular one-on-ones; a topic that I will save for a future post.

By recognising the systemic purpose of teams within your organisation — and more importantly, continually ensure the team structure is fit-for-purpose — one can avoid misaligned expectations between the organisation and the team. In my experience, misaligned expectations can manifest as organisational dissatisfaction at the team’s performance; often based on an unfair perception. Conversely, the team may feel frustrated that the organisation’s requests are unreasonable, leading to a drop in commitment and morale. Once negative sentiments are set, turning them positive again is not easy, which is why highlighting the signs early and addressing it will save a lot of time in the long run.


Appreciating Group Dynamics

Group dynamics³ is a broad term describing how groups of people work together. A key component that is overlooked is the role of different personalities and their impact on team performance. Winsborough and Chamorro-Premuzic⁴ write:

A useful way to think about teams with the right mix of skills and personalities is to consider the two roles every person plays in a working group: a functional role, based on their formal position and technical skill, and a psychological role, based on the kind of person they are.

Generally, as a technical manager, you should be quite attuned to the functional capabilities of your team members. However, as cited above, understanding the psychological role each team member plays is just as important if you want to achieve a certain team culture. Winsborough and Chamorro-Premuzic⁴ provided the following sample personality categories: results-oriented, relationship-focused, process and rule followers, innovative and disruptive thinkers, or just pragmatic.

At the team level, if your objective is to build a results-oriented team, but most of your team members are process and rule followers, you are most likely in for a tough time. At the individual level, if you assign project management responsibilities to an innovative and disruptive thinker, you may end up with a project whereby change is an unwelcome constant. The examples are contrived, as most people do not fall singularly into one category, but instead have a mix of traits. Therefore, poor personality and role fit can take a while to become obvious, by which time it has manifested as either disinterest on the part of team members or unexpectedly poor performance.

Another aspect of group dynamics is the role of interpersonal relationships. If your team has factions along technical or ideological lines or cliques based on social groups, it can influence how well the group can be expected to work together. When existing relationship structures are combined with a growing organisation that is always hiring, and perhaps some natural churn within the team, it means that understanding where the group is at requires ongoing observation. Generally, this is not a topic that comes up during any formal reviews and may not be discussed openly, but is simply understood by those paying attention.

Sometimes companies attempt to improve group dynamics through team building exercises, but the outcomes may not always be as expected if the activity isn’t something that team members can actually bond over. A more challenging, but effective, approach I have observed is to nurture the natural social circles by allowing them to work together more often, or purposely ensure that day to day workloads require continually mixed teams. Depending on the organisation, either has its pros and cons. As a manager trying to engineer an effective team, it’s up to you to decide whether it’s better to have groups that get along and enjoy hanging out with each other in and outside of the office or to have sterile but professional relationships be the norm.


Conclusion

In this article I have outlined a few pitfalls I found to be hazardous while a new manager is attempting to get their bearings. The common theme among all of them is that without an awareness of such issues, they can have an effect similar to technical debt. That is, left unresolved, issues concerning poor delegation, inadequate resourcing, and inappropriate team makeup can make a technical manager’s job unnecessarily hard. By being vigilant and curious about challenges that arise as part of your management practice, hopefully, you can uncover underlying tensions and address them before they become real problems. The desired outcome is to ensure as much management time as possible is spent helping your team and organisation achieve long-lasting positive change.

References

1: Alan Watkins, 2016, 4D Leadership: Competitive Advantage Through Vertical Leadership Development. https://www.amazon.com/4D-Leadership-Competitive-Advantage-Development-ebook/dp/B018IV01MY

2: Ray Dailo, 2017, Principles: Life and Work. https://www.amazon.com/Principles-Life-Work-Ray-Dalio-ebook/dp/B071CTK28D/

3: Wikipedia, Group Dynamics. https://en.wikipedia.org/wiki/Group_dynamics

4: Winsborough & Chamorro-Premuzic, 2017. Great Teams Are About Personalities, Not Just Skills. https://hbr.org/2017/01/great-teams-are-about-personalities-not-just-skills

5: Histuan Horvath, Person Jumping on Beige Concrete Wall. https://www.pexels.com/photo/person-jumping-on-beige-concrete-wall-2244829/

Better Programming

Advice for programmers.

Paul Chiu

Written by

Paul Chiu

Was, taught, and managed coders. Now coding and writing.

Better Programming

Advice for programmers.