One Large Team With Pods Or 6-8 Person Teams?
Hello, I am current responsible for making decisions about two team’s organizational structure. We currently have two scrum teams that are focused on different but very similar problem spaces. It actually used to be one big 20 person team with “squads” for each project; basically smaller pods that are created when a project starts and closed when a project ends. About a year ago, they decided to switch to the model we have now: two medium sized teams focused on similar but different problem spaces, that are fairly static and the PMs work together to assign projects to the teams based on their strengths and focus areas.
However, most of the leadership is rather unhappy with this structure. They want to go back to the “single big team” model where pods are created and destroyed as needed. Their claim is that because the two teams are so rigid, they don’t have the flexibility to staff projects the way they need, and they can’t move as fast as they would like. Basically, every quarter they want to have a single list of priorities for a team of 20 engineers, and then break them up into groups depending on the size of the projects. And then rinse and repeat as projects finish. Always changing, always responding to the needs of the project.
I’ve kind of been the lone voice of opposition. My concern is that this structure will lead to some problems. I.E. if people are constantly changing what pod they are on, they won’t be able to establish strong working relationships. It takes a lot of time for a team to go through the forming, storming, norming stages, and the constant tearing down of teams will mean we are always forming and storming.
I also don’t agree that it will make us able to move faster on our projects. We have a lot of what we call “emergent work”. Between the two teams we own about 10 different services that are critical pieces of our backend infrastructure. We are constantly fielding on call pages and requests from external teams that take up a lot of our time, while also trying to build new features for our product. Even if we tried to have pods focused on specific projects, they would frequently be interrupted by the emergent work because we’ve agreed to all share that burden. In my opinion, that would make emergent work even more disruptive to smaller pods than they are now to medium sized teams, who aren’t hurt as much by one or two team members taking on an emergent task while the rest of the team moves forward with the new feature project.
I am curious to learn from others what their experience has been, and which organizational structure might be best given our situation. Thank you so much for your help 🙏
Where is the team's involvement in the decision? Why are you responsible for making decisions about the organizational structure? I suspect you'd achieve better results if you involved the team in working through alternative structures and deciding which one makes the most sense for all stakeholders, which would not only include leadership and the members of the team, but the customers of the products created or services offered by the team.
That said, I'd suggest looking at a few things:
- Organizational Topologies can give you a framework for thinking about how teams collaborate, both within the team and within other teams.
- Unfix offers patterns and models for organizational design.
- If you are interested in Scrum (as it's defined in the Scrum Guide), you can also look toward LeSS and Nexus for scaling Scrum. LeSS and Nexus offer lightweight structures that are consistent with the Scrum Guide, which can be helpful if the teams have experience practicing Scrum.
- FAST Agile could give some interesting ideas. Although it's built on some ideas that I would consider extreme agility, you can use these concepts to fill in some gaps around Scrum. Especially if you can get your "projects" down to something that can fit into a Sprint, you may be able to make steps toward FAST Agile with the Sprint cadence.
I don't think that anyone would be able to outright suggest organizational structures for you and your team, since those structures are highly context sensitive and depend on the culture of the team and organization along with the work being done. But these tools should give you what you need to understand some options and design structures that work for the teams.
@Thomas provided an excellent answer and I don't think I can provide anything extra. However, I do want to support his question about the participation of the individual contributors that are doing this work. Especially if you have people there that have been part of both of the organization solutions used. Since they are doing the work, they can tell you the real issues instead of you or other managers having to try decide what could be an issue.
Give them a chance to be part of this solution. It will give them ownership over how they work. But don't stop there. Let them have a say in how they work going forward. For example, each time a "new project" is spun up, let them decide who should be on the team so that they can get people that can work well with each other and have the skills necessary to get the work done. Let them decide who/when someone will get involved in the "emergent work" so that it is less of a burden on the rest of the individual contributors.
Managers can still be involved by making sure that the individual contributors have the information that they need to make these decisions. Empowering the people closest to the work to make decisions will increase the quality of the work as they will feel ownership and take more pride in what they do.
It sounds like perhaps both you and the organization are missing a trick here. You're missing the opportunity to encourage and cultivate self-managing teams, preferably to the point that they even get to decide their own membership. If you could facilitate and harness that capability, it would establish a very powerful foundational mindset.
Consider creating a bounded environment for teams to self-organize within, something like a facilitated workshop, with clear rules about the skill sets needed within each team to create a Done increment, and the goal of having no more than about ten people in each team. As they self-organize, you can shine a light on certain imbalances which are emerging -- too little testing capability in one team for example -- taking care to reveal rather than to resolve.
When this behavior becomes institutionalized, you may have a Scrum Studio, a protected part of the organization with clear terms of engagement. The Studio, as a collective of Scrum Teams, would decide how best to respond to business demand, including the teams which are made available and what their membership would be. See Software in 30 Days by Schwaber and Sutherland.
Why are you responsible for making decisions about the organizational structure? I suspect you'd achieve better results if you involved the team in working through alternative structures and deciding which one makes the most sense for all stakeholders
That is exactly what I've been doing: Meeting with individual members of the team, and getting their opinions on what is the best structure for us to use. There is a lot of disagreement about what is best though, and at the end of the day someone needs to be responsible for making the final decision, and in our org, organizational structures is the responsibility of EMs. I am doing my best to take in everyone's opinions as well as my experience and research, and make the best decision I can.
The senior leadership in Product is trying to dictate the path forward, however. I am finding myself in a situation of either trying to have to justify a different path and why it would be better, or going with their preference and hope for the best. My approach has been to do as much information gathering as I can: asking team members for their preferences, books and articles, my own 15 years of experience and the lessons I've learned, and places like this forum that might be able to provide some insight into different structures and their pros and cons.
There's a big difference between meeting with individuals and getting their opinions and enabling the individuals to make the decisions on their own.
From my own experience, people often lack the language to talk about team or organizational structures. This is where Team Topologies, Organizational Topologies, and Unfix come in. You can give the team patterns of existing structures to frame conversations. And going back to what Daniel says, this demonstrates management ensuring that everyone has the knowledge they need to not only have an opinion, but to make a well-informed decision. Whether you apply consensus, majority, or plurality, allowing for group decision making with a well-informed population will likely yield better results than an individual making the decision.
I'd go back to my original suggestion. Take Team Topologies, Organizational Topologies, and Unfix back to the team and start having group discussions on the best course of action and reach a decision, as a group, as to how to organize around the problems.
Ok, thank you so much for your suggestions, it's definitely something I'll keep in mind!
I am not insisting that my opinion is right, but please remember that you can always cease doing Scrum snd keep your job, by suggesting some other methodology, framework or policy.
Scrum cant be mandatory thing, and if people who foot the bill arent willing to accept its proper implementation in their organisation, may be its a good idea to suggest just returning to traditional management methods, and use your services as traditional product manager, instead of torturing themselves and others by forcing things they dont want themselves?