Roles on a Team

It is critical to have clearly define roles for a product and engineering organization as it scales from Founders to multiple teams. This isn’t a “process” to implement, but just be explicit about who is responsible for what. You can still assist and take over ownership of the other roles if required, but the objective is to have clear ownership. On a SWE engineering team the roles are:

  • Technical Individual Contributor
  • People Manager
  • Project Manager
  • Product Manager

Let’s provide some definitions to crystallize it.

  • Technical Individual Contributor - The team member doing the implementation.
  • People Manager - The team member making sure people are being managed, coached, provided feedback, etc.
  • Project Manager - Keeping track of the project, dates, deliverables and ongoing work streams.
  • Product Manager - Providing business requirements and translating customer problem into specific features.

Day 1 of a company - the founder is doing all roles.

Diagram

After you hire your first engineer, you probably are doing all roles and they just do the Individual Contributor (IC) role. At Convictional, the founding group of engineers (included myself) would do the product manager role too. We would understand what problems the customers had, suggest ways to solve them, then build them. The founder acted as sounding board and kept all engineers aligned from a product perspective. Project management is often covered 1-1 with the founder since the team mostly works individually on features.

Diagram

At a certain point, you’ll hire too many engineers and you will have to give up something. In my experience, it tends to be the IC work. It’s not true for everyone and there is no rule saying you can’t return. In my opinion, it makes more sense to focus on inputs like where the product goes (product manager), shaping priorities (product manager), managing projects (product manager), managing your team (people manager), and focusing on system architecture (ic). The founder set off with the goal to solve a problem they know about and care about deeply. It’s hard to hand that work off to someone else compared to implementation.

There are scenarios where you can hand off the people management and keep the individual contributor work. There are founders and engineers who should not be people managers. Project management could also be handed off to a people manager to run. Product management tends to stay with or fairly close to the founder. Even if the founder hires a dedicated product manager, they need to constantly stay aligned and off load information to them. There isn’t really a way to stop doing product management where the product is what’s being sold.

Diagram

Obviously, as the team tends to grow the roles continue to divide. From when you introduce people managers, the role of project manager tends to live with Product, or People. It’s critical to choose and be very clear. The worst scenario is not choosing and it just gets dropped.

In my opinion, it should live with the people manager. They tend to have a technical background, they are focus on developing people, creating incentives, aligning the team towards a singular mission, and aligning that team mission with the company mission. Most companies leave project management in the hands of the people manager.

Diagram

These are not hard rules, but just guidelines. Engineering Managers can do IC work (my suggestion pick from the bottom of the priority pile). Founders can keep doing whatever they want. People Manager can be spread across multiple teams. It’s all about being explicit about who owns what.

When I’ve seen Product Managers do the role of the Project Manager it’s because of low trust or the People Manager is spread too thin. The people manager is on too many teams with too many reports and simply can’t keep up with the day to day. We create systems (agile, Shape Up, etc.), but still spreading a people manager too thin leads to them doing both roles poorly.

That’s it - it’s not rocket science, but somehow founders and early employees just ignore why big companies have official titles. Even in a small company, a team member needs to own these responsibilities. Otherwise, you run the risk of them happening poorly and the team suffering.