Pipedrive Agile Framework: How a Unicorn Company Customized Agile Processes to Scale

Fast-growing scale-ups rarely use the Scaled Agile Framework (SAFe) or Large-Scale Scrum (LeSS) because they see such agile frameworks as not agile enough. You don't become a unicorn company in 500 sprints. What's far more effective is a versatile structure that enables a dynamic match between the employee experience (EX) and the customer experience (CX). That's precisely what Pipedrive established.

Pipedrive is a SaaS company based in Estonia, with more than 900 people working across ten offices. It is the fifth company in Estonia with the "unicorn" status.

Pipedrive did not adopt an existing agile scaling framework to achieve such eye-catching and enviable results. Instead, they created their own.

In spring 2018, the company began defining a scaled-up approach to an agile way of working that they named the Pipedrive Agile Framework. They knew that scaling hierarchically was not going to work and, besides, it's hard to find excellent middle managers, so the fewer you need of those, the better.

On top of that, the intense competition for great engineers meant that Pipedrive had to do more than just keep increasing salaries. They had to come up with a way of working that, first and foremost, would improve the employee experience. Engineers wanted a work environment where they could keep learning and growing and pursue their passions. The result was the Pipedrive Agile Framework.

Today, more than half of the employees operate within this framework. Three hundred of those are engineers; the rest are primarily designers and product managers.

In this article, I offer my perspective on Pipedrive's Agile Framework. I explain how it compares to my own unFIX model.

Tribes

At the time of writing (May 2022), Pipedrive has seventeen Tribes organized around product areas. Each Tribe is a large team (fifteen to thirty people) that owns a specific customer-facing service or internal platform and is responsible for the entire lifecycle of that service or platform. This stretches from defining the customer problem to maintaining and improving all assets until depreciating the service or platform.

Figure 1: Seventeen tribes

A Tribe at Pipedrive is the equivalent of what I call a Base: a group of people sharing a sense of belonging. The Tribe (Base) is also tasked with offering its members a sense of purpose, autonomy, recognition, and psychological safety.

Each Tribe is cross-functional, meaning that it includes all knowledge, expertise, and roles needed to develop and support its product area. Tribes consist mainly of engineers and a few product managers and designers. Other roles are available on-demand through external teams and Tribes (see Support and Operations).

Tribes have their own vision and objectives, and the goal is for all tribes to work as autonomously as possible. At the same time, tribes coordinate their goals with each other and with higher management to reflect the principles of Objectives and Key Results (OKRs). There is a healthy dynamic between (a lot of) bottom-up emergence versus (a little) top-down steering. The level of autonomy differs per Tribe and depends on the lifecycle stage of their solution and the maturity of their product area.

With an underlying microservices infrastructure, the Tribes at Pipedrive are typical examples of Strongly Aligned Bases: teams within each Tribe work on one larger solution, but they can release and deploy their work independently, sometimes many times per day.

Tribe Size

Within each Tribe at Pipedrive, all engineers, product managers, and designers are collectively responsible for their product area, including all its code and other assets. For this reason, Pipedrive found that the size of a tribe is best kept in the sweet spot of twenty to twenty-five members. In this range, the flexibility and impact of the Tribe are high. At the same time, the amount of required knowledge and experience (referred to as "cognitive load" in Team Topologies) is still manageable. Also, team dynamics and reteaming work out well for tribes of that size range.

Larger Tribe sizes have been tried, but things soon become too complex. The benefits of scale gave way to the drawbacks of confusion. Teams that are too big spend too much time on internal communication, and the amount of code they are collectively responsible for becomes too large. Smaller Tribes are more common. At the time of writing, there are two Tribes of under twelve people and three Tribes with a size of exactly twelve.

Considering that a typical Tribe is larger than a "classic" cross-functional team of three to seven people, the number of services, tools, and technologies that an engineer needs to master can be more than what's common in other organizations. Onboarding a new employee in a Tribe happens step-by-step and takes anywhere between three weeks to half a year until that person feels comfortable with all code and assets in the Tribe.

