Share this article

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Pitfalls When Transitioning from an Individual Contributor to a Technical Manager

Pitfalls when evolving from contributor to manager

This post lists the key insights from this article.

The transition from an individual contributor to manager is not always straightforward, it’s an experience that can be fraught with uncertainty. 

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’.

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¹)

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. 

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.

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. 

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.

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.

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. 

Another aspect of group dynamics is the role of interpersonal relationships. 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. 

4 min​ read

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Need visibility in your software development lifecycle?