SpaceUP Inspiration: Talking Tribes & Missions With Tomas Rehor
Tomas Rehor has worked and led in some of the most notable tech companies including Skype, Microsoft, and Kosik. Now the CTO of American-based startup Zenbase, Tomas is building their R&D from Prague and scouting for talent to join the new team.
As the former Head of Engineering and first employee in Pipedrive’s Prague development center, he not only grew his team in terms of size, but created a methodology of approaching work that completely changed how they viewed and delivered projects. This Tribes & Missions concept Pipedrive adopted was a major inspiration for our SpaceUP methodology at Ataccama — and what better way to learn from previous iterations than to hear from the expert who consulted with us before starting this journey.
We sat down with Tomas to pick his brain about his experience with Tribes & Missions, what’s changed since he first started using it, and why it might be time for you to rethink your team structure, too.
Hi Tomas! To get started, could you explain what Tribes & Missions are?
The main idea is to group people together in bigger groups–we call them Tribes–and it should resemble a group of different people living together and working on the same agenda. You can imagine a Tribe as a group of 20 to 25 people with different skill sets, and they’ll have all the skills needed to run a part of the product or the whole product. It would have product managers, product designers, and all kinds of software engineers that you need and the Tribe delivers end-to-end functionality of what it owns.
Then, you need to have business ownership. The Tribe owns a very well-defined part of the product end-to-end, meaning as long as they follow the general company strategy and contribute to the common KPIs, they are free to choose how they deliver. That’s why it’s important that there is strong product ownership within the Tribe, who actually decides the strategy, and the engineering is there to deliver.
Then the second part is the types of Missions — how do you deliver once you decide what to deliver? How to deliver most efficiently and sustainably, as the number of your teams grows it’s impossible to deliver sustainably, the delivery pace slows down and motivation goes down.
How big was the Pipedrive team when you joined, and when you left?
In Prague it was one when I joined and 45 when I left. And the entire company was just over 300 when I joined, and close to 900 when I was leaving.
Most product companies use Scrum. Why should a company consider a fundamentally different approach, like Tribes & Missions?
I don’t think they are 100% substitutes for each other. For me, Scrum is a way for a single team to organize their way of working and delivering a feature. So you can be on a Mission and the team can decide to use Scrum.
If we think about structuring teams, when they chose to reorganize how we worked, we were solving a problem. This problem was that they had 17 traditional Scrum teams each working with very strong ownership of an area. This meant that whenever you needed to deliver a bigger initiative spanning across the entire product, you’d need easily six or seven teams cooperating together. They soon realized they weren’t able to innovate fast enough or deliver new features.
A project that would have taken a month to complete would take easily up to a year because of the cross dependencies. You have a team wanting to deliver something they handed over to a different team, then they realize that it’s not exactly what they needed. So they come back to the team, who’s already working on another project. Then they need to wait for another sprint to start. I call it “dependency hell” because I’ve been there. It’s frustrating for any team to have to sit and wait for somebody else to deliver for you. Naturally, you don’t sit and do nothing, you work on something that’s not a priority for the whole company. You just kill time.
Why is it important for people to have end-to-end ownership in their work?
From my perspective, this is a fundamental question of motivation. If I believe in my skills and my capacity to help the company grow, it’s super frustrating if somebody tells me what to do and what not to do. On the other hand, I’m motivated when my ideas are supported and I’m being helped to implement what I think I’m good at. That’s my personal experience about what keeps people motivated. If you give them room to do what they’re best at, they will thrive — they will grow, they will blossom, and they will be super happy.
It must give people a sense of duty and confidence to grow in their particular area.
Yes, for me as a leader, or manager in traditional terms, it almost feels like cheating. When you give people room to grow, give them nutrients and water them when needed, they do it on their own. It’s like magic.
But it’s also super scary because you let go of control and believe people will do things right. And you need to implement other means of performance management or making sure that the right people are getting promoted, that people who are maybe underperforming get the right feedback. You have to do it differently, and I think that’s why it’s so scary and only a few enlightened companies have started the journey. And we can see it with COVID. I honestly didn’t think so many companies would force people to go back to the office. I think it’s a similar symptom that people are afraid to let go of control of the people they’re managing.
If we step back a bit to when you were at Pipedrive, what triggered the realization that you needed to change how you were working?
Those 17 teams were rigid in their structure and scope of work and very interdependent. There was a constant struggle between different product managers to weigh their projects in other teams’ backlogs. It creates a stressful environment, and at the same time, the team feels they can’t deliver what they want because they are constantly blocked.
It’s mostly a feeling that something is not right in the company. But it’s very hard to measure at first. One thing that was measurable was that people started leaving. For the first time in Pipedrive’s history they had negative growth, and that was when they decided to sit down and rethink things. At this time, the engineering team had a little over 100 engineers and a proportionate size of product managers and designers. It was quite sizable, but not as big as when I left. So that was a trigger point, when the NPS score was bad and people started leaving.
How long does it usually take for software engineers to adjust to something like Tribes and Missions if they’re already familiar with Scrum?
We started with one or two Tribes, let them work for a month and learned from how they work, then we transitioned others. In terms of the way of working, it’s different. In a smaller team the scope of your domain you need to understand really well is quite narrow. With the Tribe, it multiplies. One of the biggest challenges is that people should be willing to learn new things quickly, and maybe not as in-depth as they’re used to. They should learn enough to fix bugs or write new code. If they need to understand some deeper or fundamental architectural decisions, they would know who to ask.
That was the biggest resilience I saw, that people no longer understand everything going on in that Tribe. And the purpose was not to have everybody understand everything. Some Tribes owned easily 30–40 services, so it’s hard to understand each. We wanted to nurture an open mindset. On a Mission, maybe two people already understand it, and two people are new to it and they figure it out on the way. At the end of the Mission, four people now understand this service. They return to the launch pad and spread this knowledge and on future Missions there is more mixing and matching.
Do you think this type of methodology would work for companies that are not SaaS?
I know of one Czech bank that transitioned but I don’t know how it turned out. My friend who worked there quit because he thought the transition was going too slow. But I think it fits any model or type of company. The only limiting factors are people. When he described the transition in this bank, the main problem he described was actually changing people’s mindset.
The traditional managers were used to a very top-down management structure. Basically, they like control. When somebody comes in and says they’re going to change everything and restructure, that kind of leaves this top manager hanging. There is very little room for traditional mid-level and upper management in this type of system so they fight against it. It is not transparent that somebody is blocking it but they will silently block any progress and change.
At what point of a company’s lifespan do you think that they should consider adopting a new methodology?
One important aspect of Tribes and Missions is separating deep focused work, when you are building new things and you need to really focus, from ad hoc work. When you’re writing code, especially something new, I think statistics show that you spend only 20% of the time actually writing the code and 80% time thinking about it. So you are mostly reading code, drawing on a whiteboard, talking to people and wrapping your head around the problem. This requires deep work. The moment somebody asks you to pull data from a database or asks a customer support question, the context and focus are lost.
In Pipedrive when we switched from the typical team setup to Missions, the first Mission team actually finished in 50% of the allocated time. Before, they were trying to work on 10 work streams at the same time with just six people, in addition to fixing bugs and the operational issues. So we assigned two people to work on operational stuff, and four people focused on new feature work. Then we can afford to work on four streams at once, and put the other six on hold. As a result, we could deliver much more in the same period of time. Long story short, I think even in a team of six, separating your operational work from focused feature work is already beneficial.
Do you think Tribes and Missions help connect product, UX and engineering?
Absolutely. What I’ve seen fundamentally broken is collaboration with the design team. In many companies, the design team works completely separate from the product teams, like an internal agency. They are given some design tasks, and they have their own opinion about how things should be designed. They delivered something maybe half compliant with the product manager’s requirements, and wasn’t consulted with engineers. The engineers say it is impossible. Then there’s more back and forth, and the design team becomes another dependency to fight for.
We ended up having the engineers design the solutions themselves, and it was crap simply because we didn’t have the design resources at the right time. So when you put the designers in the Tribe, and you make everyone live and breathe together, the outcomes are incredible. It worked really well in Pipedrive. If there were issues, it was typically misalignment of the organization between the engineering and product side. It’s super important to have them all together, and the more roles you can attach to a Tribe, the better.
It was totally mind opening for me when we started having a dedicated product marketing person planning with us. From the moment we started planning to deliver a new feature he was already planning the marketing campaign and using market insights in the planning process. We basically designed the product for success from the beginning, already knowing how we’re going to market it, how we’re going to launch it, what the stages are.
Have you changed any of your original thinking or structure of Tribes and Missions?
The main pillar of the original philosophy remains unchanged, but many practical things have evolved. We narrowed down the ideal Tribe size to 15 to 25. If it’s too few, you lose flexibility in terms of shifting priorities and allocating people to initiatives. If it’s too many, then the cognitive load is too big for people.
Then we looked at how we approach planning. You are always trying to predict the future and you always inevitably fail. At the same time, everybody around you expects you to put a stake in the ground and that that becomes the Holy Grail and source of truth, this release date. And this is probably the biggest stressor for everybody involved.
When we started Missions we said that we don’t want to plan the duration in the traditional way, and instead use the time box approach. Say we want to allocate six weeks for a project, and deliver as much as we can in six weeks. However, since people worked in traditional Scrum teams for too long, they didn’t switch their mindset to the time box method. They felt like it’s a deadline and they were working long hours to make it.
Only after talking to people after a few Missions, the pattern emerged that they are stressed about finishing on time. So we stopped using the word “timebox” and we decided to make an estimate after starting the Mission. We spend the first week trying to understand everything, discover all the unknowns, uncover the risks, then make the best estimate of when the Mission may end.
At the same time, some liked having an estimate for making decisions. You give the team flexibility, tell them what to deliver, give the context, how to measure success, what the business impact will be, and ask when they can deliver a meaningful version of it. They don’t need story points or anything measurable at first. We trust that they will deliver as fast as they can.
From what you’ve seen, what do you think about Ataccama’s SpaceUP so far?
I think SpaceUP is a very well-thought-out evolution of Tribes & Missions and similar frameworks. It takes inspiration from what worked well and improves what didn’t, like alignment between engineering and product organizations.
I admire the level of detail used to describe every aspect of the framework and the discipline put into documenting everything publicly right at the beginning. Having well articulated principles written down helps with general understanding and reasoning. It also helps other companies who would want to take inspiration.
Any advice for keeping on the right track with our Spaceports and Missions?
I think the best advice is to listen to feedback, learn from mistakes and constantly adapt. Frameworks like this tend to be lively organisms and they never work perfectly from the beginning. While keeping the principles in place, it should be possible to adjust other parameters to make the framework perform optimally over time.
What are your key takeaways from Tribes & Missions?
My key takeaway is that it really works and I think it really scales. It’s basically leveraging the way people naturally think and work, and putting it on scale. The principles can stay the same, and just adjust the teams. I’ve seen it grow in a company from 300 people to 900 people. We had eight Tribes at first and 20 plus Tribes when I was leaving, but the process was the same.
As I said, as a leader in this type of organization, it feels like cheating because it’s really effortless. The biggest part is to let the control freak in you go to bed. And then magic happens.
What’s your next big goal?
My next big goal is to build my own company from the ground up on these principles. And I’m very close to that. Zenbase is not my company, I’m a non-founder, CTO. But I’m the second person to be hired. So we’re really there from the ground up and I have a huge influence on how this company is being built, so that’s that’s my goal. Use this principle to build an entire company like this and hopefully see it flourish.
Want to learn a little bit more about SpaceUP? Read Chapter 6 — From iterations to tangible results: Mission lifecycle to see how our Missions and Spaceports work, as told by our VP of Product Management Tomas Porazil.
Brand new to SpaceUP? There’s no better place to start than on the first chapter! Head over to Chapter 1 — Does It Scale? Why We’re Rethinking our Engineering and Product organization by our VP of Product Strategy Martin Zahumensky to get up to speed.