It is worth noting that Pipedrive found an optimum size for the cognitive load of their engineers and decided to make this boundary equal to the preferred size of the Tribe.

Tribe Formation

Tribes are formed, changed, and split in a somewhat organic manner. In most cases, the initiative for Tribe formation emerges bottom-up, with engineers or product managers discovering a need to form a group of people around a newly defined product area. In some cases, the initiative comes from upper management identifying a market risk or opportunity. There is no defined process for Tribe formation and reorganization. Conversations and decisions happen whenever the need arises.

Sometimes, a new Tribe emerges as a spin-off from another Tribe. The original Tribe can be seen as an improvised incubator in a case like this. A small group of people leaves their nest when their Minimum Viable Product gets significant traction and seems mature enough to be managed as a separate Tribe. (Pipedrive has no dedicated incubator Tribes, which might be an option to consider for the further evolution of the company.)

Figure 2: Tribes separating and splitting off

Pipedrive's agility is boosted by the fact that its employees have a healthy habit of moving between Tribes to work in the areas where they can have the most impact and where they find the best opportunities for personal growth. On average, horizontal moves between Tribes happen about once per year per Tribe member.

Launchpads

With the fast growth of Pipedrive, it became increasingly hard to allocate time to develop new functionalities due to maintenance responsibilities for previous features. The constant switching between new product development and maintenance of existing services hurt development cycles and made work more complex than necessary. Pipedrive needed a way to solve the capacity problem. The solution they came up with was the Launchpad.

Figure 3: The Launchpad of a Tribe

A Launchpad is a small group of engineers within a Tribe responsible for support, bug fixes, incidents, refactoring, and minor improvements in their product area. Some might call them the maintenance and quality team. In unFIX language, the Launchpad is a Value Stream Crew that focuses on keeping its product area running smoothly. This includes the planning of any on-call responsibilities if needed.

An additional task of the Launchpad is to support the missions in progress in the Tribe (see below). Some might consider the analogy of ground personnel making sure that aircraft can take off and land safely. The Launchpad handles research and preparations for missions, and they assist with the "landing" of completed missions, integrating the results into the existing code and infrastructure.

The size of the Launchpad is typically between 20% to 40% of a tribe (between four to ten people), but this can fluctuate significantly depending on the ongoing missions. Most importantly, the engineers rotate between Launchpad and Mission Teams. On average, each engineer spends about 20% to 40% of their time on maintenance work and 60% to 80% on new product development.

These ratios are different for the designers and the product managers as there are fewer of them (only a few product managers and designers per Tribe). They work primarily on missions because there is much less to do for them in maintenance and support.

Launchpad Lead

The Launchpad has one person in a unique role called the Launchpad Lead. This person helps with the planning and landing of missions, prioritizing the work of the Launchpad team, and the planning of vacations. Considering that this is the first person to talk to when it comes to understanding the daily work of the Launchpad, they are the equivalent of what I call the Captain role.

In general, the Launchpad Lead role rotates with a cycle of about three to six months. Anyone in a Tribe can volunteer to be the Launchpad Lead for some time, and, in the case of multiple candidates, a quick election might take place. However, Pipedrive allows for cultural variations. It turns out that in some regions and offices, there is a stronger willingness to lead than in others. And in some environments, the role might go to a person with a level of seniority and a proven track record, while in other Tribes, even the newest recruit could take up the Launchpad Lead role. It all depends on context.

Initiatives

OK, that's enough about maintenance. Let's talk about innovation!

At Pipedrive, product design and development happen in a combined top-down and bottom-up manner. Before the engineers can get their hands on a new problem, some work is already done by Product Managers and Designers in the Problem Definition and Solution stages, which are pretty similar to stage one (Initiation) and stage two (Expedition) of the standard Business Lifecycle. In these early stages, no engineers are needed yet.

