How to grow from a team leader to a project manager in IT?
I’d like to emphasize in the beginning that there is an enormous amount of material on this subject, and it is definitely not possible to fit it in a single article. Moreover, I think it is almost hopeless to try to fit it in several articles. Literally every point which will be discussed further entails numerous training sessions, a huge number of books, Internet articles, discussions with mentors and a lot of your personal practice in self-development. And then all of it must be repeated once more.
If after reading this entry you feel that you somehow still need to grow from a TL to a Project Manager and you are willing to invest time and effort in your development, then I welcome you to read more. If you are not willing to invest in yourself and learn, practice, study, and practice again, then there is no sense in reading this. Do not waste your time.
To avoid some confusion, it is worth mentioning that in this article I only describe the option of “TL-> PM”. The option of “Engineer-> TL” is not considered here to reduce the volume of the article.
So, how exactly does a TL become a PM in everyday life? The main options are as follows:
- There is no one else available. The team has grown and someone has to be appointed as a PM, and there are no other candidates.
- The only one who has the knowledge (knowledge holder). He/she knows almost everything about the technical side of the project.
- Several TLs, one position. Only one is selected.
- “Motivating” a TL with a new position name. The name of your job position has been changed, but you do the same job as before. Motivation is a very controversial term in this case, that’s why I use quotes.
- A new PM vacancy (a new or a pilot project, where a PM is needed).
- TL is already working as a PM performing the functions that a PM must perform, i.e. is ready to become a PM.
After ending up as a PM, our Lead is exactly the same person as he/she was before, which is a Lead (except for paragraph 6 of the list above). All the misconceptions about the role and the functions of a PM which a PM really has to perform have remained unchanged inside our Lead’s head. So what are these misconceptions?
- I am an excellent TL, I am helping my team, I’m writing code about 50% of my time (if it is a development team) or testing (if it is a group of testers), or managing specifications and requirements (if it is a group of analysts). So as a PM I will have to perform more or less the same, only better, more proficient, and faster. It's like a next level in the skills that I already have.
- Since I do my job perfectly, the others must also do their jobs at least “perfectly well”.
- I have to understand everything that my subordinates are able to perform, so that I am able to perform the work for any of them just “in case”. And I should understand it at a level exceeding the one of my subordinates.
- I'm the best TL, now I will just need to fill in a couple of new reports in addition to my regular duties – that’s easy!
- PMs have a big salary and they work less - I want the same!
- A PM only has to write reports, attend meetings and talk on the phone with the customer. That’s easy – I will handle it!
Be honest (no one will know except you) – do you have at least one of these six misconceptions?
We often have no idea how much you have to learn to become a PM! Often it is simply because no one told us about it, and we only had the misconceptions described above. And we are not able to discover this “brave new world” on our own, because, well, it is so very different. And now it will become a little more clear why it is so.
Usually, in the minds of most IT employees this ladder looks like this:
In fact it is quite different, or rather it is more correct to say that it is a different career ladder:
And if these ladders are different, then the skill sets required for these ladders are different too! I would say that they aren’t just different, they are completely different. In fact, it's a totally different profession. Have you ever changed professions at least once in your life? Well, the transition between these ladders is more or less the same. You can try to figure out how long it usually takes to learn a new profession at least at an “average” level. Looking ahead, I will say – a few years at least.
Moreover, the knowledge that helped you on ladder ¹1, will sometimes hinder you on ladder ¹2. You run the risk of falling into the timeframe evaluation trap – “as a
The second common mistake is the desire to code. Yes, yes, to code (or test, or work with requirements). A Project Manager should never do this! It turns out that if you change your position to PM and stop coding, your skills as a developer (tester, analyst) start deteriorating. After six months of working as a PM (ladder ¹2), your skills from ladder ¹1 will deteriorate, but not critically. One more year – and the deterioration will become critical, and going back will become very difficult. Possible, but really difficult. And the comeback will require anywhere from six months to a year of “reverse adjustment”. Why might one want to return? We will discuss this later.
Do not forget about the six common misconceptions. If you had them, they did not disappear. And now they are seriously hindering you as a PM. Get rid of them as quickly as possible!
In part two of our article we will look at some of the pitfalls and challenges when you are a PM who grew out of a TL.