Transferwise was formed in 2011 out of frustration with the expense of sending money overseas. Unlike the banks, we display our fee upfront and deduct it before currency conversion. We use the mid-market exchange provided by Reuters with no mark-up, so there are no nasty surprises for customers.
We’re happy to boast that the service is up to eight times cheaper than using a bank. And it’s chimed with the market — we now have over 2 million customers and we move over £500 million a month globally.
Growth has been rapid in the last few years — not only do we now have over 2 million customers, we’ve also scaled up from 60 to almost 1,000 staff. So a few things have changed in the three years since I wrote this blog post, but many have stayed the same. This post is a reflection on how our culture has evolved.
The Importance of Managers and Good Management
We’ve defined the objective of the TransferWise culture as “optimising for speed”: whatever enables us to move fastest towards achieving our mission.
One such enabler is the presence of autonomous independent teams. They allow us to move very quickly because we have devolved decision-making to teams closest to our customers. Our teams have all the resources within them they need to solve customer problems and move KPIs that measured their impact. This gives us incredible agility and ownership.
One of the most striking differences when I look at how we run with almost 1,000 people today against 60 people four years ago, is that we have introduced many features that you would expect from “good management”. That’s not to say we didn’t have good managers four years ago, I think we did, but what’s changed is that we’ve recognised the importance of good management, and formalised them.
For example, everyone at TransferWise has a line manager — typically within your function, but maybe outside your immediate team. So product managers report up to product leads, and engineers to engineering leads, but engineers and product managers work together in a single cross-functional team. The manager is responsible for conducting regular one-to-ones with team members, helping them with everything from execution to understanding how to help them develop; as well as agreeing objectives and reviewing their salary regularly.
How does this help us move faster? We’ve found these processes and structure give our teams clarity on where to focus and what’s expected of them. The structure we have around this feels fairer and enables easier movement across teams- it saves teams re-inventing the wheel, and we have consistency across teams.
Consistent good management helps teams move faster
Onboard With Clear Goals and Then Empower
One point that’s caused quite a bit of confusion over the last few years — is the process by which people are “onboarded” into the organisation. Personally I define someone as “onboarded” when they’ve understood what matters to our customers and how to “get stuff done” at TransferWise. In my experience very few people can “onboard” themselves. During a person’s first few month’s in TransferWise, their lead should take an active role in defining clear tasks and objectives that help them figure out what matters to customers and how to execute at TransferWise. As the individual is “onboarded”, good leads empower them as they build context.
Autonomous TEAMs not INDIVIDUALS
One of the biggest misconceptions about autonomous teams is that we have autonomous individuals here at TransferWise. We don’t. That would be anarchy. Every one of the 1,000 “wisers” in TransferWise is part of a team. The team has a clearly defined mandate, and is responsible for setting plans in its area. Teams set plans — not individuals. TransferWise is not a collection of individuals doing whatever they want to do. That would be pretty chaotic. It’s a collection of teams that have evolved with clear mandates around customer problems. Obviously individuals can form new teams, but this always involves a conversation with a lead.
Teams with clearly defined mandates move faster
The Buck Stops With the Lead
Managers can and do tell people what to do. If a team member goes rogue — say they don’t pull their weight or they decide to work with something off-plan — the team should try to resolve this with the team member. Ultimately though, their lead is accountable for resolving the issue.
Indeed, if an entire team goes “rogue” and is consistently not delivering vs their plans, the leads of the individuals in the team are accountable for understanding the root causes of the issues in the team and rectifying the issue.
Leaders taking ownership of getting teams to “work” — help us move faster
So far, so Familiar. What’s Different?
There are a few differences at TransferWise from most product organisations I’ve worked at.
Leaders Don’t Make Decisions on Behalf of the Team
Our default management style is empowering the team members to “figure it out” and set their own strategy. This may be a heavily collaborative process with the lead, or they may do it on their own. But the team, not the lead, owns the strategy and KPIs.
Strategy is devolved to the lowest part of the organisation that it can be by default. For example our liquidity team owns where our cash should be deployed — not our Finance Director. Similarly — although harsh — our VP of Engineering is ultimately accountable for all technology decisions, that doesn’t mean he makes all our technology decisions. Apart from decisions to hire and start new teams (e.g. business and borderless) and shut down teams, I’ve never made a decision in product.
At times a lead may need to step in and set direction, but this is only if a team has proven it is incapable of doing so itself, or if there are reasons we need to move quickly on a topic.
Empowering teams to make decisions helps us move faster, as leaders quite quickly become bottlenecks for decisions as organisations scale. Additionally the quality of decisions made by leaders erodes as the complexity and scale of the product increases.
This doesn’t abdicate leaders from understanding what teams are doing, and challenging them if they are going down what they believe is the wrong path. But they shouldn’t decide for the team what to do as their default modus operandi.
Leaders empowering by “default” helps us to move faster
Teams can Work Across the Organisation
Teams work across the organisation to make changes to the product to achieve their missions. For our borderless product launch, the product manager had to work with almost every team in TransferWise from customer support to legal. They have the mandate to do whatever it takes to move their product forward, and need to work collaboratively with other teams to make this happen.
The rationale for this approach is that it’s the fastest way for us to move forward and stops the need for centralised planning and prioritisation of multiple dependency projects
Teams owning customer problems help us move faster
Teams are Self Sufficient
Our teams are self sufficient. They have all the resources within the team they need in order to have an impact — e.g. marketing teams have engineers within them, or product teams have designers. This single change has probably given us the greatest driver of our speed of movement in the last four years, in comparison with other organisations I have worked in.
Teams having all the resources within them they need to execute helps us move faster
Constraints
We’ve done remarkably well at working with constraints that run across the organisation. For example we’ve operated without the central allocation of a marketing budget since our launch. Our marketing teams have defined their pay back period, and challenge and support each other across teams.
Teams able to put Customer > Team helps us manage common resources efficiently
Challenges Ahead
Team’s rarely shut themselves down and admit failure. They also take too long to do this “autonomously”. Frequently (but not always), this needs some form of “management intervention”. When it comes to failure, the team, or indeed ego, can matter more than customers.
Another area where we’ve made only a little progress is in how teams understand the trade-offs between investing in their own objectives against supporting other teams in achieving theirs. We have the capacity to onboard 100 engineers in the next 12 months — but to fully staff the plans that our teams have proposed we will probably need 150. We have very few examples of teams reading through other teams’ plans and switching focus and joining them to achieve a greater goal.
Helping teams to understand the helicopter view of where our volume will come from in the next 12 months is not a muscle we’ve developed particularly well. However, to enable them to better prioritise across teams, it’s one we need to get stronger at. Until we do, I expect those with such information to share context and sometimes even “tell” teams where to focus.
As always, these “tells” will be open to challenge / iteration — but the danger in not doing this is that we spread ourselves too thin and miss the bigger opportunity.
