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
- SilosWe were shipping our org structure, not a high-quality product.
- Specialised teamsNarrow focus made it hard to deliver anything complex.
- Dependency hellEvery decision needed too many stakeholders and took forever.
- FrustrationLong delivery times, a fading vision, growing complexity.
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
- Fewer managers, more leadersFast decisions. Put the right team together and let them do the job.
- A culture of choiceEnthusiasm. Let people choose the problems they work on — and give them the freedom to solve them.
- 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:
- A common goalEveryone knows what they are doing and why.
- Fast decisionsAll decision makers are in the tribe, so nobody waits.
- All skills in placeEveryone you need is there — and if not, you hire them.
- Internal driveThe goal is challenging or appealing enough that the team wants to get there.
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
- Pitching TuesdaysEvery Tuesday, open to everybody: new missions are pitched, finished ones demoed, announcements made.
- VisibilityPitches, demos and OKR tracking are public, so anyone can see what is happening and why.
- GuildsInformal company-wide groups that prevent silos and solve common problems across tribes — agreeing on technologies, processes and culture.
Free will
- People choose which mission to join, and who they work with.
- Everyone owns their development plan, with a personal training budget that needs no manager approval.
- Every mission — and every stint in the launchpad — ends with a feedback round.
Technical prerequisites
None of this works if teams can’t ship independently.
- 10 minto deploy to production
- 75deployments per day
- 450+microservices in 600+ independent repositories
Three years later
- Higher engagementBetter feedback scores (eNPS) and happier people.
- Higher retentionHappy people stay longer — and bring their friends.
- A dynamic, self-managing structureMore flexible and faster, with more ownership, lower management overhead, and a chance to change gear — which lowers the risk of burnout.
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:
- How do accountability and ownership work when the team gets bigger?
- At what size does the change start to pay off?
- How long should a mission be? Around two months is a good default.
- How do you make forming new teams feel like an opportunity, not a threat?
- Who are your managers, and who are your leaders?
Further reading
- unfix — includes a Pipedrive case study (English)
- Isejuhtiv organisatsioon — on self-managing organisations (Estonian)
- Algorütm podcast (Estonian)
Related: Leadership culture