BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Harsh Sinha on Building Culture at TransferWise

Harsh Sinha on Building Culture at TransferWise

Bookmarks

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Harsh Sinha, CTO of TransferWise about deliberately designing organisational culture.

Key Takeaways

  • The organisation is structured in lots of autonomous, independent teams each one of which is focused on meeting a specific customer need
  • For a startup the biggest competitive edge is speed, and this organisation structure supports and enables speed of decision making and responding to customer needs
  • Principles such as weak code ownership allow rapid changes within clearly defined constraints
  • While this may sound like a recipe for chaos it actually results in stronger ownership and better customer focus
  • Better decision making comes about because the people who make the decisions are the ones closest to the customer problems
  • The difference between software development and product engineering.  Engineers are expected to be proactive and go deeper into understanding the customer problem, not just working from requirements but clearly understanding and addressing the real customer needs

Show Notes

  • 0:25 Introductions & overview of TransferWise
  • 1:48 Moving from San Francisco Bay area to London
  • 2:10 The innovation in the London financial technology scene
  • 2:32 Organized in autonomous and independent teams that are focused in solving customer problems
  • 3:26 For a startup the biggest competitive edge is speed, and this organisation structure supports and enables speed of decision making and responding to customer needs
  • 3:42 The best way to be successful in the market is to iterate and experiment rapidly
  • 4:07 Functional Leeds who understand the overall needs of the teams in their areas of responsibility and support those teams
  • 4:48 The importance of a consistent hiring process, but the teams make the decisions about what skills they need and who they employ
  • 5:05 Keeping the organisation structure flat – three levels of leadership
  • 5:32 Growing from 49 engineers to 190 over 2 ½ years and still keeping the structure flat
  • 5:54 Principles to enable parallel teams without getting bogged down in dependencies
  • 6:04 Explaining and giving an example of how the principle of weak code ownership helps prevent dependencies and allows rapid change
  • 7:44 The team that “owns” a service sets the rules and constraints, but other teams are free to edit and change the service within those constraints
  • 8:35 Overcoming some of the challenges that could result from this approach
  • 9:27 While this may sound like a recipe for chaos it actually results in stronger ownership and better customer focus
  • 10:16 There are some roles who are tasked with understanding what’s happening across multiple teams and providing coordination guidance
  • 10:27 There is no one decision-maker, the teams make decisions and they are trusted to make the best decision given their context and knowledge
  • 10:45 The value of a quarterly planning activity where all the teams share their plans and everybody reviews these plans and can give feedback
  • 11:10 Better decision making comes about because the people who make the decisions are the ones closest to the customer problems
  • 11:35 The value of honest and blameless post-mortems
  • 11:57 In most traditional organisations the incentives are set up to discourage risk-taking behaviour
  • 12:14 Accepting that at the pace they are moving, mistakes will happen, so find ways to make the impact of those mistakes smaller (eg rapid rollback capability)
  • 12:45 Mistakes are a learning opportunity – the post-mortem outcomes are shared with the entire company
  • 12:50 Five simple questions for the retrospective
    • What happened?
    • How many users were impacted?
    • What was the fix?
    • What did we learn from it?
    • How do we know it won’t happen again?
  • 12:10 The post-mortem practice started in engineering and has spread to become common practice in all areas of the business
  • 13:42 Keeping the number of rules as small as possible and allow the teams to
  • 14:28 The choice of development language and framework is one rule the teams have to follow
  • 15:18 If an engineer wants to propose a change to the development language or framework then they need to explain why their colleagues should spend their time learning the new language or framework and how it will benefit the overall organisation
  • 16:05 How having consistent language and frameworks enables people to move around teams and bring new ideas about different ways to solve problems
  • 16:45 Having a regular cadence of TEx sessions – Technology Exchange sessions where anyone can present new ideas and share them with the whole engineering team
  • 17:10 The factors which need to be presented when suggesting a new language or framework
    • What is the problem the new technology solves?
    • What doesn’t work in the current environment that means we need this technology?
    • How will your 150+ colleagues learn how to use the new technology and what is the learning curve for them?
  • 17:35 The difference between software development and product engineering.  Engineers are expected to be proactive and go deeper into understanding the customer problem, not just working from requirements but clearly understanding and addressing the real customer need
  • 18:13 Using analytics to help uncover the actual customer problems and getting customer feedback
  • 18:45 Sharing Nett Promoter Score (NPS) and free-format customer feedback with the entire organisation
  • 19:05 Engineers get on customer calls and respond to customer emails – they are constantly aware of who their customers are and the challenges they are facing, and use these insights to help prioritise work
  • 19:58 An example of how a problem statement is presented which the engineers then use to decide how to solve the problem
  • 20:32 This approach results in better products that solve customer problems more effectively
  • 20:47 The teams are truly autonomous, independent and empowered to make decisions
  • 21:05 The team is autonomous, not the individuals – individuals need to act as part of and in alignment with their teams
  • 21:55 Most of the decisions made in a tech company are not irreversible which gives them the opportunity and safety to change if needed

Mentioned:

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT