Cultivating High-performing Teams in Hypergrowth

Transcript

Kua: I work for a company called N26. We're in a mission to build the first bank you'll love. It's not something that you often hear in the same sentence, a bank and love. We're based in Germany, so our headquarters is in Berlin, we have a German banking license. We're coming to the U.S. this summer sometime. I want to explain the little bit of a story about how we've gone through hypergrowth, and how we managed that to create the right environment for high-performing teams.

If you're a manager, if you're a leader in this organization, you can use a lot of these techniques or think about what you can do explicitly to cultivate the right environment. Part of our mission as a bank is to build banking that's beautiful and simple to use. We've had to grow the team quite a lot because anybody who's worked in finance knows that regulation is quite difficult and you have to do things very well, but at the same time, we want to act like a startup and move really rapidly. It's the interesting realm of FinTech while trying to do modern technology, but work in a much more traditional environment.

I joined N26 in August 2017, so it's been almost two years. I joined as the CTO, and I transitioned into Chief Scientist role. Part of this is because my role as a CTO has evolved two or three times as we've gone through hypergrowth, and I'll explain a little bit more about that. My background is working a lot in software. I've been working in technology for about 20 years. I've worked in Agile methodologies for almost all of that, so I worked with OX for about 14 years of my life. I'm very passionate about retrospectives, so if you want to ever talk to me about Agile and continuous improvement, that's part of it, and you'll maybe see some of that emerge. I'm also very passionate about building technical leaders, which is super important as you go through rapid growth of making sure that you have the right management and leadership structures in place.

Another interest of mine is about building evolutionary architectures as well. If you can imagine a traditional bank and their systems they have, you don't normally think of them as being very malleable or evolutionary. When you're working in a Fintech startup, you really want to build systems that move really rapidly as well. We've been trying to incorporate all of these themes into the organization.

I do a lot of technical training as well, and this is something we've invested in as we've grown. Nick [Caldwell] in the keynote this morning talked about making sure that you grow people, but also give them the support and you'll also have to bring other people in.

Today, I will take you on a little bit of a journey. We're going to be talking a little bit about what our hypergrowth challenge was, what does it mean, what does it feel like, and how does it affect the ways that your teams work.

I want to talk about our approach to creating the right environment for teams to succeed. I've worked in a lot of different teams, high-performing teams, I love building high-performing teams, but what's interesting about my role as a CTO is that you're quite far away. I want to talk about the solution that I took on to try to create that right environment, and then I'll share some lessons learned. It's been a couple of years, we're a very different company than when it was when I first started and looking back, what are some takeaways that I hope that you can benefit from as well?

Our Hypergrowth Challenge

Let's start with talking about what hypergrowth is. One of my management philosophies around environments is thinking about what is the ground that you create? Just like gardening, you need to think about what is the fertile ground that you're operating in and what do you do to create a good condition for the garden that you have? I'm in real life a terrible gardener, so you never want to trust me with plants, but one of the interesting things about thinking about this metaphor is also in the question of, "What sort of garden do you want to build?" What is the nature of the garden that you're optimizing for and what are the characteristics do you want to have? It's very similar to how I'd think about architecture is that you want to think about what is the shape of the systems that you're optimizing for? What are the constraints and trade-offs that you want to have? These are some of the thoughts about what is the environment you want to create for high performing teams?

The common question about our company has been, what is hypergrowth? There's a couple of different definitions for hypergrowth out there, so I'll just use one of them, which was published by the World Economic Forum. When you talk about normal businesses, you typically have good growth of up to about 20%, year-on-year growth, but hypergrowth is where you're acquiring customers and growing really rapidly in revenue more than 40%. In reality, you can think of it as doubling year-on-year. That's interesting because we've been growing quite rapidly, but also that's not just about customers for us but also about the employees in the organization. If you imagine your team, your organization, what would that look like if you doubled that this year? What would that look like if you've doubled that again the year after? You get a sense of how perhaps quickly things can change. What's also interesting about hypergrowth is, as things get bigger and bigger, you can't normally work in the same way that you were working before because they start to break down at a bigger scale, and so this is one of the other interesting challenges of hypergrowth.

If any of you have ever worked in this, the analogy I like to describe it is, hypergrowth feels like you're building the rocket as it's flying. It's like your tacking on the right wings, you're trying to change the trajectory, you're trying to boost that engine as it's rapidly growing, and so there's an analogy here about a speed that's hard to control. You can't really directly know exactly where you're going to target, but what you can do is try to influence as much as possible around that.

