Scaling Pipedrive Engineering — From Teams to Tribes.

Transitioning from Startup to Scaleup is, on many levels, an extremely rewarding process, but it can also lead to the discovery of some harsh realities. You can have the truly amazing feeling of seeing all the hard work you’ve put in pay off, but it becomes increasingly clear that the systems and setups you had in place when you were a startup don’t translate as well into Scaleup life and beyond. In the true spirit of agile, let me provide a retrospective on the Teams setup and processes I described several years ago here.

What worked well from the original model?

Talent and culture. Pipedrive has been hiring at an increasing rate since almost day one, with more than half of our employees having been with us for less than one year throughout the company’s lifespan. In such situations it is very hard to maintain a culture of responsibility and ownership. To mitigate the effects that rapid growth can have on a company, we carefully selected new teammates through a long and stringent interview process and embedded them into existing teams. Then, once they were on board, we gave them tools, processes, autonomy, mastery, and purpose. This process seems to have paid off with Pipedrive being awarded as the best employer across multiple locations on multiple occasions, which is a testimony to our efforts of preserving and fostering our culture.

Independent autonomous teams. From the very beginning we believed that work should happen in small, autonomous, full stack teams, so we structured our organisation to support a model of many small teams working on new things in parallel. We adopted a microservices architecture to support this model and, through this, we managed to build many features over time at an increasing pace of delivery.

Fully automated release process. One of the cornerstones of our ability to build Pipedrive in small, autonomous teams is our fully automated software release process. Any engineer can initiate a deployment of the changes they introduced into the system and the change will be tested and deployed automatically. Through this we’ve seen over 50–60 live system deployments during our most productive days.

Specialized supporting teams. When our teams were full stack, it was not wise to have a separate devops or tooling person in each team. Because of this, we created a couple of teams that were dedicated to specific supporting roles within the software development process so that development teams could focus on development. For example, we have a dedicated devops tooling team which is responsible for the automation of our deployment pipeline, including maintenance of our test environments, and teams for infrastructure management and support engineering.

What needed improvement?

Mobility. Over time it became increasingly clear that separation of the engineering into relatively small teams with a specific responsibility was reducing our engineers’ options to move around between projects or teams. Every time an engineer would want to work on something outside of the teams’ area of responsibility it took at least 3 people to agree on that: the engineer, their current manager, and the manager of the new area. In many cases it was simply impossible as each teams’ roadmap had been planned for many months ahead, so losing a person from a small team would always mean replanning and extra hiring efforts.

Structure. When we reached around 12 to 15 teams it became clear that there was a need for an additional layer of management, one person is just not capable of overseeing so many direct reports. Additionally, it was becoming increasingly hard to find new team leads with experience and capabilities.

Prioritization. Prioritization happened in small team silos which meant that if we needed to move faster in certain areas of the product it was more often than not impossible due to inflexibility of product ownership.

Focus. For the teams with several feature deliveries under their belt it was increasingly hard to allocate time for the development of new functionalities due to maintenance responsibilities for previous features. Additionally, when developers did start working on something new, there was always something to fix in the old parts of the code that slowed things down. Constant switching between new development and maintenance of the exiting application was prolonging development cycles and made work more complex than necessary.

Knowledge sharing. Siloed responsibility also leads to silo knowledge and thus siloed solutions. We faced the challenge of multiple developers inventing new solutions for the same problem more than once.

Learning from the best

Based on all of the points for improvement we decided to upgrade our internal structure and processes. We spent some time investigating what other companies are doing and tried to take the things we thought were good and turn them into reality. The resulting model we designed is quite close to the development model Nokia has at its HERE Maps division, combined with a few ideas from Spotify, Facebook and Google.

The initial framework came together quite quickly and got support from many people inside the organization. It was one of those situations where ideas just fit together like a puzzle and afterwards you wonder how you ever did anything differently.

It took us more than half a year to fully roll the change out. Some of the teams naturally moved into the new framework, whilst others had to finish their ongoing projects before they joined the rest of the organization in the new model.

Pipedrive Agile Framework

Pipedrive’s product development is organized around product areas that are aligned with engineering Tribes and corresponding units in Product and Design.

Tribe

Each Tribe is lead by an Engineering Manager and can have up to 20 software engineers and other roles if necessary. Each Tribe, together with the corresponding Lead Product Manager and Product Managers are responsible for a certain part of the product. Each Tribe holds expert knowledge of its product area.

Missions

Tribes organize themselves into smaller teams called Mission Teams that serve a single business goal, with a Mission team containing a Product Manager, Designer, and several developers. The Mission Team exists until the business goal is met or the allotted time is over, after which engineers returning to the Launchpad. The Mission is lead by a Mission Lead, a role for an engineer from the Tribe with other engineers volunteering for missions, including for missions lead by other Tribes. All members of the Mission are expected to postpone other duties and only concentrate on the mission goal for allotted period.

Launchpad

Each tribe has a team called Launchpad. Its purpose is to support missions via research for upcoming missions, help ‘landing’ the Mission (i.e. delivering and integrating the outcome), improve the product quality, and handle smaller tasks and bugs. Launchpad also takes care of any On-Call responsibilities.

Guilds

The purpose of Guilds is to facilitate cross-tribe cooperation on specific areas, such as Front-End Architecture, Back-End Architecture, Quality and Monitoring.

Support

There are also general services in engineering that support all tribes. These include Infra, Quality Assurance, Agile and Personal coaching

Why Change?

The benefits of using the Tribes for both your organization as well as your people are potentially huge if you do it right.

Firstly, for the organization as a whole, the allocation of resources is simply better. Our previous setup was to have teams focused on a specific product area — the problem with that is, say you have a team with 5 people — not every project needs 5 engineers; sometimes you need 7, and sometimes you need 3. The Tribes model allows the dynamic allocation of resources so that each project gets the resources it needs, no more, no less, while others are either on other Missions or on the Launchpad performing general maintenance.

Secondly, allowing engineers to focus on one problem at a time will result in faster and higher quality solutions. We even found that this new system really brought a lot of focus on subjects and was one of the biggest adjustment points for our teams — this adjustment was quickly overcome and, let’s face it, as far as issues to overcome go, this wasn’t a bad one. Once our teams were settled into the new system the increased focus produced amazing results, and these results were reached much quicker than they would’ve been under our previous traditional scrum setup.

The increased focus also had another great outcome — projects are much more rewarding which leads to increased motivation and happiness among the teams.

Add to that the freedom of choice from working on the projects you choose (in a way that you choose to work on them) and you have an effective, dynamic, happy, productive, and fast moving engineering team.

So basically, you get to have your cake and eat it too. And it’s the best cake you’ve ever eaten… and it cooks faster than you’re used to… and it’s a happy cake.

Sounds perfect, right?

Did it work for us?

It’s been six months since we implemented the Tribes model and we’ve already had a bunch of successful Missions. To be specific, at the time of writing we’ve completed 20 Missions, have a further 17 currently ongoing, 5 in preparation and 30+ in draft state. We’ve seen all of the desired outcomes — our teams are happier, more motivated, and producing even better products than they were before.

We currently have 5 Tribes in Estonia, 1 in Lisbon, and we’re currently building our first Tribe in Prague. We’re hiring in all locations too.

So if you want to see more about how it worked for us, come and join us and see for yourself!

Come and taste the cake. It’s a damn good cake.