Presentation: Cultivating High-Performing Teams in Hypergrowth

Track: Building High-Performing Teams

Location: Empire Complex, 7th fl.

Duration: 1:40pm - 2:30pm

Day of week:

Slides: Download Slides

This presentation is now available to view on

Watch video with transcript

What You’ll Learn

  1. Learn about how hypergrowth in a startup fintech company looks
  2. See how to cultivate high performing teams in a hypergrowth environment.
  3. Find out how people can work together in a place where it's rapidly growing and changing all the time.


N26 is on a mission to build the bank the world loves to use. Not only is its customers rapidly growing (from 450K to 2.3M in under 18 months) but the product and tech team has almost quadrupled in that time to more than 250 people. In this talk, Patrick will share lessons learned sowing the seeds and fertilising an environment to cultivate high performing teams in a hypergrowth environment. We will look at balancing structures to maximise autonomy and alignment, explicit trade-offs in centralised versus decentralised thinking and how we’ve managed to rapidly expand a team and still ship product at a rapid pace.


What’s the motivation for this talk?


The motivation of the talk is helping people understand how to get the ideal environment set up for high performing teams in a hyper growth startup. I've worked in agile ways for about 20 years and built high performing teams, but when I was in my previous role as a CTO you're not actually a part of a single development team. It's very hard to then help build that team. You're kind of responsible for the environment. And the question is, as you do trust and hire people that are going to build a high performing team, what can you do to actually influence and create an environment where it's more likely people can build a high performing team? How do you enable that effectively is the essence of my talk.


How would you describe the persona and level of the target audience?


It’s people who are leading technical organizations that are rapidly growing. Maybe you are a startup, about to hit scale up, like we've gone into hyper growth mode. Perhaps you're already a scale-up organization and you are the CTO or a V.P. engineering or other technical leaders who are trying to create the right environment. It’s actually targeted at managers of managers, effectively people who are one step removed away from a particular team and responsible for the environment which other sets of teams are going to be working. Quite a senior audience that we're hoping to impart some advice and tips about what our journey has been like where I feel we've created a good environment to build high performing teams.


What do you want this persona to walk away from your talk with?


I want that persona to be more intentional about decisions they make and understanding the consequences. One thing I've learned as a software architect lead in my past is that a lot of choices at an architectural level are about tradeoffs and the same thing can be said about social and technical organizational structure. How do you create team structures that enable collaboration instead of creating conflict? These are things that managers are typically responsible for and particularly managers of managers at a higher level.

I want people to come away being a lot more explicit about what are they actually trying to optimize on in their environment, and give concrete ideas about options they can actually use. One of the other concrete takes away is actually a tool that I created called a Target Operating Model. This is a common vision for how an organization can work together particularly in a place where it's rapidly growing and changing all the time.


Given your previous role as a CTO, I was wondering if you could comment on how much impact the technology choices you make at N26 feet into the culture?


Technology choice is super key for enabling high-performance teams. One of the old sayings I repeated to everyone when I first joined is, “Why do we hire bright intelligent people, who are willing to learn and want to solve problems, only to turn around and tell them what to do?” As a manager what I'm trying to do is create the best environment and that includes good tooling that allows people to solve that problem.

One of the interesting challenges at scale particularly in a rapidly growing company and a rapidly changing industry is that the tools change all the time as well. And people obviously have preferences for different tools so part of the art is trying to keep up to date with tooling but also try to not have too much variation in tooling. I have a theory about entropy and how much an organization can sustain entropy and every change might add more entropy which can tip it into an overload.

We want to really equip our engineers with good tooling so they can focus on solving business problems and customer needs. We're a very modern bank. Actually we're more like a tech company who works in finance rather than the bank that you might traditionally think of. We do more than a hundred deployments into production each week which is unheard of in a very traditional banking environment. Normally you're lucky if you could play every three months right. This allows a really nice feedback loop for a team that helps building a really strong engineering culture of both connecting output of what a person creates to a customer need and immediate impact as well.

Then obviously the tooling around that is super key. Some concrete examples are that we use modern cloud infrastructure, and everything is with infrastructure as code. It means that we can actually spin up new environments and services or scale things really rapidly if we need to. We have a very strong continuous delivery pipeline and continuous delivery culture. We have a lot of quality built into our process which means we don't have to rely on the armies of people traditional banks need with checklists and process and then of course when something goes wrong you need more people to check the people with the checklists which ends up too much unneeded bureaucracy. We've really focused on good automation and building that into our ways of working as well. Our engineers get really fast feedback. It gives them more context and it helps people fail faster. That helps to build a really good engineering culture.


How much autonomy do teams of individuals have at N26?


Autonomy is an interesting one right. What we've tried to do with our operating model is really maximize autonomy and alignment. Those two things are always hard and key and I think one of the interesting things is trying to help people understand the boundaries of autonomy where they can focus on their autonomy being aware that everyone's autonomy is limited at some point.

For us, we're regulated by laws. Our autonomy as a company is bounded to a certain degree. From a team perspective, we tried to create domain-based focused products areas and teams have a lot of autonomy in terms of how they shape the services and functions or features in that product area. Then obviously they might work with another group who has a dependency and autonomy becomes a little bit harder but then they can actually also choose how they'd like to work. We're not religious about which agile practices people use everywhere. Some teams like to use Kanban because they focus on flow. Other teams are a bit more iterative based using XP or Scrum where they do planning and then they do review and retrospecting. There's a lot of autonomy in how teams work.


How do you go about growing leadership?


I run a tech lead development program internal at N26 that people who are existing tech leaders or seniors will go on. A lot of the skills that are required to lead a team are actually quite different and orthogonal to what an engineer normally is focused on. We actually run a course where we talk about the expectations where we go through different goals and then we equip people with different tools to actually help them get better at that. That process is also about creating a community of people who can then reach out to each other and ask for support when they're dealing with a very difficult situation.

Speaker: Patrick Kua

Chief Scientist @n26

Patrick Kua is the Chief Scientist and former CTO of the modern bank N26 (Berlin, Germany), who are on the mission to build the bank the world loves to use. With almost 20 years of experience in technology, he spent a majority of his time as a Principal Technical Consultant at ThoughtWorks helping organisations evolve their software and organisational structures to better evolve software. He is the author of three books, The Retrospective Handbook, Talking with Tech Leads and most recently, Building Evolutionary Architectures. Patrick is a frequent conference speaker, blogger and is passionate about bringing a balanced focus between people, organisations and technology.

Find Patrick Kua at

Similar Talks

Are We Really Cloud-Native?


Director of Technology @Luminis_eu

Bert Ertman

The Trouble With Learning in Complex Systems


Senior Cloud Advocate @Microsoft

Jason Hand

Making a Lion Bulletproof: SRE in Banking


IT Chapter Lead Site Reliability Engineering @ingnl

Janna Brummel

What Breaks Our Systems: A Taxonomy of Black Swans


Site Reliability Engineer @Slack, Contributor to Seeking SRE, & SRECon Steering Committee

Laura Nolan

Scaling Infrastructure Engineering at Slack


Senior Director of Infrastructure Engineering @Slack

Julia Grace