One of the interesting things when I first joined the company that I had was that we weren't really a tech company when I first came in. If you ever worked with founders, I like to say that founders shape a lot of the culture of a company. We had two business founders. Their strengths lie in business operations and finance, but they don't have a tech background. One of the interesting things is when I came into our organization, I was, "Where are all the tech people?" We have a lot of people, but I don't see a lot of people working in tech. Probably a lot of you who've come from traditional businesses that have been maturing into tech companies, you've faced this as well.

One of the mantras I was repeating to our leadership team very early on is that ideas are really easy. One of the principles or theories I was trying to teach our leadership team was about theories of constraint. If you've studied Kanban, if you've studied theories of constraint, now that there's always a bottleneck in some value stream, and that bottleneck will be the constraint of how well you can deliver. In a lot of tech organizations, it's really the fact that you have lots of things you want to be able to do, but you never have enough capacity to do all the things you want to have.

We had a situation where we had lots of business development people, lots of project managers, all with their ideas and initiatives that they would like to have and we had a small tech team that could build and sustain and improve our product. Of course, our engineers have great ideas as well that they would like to have, so ideas are not really the problem that we have. One of the interesting things about hypergrowth in our organization was trying to find good ratios around the organization. When I first came in, I think the ratio of technology was about 20% of the overall organization, whereas a tech company, I would expect it to be a good healthy 50% of the organization.

In hypergrowth, every part of the business is rapidly growing and, you can obviously find really a lot of project managers or business development people or people with ideas, but we all know if you had to do hiring, how difficult it is to hire good engineers. It just gets out of proportion really rapidly, but we needed to start to try to bring that back into balance. This was a useful metaphor of helping people try to understand, "We need to grow technology much faster than other parts of the business because it's already out of balance." That was an interesting challenge that I had.

Let's talk about some numbers. I joined about August 2017, it's almost two years. What's happened? When I first joined, we had about 450,000 customers, we have now more than 3.5 million customers across Europe. That's quite rapid growth year-on-year. When you think about employees, we had about 400 people in the overall organization, and now we have more than 1,300 across that time frame. We started with our office in Berlin and since then, we've expanded to New York, we've expanded to Barcelona as a product development hub, and we're about to launch another development hub in Vienna as well. We also have the issue of distribution much more as well as we've grown.

In terms of tech employees, we've grown almost five times in that entire time frame. We started off with about 50, 55 people in all of technology, including things like help desk or IT support. Now we're about 280, 290 people in technology. It's a very different company now than what it was when I first started, and we've been many different types of companies along the way.

A key message about hypergrowth - and I've studied a lot about this - it's really very generous that a lot of other companies who've gone through this have published information about how they dealt with it. If you've been through this, or if you're about to go through this, do a lot of reading, there is a lot of material out there. One of the major themes of when I first came in was realizing we are no longer the startup of the early days. We're only four years old as a company, but we needed to make a mindset shift or moving from a startup mentality and we really needed to start to make sure that we thought about how do we scale up? How do we take those behaviors that are good and dynamic, early-stage startup where you need to pivot and incorporate customer feedback, but how does that scale when you're a company that's already 1300 people? It's very difficult.

In my consulting career, I helped a lot of companies across lots of different organizations, so small startups, large enterprises, like banks and governments. It's been really exciting for me to be able to build a toolkit of seeing different ways of how companies worked. One of the things that I was trying to say to people is, if we're going to move from Start Up to Scale Up, we need to think everything about people, processes, and structures that all scaled." In an early stage startup, none of that normally scales very well, because you're trying to be really reactionary.

I like to describe my role as the shakeup CTO. You had the snow globe, and you had the snowflakes that had settled into their patterns, and these are the habits that you see as a startup. If you've worked in early stages, it's like the changing priorities on a daily basis, maybe weekly, you would have people that would talk point-to-point, make a decision, and act really quickly. These are the behaviors that start to break down when you involve much more people, If you don't have anything written down, when you have more people join, they have to find out who I need to talk to understand why something got done the way that it did.

For people that were thinking about who to involve in decisions, other people who should have been involved often get excluded, so knowing who to involve in decision making process is really key if you're going to build this right environment. Part of my role was starting to prepare our organization to go through a change in culture and the habits to make sure that everything that we did started to scale. This was the interesting challenge that I had. Our business had lots of ideas, we had lots of work to do to grow tech, and I knew lots of different approaches to organization design and team theories. If you're in my position, what would you do?

Our Solution

This is an interesting solution; this is how I approached it. There are a couple of different alternatives that you can think of when you're in this situation. I've had the fortune of working in technology for about 20 years, but some people who've been on this, maybe it's their first time working in a company, and so a common approach might be just react, "I need to make a decision. I sense this thing, I have to make a choice," and then you make that change. That's completely valid and that's what a lot of startups end up having. Or, you might take a copy and paste methodology. People say, "Spotify does that, so we should copy their tribes and squad model and then apply that to our organization."

