We already know that diverse teams are more creative and deliver better results. We've seen this play out in repeated studies and in bottom line financial results of companies across many industries. Sadly many organisations lag behind in adequately representing the population, but those that are making strides are also outperforming the competition.
So we know WHY but what about the HOW? In this talk, we’ll explore a framework for how to think about diversity and inclusion, and practical things you can go and do to make your organisation and culture genuinely inclusive. Because that’s the only way to attract, recruit, promote and most importantly retain a wide range of people. And THAT is the only way to have the highest-performing teams possible.
1 / 54 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Thanks. Thanks. Hi. Good afternoon. Out of interest, how many of you are n twenty six customers? Thank you. Thank you. For those of you who don't know us, we're a German based bank, and we like to describe ourselves as the first bank you'll love.
So you don't often hear about banking and love in the same sentence, and we're really on a mission to try to change that. We're really trying to bring design thinking and usability into banking. And we talk about banking that's beautiful, and trying to build the global bank the world loves to use.
I'm the chief scientist. I evolved from a former CTO role, I can talk to you in the break about why that is. And my background has been working about in technology for about twenty years. So I've worked in a lot of organizations as a consultant helping them change, transform, go on the digital transformation, and I had an opportunity to help sort of shake up a startup to try to help us scale.
And this is kind of the contents of a lot of the talk that I'll be covering today. If you're interested, I've written a number of books. One of the ones that I really like talking about is particularly around technical leadership. That's talking with tech leads in the middle.
And I actually run some training courses, and I started a new newsletter called Level Up for Leaders in Technology. But today, our story is really about a three step stage where we'll be talking about our hyper growth challenge. What's interesting in Europe is that a lot of companies don't often go through hyper growth.
It's a phenomenon that happens a lot in the US, but not something that happens in Europe. So I'll talk a little bit about what that is, what it feels like. I'll talk about how we approach this, and this is an interesting sort of space for anyone in a leadership or management position about what you can do to sort of, manage a very rapidly changing context.
And then I'll talk a little bit about maybe some of the things that we learned, some of the things we'd probably change, and maybe some lessons that you can take away. So look first, let's take a look at what hyper growth is, and and, sort of the challenge that we had.
So as a sort of CTO, I like to describe myself as a shake up CTO. Right? So you have the very very early startup stage of a company. What can you do to help us scale and make a and and build the environment for a rapidly growing technology company?
So if you pose yourself, what sort of environment would you like to cultivate? And this is where I sort of thought about, well, if you have sort of the raw earth and you're building a sort of garden, what type of garden would you like to build?
Right? And there's many different types of styles out there. You could be completely random, you could be the English garden, you could be more desert, Japanese oriental. Right? There's lots of different flavors, but you as a leader get to sort of shape the environment in which people build and thrive.
And so this is a really interesting thing when you're a leader because you're often not attached to a particular team. Right? You're trying to foster the right environment to allow other leaders to build their high performing teams, but you yourself do not have a direct influence on a particular team.
're sort of shaping the environment and you're cultivating that environment. Now, hypergrowth is a very interesting, sort of experience, and there's a couple of different definitions out of there. One of the nicest, easiest ones is, defined by the World Economic Forum where they talk about hypergrowth being more than forty percent year on year growth particularly in revenue.
And for us, it's kinda interesting because that's definitely been happening from a customer's perspective. But obviously, as a startup, you're always trying to do more. Right? So you're starting off to find a product market fit and then you're trying to respond to those needs.
And if you've built software systems, you know, once you start, you don't just simply adding new things, you're also having to evolve and make sure that your existing capabilities scale appropriately. So you're also needing to think about how do you scale the organization behind building complex software there.
A really great analogy, if you've ever been in anything like this, is like feeling like you're building a rocket as it's flying. Right? So you're assembling pieces in the air as this rocket is taking off with a very fast trajectory. And that's an interesting analogy because when you're sort of on the ship, a, it's kinda hard to get off.
But also, it's really interesting because you're trying to navigate and trying to add in the right supporting structures that may not have been there from the very beginning. Now, let's talk about some numbers because we like to talk about numbers. So if we think about some of the different types of metrics that we have, we have now more than three point five million customers.
So when I started two years ago, we're about four hundred and fifty thousand. We had about four hundred and fifty employees. We're now more than, I think, thirteen hundred. And then in terms of offices, we started off in Berlin. We've now expanded to Barcelona as a product development hub, New York.
We're about to start Vienna, and we've actually also started an office in Brazil. Now, as part of the technology organization, I came in with about sort of fifty, fifty five people, Not all engineering, all technology was there including help desk. And now, we're more than about three hundred and twenty.
If you add products and and design in there, we're almost an organization about four hundred. So we've gone through a growth of about six times in two years. And if you've worked in that environment, you know how stressful that is. Now, as an engineer, I know this is really hard as you're trying to onboard, recruit, and try to keep that environment.
And the question is, what would you do to actually help support that? What do you do as a leader to create that right environment to help people really thrive? And so when I first started, I was really on a mission of helping shake up this idea of we're no longer an early stage start up.
What we really need to sort of recategorize ourselves in in terms of behaviors, in terms of culture was move from early stage startup to really a scale up. Right? So this is starting to think about, do these things actually scale? Do these things actually help us move beyond?
And so here's some concrete examples of this. When you're in a startup, right, you're probably in the same room, you can talk to everyone, you can grab everyone in front of a whiteboard. What happens when you distribute it across three different sort of offices and three different time zones?
It doesn't scale anymore. Right? So there's a lot of practices that habits that build up over time, and you're needing to sort of guide people towards new habits that actually scale and help with that. And so these were some of the interesting challenges that we had.
Now, I'm kind of lucky because I I used to do a lot of consulting. And so having worked in a lot of environments, I've seen how organizations deal with this at different scales. So newer stage, so the Internet based companies, older stage kind of companies who have maybe more brick and mortar style, who've gone on their digital transformation or maybe still going.
And, you know, the interesting thing is, what would be the different approach there? And so one of the things that I really wanted to take away was really thinking about how can we do this in the best possible way given there's a lot of things that are out of my control, particularly around how the market responds, around how the rest of the business, sort of responds, but what can you do?
Alright? So there's obviously, there's a few different ways you can approach this. One, which if you haven't had the experience of sort of seeing how other companies approach this, is maybe just reacting. Right? Today, have this problem. What should I do about that?
I need to actually think about that. That. And it's a big trap that you can fall in, particularly in the early stage startup, where you're really not trying to burn yourself out, but there's so many issues that you have to deal with. It's hard to get out of that reactive phase.
Another particular approach that you can take is kind of what I call copy and paste. Right? This is the Spotify does this, so we must do what Spotify says. Right? So take something that's well known. Amazon do this. Google do this. OKRs. We should roll them out here.
And let's take them into our organization. And that's not really an approach that I like to think about. What I like to do is think about you have a toolbox of different options, and you need to think about what is useful in your context.
Are these problems you have today? And do these things actually have a chance at solving the problems that your people have? And this is where I wanna be sort of deliberative, and this is really talking about strategic. Right? So it's not just about which practices you do, but also when you actually start implementing them if they're solving the problems that you have.
Now, I talk about high performance teams and this talk isn't really what makes a high performance teams. There are many many things out there. And I've done talks about that before, but some brief references if you're looking for material. So Dan Pink's drive. Right?
Theory of motivation, drive mastery autonomy. Sorry, purpose mastery autonomy. If you think about rework, this is actually some of the stuff that proxy Project Oxygen from Google did about what makes high performing teams. There's a very classical book, five dysfunctions of a team, and if you sort of invert them, they become the five things you can do to prosper and make a high performing team.
And then there's a little book that's probably not so well known. This is called Lift Off. And this is really about sort of teams sort of, onboarding, chartering type of activities that help you build teams. But as a CTO of sort of fifty fifty five people in a rapidly growing department, I don't get the benefit of actually building a single team.
As a manager of manager or a leader of leader, you have to work out how do you amplify other leaders to help build their teams and try to build up that sort of trust. And so it's really an interesting challenge when you're thinking about a scaling approach of stepping back and thinking about how do you make that more likely that all of these teams are high performing, they won't be at the same time, but what can you do to maximize the likelihood of that?
Now, love this quote from Grace Hopper is that as a manager, you manage things and you lead people. And so my approach to really thinking about engineering management is I'm responsible for the system. Right? So processes, the rituals, and things that are mandatory or optional, and you really want to inspire people to help them understand what is necessarily, give them the right context, and help them solve the right problems for where we are.
So a really good approach is thinking about first, thinking about what are the problems that you have. Observe. Right? What are the things that are going on? And then you wanna actually orient. You wanna think about out of the things that you observe, you'll probably have cataloged a whole bunch of interesting observations, which are the first three things that you will deal with that will give you the most amount of benefit?
What are the three most urgent or most important topics that you can have that can have the greatest impact? Then you actually wanna think about how do you decide on what you wanna do, and this is where you need to also buy consensus, build consensus, get input, and then make sure that you act upon this really rapidly.
But like all things in any startup, we're never ever done. Right? So constantly evolving our systems, we're constantly evolving our product, and therefore, we also have to think about the system behind building that product. Now, this isn't a sort of new kind of approach really because this is very iterative.
This is actually John Boyd's OODA loop or something from, sort of, I think the Second World War at least, about how do pilots sort of respond really rapidly in a highly changing environment. Now, we're not really working in a sort of airplane metaphor in software a lot of the time.
So how do you actually translate this into specific practices? So one of the tools which I was really pleased to hear from the previous speaker is really doing retrospectives. So it's really interesting when you surface retrospectives and then thinking about what are the common topics that pop up in every team that the team doesn't feel empowered to solve.
Right? There are often systemic things that are in their environment where a lot of teams feel they can't have the impact around that. And your role as a manager of managers or a leader of leader is trying to find those common themes and try to understand how do you remove those blockers or how do you increase flow and connect people to things that they need, maybe it's context, maybe it's information, maybe it's more support, and help them with that.
Right? So retrospectives at a broad scale, and then farming for common themes around that. Another powerful one is one to ones, and particularly one to ones with not your direct reports who you'd probably typically have one to ones with, but really one to ones at what they call a skip level.
Right? So beyond a couple of levels, and you're trying to get a sense of what act actually happening. So you have the themes that come out across all of the teams, but you're also sort of spot checking with, okay, what do people really experience?
What is their daily life like, and how does that actually work? And this is kind of the equivalent of sort of going to Gemba for me. And once you have a lot of this information, what you're really trying to understand is where are the gaps.
Right? So it could be about company culture or what's actually evolving and changing. It could be about what sort of processes are evolving, and you're trying to understand maybe you need to have a clearer process because what was an informal agreement between two people is now a very confusing, conundrum across like fifty or or sixty people.
So one of the tools that, was very useful in this whole process of change was being very deliberate. And one of the things that we created was what we call a target operating model or TOM for short. So when I first introduced the idea of a target operating model, this is something that we said we would start with.
So we started off with target operating model one dot zero. We're actually technically now on one dot two, so we've evolved it twice in small increments. Interestingly, we had a debate whether our most recent should be two point o, but it's more of a evolution rather than something fundamentally different.
But the reason we called it a target operating model is well, firstly, the target tells us where do we want to be. Right? So in six to eight months time, here is kind of the organization that we wanna look like and here is how we'd like to work.
Operating is really focused on the how do we wanna work. Right? So it's not really about the product side. We already have product road map that tell us where we'd like to go and planning processes for that. But this is really about how do we wanna evolve, say, products and technology and change the way that we work in a very deliberate way.
And the reason why it's a model is that it should be a guide, not a recipe. Right? So it's applying Pareto's principle of eighty twenty. Right? So for most of the organization, this model should resonate with solving the problems that we have today that gets us to a state of more effectiveness over the next sort of six to eight months.
And if you've ever studied sort of statistics and models, there's a really fantastic quote that I love called, all models are wrong but are some are useful. Right? So having a common model with the organization helps set a sort of operating vision of where you'd like to be, but we know it'll be wrong.
There'll always be exceptions. Right? It's like there'll be a category of something that doesn't fit into this box and that's okay. A model is never perfect from that side. Now, I don't have as much time to go into all principles, but there are six principles that we built into thinking about our target operating model.
So the first one is really thinking about alignment. Right? So autonomy and alignment. When you think about sort of engineers, one of the things I really believe in is you don't need to tell creative problem solvers who learn how to solve a problem.
Right? That's their job. Right? They want the freedom and autonomy to do that. However, what they need is constraints and context. And this is really about the alignment. Right? And this is making sure that people understand, okay, are we building using a common technology platform?
Or do we have freedom as to do we invent everything ourselves at a team level? Every organization has its own choices, but you as leaders need to sort of be clear about that context. So that's really about this interesting balance between autonomy and alignment.
Because everyone, can have lots of autonomy, but at some point, somebody's autonomy starts to step on somebody else's autonomy. So we need to make sure that we're aligned as an organization about where those boundaries are at different levels. We also really wanted to make sure that this is scalable.
Right? So we didn't really want once off models that worked for one team, but then actually had to create new models for everything. We wanted something that would actually also be scalable. So could we do a n plus, x version of this versus a one version of this.
We also wanted to make sure that we have fast feedback. And this is an interesting as your organization grows really rapidly, at a smaller scale, you can iterate on on a model much larger. But once you're sorry, much quicker. But as your organization gets bigger, you obviously need to get more input from more people, so you can't iterate too, rapidly over that.
You also don't necessarily wanna iterate over a target operating model really rapidly because it's too much change for a lot of people. It takes a while for people to get used to different, ways of working. Another thing is really making sure that this target operating model paints a bright future.
And so this is an interesting conundrum that I've seen working from the other side of an engineer coming in from an organizational change perspective is that people don't understand why it solves my problems. And by actually listening to teams and collectively talking about, okay, we gathered input from the organization, here are the common blockers that will resonate with a lot of people of saying, actually, these changes helped me.
It's not really helping, you know, us as an organization only or management, It's helping me me with my job, and that will help me be a lot more effective. We also wanted to make sure that this thing was also sustainable. Right? So could we actually hire the right people?
Could we find the right talent? Or are we gonna be growing people in a certain way that will sort of put too much pressure on certain numbers of people? And we also wanted sort of clarity and flexibility. So this is really making sure that we're short, so we didn't really want a operating model that was like a thirty page document.
We wanted something that was clear with words that people could understand, and that people could assimilate. So what did that look like for us? So two thousand, and seventeen, we published our first version of the target operating model. And this is really taking us from a very rapidly changing startup, right, where you're reacting to issues every day, where priorities would change on a daily basis.
And a lot of the consensus was there was too much change. Right? It wasn't clear. People would sort of change, but by the time they started to get on board with what the problem was, they would change again the priorities. And so what we really wanna do was create stability.
Right? And so our goal here was really allow people to focus on what they're strong at and improve where teams have gaps and activities fall through due to skills gaps. Now, could probably be a little bit more condensed but there was a lot of things going on.
A lot of this goal was really about bringing sustainability to the organization for products and engineering. And so what this meant is that we really wanted to improve stability. So a lot of teams were very lean on what I'd call engineering, particularly back end engineering capacity.
You tended to have one or two single points of failure. And what we really wanted to get to was not just one person who was like listening for changes, doing production support, reacting to lots of stuff, who were always stressed out when they went on holidays, but actually getting to a point where they could actually comfortably take holidays and not feel guilty that they're leaving stuff behind on the rest of the team.
This is really also about supporting engineers. Right? So this is about making sure that they have the ability to, get out of a reactive loop and also get involved in planning. Right? Because planning is an interesting process where if you get some engineers who talk about what are current constraints, you might actually find out what things appear to be simple are a lot more complex than that.
We also wanted to make sure that we had scalable processes, and this is an interesting change for when you go from startup to scale up, is that everything is normally very informal in a startup. Right? Everything is very point to point, mouth to mouth, and conversations.
But when you're a distributed office, you kinda need to get into a habit of starting to write things down. You need to start repeating things multiple times. You need to make sure that, you know, people who are coming into the organization understand the reasons why we operate the way we do and make sure that's a strong onboarding process.
And so we really wanted to make sure that for instance, every team, every product team had a really clear onboarding process. We have an onboarding process for the entire organization, so it's a whole two day onboarding where people get visibility of all departments.
But obviously, in a product space, you need to understand what product area you're working on. You need to understand the technical infrastructure in order to be able to evolve that. And so we wanted to make sure every product team had various strong processes in a consistent sort of manner, but it would be dependent on their product areas, of course.
And so some of the interesting changes that we had in this first version, was really sort of starting to create a a newer leadership team per team. So before, we used to have a product owner and we used to have a tech lead.
And you can kind of see we listed out all the responsibilities and what what sort of fell through the gaps was kind of a whole bunch of things that popped up in retrospective. So it's probably a little bit smaller, but things like process improvement around people development, around career explanations.
These were things that kind of when you when you sort of ran out of time, the combination of two people wasn't enough to take care of that at scale. Getting involved in reporting on where we are with delivery pro process or risk management weren't things that came naturally to the teams.
And so part of the evolution of this was saying we wanted to start to expand the leadership team per team to a a new set of people. And this is where we introduced the role of an engineering manager. Right? So an engineering manager who's responsible for what I often call delivery, people, process, and culture.
You have technical leads who are responsible for system architecture, technical debt quality, making sure that we're continually improving our systems, and of course, product people who are very much focused on product road map features, customer feedback, and making sure that we continually improve and also think about the sort of commercialization.
And so, you know, part of this was introducing new roles, part of this was introducing a sort of head count plan of where our gaps were, because obviously, the model was like nice. We have this idea of an engineering manager, but we had nobody that was playing an engineering manager role.
So we had to introduce new capabilities to our organization as well. And so, you know, we built up and we we interestingly hired different types of people, and then we started getting feedback about the model because, you know, you have this idea of where you'd like to be.
It starts rolling out. So then obviously, people say, hey, this doesn't feel right or this isn't working. And so we actually started iterating and building and collecting feedback on our first target operating model. And then we published out our second model, which we incremented to one dot one.
And the focus here was really moving from a team based empowerment to what we call a product group based empowerment. So what was interesting for us in the first version of the model is that we really created strong teams around product areas that were fixed.
But as we sort of mapped out the number of people and the number of roles, we had a huge sort of headcount difference from the ideal to where we are. Now, as we started to fill up those teams, we started to notice that there were differences across different product areas.
So if you've ever worked in sort of banking, you'll probably know that things like payments or payment infrastructure, that's quite different than if you're looking at, say, your onboarding or growth sort of space. So one is very sort of back end infrastructure heavy, the other one is very user facing sort of iterative consumer that you can do a lot more AB testing in.
And so we actually started to notice that there was sort of different skills gaps, different experiences just based on sort of focusing around different product areas. And so we wanted product groups to sort of help us optimize for their product areas, and this is the big shift that happened when we moved to product groups instead of focus on teams.
So before this change, we'd sort of modeled out these different types of groups, and each group had a specific client and clear area, and each team had a sort of six to eight person kind of role mix in there. What we actually wanted to move to was a bit more of a generic kind of space where we said, actually, a group is a cross functional mix of people.
So people from product design and technology, but we know that that mix will be different depending on the area that they are. And what's interesting is every product area also has different needs. So sometimes, it made sense for a product group to say, actually, we wanted to spin up a short term working team for three people for maybe about two months to work on a particular topic.
They're not really a long lived team, but it made sense in that context. And so we wanted to empower groups to say, okay, you need to have some more, autonomy over how you structure yourselves so that you could work best for your context.
And this is kind of some of the change that we went there. And so when we published out this model, we also sort of talked about, what are those groups and how do people, change the environment from that perspective. Now hiring continues to grow, and so, we've at this time, we've actually rolled out, I think, Barcelona.
So Barcelona now, I think we've got about seventy people in Barcelona. We launched that in September last year. We've got, two strong product groups with lots of teams underneath that. Berlin's been growing really rapidly, And, you know, we're collecting more feedback. Right? So we just launched into the UK last year.
We just launched into the US, like, literally two weeks ago, public. And so we've got a lot of complexity that, you know, we're starting to understand how do we create more autonomy but create alignment within that. And so we actually recently iterated over our next version on target operating model.
And this is really talking about taking us from, what we call Berliner startup, tech startup to a global bank. Right? So what's interesting for us is as we were working towards the US, we have a team focused on, you know, US specific needs.
A lot of people in Europe who are very much focused on our product already in Europe, and that's an interesting tension as we're starting to move towards a vision of being a global bank the world loves to use. Right? Is that obviously, most people working in Europe are just focused on what they do, and that's normally the European market.
But we have a small part of the organization that's starting to focus on things that aren't so European specific. And so we needed to start nudging the environment so that people start to think more broadly, think more globally rather than just thinking about their particular product area that's currently out in the market.
So what would that look like if we launched that in a new region? What what would you need to launch that into a new region? And what capabilities and skills would we need to be able to do that? And so this is actually where we've evolved again.
So we've moved from teams to groups to what we're now calling segments. And so segments are our latest evolution of our target operating model. And we've actually also introduced a new sort of team which we call product and technology operations. So one of the first roles I brought in was a director of software engineering to help us with sort of hiring, headcount planning, sort of different processes.
As we've sort of scaled up our organization, most of you will know if you've been working in a large organization, there's a lot of things that just take a lot of work to sort of get going. So quarterly planning, you know, OKR roll ups, sort of alignment type of things, things that create alignment across the groups, but a group isn't necessarily responsible for.
And so we've also created a product and technology operations group, which is kind of supporting product and technology to help us sort of scale out different types of plannings. But it's really quite interesting because segments for us are groups that are aligned towards the same goal.
So for instance, we have now a growth segment, and every group within that is really contributing towards what does it mean to grow. And so there's different types of groups within there. So we have for instance, our onboarding group which is really about the onboarding funnel, and then we also have another group which is called KYC which is Know Your Customer in banking terms.
And this really has to do with making sure that we're compliant to different know your customer processes according to the different regulations, and that's quite complex depending on the type of market. But both of them are really contributing towards onboarding and growth, so they sit within the same group.
And so you can kind of think of this as something that sort of scales at different levels. So a team of six to eight people, a group of about thirty to fifty people, and then a segment is a sort of a mini company, if you will.
So we're running out of time, but I wanna talk about some of the things that were really useful of going into a target operating model. Now, as I said, don't just simply copy and paste. Think about what's useful in your organization. And so your target operating model will look different because your context is very different.
However, there's a few key elements you should think about with when you're building that. So one of them is really talking about where are you. Right? So having collected all this information, talk about what are the things you've noticed, what are the observations that everyone will that people will resonate with, that people will acknowledge.
Talk about the why. Right? Why are we changing? Pain I often talk about change in being pain driven. Right? We need to have enough pain in the organization to say, this is something that we really need to address, and this is one of the reasons why we're introducing these types of changes.
We wanna talk about where do we want to what's in it for me? Right? So you as an individual working in this environment, how do you benefit from these changes? Part of this is also some of the interesting things around vocabulary. Right? So if you're domain driven like myself, you want a ubiquitous language where if you use a term like a group or a segment, it's really meaningful in your organization.
And so you really wanna make sure that people understand this is a special word that has a special meaning in our context. And then making sure that you have new roles, processes, and structures. So we introduced things like engineering managers. We've got new processes, so we started doing sort of quarterly planning processes as we scaled up to help us align.
And we have different types of things that allow us to sort of communicate information a lot more broadly. And then making sure that you also then say, okay, this is great. Here are all the changes, but this is where we go now. Right?
So after we sort of talk about this, how do we actually make those changes come into reality? Right? So how do you make it actionable? And so these are elements I would encourage you to put into your own target operating model if you're actually thinking about that.
So what did we learn from implementing some of these different things? Well, the first thing is really, really starting with why. This is super powerful. People want to know why these changes happen. So talk about priorities, talk about the impacts that it can have on customers and why the benefits are that help us scale up.
Also, about maybe the business impact. So some teams don't work on customer related things, they help work on sort of operational efficiencies within the business. So make sure if they're not related to a customer, think about how they actually are adding value. As you roll this out, and this is a completely non engineering specific behavior, or habit, do repeat yourself.
Right? So in code, you're told don't repeat yourself, like remove duplication. But when it comes to people, you need to continually repeat the same message. New terms, new concepts, changes in how you behave, you need to make sure that it's repeated message that resonates with people.
Make sure that it's fast enough but not too fast. Right? So iterate over the model, but it will be a function of how how large your organization is and the types of problems that you're solving. Don't change it on a weekly basis because that will be too quick, but don't also never change it because it means your context probably will have changed beyond that.
Now, how does hyper growth affect this? Well, one is that the pace can be really overwhelming. One is that there's always emergencies happening. So regardless of what you have, there'll always be something burning, and there's always more stress like for individuals. But on the flip side, what's really interesting working in environment like this is that there's a lot of opportunities for people to grow, try new roles.
There's lots of improvements. So the interesting thing is when you react and you improve things, people feel it immediately and celebrate that. Right? And you can also think of yourselves as working in multiple companies. Right? You don't have to change companies because the company will continue to change.
And make sure that you make time to celebrate. So these were some of the things that we talked about with thinking about cultivating high performing teams and hyper growth. Think about the type of garden that you actually would like to cultivate, the environment you'd like to create for people, and I'll be hosting a q and a later today.
