Project Managers are perceived today as must-have teammates for a development team. No one will question why the developers themselves are present in the team 😁
The benefits of QA engineers are less obvious, it may seem to many software developers that their code has no bugs (of course not). However, there are teams without QA engineers. But why does a team need Project Managers? Can the team work without them? Are any courses sufficient to become a professional PM? Let's try to figure this out.
Disclaimer In what follows, we will discuss the role of the PM in AGILE projects. In Waterfall projects, the role of the PM may differ. For the purposes of this text, we will not analyze the waterfall.
When I started my career as a project manager, a friend of mine asked me how the team treated me. Many rookie PMs are treated like a fifth wheel by the team as long as it doesn't slow down the entire car. A lot of developers, especially if they are qualified, may not see the value in this role. How can someone who doesn't know how to code, who is probably younger than me, manage my work and tell me what to do?
What is the value of PM?
What is required from the development team is not the code! The code itself is worth nothing. The software development team is required to solve a specific problem of a specific client. But how does the team know what the problem is and how to find the solution? Is it possible to solve it by oneself or a few people is needed? Is it easy to distribute the tasks (including dull and routine) and not to quarrel when it turns out that the software does not work at all or does not do what the customer wanted? And also, it would be nice to fly to the Maldives with your family on vacation and not answer the client's calls every 10 minutes.
In software development, as well as in everyday life, there is a lot of work that is invisible to the eye. When you come home after work, it turns out that the "second shift" is waiting at home. You need to organize things, cook food, clean up, etc. - so you have to pay for the comfort of the house with time. Moreover, the time in this example has a completely understandable cost - you can hire a cleaning service and order food in a cafe. Often one hour spent on cooking instead of work costs much more than food from a cafe. In work tasks, everything is the same: to solve a problem, you always need to do a lot of "underhood" work (which is often invisible). But if this is not done, time will slip through your fingers:
- endless calls,
- reworking work is already done because the client has not accepted it,
- developers are leaving, so you need to look for new ones,
- the client swears and does not want to pay.
In general, the project is falling apart, so there is no time to write code.
And this is where PM can help to save the team time spent on negotiations. Be a proxy between the team and the customer, collect the requirements and interpret it into tasks that are clear to the team, and do some organizational and administrative work instead of teammates to help resolve conflicts within the team and maintain its health. Let's take a look at his work.
Dream team
So, in Agile projects, the team brings the main profit. A team is not just a set of random people approximately corresponding in terms of qualification to the task being solved. It is a well-coordinated mechanism or, if you like, an ecosystem, an organism. The necessary condition for its performance is the appropriate qualification of the people in it. But the sufficient condition for high performance is self-reproduction. This topic is worthy of a separate text. It is important to note that uniting people, rallying, motivating, supporting, and ultimately making everyone feel responsible for themselves and the entire team is hard work.
First, the velocity of solving any problem with a team is always determined by the velocity of its weakest member. The ability of the team to support, unload, teach, and lend a shoulder to those who are tired (and everyone gets tired, not only the juniors) determines the team's average performance.
What does it take to build such a team? Experience and emotional intelligence. PM is able to feel the atmosphere inside the team, to control the mood, to know about every teammate and how exhausted, anxious or happy each of them is. The PM also needs a capacitance of internal energy, which will inevitably have to be given to the team to create this very atmosphere. This cannot be taught. You can read an endless number of books and articles, but this is a skill that comes only through time, experience, and reflection.
How to write less code
Oddly enough, a project manager can significantly reduce the amount of work in a team: avoid rework at the client's request and overhead on what was not useful (or was not asked to be done). It's about working with the client's expectations and requirements description.
It is necessary to clearly understand what exactly the customers want and what their goals are (sometimes the requirements of individual features do not bring the customer closer to their goals but move in the directly opposite way. However, this is not obvious to the customer), and what the team is able to do without overstrain. The only way to find out is by saying through word of mouth (well, or letters through the text) while discussing the goals and requirements.
So it is important to find the right words for the customer and the team. A shift in focus from the optimal state of team loading both towards the wishes of the customer or towards the team hurts the team's reputation. If the team commits to less work than needed, the customer will be disappointed and will look for other developer teams. The team's reputation will deteriorate. On the other hand, if the team commits to more work than it can do in a normal mode, it will have to work in a state of stress, which will either lead to conflicts and, in the long run (if this continues during the whole project) to the fact that the developers will leave, or to a fuck-up the commitment. If the team does not fulfill its obligations, it will also blow its reputation. Either way, it's a failure in the long run.
But it is only half the battle to define the scope accurately. It is also necessary to describe the requirements correctly. Otherwise, the expectations from the features will not coincide with reality, and the work will have to be redone. First, for an accurate description, it is necessary to understand the customer's goals and the specific tasks. This will help the skill of communication in a broad sense. It also cannot be taught, only endlessly polished by analyzing feedback from all sides.
Time is money
Well, perhaps the most obvious thing that PM can help the team with is to save time. Time spent on communication with the customer, planning and prioritizing, clarifying the requirements of the customer, internal showdowns, and arguing. Time spent on analyzing problems and preparing solutions.
PM will not be able to rid the team of communications with the client completely (there will be implementation questions, technical disputes, and clarification of unclear points), but it will be able to reduce unproductive time spent somewhere by reducing the call duration and the number of participants. PM can also switch the attention of an overly active customer from the teammates to himself.
Perhaps, one of the most important parts of a PM's job is communication in the broadest meaning of this term. In the context of benefit for the team, it is necessary to communicate excellently with the customer and developers, to find a common language, to explain clearly, to understand the goals, intentions, and motivation of people, and to understand and take into consideration the personal problems of teammates. Otherwise, the result will be the opposite.
PM can reduce sluggishness by intelligent orchestrating tasks and processes internally, using Lean production in a team, and expanding bottlenecks. Optimal processes within the project help to less trip over each other and to recognize and to solve problems faster. Thus, the team gives high performance with less strain. All the processes need to be thought out, built, and debugged - this is also the job.
Why courses cannot replace real experience
Everything mentioned above can increase and decrease the productivity of a team. Imagine a situation (I must say, quite common) when a newly minted PM with no practice comes to the software development team just after finishing a course. The team is recruited from people who may not have previously worked together. PM begins to build processes according to the theory, but the team resists. The PM does not have enough authority (the team feels that there is no experience) and arguments; he cannot foresee the consequences of certain decisions.
Without experience, a newly minted PM will roll out theoretical knowledge to the team, having absolutely no idea what the result should be in the end. It will be extremely difficult for him to find arguments, convince his colleagues and come to some kind of common solution due to the lack of understanding of the essence of the problems. Bad things will happen to people. Deadlines will burn, and customers will yell.
Mad Devs' know-how in terms of gaining valuable experience for PMs is internal projects aimed at clearing up the "organizational debt" of the company. Mad Devs has been actively rebuilding internal processes for the last year. We launched an internal LMS system, and various communities began to appear, the purpose of which was to ensure the continuous development of employees.
Mad Devs' company know-how in terms of gaining valuable experience for PMs is internal projects aimed at clearing up the "organizational debt" of the company. Mad Devs has been actively rebuilding internal processes for the last year. It launched an internal LMS system, various communities appeared with the purpose of ensuring the continuous growth of employees.
Mad Devs has an in-house CTO team that ensures the high technical level of projects. Actually, these are separate non-commercial projects with their own Jira, tasks, OKRs, and deadlines. In any internal project, the "senior comrades" are always involved and able to prompt and direct. If an aspiring PM lacks experience, Mad Devs' internal projects are a great way to get started, both bringing value to the company and reducing the risk of failure on a commercial project.
So to confirm
We do not say that courses are evil. They provide insight into the role of a PM, introduce tools, basic processes, and more. But it would be strange to expect that a course will somehow replace the experience, which is still the key to the work of the PM.
So, PM in the team takes the role of the nervous system inside the body. It provides smooth movements by engaging various muscle groups in the right sequence, signals fatigue and illness, looks for the best ways to solve a problem, and much more. PM provides calls to take exactly as much time as necessary, tasks to be clear, and deadlines to be realistic. A good indicator is if the customer gives only positive feedback (and does not say that everything is lost). A PM is just as much a member of the team as a designer or QA, who performs his or her tasks to achieve a common goal - to make the client happy.
For those who are just looking at the work of PM, the ideal is always unattainable. You should not chop off your shoulder, being in a team (it somehow worked before you came). It is worth understanding and feeling how the team lives, what the team's pain points are, and engaging in their systemic treatment. Gradually, the team will feel the benefit and accept you first among equals.