It is only when new initiatives turn into proven concepts that production teams need to be formed for implementation in design and development. This handover coincides nicely with stages three (Formation) and four (Exploration) of the lifecycle model. From this point onward, engineers get involved in new product development, and the top-down initiatives coming from Product Management turn into bottom-up missions where engineers take the lead.

Mission Pitches

Ideas for new product development are pitched at Pipedrive's company-wide "Pitching Tuesday" event. A pitch should offer a problem statement, a proposed solution, and a rough estimate for the timeframe and the number of people required. There should also be an indication of the metrics used to establish mission success. These metrics might cover customer adoption and customer satisfaction but also reusability, scalability, and more. Considering that goal-setting and mission-launching are ongoing activities at Pipedrive, we see a continuous flow of Objectives and Key Results. (I wrote about OKRs in Flow here.)

Most commonly, a core team of a Product Manager and Lead Engineer prepares the pitch. And a Designer may be involved as well. Either of them can do the pitch, and the intent is for people (mostly engineers) to volunteer for missions. These volunteers can come from the same Tribe as the core team but also from other Tribes. A standard guideline is that a person who's been working on a Launchpad the longest is the first one to be allowed to go on a new mission, either within their Tribe or in another one. This helps Tribes to keep up a steady rotation.

The core team and engineers who volunteer for a Mission Team are usually all from the same Tribe, so they know their mission's impact on the Launchpad. It is obviously not desirable that the Launchpad is left behind understaffed.

Over the years, it has become more common for engineers to join missions in other Tribes. Such temporary "cross-tribe reteaming" allows people to make new connections across the company, which translates into easier dissemination of ideas and practices, breaking down cultural silos, better coordination across Tribes, and increased social cohesion and alignment in the entire organization.

Granted, assembling Mission Teams out of volunteers takes time. It would be a lot easier and quicker to simply assign projects to teams, as most other organizations do. However, the extra hours spent crafting convincing pitches, volunteering for missions, and negotiating availability, results in highly motivated Mission Teams. This additional effort pays back many times in the weeks or months that follow. Furthermore, when nobody wants to sign up for a mission pitch, it sends a clear signal to the core team: do your homework and improve your pitch, or else it's not worth our time! For product managers, this is not always easy.

Mission Teams

A Mission Team is a fancy name for a small project team with a well-defined business goal. These teams usually consist of one Product Manager, one Designer, a Mission Lead, and a couple of engineers. (In rare cases, Mission Teams may have only engineers.) The mission of such a team is to improve the state of a product area in a specific way. It could be a significant upgrade to existing functionality, a considerable refactoring or migration effort, the addition of an essential new feature set, or even the launch of an MVP version of a new product.

Figure 4: The Mission Teams of a Tribe

The kick-off for a new Mission Team is usually on the Monday following Pitching Tuesday. (Before Covid, new Mission Team members literally moved into another room when they went on a mission together.) The Mission Team spends some time defining their working agreement, setting up a task board, initial backlog, and infrastructure, planning customer interviews, daily standups, retros, and so on. In most cases, Mission Teams choose Kanban as their preferred agile method. In a few instances, their starting point has been Scrum.

Pipedrive has, at the time of writing, 47 Mission Teams in progress (on average, three missions per Tribe), 35 are being prepared, and 616 have finished. On average, engineers spend roughly 60% of their time on missions. They spend the remainder of their time in the Launchpad.

Missions can take three or four months, but four to five weeks is the median. It depends on the mission. Instead of arbitrarily sizing the objective to match an available timebox, the available timebox is sized to fit the objective. The Mission Team exists until the business goal is met or the allotted time is over, after which the engineers return to their Launchpad. In some cases, missions get an extension, or they get canceled due to a lack of success or changed priorities.

