An outlook, from personal experience, on transitioning from Software Developer to Project Manager
You got that job you wanted: you are a software developer. Just got out of university, with big plans, moved or living in a big city with high prospects in the IT Industry. The world is yours and you. are. trending! There is a lot of hype around you and you know you are in the right place. Passion and coffee gets you up every morning as you devour this new field. Soon some years pass, you learn the methodologies, the process, the way of working. You share your project leaders' opinions, learn from them, but soon develop your own. Some things they get right, other you can do better. More years pass, you start to develop new abilities that are now not so technology-oriented, but more people-oriented. You start to care about your team's health and your effort to do better is noticed by the company you work for. Soon, you find yourself in a formal or informal leader position and somehow have the satisfaction that you can help others. Maybe more years pass and after 10+ years of software development, you start thinking about the possibility to change directions: you think of management. This change is possible only with the support of your company, but if you're lucky the hard part just begins. Next comes a series of trainings from a high-level perspective that show you what should be done. The e-mail signature changes to Project Manager, and you are given the possibility to choose, from a list of available projects, something that feels close to what you are familiar with.
Is this you? Do you find yourself in this position? Do you see yourself there at some point? My case was somewhat as described above and I will continue to present this topic from my perspective.
Like in your personal life, the first project you manage leave marks of a good or bad experience behind. So, what did I choose? Everybody knows I get easily bored, so when a project was presented to me as a challenge, I knew this can be it. Not blindly, but even from the analysis phase I got hints that it had issues at several levels: delivery, processes, budget distribution and it seems that everybody had a problem with it being an internal project. Why is that? I don't know, maybe because it has a legacy code a few years old, or because the stakeholders' management comprises 17 persons, all colleagues. I joined the team, which I found to be very interested in their work and I started... managing.
Along with this, which had a certain type of challenge, I took another one, a new project with a new client of the company. If for the first there was no relation to build, just to repair, with the second one there was a whole different story of building trust, building a team and learning a specific niche.
Like in driving: you can be a great driver, with years of driving experience, and if by luck you have a clean start, without any incidents, you are set for a smooth path to mastery. If the same individual has, let's say, an accident right at the start of his driving career, everything is affected: confidence, enthusiasm, and the above mentioned path has some twists and turns.
I don't know why everybody runs away from internal projects. Ok, there are some downsides: no on-site delegations, no bonuses, instead constant direct contact with the "client" that mostly consists of colleagues which you see every day. You can also easily taste the bitter feeling of a failed deploy. My approach on the one I managed was completely the same as with an external client, same ceremonies and attention to details and to the client
s needs (no compromises) and this changed the entire perception of the team and project. I will mention here that I was lucky to have an involved team and an interested Product Owner. It's not yet finished, but I think we are on the good track. To tell you the truth: if at the beginning I got pissed on colleagues complaining about the software, after a while this was an important motivator for me: if I can change this perception, I will be already one step ahead.
The first thing I found odd was that people congratulated me on the promotion, even on LinkedIn :) No! It's not a promotion. I was "promoted" from a job in which I knew exactly what was expected of me, where I had a general overview of what was happening and everything depended mostly on myself. A job in which I had grown and had an experience of many years, to a job which had a totally different perspective: you measure your progress based on the team's effort.
So how does this work? Being a developer, the conditions to "do good" were clear: write compilable, clean code; the review must be successful, the tests must be green, and all this respecting the general design of the application. Not necessarily simple, but clear. I could see a general progress and know if it goes in the right direction. On the other side, as a manager you work with people, and a wide variety of them. More than that, the result is not immediately visible, sometimes it will take a long time to see the outcome for your actions and it's not always the desired one. Each person gets motivated by different things and trust must be gained within the team as well.
One of my main frustrations when I began working as a Project Manager was that, if after a whole day I wanted to summarize what I've done (same approach as from a development point of view), there was nothing actually "done done". My job consists in a lot of meetings, discussions, statistics, reports, and basically ensuring that everything works as expected; but this can differ on each project... in other words I did not feel all that productive.
There is a switch of mindset to what your responsibilities are and there is no perfect model to follow, you may go outside the box as much as possible as long as you address the situation correctly. This can be an advantage, if you are creative, or can create complications, based on the personality of everyone involved in the project. A project win is the team's win, a project failure is the project manager's failure.
Another thing which is worth to be mentioned is that you can no longer be their friend. As a social person, this is sad, but soon you will get excluded from their joke group, their coffee breaks, and their smoke talks. But that shouldn't be a bad thing. You are there, but they will try to shield you out and it depends on you to break that barrier. Developing relations is a needed aspect of management and you need to understand this distance and how to handle it in order to have a proper interaction with the team.
What I found is that satisfaction comes in more forms and shapes. As a developer it was constant, visible, but relatively small, while managing a team can be very rewarding (even if not on the short term): seeing that your contribution to a person's needs helped him reach his potential, that the client begins to trust your team based on the interaction, that with the help of your team you manage to meet a critical deadline, or that the delivered release package does not get rejected.
Everything I said until now was based on perception. It's a shift of mindset on how to appreciate a day's work and what I wanted to emphasize was that it's a big change. Actually, there is a lot of work to be done, lots and lots of responsibility, and there is a mastery path with a slow learning curve.
There are a lot of processes involved in doing our work, starting from the process of forming a team, bidding for a project, reviewing requests, budget estimation, creating a delivery plan, following that plan, removing all impediments to (maybe the most difficult) building a trusty relation with a client. Just referring to the budget, I found a whole different perspective from this side. The overview and forecast of costs is quite a difficult job; I'm not talking on planning them, but on respecting an assumed plan.
Project Management is not to be taken lightly, there are rules and best practices. Just like in the development field, there is a more "technical" part and there are entities that regulate this. The Project Management Institute (PMI) is one of the most appreciated organization and becoming a PMI Professional is a bit harder than getting a technical certification: there is a consistent prerequisites list (proven experience of several years in doing project management, gathering PDU credits, attending courses and presentations) and only after that you are eligible for the certification.
Not to underestimate the responsibility part, the Project Manager is fully accountable of a project's success, taking into consideration all aspects: client, team and of course profitability. Saying this, I would conclude that it's not one of the easiest job out there and it's not suitable for everybody, but you can find motivation and a lot of challenges.
From my experience, the best managers are the ones that work along with the team and not the ones that demand and control. The team does most of the hard work and their motivation doesn't always consist in salary compensations, but in a balanced work environment.
There is a lot of discussion on the subject. This all comes down to what the PM's job is? Even if I already described it above, I will state that a PM's role is 80% about maintaining good relationships, clear communication, and people management. So, is it mandatory? PMs don't need to be "techie", but if they listen to their teams and learn their day to day they have a great advantage. If the PM also has a technical know-how of the technologies used in his project he can go the extra mile to be of great value, not only to the team, but to the customer.
What I want to emphasize here is that this transition is not mandatory. It's not the "normal" path to becoming a project manager: nowhere does it say that you have to become a senior software developer first. But does it help? My opinion: absolutely yes! Even if you will not be involved in the technical part (and for me just sitting aside letting the tech guys do the tech job can be a hard thing to do), having the technical perspective in mind first of all, you can spot several risks or understand the team on their development cycle.
Another good angle you can have on the project by having technical background is to understand estimations and why the team behaves in a certain way.
Careful: using too much of your technical knowledge can be a trap too; just keep your current role in mind.
So, is it worth it? I don't think that's generally valid, my guess is that this depends on each individual.
What I can say is that I am very happy with this change, with all its goods and bads, all the new situations, difficulties and challenges. I can tell you that this is definitely a situation without the coziness of a comfort zone, but that this is exactly the reason why I love it. Looking back, this change was a challenge for me and I am happy that I had the chance and took it.
by Dan Dragu
by Mihai Varga , Raul Deac