I prefer to take a much more strategic approach around this. The strategy for me is thinking about two different elements. One is, which direction do you want to move in? What does that look like? Then the second part is, how do you get there? It's not enough just to have the vision, but also what are the mechanics of how do you move the organization to a particular direction? That's the intentionality I wanted to bring into how we wanted to scale up our organization and build a really good environment for teams to perform as best as they could.

My own personal goal - and this is maybe perhaps my philosophy around leadership and management - was to create a nourishing environment for high-performing teams. This was the basis I would always return to in my role as a CTO. I'd worked as an engineer, as a tech lead, an architect in high performing teams. If you've worked in those sorts of environments, it's often the questions like, "There's these things in my environment that really niggle me that prevent me from building a high-performing team." In my role, I was that person who was to blame effectively for all of those things. One of the benefits was, I was also a person who could help change some of that and start to consider, "What are the trade-offs that I would like to make?" If you are in this position, a good question to ask yourself is what environment would you cultivate to enable this growth given the rapidly changing environment?

I'm not going to go into what is a high-performing team so much because I want to focus on what you do to the environment. To give you a sense of some of the things that I considered that I wanted to create the right environment for, there's things like Daniel Pink's "Drive," so autonomy, mastery, purpose, making sure that everyone had an individual reason of intrinsic motivation to do the best work that they could. In the last talk, they talked about Project Aristotle, which is a really great research project from Google, talking about the elements of what makes a high-performing team. There is the famous business book, "The Five Dysfunctions of a Team and Trying to Invert Them to Make Them Sure That They're Functional." Then there's a really great book called "Liftoff on Pragmatic Programmers," that talks about how you set the stage for a single team to grow that team culture.

I understand the theory, I've practiced this, and I've tried to help build a lot of teams that I've worked on. The challenge that I had is that we had a lot of people and when you're part of a team, you can help that team form and cultivate. You can directly influence based on your actions and interactions. The issue that I had is that we had lots of people, and I couldn't spend the time interacting with every single team. This is exactly what a good leader should also do. If you're doing that, you're probably not being a great leader, you need to grow other people to take care of and build that, so I needed to build trust in my leadership team and management team of engineering managers and tech leads to try to create and allow them the space to do that.

I go back to Admiral Grace Hopper who has this wonderful quote of "You manage things and you lead people," We wanted to lead people to great outcomes and it was my responsibility as a CTO to manage the system in which they work. There were things that we needed to change in our system.

The way that I approached this was really thinking about looking at the current system. This is about observing the current state of where we are. That's one of those things that I learned as a consultant. If you're a consultant and you come in and you say, "Here's what you should do," without considering your current context, it's probably not going to be the right solution for that organizational team. I really wanted to spend time thinking about and hearing what are the issues that our teams have that prevent them from being high performing. What are the elements that are they saying that would help them be even more performing, even though they are performing well, and they could do even better?

Once you understand what the current situation is, you then want to start thinking about, what are your options? What are approaches that can influence these things, and help you make the right choice that you're orienting? This is where you then need to decide and say, "Here's what we're going to do. Here's the strategy, here's the steps that we're going to reach to meet a strategic vision." Then, obviously, you have to follow up and act. Like everything, it's not really a singular element is that you need to go through this, and this is really John Boyd's OODA loop, This is a continuous loop of observing, orienting, deciding, and acting and this is the approach that I took at an organizational level. I would do this at an architectural level looking at systems, but what I'm looking at is really the system of people and the interaction, so think about, "What can you do to maximize the right environment for high performing teams?"

Your question here is probably, "What did you do as part of that?" Practically, what this meant was running a lot of retrospectives with different teams. One of the first things I did when I came in was I spent time with each team, we did a retrospective around the general organization and environment, what was working well, what was going less well, and trying to understand what are the common themes that started to emerge from team to team? What was within the influence of a team to affect, or what was slightly outside of their ability to influence that was more responsible about the system in which they were working in?

Another real key tool was working with one-to-ones as well. It's a good management trait to have, which is to have time with individuals. When I first came in, I think I inherited 12 direct reports. By the time that I had transitioned and hired successfully, I ended up with about six teams. It was pretty intense for a lot of periods of time, but one-on-ones are really invaluable particularly if you're listening to what people are talking about, If people are bringing up the same pain points again and again, across different parts of the organization, you can listen to that and say, "These are the things that we need to systematically improve that will allow people to be even more high performing."

