TransferWise has grown from 10 to 300 product engineers in 6 years. When building a new product, nobody has the answers. Scaling decision-making is all-important. This talk explores some key tenets and painful learnings of product engineering in autonomous teams.

1. Scaling autonomy in a
FinTech unicorn.
Alvar Lumberg
WeAreDevelopers 2019

2. Alvar in 1 slide:
6 years at TransferWise:
Lead Engineer
KYC Engineering Lead
Platform Engineering Lead
Before that:
Banking
Contracting
Telco
🏃Likes running, far and slow
I ❤ coding but building
teams is pretty cool, too

3. Who are you all?
! How many are developers?
Do you spend most of your time coding?
! How many are product managers/owners?
Are you the one filling the backlog?
! Do you have skin in the game?
Do you directly benefit if the product you're building is successful?

4. Our program today
1. TransferWise in a nutshell
2. Autonomous teams - why and what?
3. What does this mean for engineers?
4. Short evolution of TransferWise systems
5. What have we learned?
6. Takeaways

5. Let me tell you about
TransferWise, real quick.

6. Figures
Founded 2011
5M customers
£4B processed monthly
70+% y/y growth
1600+ people
12 offices across the globe -
Tallinn, London, Budapest,
Tampa, Singapore, NYC,
Cherkasy, ...
Hiring 750 more in next 12
months
People

8. £1 bn saved for customers last year

9. This is all very cool. Who's
the mastermind?

11. How are successful startups built?
You learn as you go.

12. Growth
is constrained by
velocity of product improvements.
Velocity of product improvements
is constrained by
speed of learning.

13. Speed of learning
is constrained by
speed of decision-making.

14. Wait! 👮
With so many deciders, are we moving in the same direction?
...in the right direction?

15. Fair, transparent and eventually free.
Price
International bank transfers are slow.
We're doing much better.
Speed
You want your money to move, not to
fidget with another app.
Convenience
We support your currency and your
use case.
Coverage

16. Tenets of autonomy for
engineering.

17. Scary amounts of freedom and responsibility
! Everyone makes product decisions
PM falls ill or switches teams. Engineers need to figure out what to work on next.
! Everyone asks "why?" a lot
It's easy to rely on assumptions or old habits. When people support each other and
peers with questions, team gets a better result.
! You build it, you run it
No Ops team to hand over to. Engineer's responsibility ends when they remove the
feature from production.

18. Weak Ownership Model
! Engineers make the changes you need, across the system
Need to be ready to work with other people's code.
! Engineers are responsible for all aspects of the components they own
As an owner, you discuss design proposals and review pull requests
! ...but bus factor must be kept high
Components are owned by teams, not people

19. TransferWise system evolution
in 5 minutes.

20. History of TW technical evolution
Building larger
functionality outside
monolith and pushing
modularisation of
monolith to separate
services.
Event-driven flows.
2011 - 2014 2014-2015 2016 onwards
Monolith -
Integrated
customer
experience, back
office/admin
First step to
Modularity -
separate front
end & back
office/admin
Modularisation
effort for moving
data out of
masterDB to
service DBs
2018 Q1 onwards 2018 Q3 onwards
Migration to
AWS /
Kubernetes

21. Started where most products do
DB
Groovy on Grails Monolith
(user experience, back office/admin
tools, business logic)
Hibernate
Banks
Third parties
Accounting
Easy to work in a monolith in early
stages - work across the code base
and have less moving parts to ship.
No use building a complex modular
architecture when we don’t know if we
are going to be successful.

22. 2015: Separate back office & customer facing experiences
DB
Groovy on Grails Monolith
Hibernate
Banks
Third parties
Accounting
Customer
experience
Admin
Backoffice
processing
Common library
With number of engineers
increasing and growing codebase
it was getting harder to ship the
monolith.
Build times got longer and many
people working on the same
code case caused more
breakages.
So our first step was to break up
the back office and customer
facing experiences.

23. On our way to something roughly like this:
Kafka
TW Front end apps TW Back office Mobile apps
API gateways
Svc a Svc b Svc c Svc d... Svc e
Partner banks
Direct API
integrations
...
Async 3Async 2Async 1 Async 5Async 4 Async 6 Async 7...

24. Stats
300+ engineers
40+ teams
30+ people in Platform team
160+ microservices
~100 deployments per day

25. What have we learned?

26. Every component needs an owner
! As teams split and focus, things fall between the cracks
Tragedy of the commons and broken window syndrome.
! Components without owner rot, fast
Design and quality deteriorate if many contributors but no owner
! Strong ownership required for long term architecture vision
We ended up dragging along hairy legacy components

27. Making big tech changes is hard
! Getting teams to invest in cross-team efforts needs time
Everyone has their priorities and plans. Reasons and expectations must be clear to
gain traction.
! Even with buy-in, need to make it easy to get everybody going
Teams may know they need to do something but it needs to be easy to do the
right thing. Compile guides, provide reference implementations, automate as much
as possible.
! Big changes across the system need someone to own the change
Even if a change is obvious, need to follow up across all teams. Project
management 101.

28. Central teams are needed for some things
! We ran an underpowered Platform team for a long time
Still paying heavy price for tech debt.
! In a serious business, you need to unify and control the zoo
Audits and security gets painful if you don't have the big picture
and solid processes in place.
! Platform technologies, Security, Engineering Experience
...are some central teams we've started for governance or
efficiency

29. Effective autonomy requires leadership
! Autonomous teams need strong leads
Their responsibility - keep tech tasks on the radar and stay strong on
ownership. We've seen teams struggle without strong leads.
! Top engineering leadership must provide clear priorities
Many parallel must-do threads - this for security, that for reliability - here,
top-down priorities help
! As much as needed, as little as possible
Teams should retain control over their product and technical roadmaps, but
leaders push when teams get stuck.

30. This was too much,
just give me the juicy bits!

31. Think along, ask why,
and increase your impact 💪

32. You're still engineer first,
everything else after.

33. Thanks.
@alvarlumberg
alvar@transferwise.com
All images public domain CC0