- Written by: Patrick Bollinger
- Created On: 2022-12-04
- Last Update: 2022-12-04
In the beginning, there is a user and a developer.
graph LR;
User --> Developer;
The user can give feedback to the developer on what improvements that user would like to see and the developer can deliver said changes. With this feedback loop, this may lead to eventual growth with multiple users.
graph LR;
A[User] & B[User] & C[User] --> Developer;
The developer may have more than just external users to interact with. They may also have internal stakeholders in the company to consider.
graph LR;
A[User] & B[User] & C[User] --> Developer;
Executive --> Developer;
Department --> Developer;
With all of these sources of input for a developer to handle, they may request a team to handle user feedback. This team is typically referred to as customer support or customer success team.
graph LR;
A[User] & B[User] & C[User] --> D[Customer Success];
D[Customer Success] & Executive & Department --> Developer;
Although this helps alleviate some headaches, how should the developer prioritize between the different source? Perhaps, more developers can be added into the mix where each one handles specific requests from a given stakeholder.
graph LR;
A[User] & B[User] & C[User] --> D[Customer Success];
D[Customer Success] --> E[Developer];
Executive --> F[Developer];
Department --> G[Developer];
This may work for some time but should a request from the CEO have equal weight to customer success? Also, since each developer is working to support their stakeholder, it may be hard for the developers to share knowledge. Worse, what if two stakeholders have conflicting changes they want their respective developer to make? The stakeholders and/or developers can host meetings to resolve conflict but this will delay delivery.
This is where a Product Manager comes into the picture to serve as the producer of a single source of prioritized work for developers. By having a single source of prioritized work, referred to as the Product Backlog in Scrum, developers can work as a single team and scale their work more effectively. The developers reference do not have to be "Software Developers" but any sort of person who is contributing to the development of the product, e.g. UX Designer.
graph LR;
A[User] & B[User] & C[User] --> D[Customer Success];
D[Customer Success] & Executive & Department --> P[Product Manager];
P[Product Manager] --> Backlog
Backlog --> E[Developer] & F[Developer] & G[Developer] & H[Developer] & I[Developer];
Up to this point there is an assumption that everyone is component in agile methodologies and that the team is focused on a specific product. But, what if the team or some of its members are new to agile methodologies? What if the team is working on too many aspects of the product and its hard to coordinate work. This is where Scrum Masters or Agile Coaches can aid with the running of teams and incorporating continuous feedback in daily processes.
Personally, I feel the need for a Scrum Master or Agile Coach is a sign that the organization needs to improve. It could be a gap in knowledge about agile, a lack of team members to support the product, or the product development team's scope is too large for a single team to handle. I feel Scrum Masters should be active in improving the team and advocating such that their role is not needed, to reduce risk of dependency.
graph LR;
A[User] & B[User] & C[User] --> D[Customer Success];
D[Customer Success] & Executive & Department --> P[Product Manager];
P[Product Manager] --> Backlog;
Backlog --> E[Developer] & F[Developer] & G[Developer] & H[Developer] & I[Developer];
P[Product Manager] & E[Developer] & F[Developer] & G[Developer] & H[Developer] & I[Developer] --- S[Scrum Master];
With that, you have a product development team that has grown organically from one developer to a team working together on a product.
graph LR;
P[Product Manager] --> Backlog
Backlog --> E[Developer] & F[Developer] & G[Developer] & H[Developer] & I[Developer];
P[Product Manager] & E[Developer] & F[Developer] & G[Developer] & H[Developer] & I[Developer] --- S[Scrum Master];
But what about multiple products or one product that is quite complex?
graph LR;
Stakeholders --> E[Product Development Team] & F[Product Development Team] & G[Product Development Team];
As more teams are instantiated, each team will have their own focus and technologies they may use. To help with the broader perspective of the company, Technical Project Managers can help ensure that communication is flowing throughout the organization. This role acts like a Scrum Master but across teams rather than a single team.
graph LR;
Stakeholders --> E[Product Development Team] & F[Product Development Team] & G[Product Development Team];
E[Product Development Team] & F[Product Development Team] & G[Product Development Team] --- T[Technical Project Manager];
When it comes to alignment on the technical process of developing a product, a dedicated platform team can help with the operations and setting templates for development work. This eases the burden of maintain compliance for regulatory reasons.
graph LR;
Stakeholders --> E[Product Development Team] & F[Product Development Team] & G[Product Development Team];
E[Product Development Team] & F[Product Development Team] & G[Product Development Team] --- T[Technical Project Manager] & P[Platform Team];
This structure could be repeated but I would advise caution that the organization does not become so layered that it is easy to lose track of the users' requests.
I wrote this article to help myself understand why product development teams are structured the way that they are. I was wondering if team organization structures are more complex than they need to be within my organization.
This article is a simplification of team structures as other functionalities are not represented. Since every organization is different, it can be helpful to repeat the exercise to understand why your specific organization is structured the way it is.
As long as everyone involved keeps the users in mind, everything should work out.