Through these two tools in particular, it was starting to look at where are the gaps? My understanding of what a high-performing team should be versus what it could be, so what's the gap that we're trying to resolve? To come up with an idea about how to improve this, we introduced something called the target operating model. This has been a tool that we've really tried to focus on about the intentionality of how we want it to work as we move forward, and we'll talk about how we've implemented this.

To break this down a little bit, let's first talk about what target is. This is really about where do we want to be. This is interesting because in hypergrowth, we know that we're going to grow really rapidly, so what works for one person won't work for a team of 8 and what starts to break down in a team of 8 when it gets to 12 or 15, you need to keep transforming that. One of the expectations that we also had with target operating model was also a time frame. I guessed that we would probably need to revisit this every six to eight months. Just like a team would do retrospectives on a weekly basis, at an organizational level, we need to revisit this at a broader scale as well. When we published the first version of the Target Operating Model, I made sure that we labeled it as 1.0 because we knew we would want to iterate and increment over this as well. It's really where do we want to be, and also by when, so a certain time frame.

The second part was, thinking about operation. This wasn't really about how teams implemented specific practices, or standards about how they accomplish work, it's really about the organizational side. Why would you go to your organization that maps down how your organization should work in an ideal way? One of the reasons why Spotify has been so popular is they codified this into a way of describing this model. This is very similar; we want to operate differently but you need to describe it somewhere and you needed to find a way to help express that. Just like we would create architectural models that described systems, we wanted to create an operational model that helped the entire organization understand who should be focused on what, how they should work together, and where the ideal state should be.

This really brings us to the third keyword - a model is a guide, it's not a recipe. The model will break down at certain points between different people. When we talk about an ideal team composition at a certain level, and we'll talk about that later, then it may not work exactly for these sets of individuals, but it's a good start to have the common expectations and conversation, so it's the starting point for the conversation. This was a really useful tool for us to express how we wanted to transform and create the right environment to allow teams to succeed.

I love this quote from George E.P. Box, "All models are wrong, and some are useful." One of the reasons we want people to think about this is that it's not meant to represent every situation. It's that there will be exceptions, but we really wanted it to work for the 80%/20% rule, so Pareto. For the majority, most group should fit into the model that we had.

As we were building out the Target Operating Model, it was quite key to think about what you wanted to optimize for. I'll explain some of the principles that we used to build our first Target Operating Model. One of them was first maximizing autonomy and alignment. Autonomy is a very interesting word because everyone wants autonomy, everyone wants to have freedom to do what they like, but there are always boundaries to everyone's autonomy. In a team, my autonomy might start to step on somebody else's autonomy, and so we need to form an agreement, expectations.

Our autonomy is bounded by the Code of Conduct and by laws as well. It's not like we have complete autonomy, but what we really wanted to do with the Target Operating Model was be clear about where people could exercise full autonomy in the areas where they should have and where they might be able to more informally influence outside of their areas. We wanted to create a focus of clear expectations about how people could exercise. A good example of this is that we don't mandate how a team should work. We don't say, "You have to do stand ups. You have to do one weekly iterations." We asked teams to be very agile and adaptive and we wanted to focus on the outcomes. We want to make sure that all code has automated tests, we want to make sure that you do frequent releases, and we expect that, but how you would like to do that is up to you and your team. We're talking about the boundaries of autonomy.

Alignment is an interesting one in here as well, because when you're in a larger organization, and you're moving from Start Up to Scale Up, everyone is normally aligned to working on the most urgent thing. In a very early-stage startup, that most urgent thing constantly changes, and as you get bigger and bigger, you need to create levels of alignment and I'll talk about that on our first version as well.

One of the other principles of the Target Operating Model is that it really needed to scale. Everything that we needed to think about is, "If we did this again with more people, what would break in that model?" That's the key question that you would ask as you're putting things together. Are we trying to hire somebody or a role that the market doesn't even have that we're going to rely on a single point of failure? Another behavior that you're trying to shift from Start Up to Scale Up is that normally you're relying on a whole bunch of experts or individuals, you know to talk to Fabio, you know to talk to Alena. As you scale up, you want to have a repeatable process. You need to have a bit more of an abstract role and you might have multiple people play that role versus the single individual.

We also wanted to make sure that we had fast feedback. As we were building this, it's not like we decided this in isolation. This is really about an iterative process of presenting this feedback to teams and to leaders and talking about, "How do you think this solution would work or what can we possibly do to address this pain point that our organization is having?" What we really wanted to make sure that it was motivational. We really wanted to anchor all of the changes into beneficial problems or improvements that teams could realize. One of the original pain points that we had with the first teams was that there wasn't a lot of stability. People felt like there was constant churn as parties kept changing, so we wanted to create a good future where teams could feel that their environment is improving and that's something that they would also want to work towards as well.

