Scaling engineering teams
Contents
With growth companies tend to create new ways of work and interact in order to scale. The simple vision of small teams using the some agile methodology simply does not work in growing companies that want to retain talent and keep their engineers motivated. The repetitive work, the fact that small teams don’t have the capability to be responsible for several engineering solutions and the fact that, in a small team, challenges that can be given to a engineer are limited makes growing companies to question the common work methodology and create new approaches to software development.
Pipedrive is one of those companies. Joining the best practices used by the biggest companies and, using this information, appling a major brainstorm, it came out a framework that reimagines the way we produce software development.
In Pipedrive we are organized within Tribes. Tribes are formed by a maximum of 20 engineers lead by an Engineering Manager, maximum of 4 Product Managers leaded by a Product Manager Lead and a Maximum of 4 Product Designers leaded by a Product Design Lead. It can also have researchers and data analysts dependending of the necessities of the Product. This structure is responsible by 4 or 5 product features (which up to 2 can be big ones) and their continuous improvement and support.
Within the Tribe, we have 2 types of places a tribe member can be: in the Launchpad or in a Mission.
The Launchpad is the physical place were all the Engineers, Product Managers, Product Designers, Researchers and Data Analysts that are not on mission are. In the Launchpad, Product Managers, Product Designers, Researchers and Data Analysts prepare the next missions, investigating and preparing what, on product terms, makes sense to tackle next. This, of course, is aligned with the global product strategy and company objectives for that year. Engineers, while in the Launchpad, are responsible for the maintenance of released features (bug corrections, refactors, small improvements, etc), some research and development that helps ongoing or future missions and is the perfect time to do some training (online training courses, internal company trainings, conferences, etc).
One of the main differences between the Product Launchpad and the Engineering Launchpad is that the latest has a Launchpad Lead. Launchpad Lead is a rotating role that is given to our most senior engineers. The main objective of this role is to manage and prioritize all the tasks in the Launchpad board, remove any roadblocks that engineers might have, work with ongoing missions to understand if the launchpad can help in anyway and finally making sure that a mission, when it lands, fills all the necessary requirements in terms of code organization, quality, security, scalability, documentation and so on. Of course that this is an ongoing job that starts weeks before the landing of a mission.
A mission is what we call when a Tribe wants to tackle something that will take a long period of time and several resources, usually a full feature. It can be driven by product or by engineering and always follow similar concepts. In Pipedrive we have 4 types of missions we can launch:
- Exploratory Missions: the main purpose is to validate a product idea. The result of this mission is a Proof of concept of some feature and 90% of the times all the code is threw away. In this kind of missions we prefer speed over quality. Sometimes this missions are just design sprints with a limited time of 1 week. Usually takes between 3 weeks to 5 weeks.
- Feature Missions: the main purpose is to create a feature from scratch. When these kind of missions are launched, Product already has a pretty clear idea of what we need to develop. This means that a Exploratory Mission was already done as well as a fair amount of research, data analysis and client interviews. Usually takes between 1 month to 3 months.
- Follow Up Missions: these are basically improvement missions. The main purpose is to add more functionality to an already released feature. These kinds of missions typically happen when the feature is stable in production and the product already identified several improvements that can be done to it. Usually takes between 1 month to 3 months
- Engineering Mission: Is a mission that has no dependency of the product team and its main objective is to improve or refactor a big part of a feature (e.g. improve the scalability of a certain component). Usually takes between 1 month to 3 months.
With this model, we hope to have motivated motivate by always being experiencing new challenges, have focus on the value we deliver to our clients (move fast, fail fast) with focus on understanding what our clients want and not what we think they want and mainly give everyone the opportunity to growth and develop themselves.
PS: Read more from Nuno on his interview on managing teams.
Discussion and references