CWDN series: Dev-eXperience - Pipedrive: Tribes & missions breed growth & nourishment
This is a guest post for the Computer Weekly Developer Network written by Mikk Mangus in his capacity as engineering manager at Pipedrive – a company known for its sales and Customer Relationship Management (CRM) platform technology.
Mangus writes in full as follows…
Developers just want to get things done.
Ensuring the business gives us a great experience means we give more time and attention to the things that matter most. That puts a premium on a high quality of organisation and collaboration that allows time for deep work, removing the messy, organic friction that developers aren’t generally known to relish.
In my SaaS business of 850+ people, we have a variety of engineers and various business roles. Far from keeping to our own lanes, we find we have a better collaborative experience and create better outcomes when we work together. We rotate through a system of tribes and missions, constantly sharing best practices and learning from each other.
Tribes & missions
[I like to say that use of] tribes & missions keeps engineering central to solving customer problems
Pipedrive is now in year six of our ‘tribes and missions’ framework that guides how our developers and engineers work and collaborate with other roles. This sits on top of a very common organisational structure that includes the separate functions of product, engineering, and marketing and sales.
Our tribes are groups of colleagues all focussed on solving a common goal. They tend to be big teams that collectively own either customer-facing or internal services. For example, one tribe is responsible for Insights, through delivery of data visualisation and reports. Another handles ecosystem, via our marketplace and integrations.
Every once in a while, tribes form, dissipate… and are reborn in new configurations as needed.
Tribes are made up of each of the roles required – always in addition to engineers – for their goal, usually numbering between 15-30 people. Work is then organised into smaller, dynamic subgroups of each tribe, called launchpads and missions.
When the tribe owns the entire vertical solution for a customer problem it’s easier to set priorities and keep a high engagement environment. Each tribe has an Engineering Manager and one or more Product Managers who are accountable for the high-level roadmap and troubleshooting the experience.
We organise our work into chunks that we call missions. Missions are projects that solve a customer challenge. A mission has a core team including a product manager, a designer, and a mission lead, always a software engineer. They are accountable for mission deliverables from problem validation to the solution’s quality and implementation.
Houston, we have launchpad
The launchpad is a dynamic group with a variable size related to priorities and mission requirements. It’s usually 30-50% percent of the tribe and are the ones who maintain and support the rest. They are the talent taking on technical debt and improving service quality and they can make targeted product improvements, too.
What these groupings offer is massive flexibility to manage rapidly changing business needs. Developers are most useful when we are adaptable. When we adapt quickly, so does the business. Allied to this adaptability is the freedom of choice on offer. We allow developers and engineers to work where their passion takes them. Our teams report great satisfaction and knowledge sharing, in a virtuous circle, and can grow areas of expertise, mastery, and responsibility.
Pipedrive’s Mangus: People & collaboration – combined – make the best developer experience.
Everything has trade-offs, and engineering managers focus on minimising friction. This tends to come from the learning curve that our developers face. With tribes tending to be larger than the more usual cross-functional team, there will be more services for developers and engineers to manage. Onboarding and assembling teams requires careful planning before work kicks off.
People and collaboration make the best developer experience, it’s one of my core mantras.
Interaction contraction
As companies grow and more activities are undertaken, your developers can no longer interact with everyone in the business. Sometimes another team may own a section, but you’ll need to work on the code for them. Issues of access approval before developers implement changes becomes important and lessens the friction whilst widening internal access.
Transparency is also allied to access. We can’t have code being a secret. It’s important to have access, as product code is interlinked. We stress the importance of transparency to DX so the individual and the collective succeed together. But as a manager, I keep top of mind that my team needs the focus time to do their job properly. Too much collaboration kills the flow state. Keeping a demarcation between time on task and time about tasks is key to great experience and great results.
Now, as an engineer, it’s important that if you’re stuck, it’s a good idea to ask someone else the question that could save the business time on reinventing the wheel. Yet it’s a fine line – you don’t always have to be the person asking someone questions, but you need them addressed in order to improve and implement the right changes. Balancing the need for a quick answer with disturbing someone else becomes key in self-management.
As a consequence, many of our developers enjoy pair programming, working together side-by-side, perhaps virtually, allowing both to edit together. With two brains working together to solve a problem, we tend to be smarter than the sum of our parts.
That theory is at the heart of the missions and tribes organisation, and the theory behind our ways of working: A great developer experience is one that develops a better experience. That is, it’s always getting better, and it’s open for improvement from any direction.