It also needed to be sustainable. This is one of the reasons we versioned the first version of the Target Operating Model. We knew that we're not going to hit every single issue out there. We're going to try to cater for most of them, we're making explicit trade-offs, but we also wanted to know that those problems will change. As you optimize a bottleneck in a value chain, a bottleneck will move into a different part of that value chain, and you'll need to optimize for that as well, and so this is another principle.

We really wanted to be clear and flexible. We didn't want documents and documents about the target operating model. We wanted a clear visual model with a little bit of description that can provide a good discussion point that people could refer back to you later so it's clear, but also it could help facilitate conversations with individuals so, "How does this apply to me?"

We'll talk about the Target Operating Model that we started off with, and we'll look at a couple of evolutions that we've had since then. I came in about August, September 2017, and spent time with teams trying to understand what are the key pain points, and we published our first version of the target operating model in December of that year. It's quite interesting because you'll see an old theme from our internal thing. Our goal here was to allow people to focus on where they're strong at and improve where teams have gaps and activities fall through due to missing skills, expectations, and time. Probably could have been a lot more summarized, but I was under a lot of stress.

This is part of the overall reason why we're implementing it, so what's the biggest pain point? In reality, what this meant is, we really wanted to improve stability. Teams were constantly being mixed up all the time. We had a habit of bringing this person to this problem over here and they would work on that. Then this problem needed to be changed on a weekly basis. We really needed to create a little bit more stability, so teams had a chance of forming, so teams had a chance of creating an identity and a focus for themselves.

Another level was trying to support engineers. I said earlier how we didn't really have a lot of tech people. I turned around and said, "So who's going to take care of incidents and who's going to take care of product enhancements, and who's going to be involved in future design discussions?" For one team in particular, I can remember there's one backend engineer. They are overwhelmed with the amount of work as well. Part of the original model was also getting to a sustainable team level so that teams had the right inflow of work, and they had the right capacity to deal with that work as well.

Another element I was starting to talk about scalable processes. We had a lot of ad hoc ways of working, but we didn't really have any of that documented - the magical word, documentation. Documentation is really key as you start to scale. As you continue to add people to the organization, you end up with a telephone game if they're just talking point to point. If you've never played the telephone game, it's that game where you get a line of people, you tell the first person a message, they whisper into the next person's ear, they whisper it to the next person's ear, and so on. What you find is the original message you have is no longer that message that is reported at the end.

This is exactly what happens as you rely on point-to-point communication and relying only on verbal communication. It doesn't really scale. Imagine when you write something down and you onboard five people. They can read a document immediately and that scales much further. It scales beyond the people you can touch, it's much more asynchronous. you still have to deal with keeping it up to date, which is also difficult in a rapidly changing environment, but writing stuff down and getting the habit of writing things down is essential if you really want to scale.

A really great example of this is our Android team started to write an onboarding manual fairly shortly after they started to hire. Our Android team rapidly grew from 6 people, I think now it's about 22 people, so it's almost three times in a couple of years. One of the keys why they were able to onboard people so effectively, is that they invested in writing and improving their onboarding process, they wrote things down. As people had questions, they would make sure they would take a snapshot and see, "Why haven't we written that down," and kept putting that into their Handbook. They invested in saying, "We want to make it easy to read as well and digestible," so, simplify the words, make it accessible and easy to discover.

That was the first version, or at least our goal for the first version of the target operating model. Some of the things that we did to match this is we want to first create company-wide prioritization. There's the old saying of "If everything is a priority, nothing is a priority," and maybe now about this. In a Start Up, those priorities keep changing over and over again. We ended up in a vicious cycle where company priorities would change, teams would react, you'd move a whole bunch of people around, and suddenly nothing gets done. Then it gets re-prioritized again, so you end up in a vicious circle of constant reprioritization, nothing happening, a lot of frustration, and then another reprioritization because you need to do something. What we wanted to do was start to establish quarterly level prioritization and say, "We want to say as a company what are the top four things we want to accomplish this quarter and what are the most important things for the company overall?"

This is a really hard thing to do because if you're normally used to early-stage people, if they say, "This is the most important thing," it gets done, or it has the sense of getting stuff done. You have to go on an influencing journey with the leadership team to understand how you get them to adopt this. This is something that we were able to do because what that meant is that teams could stabilize around saying, "We're on the critical path for priority number one, so everything that we do is attached to that. We can't be interrupted if it's not on that priority one." For other teams who aren't working on that priority, they can work on the next priority down. If they needed that first team to accomplish their priority, they knew they would have to wait until that team was free. That helps free up contention across teams, which can be a huge source of frustration for teams who want to be high performing.

