A couple of months ago I wrote about remaining a startup with 100+ people. Today we are nearly 300 people and having an ever better appreciation of what being a startup means.
Startup is defined by growth. Growth is generated by the speed of the organisation … with a bit of luck. There is luck in the original idea, the supporting market condition, in the people who come together around the idea. Optimising for luck is near impossible. Hence the success of the startup after it has reached its first fragile product-market fit is determined by the speed at which the organisation can evolve the product and engage customers.
Speed of the organisation isn’t trivial. We have lots to learn from the 5-10 person pre-money startup teams, who are super focussed on their mission and are dedicating their every brainwave to making the product a success. These teams move incredibly fast. How to retain that same speed with 300+ people?
In theory one would think that you just split 300/5 into 60 of 5-person teams and that’s it. Why has no organisation quite done this? We have. With 47 teams, every team is working like a little well-funded startup.
We have distilled the magic down to autonomy and focus. The teams’ sense of ownership and ability to act independently. The radical framework is that teams don’t own product or product features, but they own the “levers of success”.
Speed is not about working faster. Speed is about working smarter.
How does it work
Over time we have figured out what people want from an international money movement product. Some of those things are obvious, such as speed, low cost, more currency routes, easier payment methods, a convenient experience.
Each of these is a “lever of success” – moving any of these levers, will get us closer to our mission of truly international money. Moving them all together will make sure that it will be us leading the revolution.
The beauty is that each of these levers are independent and measurable. Hence we have a team that works independently on nothing else, but the speed of our payments. Another team, who delights customers on new currency routes and so on. Every team is keeping everyone else up to date with their success in weekly heartbeat reports.
The setup, where teams are organised behind the KPI seems rare. Usually teams look after a function (design, sales, operations), a platform (eg iOS, web) or a portion of product defined by its codebase. We are yet to see how this works, but already seeing some of it being more successful and challenges emerging too.
Successes
Some aspects of our KPI driven autonomous teams have been a pleasure to observe:
People know exactly why they come to work
It becomes very very very obvious how you and your small team make an impact to the customer. In fact you can objectively measure the impact that you made last week. Motivating.
No project managers, no committees, less meetings
As it is so clear, what is the team’s mandate and as they have independence, there is no reason why anyone outside of that team should worry about what they are doing and how they are doing it. As they show month over month how they are making positive impact on their KPI and in turn to the customer, they will decide themselves what they build and when they build it.
Works in sync with the weak code-ownership model. The code is split by teams, who look after the overall design and quality of their piece. Anyone can commit code to other team’s code base, but if the team doesn’t like it, they might revert. Makes sense to discuss substantial changes beforehand.
No top-down command structure
As the team is clear what they need to do, the rest of the organisation don’t need to help them decide or agree with their plans. The main input comes from the peers in form of healthy challenge to the team’s assumptions and hypothesis. At the end of the day it is totally up to the team what they’re going to build.
People measure their success
It is powerful for building confidence. Imagine you have come up with an initiative, you can see the benefit in your metrics, and you’ll feel invincible.
Congregation of skills
Teams need to be full-stack in its broadest meaning. Between the 5-7 people, they will need to be able to deliver measurable value to the end customer. Like a little startup.
Challenges
Some of the things have come in a hard way with lot of soul searching. Some teams are still in the process of figuring it out.
Defining metrics and measuring
Some things are great to measure, others are very clear in abstract concept, but much harder to measure. For example, the product and service should create a sense of “trust”. No brainer, but how do you measure it? Through conversion rate maybe. Yet then you ought to be really careful to find a stable traffic channel where you see the changes in product presentation to have direct impact on conversion.
Product metrics versus engineering goals
Inevitably there is some pure engineering work that doesn’t have direct impact for customers, but will definitely make sense to do. For example, anything around common test-build-release harness will add speed to every team, but only indirectly to customers.
There is an easy option of creating “internal” KPIs and then a separate team who works on these internal improvements. We have taken an alternative approach. The product team who benefits most from the speed improvement will at some point prioritise the development speed over product metrics
Internal functions
We have 3 centralised functions: finance, HR & office admin, server infra. Each of those teams are 3-4 people, all together make up less than 5% of the company. These teams currently don’t have “success levers” yet and can’t really measure their impact. Maybe they will remain the teams, who are here to make sure we don’t f*ck up.
Choosing your team
As it became transparent how each of the teams are having impact to the customer, people start thinking actively, where they personally can have the biggest impact for customers. No wonder then that people move teams.
Country teams
This must be a common problem. You get to the junction, where it makes sense to break out country specific teams, who kinda own all the levers in the context of that country. We went through that, when we opened up in the US.
Vision
Where does product vision come from? There is a common vision – effectively, what we believe the “levers” are that matter to success. And then each of the teams will have to create a vision how they will have the biggest impact on their chosen lever.
Critique
1. Numbers focus. We can’t see the customer behind the numbers. We’re building for the KPI, but not for the customer.
2. Consistency on the front-end design. While different teams are working on different parts of the user experience, there is a real danger that the designers in the teams will be pulling in a different direction. People who optimise for trust and first time experience get to one result and the other team who drives ease of recurring usage, get to conflicting user flow
3. “You need to make it really clear what is expected from a role”. No you don’t. You need to be clear on the context and let everyone else figure it out.
Ah, did I mention that we’re on the lookout for engineers, product managers and designers to add fuel to the fire.