Do you really need a PM in your team?

Example 1. Self manage team of Senior devs

My journey from the initial steps in development to the day I decided to start a business never included any managers. There was always someone who provided what he wanted, but rest was on my or team side: analyzed, set up tasks, provided estimations, do development, explained if I was not meeting a deadline and, of course, made demos. I've heard about this "world with rose-colored unicorns" where, as a developer, you only do development, but that was not my experience.

After I grow up in my professional skills, I received an offer from a very large tech company in Ukraine with a very senior team (4 people of mobile development + 2 qa + pm + designer, maybe some other roles). I thought, "This is where I will receive perfect tasks, and my work will be to turn ideas into real value." However, in reality, the PM existed only on paper. She was too busy to explain the scope and set priorities. I saw her every two weeks on a retrospective call and sometimes on demos.

But here, I want to emphasize that the product was successful, work was completed according to deadlines, the quality was good, and customers were happy.

This is how the team made it work:

Select a responsible person for the week.

Responsible person should take tasks that came from customers, check does everything clear, ask question if needed

Make a call with rest of the team and explain the scope (description in google doc)

Make tasks and estimations with the team

So, the PM role shifted from one person to another. At first, I thought that preparing the four steps mentioned would take a lot of time, but in practice, everything was quick. I don't remember the exact estimations, but it was less than 8 hours.

I believe the benefits of such an approach are that everyone knows the project inside out. By preparing, you understand the tasks very well, which allows you to complete them quickly. On the downside, in my experience, a senior developer costs much more than a senior PM. Also, the project team should not exceed five people, and the project's complexity should be small to medium (when new members can understand the project 2-4 weeks, in other case approach is not scalable)

Example 2. Scram master instead of Project Manager

Input parameters: 1 mobile developer, 1 web developer, 2 backend developers, 1 QA engineer, 1 Scrum Master, 1 designer, 1 business analyst (BA), all of them at a middle level with 2-4 years of experience. This story is also part of my personal development experience, where my role was in mobile development.

In my understanding, a Scrum Master is kind of a "coach" who guides a self-organized team. I've heard about good examples, and my current PM calls himself a PM/Scrum Master, stating that it's the best approach ever created. But, let's talk about that later. This story is about a bad experience.

I think the significant advantage we had was the BA role; she did her work very well, providing us with a quite clear understanding of the project before we started. The issue, I believe, started from the beginning, but we fully understood it when a lot of time passed. No one determined the priority, and the backend team went in one direction while the frontend went in another. Even with planning together, everyone was interested in their own side, and no one knew what we were expected to show at the demo, or even if we were to have a demo. The Scrum Master made calls according to the Scrum process, but that wasn’t enough. We need someone who will lead the team with business goals. We didn’t fail the project but delivered it with a significant delay. I think the main issues were:

Team was not informed with deadline and milestones ("we agile, do the best you can")

The team provides estimation in story points. When the project is short (finally we got info that it was 2-month pre estimations) story points are not synchronized inside the team. 2 for the backend are not the same as 2 for frontend

There was no responsible person for priority

Team members work in different stacks, standard team scrum calls were not enough. I think it could be solved through the responsibility of each team member, but without the info above, we saw too late that we delayed with business expectations

Perhaps due to the lack of experience of the Scrum Master, or maybe because the project duration was too short to demonstrate all benefits. However, what I've learned from this case is that not everything that works for others will work for you. Adapt your approach, and have a responsible person, not just a facilitator

Example 3. Team Lead

Once, I had a one-on-one call with one of my employees, and he said, "PMs are useless. I can do their work better and quicker by myself." I was surprised and conducted my investigation to understand why he reached such a self-confident conclusion. It turned out he had a good, proactive team lead. The workflow was somewhat similar to the first example:

The lead received the scope from the customer and, being technically senior, divided it into pieces.

Each team member received their own piece and needed to create a task for themselves, along with a description of how they would implement it from the business perspective. This included what the edge cases are, validations, architectural peculiarities, and how the current changes affect existing functionality.

After the analysis was done, the team member presented it to the team lead and got approved to proceed

In this case team lead manage the priorities, checking reports, communicate with customer. So sometime PM its not a position its a role, and one person in the team could have few roles

In my experience, projects with a team or technical lead work best because there is a single point of contact for the business to interact with the developers. On the other side developers know who is leading them, which is helpful when questions arise. He not only provides technical guidance but also mentors the team members

I've decided to split the article into two parts to make it easier to read. No general conclusion for now.

I hope that my cases will help you make your team composition more cost-efficient and productive