We also leveled in into domain-based teams. One of the really great habits of our organization when I first came in is that we were already cross functional. Product, Design, and Technology were all sitting together, all end-to-end skills, so front end and back end, and so they were able to work quite well, but what was different was that they were never ever stable, and there was not really a very clear focus on what they worked on. One of the first things that I did when I first came in was work on introducing domain-driven design to our products team and let them go away and try to do some domain modeling around our organization.

What we're looking for are the highly cohesive domain areas that are loosely coupled and then we could say, "Here's our payments team and they need to focus on this area over here. Here's the onboarding team. If you've ever worked in banking, there's a Know Your Customer process, that is owned by this group over here," and so that can be well encapsulated in that area. They had the focus of working with marketing on onboarding. What we're trying to do is create focus areas for teams to have a clear goal, which is really helpful for building high-performing teams, but also stability. They started to understand the services that backed that fairness, the decisions that were made, and also future decisions that might affect how hard it would be to change that domain area.

We also set it to move to larger, stable teams. When you ever work in cross-functional teams, there's an interesting paradox, As a leader or manager, you're often taught you want to remove single points of failure. You want to not rely on a single individual of expertise because that's a big risk to your overall delivery. If they fall sick, or if they decide to leave the company, then things slow down. On the flip side, there's also the good advice of saying, "You need cross functional teams." It's very good to get feedback-end to-end. What's an interesting challenge here is having small teams of six to eight people, but having a full stack of different skills, where you have the right mix of skills as well.

One of the harder things that we ended up trading off is that we said, "Let's go for bigger teams, let's have a few more back end engineers, we'll end up with a little slightly bigger team, have more communication passed between team members, but we'd have larger stable teams that have more capacity to deliver things." It was incidentally one of the things I wanted to also encourage more pair programming. I didn't want to enforce that but a great way of helping onboard new team members and deal with a larger team is to form pairs so there's more knowledge sharing there as well.

As I said before, we wanted to start documenting implicit. Whenever anybody raised a question in the organization about "How is this done?" I would ask, "Where's that documentation in our Wiki?" Just through asking that question all the time, people started getting the hint, they probably needed to start writing it down somewhere. If you get everyone in your organization who are leaders to also start asking this question, that's a really great way of reinforcing this.

To keep it up to date, one of the interesting benefits of hypergrowth is you have lots of new people coming in all the time. A good way of keeping up to date is by getting the last people who've come in to update whatever is out of date. They talk to the right people, and then their tech leads or leaders ask them to update the documentation so it's fresh for the next set of people as well. That's a really great way of keeping documentation fresh, because they're the people who have that questions that the next set of people will also ask questions for, you're starting to build the documentation incrementally.

We also overhauled onboarding as well. A lot of our teams have either doubled or tripled in number of employees, particularly on backend engineering and we really wanted to make sure that we optimized the onboarding path. We really went through with people team and our people department to work out what's a good onboarding strategy and how do we do this? Onboarding isn't over in day one. You want to look at things like pre-onboarding before somebody joins the company, to help them understand, "Here's what you should expect when you join the company. Here's how we'll work." Day one is obviously, we do a whole companywide onboarding so people learn about other departments, what we're working on as a company. Then you have the team level onboarding on day two, which is, "Here is the focus area for your team." Then, obviously, the technical onboarding, which takes some time about the domain and the tooling that we use. What we really wanted to do was be very explicit is for each type of functional area or team area, have we got a solid onboarding process for everything, which helps to build a new team?

Finally, we also introduced a couple of new roles engineering managers and principal engineer as we grew. One of the interesting things as we grew is that we used to have tech leads who used to be like management and they used to make technical decisions about architecture and choice and steward designs, but they're also managing people. As teams were growing, one of the things that I observed is that those people couldn't do both things well. They could either do line management really well, or they could make technical decisions really well and people would make a choice based on their own preference as to where they would focus on and so things would be starting to fall down. People at individual level would be saying, "I'm not getting any one-on-ones." I found out one person was getting one-on-ones every two months. You start to hear some of these takes, or there are some services that haven't had deliberate thinking about design. You can detect these smells.

What we wanted to do was introduce a couple of focuses as we grew and scaled. We wanted to introduce an engineering manager that would focus more on delivery, communication, and people support and we wanted a principal engineer role to also start helping with more cross-team decisions. A tech lead could take care of decisions within a team and the services but what happens when you need to get two teams or three teams agreeing on perhaps a common interface? This is where our principal engineer was planned to help out with that.

