kuld.dev / topics

Tribes & Missions

How Pipedrive scaled engineering without scaling bureaucracy — fewer managers, more leaders, and teams that form around problems.

Also in Estonian: Suured ja väledad — isejuhtimine suurettevõttes

Context

Pipedrive builds a cloud CRM for sales teams. Between 2010 and 2019 its engineering organisation grew from five founders to more than 250 engineers, inside a company of 550+ people. By 2023 Pipedrive had around 100,000 paying customers, over 1,000 employees and ten offices across Europe and the US.

Growth like that breaks things. In 2018 R&D saw its first negative headcount growth.

The problem

Underneath: competition for resources, local optimums, key people turning into bottlenecks, work queues everywhere — and a lot of work started, very little finished.

What we wanted

Teams should

  • own problems, not tasks
  • have sharper focus
  • interact more with each other
  • work in a flatter structure

Engineers should

  • move freely between teams
  • choose projects and technologies
  • spend less time on barriers and management

So that time to market drops, we work on the right things, we get more done with the people we have, engagement goes up, fewer people leave — and Pipedrive becomes a place people want to join.

Borrow ideas, build your own model

We studied how Spotify, HERE, Facebook and others run engineering. The lesson was not to copy any of them, but the practices they share: remove every barrier to productivity, cut the red tape, hire responsible people, reduce complexity, be kind and humble in how you communicate, and allow mistakes. Change should be triggered by evidence — interviews, real problems, org and business data.

Three principles

  1. Fewer managers, more leadersFast decisions. Put the right team together and let them do the job.
  2. A culture of choiceEnthusiasm. Let people choose the problems they work on — and give them the freedom to solve them.
  3. SuperteamsAll skills in place. Form the right team for the problem, making it a super team for the moment.

The tribe

A tribe is 13–30 people (never more than ~50) who own a clear service domain end to end, with full business and technical responsibility. Developers, designers and product managers work together; where they sit doesn’t matter. Each tribe contributes to company goals but otherwise runs independently.

A successful tribe has four things:

Tribe · 13–30 people · one service domain Launchpad keep the lights on quality · small fixes Mission Mission Mission 1–3 months 1–3 months 1–3 months
People rotate between the launchpad and missions; roles rotate too — developer, mission lead, launchpad lead.

Launchpad

Keeps the lights on: monitoring, incidents and bugs. Actively looks for weak parts of the system and refactors them, and picks up small product improvements not worth a mission. Engineers land here when a mission ends.

Missions

A short, 1–3 month engagement to solve one specific problem, with clear goals and measurements and a dedicated team focused only on that mission. Supporting roles — research, analytics, marketing, support, infrastructure, coaching — join as needed. When a problem needs skills the tribe doesn’t have, it becomes a cross-tribe mission with the same rules.

100% focus — no buts

A mission team works on nothing else. That means more total value delivered earlier, gaining or failing fast, less waste, no context switching and higher quality. It applies to everyone: designers, PMs and engineers alike.

Keeping it connected

Free will

Technical prerequisites

None of this works if teams can’t ship independently.

Three years later

What to avoid

Technology

  • Accumulating tech debt
  • Poor technology lifecycle management
  • Too many technologies
  • Decisions made too late
  • Reinventing the wheel (engineers love it)

Management

  • Micromanagement
  • Silos and local optimums
  • Hoarding resources
  • Poor decisions — or none at all
  • Leaving affected people out, not sharing reasons
  • Not delegating

Before you try it

Questions worth answering for your own organisation:

Further reading

Related: Leadership culture