A couple of months ago, I wrote about remaining a startup with more than 100 people; today, our company, TransferWise, has nearly 300 people – and an even deeper appreciation of what being a startup actually means.
A 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, in the market conditions that support it, and in the people who come together around it. Optimising for luck is almost impossible.
That means that, once a startup has reached its first fragile product-market fit, its success is determined by the speed at which the organisation can evolve the product and engage customers.
Organisational speed is not trivial. We have a lot to learn from the five-to-ten-person, pre-money startup teams that are intensely focused on their mission and devote every brainwave to making the product a success. These teams move incredibly fast.
The question is: how do you retain that same speed with more than 300 people?
In theory, you might think the answer is simple: divide 300 people into 60 teams of five, and that is it. So why has no organisation quite done this?
We have.
With 47 teams, each one is working like a small, well-funded startup.
We have distilled the magic down to autonomy and focus: the teams’ sense of ownership and their ability to act independently. The radical framework is that teams do not own products or product features – 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: speed, low cost, more currency routes, easier payment methods and a convenient experience.
Each of these is a “lever of success”. Moving any one of these levers gets us closer to our mission of truly international money. Moving them all together ensures that we will be the ones leading the revolution.
The beauty is that each of these levers is independent and measurable. So we have one team working independently on nothing but the speed of our payments. Another team delights customers by opening new currency routes, and so on.
Every team keeps everyone else up to date with its progress through weekly heartbeat reports.
This setup – organising teams around KPIs, or key performance indicators – seems rare. Usually, teams look after a function, such as design, sales or operations; a platform, such as iOS or web; or a part of the product defined by its codebase.
We are still seeing how this works, but already we can see some of it succeeding – and some 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 obvious how you and your small team make an impact on the customer. In fact, you can objectively measure the impact you made last week. That is motivating.
No project managers, no committees, fewer meetings
Because the team’s mandate is so clear, and because the team has independence, there is no reason for anyone outside that team to worry about what it is doing or how it is doing it.
As teams show, month after month, how they are making a positive impact on their KPIs – and, in turn, on the customer – they decide for themselves what they build and when they build it.
This works in sync with our weak code-ownership model. The code is split between teams that look after the overall design and quality of their own areas. Anyone can commit code to another team’s codebase, but if that team does not like it, it may revert the change. It makes sense to discuss substantial changes beforehand.
No top-down command structure
Because the team is clear about what it needs to do, the rest of the organisation does not need to help it decide or agree with its plans.
The main input comes from peers in the form of healthy challenges to the team’s assumptions and hypotheses. At the end of the day, it is entirely up to the team what it is going to build.
People measure their own success
This is powerful for building confidence. Imagine you have come up with an initiative, you can see the benefit in your metrics, and you feel invincible.
A congregation of skills
Teams need to be full-stack in the broadest sense. Between five and seven people, they need to be able to deliver measurable value to the end customer – just like a small startup.
Challenges
Some things have come the hard way, with a lot of soul-searching. Some teams are still in the process of figuring them out.
Defining metrics and measuring them
Some things are easy to measure. Others are very clear as abstract concepts, but much harder to measure in practice.
For example, the product and service should create a sense of “trust”. That is a no-brainer – but how do you measure it?
Through conversion rate, perhaps. But then you need to be very careful to find a stable traffic channel where you can see whether changes in product presentation have a direct impact on conversion.
Product metrics versus engineering goals
Inevitably, there is some pure engineering work that does not have a direct impact on customers, but still definitely makes sense to do.
For example, anything around a common test-build-release harness will add speed to every team, but only indirectly benefit customers.
There is an easy option: create “internal” KPIs and then set up a separate team to work on these internal improvements. We have taken a different approach. The product team that benefits most from the speed improvement will, at some point, prioritise development speed over product metrics.
Internal functions
We have three centralised functions: finance, HR and office administration, and server infrastructure. Each of these teams has three to four people and, together, they make up less than five per cent of the company.
These teams currently do not have “success levers” and cannot really measure their impact. Maybe they will remain the teams whose role is to make sure we do not mess up.
Choosing your team
As it has become transparent how each team has an impact on the customer, people have started thinking actively about where they personally can have the biggest impact.
No wonder, then, that people move teams.
Country teams
This must be a common problem. You reach the point where it makes sense to break out country-specific teams that, in a way, own all the levers in the context of that country.
We went through this 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. Then each team has to create its own vision for how it will have the biggest impact on its chosen lever.
Criticism
1. Too much focus on numbers
The criticism is that we cannot see the customer behind the numbers – that we are building for the KPI, not for the customer.
2. Consistency in front-end design
While different teams work on different parts of the user experience, there is a real danger that designers in different teams will pull in different directions.
The people optimising for trust and the first-time experience may arrive at one result, while the team focused on ease of recurring use may create a conflicting user flow.
3. “You need to make it really clear what is expected from a role”
No, you do not.
You need to be clear about the context – and let everyone else figure it out.
This article was originally published by Kristo Käärmann on Kaarmann.com and was republished by Estonian World in 2015, with light edits for clarity.