To give you an example of what was included in our Target Operating Model, we just explained here are some of the problems that we're seeing based on some retrospectives and one-on-ones. We have here our tech lead, and we have a product owner and there's a whole bunch of responsibilities that mostly get done but then there's a whole bunch of things that keep falling through the cracks. These are perhaps line management about communicating out to other people where things are at and it's just too much for two individuals. What we wanted to say is, "Ok, if that's the before picture, here's what we're expecting afterwards." We wanted to have an alternative model of key leadership roles for a team level where the tech lead is really focused on technical decision making, the engineering manager is focused on people, process, and internal communications. Products should really focus on the product roadmap, customer, and external communications so thinking about marketing, go-to market strategy. These are some of the elements that we added in our first Target Operating Model to help people understand how we wanted it to work.

We described how we expected teams to be stable around which domain areas they should focus on and we also explained the roles and how they changed roles and responsibilities. We also made sure that we included the changes in our organizational structure. A lot of people want to know "How does this affect me and how does this affect where I'm reporting into?" We wanted to paint a picture of effectively key leadership roles, how they relate to each other, and how they should commonly work together with each team. One of the roles that I was bringing in was a head of software engineering. In the U.S., it's typically called like a VP of engineering type of role. Obviously, I also needed to work out how do I scale myself, so I can remove myself from the day-to-day of product operations.

This was the first model that we had of trying to roll out a change in our organization. What's interesting about this is that this model gave us the ground point for understanding our recruiting targets and how rapidly we needed to start recruiting. A big surprise to me - I moved from London to Berlin for this role - is the German market is very different from probably here in the U.S., and definitely different from the UK. Most people have a two to three-month notice period. Even when you manage to hire somebody, you sign them on, you still have to wait almost a quarter until they join your organization and then you have to onboard them and that's really painful.

You've tried to plan this organization, you've tried to grow this, but even when you've managed to hire people, you're going to be waiting until they hit the ground and can be effective. An interesting thing about hypergrowth if you ever go through this, is that you almost have to be able to deal with a high threshold of pain points and you really want to paint a really good picture about where you're heading to because the only thing that will keep people going through this is that they want to know it will get better and that things will improve. That's why this model was really powerful.

From the first target operating model, we knew that we had to hire some key leadership roles. We now knew, if we mapped out ideal team structures, we had a huge number of vacancies that we needed to hire and so I could work with our people team and recruiting team to improve our recruiting processes. To give you an example, we started off when I first joined, only recruiting one to two engineers per month, it was quite low, I think we were about 55 people. By the end of 2018, we needed to be about 180 people. That's a huge gap of deficiency. We worked with the people team to institute a project of, "How do we revamp our recruiting process? What do we need to do around interviewing? What do we need to do around employment branding and getting our name out there to help people understand what we could offer and hopefully attract the right types of engineers that we wanted to hire?" I think it was quite nice because we finally hit something like 20 hires in a month, which is a huge difference from the 1 to 2 at the very beginning, but it took some time.

Some of the other roles that we were hiring were some of the key leadership roles, finally brought in a director of engineering and a couple of engineering managers to try to help us move towards the model. This is the time when we started to revisit it. This is almost six to eight months later, where we were talking about, "We've started hiring. We're starting to fill the teams, teams are getting a lot larger. What are some of the organizational smells that we're detecting?" We'd spend time once again repeating the process of talking to teams, helping us to understand what are the common pain points across the organization that would help them be much more effective? What do they need that's stopping them from being effective around that?

One of the interesting things that we had was we'd been pretty strict about our team structure. To a certain degree, it was a moot point because we didn't have the people. It was more just a target for hiring. As we added more teams, we started to realize, "Now that we had domain teams, some domains are quite different from other types of domains." If you think about our growth team, which was responsible for our website and onboarding, it's heavily user-centric where you need a lot of web, you need a lot of front end, iOS and Android, and they would work very closely with marketing.

You contrast that to a team like payments or banking infrastructure. If you've ever worked in that, it's heavily integration based, it's high scalability, low latency, you really want to deal with deep security and you don't really need so much front end from that perspective. As we started to work with teams, we started to notice that each team needed a bit more specialization in terms of skills and responsibilities. This was the trigger for us to step back and say, "We want to empower each of your teams for you to make the best choices for you to do the best work in your domain that you're working in."

Our second version of the Target Operating Model was moving from team-based empowerment to product group-based empowerment. This is interesting because we're introducing a new word, product groups, and we're trying to help people understand what that is. Instead of having domain-based teams, we moved to groups. We said that a group is composed of a mix of different people and the group can decide how they'd like to organize their teams. It's no longer us saying, "Here are the teams that you should have." Is that, "You have a collection of people, you optimize your working structures best for the work that you need to achieve." We're trying to give that autonomy back and so in each of the different groups, we can say, "Here are different skills that we expect the group to have, but you have to work out how you'd like to work."

