The Heresy of Mixing Together Large and Dynamic Teams
Co-authored with Kadri Pirn
Introduction
When companies talk about Agile, it’s quite common that regardless of the framework they use, they will have very similar ideas towards teams and having the team be the cornerstone of the development process. In this context, “team” means: a team that two pizzas could feed or a team of 7 +/- 2, which is long-lasting and cross-functional. Having bigger teams or a short span of time to work together is usually not accepted as it goes against two well established ideas in the Agile world — which promote strong ownership, communication, mastery and productivity.
We wanted to challenge those two ideas and experiment with other approaches which would increase flexibility and enhance knowledge sharing while still keeping a high degree of the benefits of small and stable teams. What if we had bigger stable teams (15 to 40) and, smaller and short term teams (0.5–3 months, 2–6 persons) formed dynamically out of them? This is what we have been experimenting with.
How we work inside Pipedrive
In Pipedrive we’ve organized our product teams into different sized tribes with a minimum of 15 and maximum of 40 people. Each tribe has their own areas of responsibility and are accountable for the customer satisfaction for those areas — roadmap, service quality, and technical debt. Each tribe is cross-functional, including all the needed roles: product managers, designers, data analysts… and of course engineers.
Tribes are organized in launchpads (4–8 people) and missions (2–6 people). The launchpads take care of support, maintenance, quality debt, bug fixes and small enhancements. Missions are about getting something new out to the customer as quickly as possible by focusing completely and specifically on that mission objective. Both have a lead (Launchpad lead or Mission lead) which are roles that rotate based on volunteering. People rotate from missions to launchpad and vice versa; thus, launchpad and mission teams are very dynamic and often changing. Read more about that in our article on Pipedrive Agile Framework.
Freedom to choose
One of the biggest advantages for our engineers is the freedom to choose what and whom they are working with. Whenever new missions are pitched in our company wide event “Pitching Tuesday”, engineers can apply to the mission, keeping in mind that the Launchpad shouldn’t suffer from a lack of resources.
The choice can be based on personal preference based on the technical stack, other people on that mission, or the particular problem that mission is tackling. That gives ultimate motivation, commitment and accountability towards doing your best in a mission as it has been a personal decision. People become very “locked in the zone” until the mission is completed.
New connections and broader network
Due to a freedom of choice, it has become more and more common that missions end up having people from other tribes. This allows people to find new connections across the company while working together. This also translates into less cultural silos, easier communication along cross-engineering, and simply having more human connections in the organization. People get to know each other in the best way possible, if they have to tackle challenges together during the mission. To quote one of our engineers:
And with those people comes another view, other ideas or just pleasantly spent time. The ability to escape the routine without escaping not a company but even a team. You could always pick a person in a tribe who could lead a new thing, no need for 3 persons to do that separately.
The more connected people are, the more engaged they will be, and the smaller the employer churn will be.
Silos, company alignment and cross-pollination of ideas and practices
Tribes are very different from each other in nature and have a lot of freedom to choose their way of working. One of the outcomes of having cross-tribe missions is that ideas and practices move around. When people come back to their respective tribes, they usually share how things worked in other tribes (from technical solutions/tricks to processes), what things they were impressed with, what worked well, and what would be worth trying in their home tribe. This of course, works the other way around as well, engineers bring ideas and practices to the host tribes which creates conversations about how to improve and puts ideas on the table that otherwise would have been difficult to get in a closer context.
Getting to know other tribes and the people in them, other tribe specifics, problems, and other perspectives reduces silo thinking and increases company alignment. When engineers work for a few months on another tribe’s mission, they truly see themselves as part of the same company, going beyond their own tribe, and they see common problems that need to be solved company wide in a collaborative manner.
Experimenting and Learning
When people work in different teams and change the peers with whom they work with, they can constantly grow and learn. They can switch between different technologies or slightly different implementations. People with different seniority levels can provided help in understanding different methods of troubleshooting and different styles of leadership offers knowledge in a way that suits people the best.
Even the most senior engineers are constantly learning — getting into a new service or technology stack where there are other experts involved, gives them back the feeling of “I am not the smartest person in the room”.
After each mission and time in Launchpad, people are invited to give each other direct feedback and engineers get it from different types of people thanks to the dynamic and changing teams.
Dynamic team structure and Pipedrive Agile Framework give the opportunity to experiment and learn new roles, and safely grow in them by developing the skills and knowledge needed. More than 50% of our engineers have tried out one of the lead roles, making the understanding, empathy and growth in leadership really diverse. A comment from one of them:
Dynamic team structure benefits for me: working with different people gives more opportunities to learn from others. Every person you work with you will learn something new from (from technical POV) gives a chance to try out being a team lead without having to be promoted to full time team lead… this way you can see if you like it or not, and able to switch between being a normal developer + lead is also nice
More dynamic organization with feasibility to quickly change investments
When COVID-19 hit us during the spring, suddenly and harsh, we had to close our offices and start working remotely, we also understood that this hit everybody across the world, including our customers. After a week we had a clear plan of what we should change quickly in our product, so that we could support the new era.
Within 2 weeks we had missions started and we were able to re-prioritize a lot of initiatives and create or modify missions accordingly. This means many missions were postponed while others covering our new prioritization were created with engineers, PMs and designers jumping into these new mission without needing preparation. Due to the urgent need to prioritize (because of the crisis), cross-site and cross-tribe was enhanced even more than it naturally would have.
This was an easy and natural step for us to do and it didn’t break processes or teams — everything went smooth and we were able to start delivering needed features immediately.
This is one of the biggest benefits of our framework — if a company needs to put more effort into some initiatives, we can do it by starting missions in that area. We don’t have to break the teams, we don’t need to agree with a bunch of team leads, negotiate with people and make breaking changes — the company can just pitch missions, pausing other pitches, and dynamically increasing investments where needed. People don’t have to make a long term commitment to change the team, they can decide to help out the company where it’s most needed.
With a slight extra effort on mission kick-offs, the teams can start working together pretty much immediately. We have implemented kick-off templates where people get to know each other, cover the mission goal and agree on the high level technical architecture. We’ve seen that this can make the team dynamics exceptional from the first day of the mission.
Downsides and ideas for improvement
Predictability over flexibility
The first estimation for the landing date (a very high level estimate) is set before the team has been established. Later it is refined by an engineer when it is being prepared in more detail. Finally, when the mission starts, the re-estimation is done together with the mission team who might not have worked together before and (moreover) some people in the team may not have worked with the problem area the mission is solving. This causes mission re-planning during the process and ends up extending the mission sometimes by more than 50% of the initial plan. However, there is a very high correlation between the extension and the mission duration, the longer the missions are, the more they are extended (and for a longer period of time). Moreover, as tribes are different, those that tend to have longer missions are the ones that extend the missions more and for a longer period of time.
We have consciously accepted to sacrifice predictability over flexibility although we continue to explore and experiment with ways to improve in this area.
Reduction to performance
Every mission that receives new people in their mission team experiences slow performance at the beginning of the mission. New members need to learn the feature, the tech stack, and then they can start being efficient.
We do encourage people to change the team with every mission, but most of the time, the majority of the group have already had experience in this area.
Extra effort putting mission teams together
In static teams, the set up is settled for a long time period, and even if there are issues, the change of the team structure isn’t as complicated from a process perspective. Having dynamic teams makes Product Managers to “hire” the team constantly, to each mission. This is extra effort to sell your idea to the engineers and convince them to join the mission.
Even though it’s more time consuming, we believe this time is an investment that pays off by ensuring going through wider aspects on the deliverables and the customer needs, making the sales pitch for objectives and business needs clear to the team and the company in general.
Conclusions
After two years of experimentation with the tribes and mission framework, we can say that mixing together large and stable tribes with smaller and more dynamic teams improves the flexibility and maneuvering capabilities of the company, the engineers’ growth, and knowledge sharing while still keeping a good level of performance.
Engineers are happy with this process, and our eNPS stayed at the same level or grew slightly (above 65 which is already above market average) despite all the changes and turmoil changes usually create. Engineers participate more and more in other tribes missions, increasing knowledge sharing and company alignment, and decreasing silos. It provides engineers an ability to diversify their focus from a more maintenance and quality improvement approach in LP, to instead, very goal oriented in missions.
One thing we have noticed, is that there is a sweet spot for tribe size which is about 25–30 with all roles needed included, not only developers. That is the number where tribes seem to work the best — the flexibility is high, the amount of services and knowledge isn’t overwhelming, and is shared naturally. Also, people interactions and team dynamics maintain at a high level. After this number, things become too complex and the benefits over effort start shrinking. However, if the tribe has a very clear and unique focus area, it can still work well with a higher number of people (30+).
During the introduction we mentioned ownership, communication, mastery, and productivity as the main benefits of having both long lasting and small teams. I think we’ve covered the communication and productivity aspects well in this blog post, however ownership and mastery are just touched upon superficially. There will be a follow-up post going deeper into missions and launchpad where we will focus on those two. Stay tuned!