During a mission, all Mission Team members are expected to postpone other duties and diversions (including vacations, if possible), and they only concentrate on their business goal for the agreed-upon period. This results in high employee engagement and commitment, as measured by Pipedrive's employee satisfaction scores. And the Mission Team does not need to worry about bug fixes, refactoring, support, and other maintenance activities in their product area, which would just slow them down. That's what the Launchpad takes care of while the Mission Teams pursue their goals. It is hard to think of a better example of a steady Base with goal-driven Crews.

Mission Leads

As discussed, each mission usually has a core team consisting of a Product Manager, a Designer, and a Mission Lead (though the Product Manager and Designer are not needed in all cases). The core team is accountable for Mission Team formation and deliverables, from problem validation to the solution's implementation and quality. The Mission Lead (a Captain role) is usually an engineer. The Product Manager or Designer could have the Mission Lead role as well, but in practice, this is a rare thing to happen. In other words, at Pipedrive, engineers are in charge of most missions, not product managers.

The role of Mission Lead rotates among the engineers in a Tribe, based on volunteering, meaning that everyone gets a chance to be the lead on a mission. It is common for 50% to 70% of engineers in a Tribe to have experience with the lead role, which boosts their personal development and leadership skills.

Mission Landings

At the end of a mission, the Mission Team returns to their Launchpad with the aim for the mission to "land". As part of this landing, the Mission Team meets with the Launchpad team members to review what was done, what was produced, and why. Based on this review, the Launchpad Lead decides if the mission is cleared for landing on the Launchpad. The Launchpad team then takes ownership of the new code and assets produced on the mission.

Figure 5: Missions launching and landing

If the quality of the mission is not up to standard, the Launchpad Lead may choose to deny permission for landing, and the Mission Team has additional work to do before making another landing attempt.

After a successful landing, it is common for the Product Manager and the Mission Lead to remain available for a bit longer for questions and to wrap things up. On top of that, a common strategy is to have at least one Mission Team member rotate to the Launchpad for the smooth dissemination of new knowledge and experience across the rest of the Tribe.

A recent addition to the Pipedrive Agile Framework is the role of the Quality Ambassador. There is one Quality Ambassador per Tribe, and, similar to the LaunchPad Lead, this person is most commonly elected from volunteers. The Quality Ambassador's role is to monitor quality across the Tribe's entire product area, and they contribute to the Launchpad Lead's responsibility to accept or deny mission landings.

Last but not least, missions commonly end with a demo on Pitching Tuesday, which includes a show of deliverables, success metrics, and learnings from the Mission Team's retros. This is where people across the company can learn about the upcoming changes to Pipedrive's products.

Dynamic Teams

As I've noticed, many people have an opinion on the benefits and drawbacks of stable teams vs. dynamic teams. Still, Pipedrive came up with an innovative compromise: The large teams (Tribes) are stable, while the smaller teams (Mission Teams) are dynamic. They have introduced a larger Base to satisfy people's sense of belonging (stability) and then create temporary Crews to pursue short-term objectives (dynamics). There are several benefits to this approach:

• Having small teams focus on one problem at a time results in higher throughput of objectives and a faster pace of turning problems into solutions. It is a perfectly lean and agile thing to do.
• The dynamic allocation of people to problems means that teams are formed to match the size of the problem instead of arbitrarily cutting up problems to fit the size of available teams.
• The extra effort of pitching to get volunteers to sign up for missions pays off by ensuring better problem definitions and more compelling ideas for solutions, or else nobody wants to join.
• Allowing people to freely move around tribes to where they believe they can have the most impact or learn the most significantly enhances the employee experience.
• The dynamics of reteaming, both within and across tribes, reduces the organization's tendency toward siloed knowledge and solutions. Dynamic reteaming is one of the antidotes to sub-optimization.
• Having dynamic teams (without managers) that operate within stable tribes (with managers) improves the organization's agility and flexibility in responsiveness to risks and opportunities in the market.