That's sustaining us quite well as we've added in and prioritized new products areas and we've got to a stage where we needed to revisit this again because we had a lot of groups. We now have about 270 people, if each group is about 30 people, then you end up with like 9 groups, and you need another structure to help coordinate that. This has brought us to our most recent version, which is 1.2, and this is really about moving from relationship-based processes to transparent structure-based processes.

One of the key ideas here is introducing a segment. Here we're saying that groups are now aligned into a segment and they're working towards a common organizational KPI or goal. The group still have autonomy about how they like to structure teams, but they now need to align with other groups in a better format to organize their work. We also introduced a new group called a product and technology operations, because there's a lot of logistics to running an organization of that size as well and so we needed people to help us with organizing common comms, planning meetings, and it doesn't really fit into a normal production group.

To summarize some of the elements that I'd like you to think about, if you talk about it, it's really important you think about where you are, talk about the why, talk about what's in it for me for individuals in your organization. It has to bring benefit for everyone. Make sure you're explicit about vocabulary, I'm a domain-driven design evangelist and you really want to think about what's the terms that you introduce that mean things for you. You'll talk about new roles, processes, and structures, and next steps.

Lessons Learned

We've looked at the solution, let's quickly talk about some of the lessons learned along this journey. For me, a lot of this comes down through my own leadership philosophy of really making sure you start with why. For a lot of people, for teams to be highly successful, you need to help them understand what are the highest priorities that there are out there. If your leadership team doesn't have priorities, established priorities, make sure that people understand what impact they have on customers. Engineers get motivated because they have an impact on real users. If they're not working on external users, help them understand how they help business. Maybe they make processes more efficient, but make sure that you start with why.

As engineers we're taught, "Do not repeat yourself." As a leader and a manager, "Do repeat yourself." When we introduced the first target operating model, we went through each team, we went through the Target Operating Model about what it was, we then added a little Q&A, and we made sure that people had a chance to hear this multiple times to make sure it really sunk in as well.

I talked about versioning. Part of the tricky level of this is that I'm the person that's probably responsible for all of the reorgs, but you don't want to do it too often, but you also don't want to leave it too late. I think there's a certain thing to startup culture where people are used to change anyway and people like to have the change if they can understand why it's useful, if they can help understand why it helps them.

As a leader, make sure that you listen to people as to what are those pain points, and you consider trade-offs. These are some of the things that you never end up with a perfect model, you always make trade-offs and so you need to be explicit about what things you're trading off and make sure you expect limits as well. This is one of the reasons we introduced a time-based level to our target operating model. We knew that just starting with teams and having hundreds of teams wouldn't really scale. We needed another level of granularity because that would break at a certain limit.

A lot of people said, "Why do we need to reorg?" A system that I think about is that when you're in a startup, you think about product. If you're doing inverse Conway's Law, then your software architecture should reflect that and so should your org structure of your teams to build the appropriate architecture. In Start Ups, you're also affected by the size of that and you're getting input from the market. You get customer feedback, and you get changes in business priorities. If we're going to interact with all of these, there are certain things that you can influence, but there are certain things that you won't be able to influence which you need to trigger changes in the organization to optimize for. It's very helpful for people to understand why it's important that we make these changes because there are certain things that we need to make changes to if we're going to be successful as a business.

To talk about some of the things that went well or went less well, one of them was struggling with role identity. A lot of the time, as you introduce new roles, people think about things being taken away and you need to find ways to help people find their identity. A difficult thing in hypergrowth is proportional hiring. You can't hire people at exactly the same pace, but you have to be able to deal with that there'll be imbalances throughout that. As you introduce new words, like team, or group, or segments, you have to also realize that people will have different flavors of interpretations of what that means, so you have to repeat yourself over and over again.

Fortunately, I think what didn't go so well is that we ended up with lots of high-performing teams. We got a lot of things done, so we didn't cripple the organization as we went, and we went through accelerated growth. If you go through hypergrowth, then be prepared, the pace can be overwhelming, there's going to be a lot of emergencies, and there's going to be a lot more stress. On the flip side, there's a lot of benefits to this. It's a huge opportunity for people to grow. There's a lot of improvements really rapidly because things happen and there's different types of companies that people can experience and more to celebrate.

You've seen our hypergrowth challenge, you've looked at the solution, and hopefully learned some of our lessons learned. My final question for you is to think about what is the environment you would like to cultivate for the teams that you want to build

See more presentations with transcripts