Presentation: Cultivating High-Performing Teams in Hypergrowth

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.

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.

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.

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.

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.

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.