Pipedrive considers dynamic reteaming so crucial that, as a rule of thumb, engineers are expected to rotate between Mission Teams and the Launchpad. For sure, some engineers may prefer either, but spending time only on missions or only on the Launchpad is highly discouraged.

Chiefs

If you're a follower of my work on Management 3.0, you know that I don't believe in self-organization without constraints. It takes management to put boundaries around self-organization and tweak the parameters so that great things emerge from a self-organizing group of people, or else you end up with anarchy. That's what the Chiefs are for.

Figure 6: The Engineering Manager

At Pipedrive, each Tribe is led by an Engineering Manager. They are the direct manager of all engineers in the Tribe. (The Engineering Managers themselves have the VP of Engineering as their manager.) The Engineering Manager is obviously the Chief. However, the alignment with my unFIX model starts to break down with the non-engineering roles.

Almost every Tribe works with several product managers and designers. (When Tribes exclusively do low-level engineering, they can do without.) But these product managers and designers have no direct line manager among the Chiefs of the Tribe. Instead, they have their managers outside the Tribes.

Problem Spaces and Verticals

Though the Pipedrive CRM system can be seen as one big solution, Pipedrive defines about ten different Problem Spaces, such as Platform, Customer Communication, Campaigns, and more. Each of these Problem Spaces has one Group Product Manager.

Each of the seventeen Tribes corresponds to one of the ten Problem Spaces. And every product manager working with a Tribe is managed by the Group Product Manager of the corresponding Problem Space. The Group Product Manager of the Problem Space is the counterpart of the Engineering Manager of the Tribe.

Figure 7: Tribes in Problem Spaces

In addition, Pipedrive defines six Verticals, such as Shared Experiences, Lifecycle, and Apps. These Verticals contain multiple Squads of Designers and Product Managers doing research and design activities for their Verticals before any work goes into the engineering Tribes. There is an MxN relationship between the Verticals and the Problem Spaces.

The result of this complicated arrangement is that Pipedrive has a matrix organization. Tribes are not fully autonomous because the management of all people in a tribe is not contained within its Governance Crew. Therefore, there is no complete control over the product area, and thus Tribes cannot be managed as small, independent businesses.

Having a matrix structure is not necessarily harmful. It just comes with certain risks, and it can be a good-enough temporary structure in a company that is transforming itself continuously (as Pipedrive does), hopefully from a traditional hierarchy to a more future-proof network organization. As long as there is an awareness of the dysfunctional side-effects of the matrix, the problems can be managed.

Support and Operations

There is, of course, a lot more going on at Pipedrive because the product development part is "only" about sixty percent of the company. There is a dedicated DevOps Tribe responsible for the automation of the deployment pipeline, which includes the maintenance of test environments. There is an Infrastructure team managing the lowest level of Pipedrive's operations. There is a Data Analysis Tribe supporting the other Tribes in gaining intelligence from the data they're collecting. And then there is Agile Coaching, Quality Assurance, Research, Localization, and more.

Figure 8: Support and Operations

Because these support functions are provided from outside the engineering Tribes, the company could treat them as platform Bases that have the engineering Bases as their customers. That's how one would organize a networked organization, with all Bases serving external or internal clients. These platform Bases might need different structures because form follows function, and the dynamic reteaming in engineering might not apply to support and operations teams.

Guilds

Like many other organizations, Pipedrive has Guilds that facilitate cross-tribe cooperation in specific areas, such as functional roles (Security, Front-End Architecture, Quality and Monitoring, and so on) and specific technologies (PHP, Go-lang, React, etc.). I would call these Functional Forums and Technical Forums that span multiple Tribes.

Any group of people with a shared interest can initiate a mission to accomplish an objective involving guild members. A rule of thumb is that engineers invest roughly 20% of their time in guild activities while working on a Launchpad. Some of that work on Guilds can involve participating in (or setting up) training programs.

