Markets around the world are dominated by large incumbents with a ton of market power – whether it is media, logistics, e-commerce or finance. For a startup to succeed at a busy market they need to out-execute all the incumbents by an enormous margin.
Why is it that only 1 in 100 startups ever succeed after raising $5m in series A? They always have a good idea that could work. Where startups fail after Series A is execution, specifically the speed of execution.
No startup, no disruptor, has ever succeeded with a mere average execution speed.
You have heard this meme, coined by lazy people, which argues that as organisations and teams grow in size, they inevitably get slower and less productive. That’s of course just an excuse to avoid thinking about the hard problem – how to keep the speed as the size of the team grows.
When our TransferWise engineering was less than 10 people, we worked as one team – single roadmap, one prioritisation, common weekly standups. This worked only for one year – until 2012. Since then we had to learn how to parallelise, how to create independent, autonomous teams.
I wrote about this challenge when we hit 100 people, when we established the core principles of our method. [link] Now that we’re 1200 people in 9 offices, of which the product engineering team is 350 – it is worth taking another look at what we’ve learned.
In a product company, when you solve the product development speed, you’ve solved the “execution speed”.
Over time the best measure of our product development speed has been the number of independent teams, who can execute autonomously. There are other drivers, like how experienced a particular team is, how they get along, and so on.
TransferWise is no special startup – it too will only succeed, when it out-executes the incumbents by an enormous margin and keeps going faster than the younger startups coming from behind. That’s why we have 35 independent autonomous teams, think of them as startups in a startup. That’s why we’ll have 50 autonomous teams by the end of 2019 and 65 by the end of 2020.
Our overall execution speed comes from every one of our 35 teams today moving their KPIs at the same speed or faster than the original 3 teams in 2012. It is the sum-total of each of our teams, plus the benefits from a common infrastructure that is already built – e.g. how to spin up new services, test environments, databases. The common infrastructure is not just technical, it’s also funding – instead of each of the 35 teams fundraising, we do it once for everyone. Instead of each team putting overhead into payroll, finances, offices, travel expenses, we do it once for everyone.
This is a snapshot of our autonomous teams. Although not all here are product teams, i.e. won’t have engineers. About 35 are complete product engineering units.
Four forces to help get started with autonomy
How does it all come together? How come this doesn’t become chaos? There are four kinds of glue, which bring the teams together. In addition to those there are many other challenges to solve: how to arrange communication effectively, how to inspire teams to peer-review each other’s work and plans, how to allocate resources, e.g. new engineering hires, across teams. But getting these four common forces right is the basis for anyone to establish autonomy in the organisation.
1. Mission
Clarity of our intrinsic common mission ties the teams together. The product teams earn their birth-right offering substantial impact on the TransferWise mission. They measure themselves against that impact. Engineers and designers compare the teams by their impact – where do they want to spend the next year of their life working. If a team can’t inspire engineers and designers with the impact — that team will not succeed.
2. The code base
When we launched TransferWise in the USA in 2014 after being live in Europe for 3 years, there was some brief discussion of whether we should fork the site and the app. Luckily this idea was short-lived.
A big reason why we can be as efficient as we are today – is thanks to having a common codebase. It works for individuals, small businesses, large businesses. It works the same in Japan as it does in Brazil. It looks a little different and feels a little different – but it is mostly the same thing solving the same problem.
But it is also 3 million lines of code. In 2014 it was still literally one github repo and a single monolith build. Now most of it has been stripped out to 110 more manageable services.
The solution for us to enable 35 teams collaborate over the 3 million lines of code is weak ownership. It effectively means that every line of code is owned by a team, but everyone else is invited to contribute to their code base – provided they ask for a code review and take feedback.
Learning a new domain and working on someone else’s code takes mental investment and is not most efficient, but it guarantees that no engineer gets blocked in whatever the team needs to build to advance their KPIs and their part of the mission.
Each company can have a different recipe. Establishing the rules how multiple teams can work across a same code base will be the basis of autonomy.
3. User experience
When multiple teams are involved in building aspects of the same product – in our case a digital product, one will need some method of avoiding the UX becoming the work of doctor Frankenstein.
For example, we recently launched the Borderless international account with multi-currency balances and then added a debit card to it. Suddenly we have some visitors looking for these new debit cards or international bank accounts, but at the same time a huge population of visitors just needing to get their money from bank A to bank B with as little fuss as possible.
As you see from this example, we’re still working on a solution to this challenge – how to empower number of independent product teams iterate on a common user experience, which might initially seem that have conflicting goals. At the end of the day all the teams stand for the same mission and ultimate goals, there must be a way how the most optimal user experience would naturally evolve.
4. Balance sheet
When autonomous teams have figured out how to establish a common mission and then split it down to independent sub-missions, once they have worked out how to iterate on the same code base, they have a way to build the common user experience – they will meet each other on the common balance sheet of the company.
There is an immediate question of common resources: which team should get the next joining engineer? This one is relatively easy to solve rationally. While a new engineer might help that team go faster, there should always be an objective agreement across teams about where the next pair of hands would have the most impact on the ultimate mission. In addition, engineers come with pre-existing experiences and may be more effective in one team than the other. Most importantly they come with their preferences and usually get to choose which team they believe, they’ll have the most impact in.
It gets a little trickier with the revenue side, in our case with pricing. Because part of our mission is to make moving cross-border money cheaper, in order to achieve that we’ll have to gradually lower the fees we charge. Many teams have price drops in their mission. But how much, how fast can they cut the fees without hurting other teams? For example – our balances team learned from their user feedback that our balance-holders really don’t like paying for same-currency payouts from their TransferWise balance. Of course, lowering fees related to handling money is part of our mission, so the balances team removed payout fees. As a result our Europe team was told by the finance department that they now need to increase the money transfer fees – because they are not covering the cost of making same-currency payouts. Oops.
Devolving pricing into autonomous teams is still the right approach – people who can impact the costs, should also get the benefit of being able to pass savings back to their users. However it has to be orchestrated as we’ll be working from a common balance sheet and you want to avoid the outcomes where one team’s price drop will become another team’s price increase. Our costs align really well with currencies, as do some of our teams – so price-setting has become a job for currency-owning regional teams. In order to enable them to do it safely, we’ve developed our common unit-economics by currency, which I’ve previously described in this blog post.
Are autonomous teams the only option to get execution speed?
Most likely not. Big and successful organisations have been built in the past using different models – through “managing by P&L”, by little armies of effective Napoleonic commanders, franchises, subcontracting and many more ways. However in many of the historic cases, these companies were built to the size they are now over many decades. In the era of tech startups, all these timelines are much faster and we haven’t yet seen anything reach execution speed faster and more comfortably as autonomous independent teams.