Figure 9: Guilds (that can actually span multiple Tribes)

Guilds are managed by Guild Masters (equivalent to what I call the Chair), a role that rotates about once per six months, driven by volunteers and elections.

Benefits

Early 2020, when COVID-19 hit the world, Pipedrive could respond swiftly. New missions were started, others were canceled, and the business re-prioritized many initiatives in just days. For a company using dynamic teams, refocusing is an easy thing to do. Mission Teams absorbed the shock of reorganization while the Tribes remained stable. For companies relying on static agile teams, or worse, traditional functional departments, such rapid reorientation is much more painful.

Figure 10: A complete Tribe

Flexibility is one of the main benefits of the Pipedrive Agile Framework. No negotiations with middle managers are needed, no breaking of earlier commitments with employees, and no confusion because of redrawn team boundaries. There are just new objectives, new missions, and everyone trying to help out where they believe they can make a difference. It is a framework for versatile organizations that rapidly respond to crises and quickly pursue new opportunities. Hence, Pipedrive's stellar performance in the CRM market.

Besides increased flexibility and versatility, there is a link between the Employee Experience (EX) and the Customer Experience (CX). Mission Teams have direct contact with their customers, and employees flock toward missions where they can learn, contribute, and follow their passion. This freedom of choice increases employee engagement, higher quality of work, and more delighted customers.

What I learned from Pipedrive

There are three insights I take away from Pipedrive's unique approach, which several other companies in Estonia have already copied.

• My unFIX model recognizes optimal team size (three to seven) and Dunbar's Number (up to 150). The Pipedrive approach shows that an intermediate level for collective ownership or cognitive load (15 to 25 people) is worth considering as a separate design parameter.
• There are multiple ways to divide an organization's capacity between product maintenance and product development. Pipedrive has shown how you can organize this with people rotating between Launchpads and Mission Teams.
• Most agile approaches tell us to cut up and size objectives to match available teams and timeboxes. Pipedrive shows you can also do this the other way around: size the teams and timeboxes to fit the upcoming objectives and still operate in a fully agile manner.

Each of these insights might find its way into future versions of my work.

What Pipedrive can learn from unFIX

There are also three ideas that I would suggest to Pipedrive:

• A rapidly scaling network organization could consist of truly autonomous Bases (Tribes) all over the company. The matrix organization can be unfixed by having line management go upward through the Governance Crew of each Base.
• Pipedrive has no dedicated incubator Tribes (or Ful that could be the birthplace for genuinely disruptive innovation. After all, the managers of existing product areas are unlikely to prioritize ideas that, if successful, would replace their own products.
• In my opinion, turning Objectives and Key Results into a continuous flow (as opposed to having a fixed, quarterly cadence) makes total sense for a highly versatile organization. However, this requires commitment from the very top of the company.

I know that Pipedrive keeps changing, trying to find more ways to grow and expand. Maybe some of these suggestions could be helpful on that journey.

Conclusion

This case study is a snapshot picture. The way Pipedrives operates will probably be quite different a few years from now. But it is safe to say that the Pipedrive Agile Framework had a significant influence on the company's performance. Pipedrive would not have become a unicorn company by using a standard off-the-shelf agile framework.

Pipedrive created its own framework. The unFIX model can help you do that as well.

Acknowledgments

A big thanks to Kadri Pirn, Sergei Anikin, Aivar Ots, Stephen Rea, and Martti Kuldma for offering their time to give me input for this case study.

Sources

• How We Run Our Growing Engineering Team at Pipedrive
• Scaling Pipedrive Engineering — From Teams to Tribes
• The Heresy of Mixing Together Large and Dynamic Teams
• Pipedrive Agile Framework: A Detailed View
• Kadri Pirn on how Pipedrive Agile Frameworks enables to be an empowering organisation
• Martti Kuldma - What is Tribes & Missions and how did Pipedrive get there?