Organising engineers, product and data people, designers and marketing people to work together for growth is hard, especially for start-ups and scale-ups that are primarily set up to be great at building products. How do you change your organisation to a model that works better for growth while keeping the great parts of your culture - and keeping people happy and involved, all while still improving, running and maintaining everything you’ve built? In this talk, Pim will share learnings and failures from Skyscanner, TravelNest, Deliveroo and Oda, looking at some of the nuances and practicalities of building teams for growth - what are things to consider and think about at different stages of company maturity, and what are different approaches that you can take to build growth teams that work.
Growing Growth: Building Growth Teams In A Product Engineering Organisation
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Hi, everyone, and thanks for coming to to see me after sort of a after lunch. And I hope you don't fall asleep too fast and don't snore too loudly if you do, please. Till I get in. Yeah. Let's get into it. I'm gonna talk a bit about how you grow growth. Right?
And how you sort of think about building growth teams in a product engineering organization. Because it's it's sort of what I've done for a while. And I'd love to sort of share with everyone some of the stuff I've learned and maybe there's some stuff you can take away from it or maybe there's stuff I'm just talking complete nonsense.
And then please come to the q and a afterwards and tell me if that's so because I'd love to hear that. So I'll go a bit through this. Right? The the top bit sums it up. Like, how do you go about changing your organization to a model that works better for growth?
Capital g, we'll get into that later, while keeping all the good parts. So your culture, people being happy, everyone being really bought in and building all the stuff that you have because there's always way more to do. And I'm an engineer by trade. Right?
I just dabble in this growth and product stuff. And in the end, you need to keep things running and working. So we'll go through some examples. We'll we'll highlight some learnings along the way and talk about some stuff that that I sort of found you always have to have.
And then we'll just sort of summarize a bit at the end. So super simple, nice and quick. But I guess the key thing to sort of realize maybe and great for this audience, hope, is that we'll talk a lot about, like, smaller organizations.
I've never been in giant corporations or anything like that. So we'll focus a bit on startups and scale ups and how to start thinking about growth in those sort of organizations. And I guess well, I've been at a bunch of places over time.
I'm I'm pretty old, so I've been doing this for, twenty years. Originally from Utrecht in the Netherlands. Go there. It's way nicer than Amsterdam. Less tourists, still nice canals and stuff. Moved to to Edinburgh fifteen years ago with my lovely wife, Marlus, who's over there.
And I worked for a bunch of places, started out in security, CCTV, that sort of stuff. I'm not actually an engineer. I sort of did psychology and then fell into engineering after that. But moved over ages ago to the sort of tech world and ended up at Skyscanner for ages with loads of great people here who've worked there.
And ended up working for Travelnest, a smaller startup in the travel space. That's also great and still here. And ended up at Deliveroo as well, working for them for a while, going into more logistics. And that's where I sort of ended up where I am now, which is probably a company none of you have ever heard from because it's a Norwegian company.
We're Norway's biggest online grocery, sort of Norwegian Okado, I guess. And we're we're Norway's first unicorn. So we're we're a proper sort of tech start up scale up stage there as well. We sort of I guess our slogan is we want to make space for life.
So we try to, you help people get groceries to their door without any effort. So they've got more time to do other things. And to do that, we've built a sort of end to end chain from logistics all the way into the customer buying stuff on the app and on the website.
And that's sort of where I come in. I support the teams that build all the all the customer facing stuff. We've got other people dealing with the robots and all the fancy things, and I just look at that very jealously going, that's awesome.
But it's great to help the guys and the girls and everyone who builds all the great apps and website stuff that we do. So part of that also is to help them into this growth journey. And I think not everyone here lots of people will know what what we mean when we see growth.
Right? And we talk a lot about growth in lots of the great talks that we've had on this awesome on awesome Turing test. But I reckon I'll do a really quick and super inaccurate primer just going over what is the growth thing and where do we go.
Just think, you know, so we're all on the same page and so we can all know what we're talking about. And I think I'm gonna I'm gonna do a boo boo and, like, make a shadow on the thing now because I'm gonna point at this thing and say, it's this capital g thing.
Right? That's sort of the important part. It's the there's growth. There's growing your company. There's growing as the normal work we all know, but also growth, the methodology. And that's an interesting thing to talk about. And I'd sort of start off and I'd like to start with this sort of thing.
It's it's sort of started from pirate metrics. Right? This is back in two thousand and seven. This this really pains my age. Dave McClure sort of invented this thing called pirate metrics where you look not just at your own parts of what you're trying to build, but you think about the entire customer journey.
So how do people, even though you're there, how do people find you? And this is people who have a problem to solve. Right? A problem you want to solve for them. So how do you bring them all the way from, you know, coming to you, finding you to solve that problem, into actually solving that problem really well, then going into copying back time and time again, which we call retention, bringing their friends along because they're so happy, which is the referrals thing, and then in the end generating revenue for your company.
So it's a holistic view of how a user actually finds you, how a customer finds you, how they get to your product. But in loads of our companies, I'm sure, like, lots of us who've seen this a lot, this gets really siloed. Right?
There's a bunch of people, sales, marketing, whoever, who looks at this first bit of trying to get people to know about you and to find you. Then there's people normally in a sort of product organization who build a great product and make sure that people actually start using it and make sure that it's great to use so that people come back and stuff.
And then there's people, customer success or whoever or other marketing people who think about referrals and how you get friends along. And there's people, commercial or whoever, who thinks about revenue in the end, but it's all a bit sliced up. And these slicing points build friction.
And this is all completely stolen from Andrew Chen because he and Sean Ellis sort of were the people who popularized some of the stuff. So great link down there. Go look at the blog post. It's fantastic. Summarizes the whole thing way better than I can.
But the thing on the left, the product dev cycle is what often happens. Right? Because you as a product engineering team are building in isolation, relative isolation. You still talk to customers. You still talk to things. But, you know, you get customers thrown at you from the marketing side or whoever.
Build stuff, figure out if it works. And there's a trap there where, you know, you build something awesome, you launch it, you throw a bunch of customers at it, people use it. They don't actually come back because it's not quite the right thing.
And your user numbers slowly die over time. And you end up in a place where you tear your hair out and go, was so great. What happened? What changed? Look at competitive products, say, add more features, build those features. And then in building those features, go through the same cycle again where this happens over and over again.
And like, I've seen this happen a lot at companies. I've even seen it happen at companies that have a really good view of this growth because it's such an easy trap to fall into. And that's where growth comes in. It's the scientific method applied to KPIs.
This is a quote inside a quote, so it's super meta. Stephan Dupree said this. And it's sort of a way to figure out how do we take that holistic view from AAR, how do we apply the scientific method to that, and how do we build this sort of iterative hypothesis driven cycle.
Right? So you you look at this entire holistic user journey, you figure out where are the places where my levers are, where can I affect most change, how do I prioritize of all the stuff in there? Right? This is important. It's not just the product people doing the product bit.
It's it's looking if there's way more gains to be had at the start of this in finding the right type of users who come into my product, then we should focus there as a company. Right? We're not just sort of blindly going through this one bit because it's the bit you are supposed to look at.
And then how do you build that and experiment and execute and validate that your idea is actually right and then analyze and figure out what are the next steps that come on top of that. And this is not different at all from, like, for for product people in the room, hope there's a few, it should be great.
Like, it's not different from product thinking. Right? This is a great book by Martin Kagan. It's it it goes super in-depth about the what I see sort of as the right way to build products and a lot of best practices in there. And a lot of that has massive overlap with all of this growth thinking.
Because in the end, you're just trying to do this, right? Get everyone in your in your organization to have a shared and aligned focus of making your customers solve their problems and doing so in the best way possible. So that's growth. There's loads of really good stuff there at TuringFest.
Links here which you can just search the website. So Jara Pauli did a great thing a couple of years ago. Rebecca Moore did a great talk. Jonah Lord did a great talk about this stuff, and they go way more in-depth about the actual organizational side of this thing.
I'm gonna just talk about some of the boring bits, guess, or the not not theoretical bits. I don't know how to say this. But, like, the practical parts of it. Right? When you want to do this, how do you actually accomplish that? And what will you do? And it can feel like a huge change.
Don't feel like you have to read all of this, but I sort of listed the whole pile of stuff. I even left my notes in there at the top to say, oh, I should point out cross functional teams here. So I'm gonna do that now.
There's there's lots of stuff there, like like team structure and things like that. And we're talking about products empowered product teams there. So a group of people who have a vision, a mission, who work together as a group with different disciplines. Right? Engineers, product people, data people, designers, all working together to achieve a common goal.
And that common goal is then done by those people also having ownership of stuff. So product service area or a bunch of services or what have you. Right? There's loads of things in which you can slice that, but there has to be a bunch of people who can work on a bunch of stuff to accomplish goals together.
And how do you organize these teams? And how do you slice into that image that we saw, right, with with these silos? Does does this growth thing sit within product? Is it a marketing thing? Is it in between? Is it its own thing?
And what do you do when you're international and there's there's local people having to work on, I don't know, making things work in Germany. And, you know, all that stuff has to be done. How do you slice that in? How do you set direction?
How do you set up collaboration between those teams? How do you do ownership? What what's this enablement thing that sort of comes into there? Loads and loads of stuff. Importantly, the people factor, right? People need to be happy doing this and working in this growth way.
And, if you're hiring, you need be able to find people who do that. So the good thing there is that there's a lot there, but it's all relative. So there's no easy one way is the right way answer. But there's a lot of sort of these these dimensions that you can use to figure out what is the best way for your organization to start working in the sort of scientific iterative growth way and keep people happy while doing so.
So I'll just quickly going to sort of point them out, like, know, size of the organization, how big are you? Are you small? Are you sort of three hundred people? Are you a thousand people? Are you actually hiring and planning to grow? So can you can you look at it forward and sort of say, okay, we create new teams or do you need to change stuff up inside your current organization?
Are you actually tooled up pretty well? Can can you do the stuff you need to do okay? Or is there loads of stuff to try and figure out how to do? And how fast do you have to be in getting to that point of being sort of really good at doing this growth thing and having all the tooling in place to, you know, send marketing messages to people, all the stuff you want to do?
And actually, important, like, our people bought into doing this and the sort of idea of doing this in this way. And I'm gonna talk a bit about this sort of first bit. I this is I think I really don't like drawing stuff in, these presentation things.
So you'll see a lot of Miro boards coming through. So if you really hate Miro, sorry, but I like it. Because it's way better than my handwriting if I try to write stuff properly. So I'll talk a bit about startup piece, scale up bits in here.
And we'll start, I guess, with talking a bit about the startup side of that. So I worked for Travelnest for like a year and a half, is great. Really nice organization. And in there, we sort of did a bit of a growth pivot.
So we were already working in a really good sort of product way, which looked at at at what are the two sides of this marketplace. So what Travelnes did is we created a place where people who own holiday homes can have one place where they input all the data and images and stuff about their holiday home.
And then it gets pushed to Booking dot com and Airbnb and Expedia and all the channels where they could then get bookings for it. So trying to aggregate that and build a sort of place where that's centralized. And so we had teams working on the sort of the user side of that, the holiday owner side of that, who had to input stuff.
And teams working on getting things out into all these channels and trying to figure out how that works. And as we were growing, we reckoned that wouldn't be the right shape. So we made this sort of version of the pirate metrics of the AAAR thing.
That's that is sort of the the the travel SD version that has an acquisition, activation, conversion, and delight in their things. And we shaped our teams around that. So we built a team on the more acquisition y side where also when we got more salespeople, they ended up in that space.
We built an activation team to figure out how do we actually get people who start using this to put properties online. And of course we looked at like once they've done that how do we keep them around and get them to add more of their properties if they're really rich and own lots of properties.
And that's where also customer success and other teams slot in. So nice cross functional teams that sort of work together to hit these. And the thing we had to do, the big learning there to be able to do that is this, which is a growth model.
So this is not me. This is Mark Shelton, who's great. And still at Travel Nest. He's an awesome person. And we built this on a giant whiteboard in the office. And this sort of describes all of those stages. Right? So the acquisition, blah blah blah.
Bits with all the metrics that really sort of matter to know where they go. So we had to build this data model so we could map the teams onto this data model. And this really, really helped us in helping everyone in the teams know that these are the things you can move.
This is your area of ownership. Right? If if you're working in this acquisition space, then your main focus is probably on figuring out which ones of those yellow blocks are the things that are the metrics that you can move by building stuff, by running experiments, by going with stuff.
And this sort of really helped us as we grew and as we added more people and more teams to keep making sure that everyone was always working on the most impactful things. But we also had a shared language to talk about those most impactful things.
And this differs with different sizes. Right? So this is gonna be a Skyscanner example because I've got Skyscanner airplane sort of thing in there. You see I've put the old logo by the way. Sorry Skyscanner people. But this is about sort of the bit where I was there and that that that's the logo we had back then.
It felt it feels nostalgic doing that. Super complicated slide, but I'll just point it out a bit as to what's on there. So the point I'm trying to bring across with all these little people on the thing is that we were a large organization.
Right? At this point, eight, nine years ago, Skyscanner was three hundred people, something like that. And we were organized in a fairly sort of product y way, right? We had marketing teams that did great work in getting the work out there and getting things moving, but they were fairly siloed from all of the different product engineering teams.
So our people working on flights products, people working on hotels products, car hire, all the internal stuff. And we had to make a move there for multiple reasons. So we wanted to move from this place of having a fairly solid marketing organization to an organization that could actually work with this growth methodology and apply the scientific method to especially this first part of the thing.
Right? How do we find the right people who have a good who who want to book travel? How do we get them to us? And how do we move from there to actually make sure that they do that and they they're happy and they come back to us, and we don't have to pay for them via advertisement or whatever time and time again.
And at the same time, we're trying to solve for this problem where we were sort of throwing people over the wall. So a lot of the product teams were focused on, you know, how do we how do we get the people who come in to convert and to actually buy flights.
But not really taking into account where people came from or what type of people they were that came into there. So that was all a bit sort of friction y and didn't go as well as good. So we made a bunch of changes.
This is super simplified, right? Everyone who's been around at the time ago, God, this isn't right at all. But we moved a few things around. So we made our marketing organization into a growth organization. That was a big move. Lots of complications. The talk that Rebecca Moore did on that is a really interesting because that's a lot of work that went into that.
But we also, at the same time, merged a whole bunch of relevant teams from our product engineering organization into that new growth organization. So this wasn't just marketing with another name. This was actually a whole bunch of teams from various parts like the team that sent out the newsletters and that sent out price alerts and stuff like that went into that organization.
Right? Because that's all part of these sort of growth remit bits. That's that's in those AAR, parametric terms. That's a retention team that sort of lives in there. So this this sort of iterative approach of moving teams about building the best shape that we thought we could, and at the same time, moving into the Spotify inspired sort of tribes and squats model.
So everything just ended up in slightly different shapes at the same time. Lots of change happening, but, you know, not one big bang, which is good. Because you you don't wanna end up in a situation where everything is frictiony and then explodes. And that's what we try to avoid by doing these iterative steps.
And one of the the key interesting learnings there, at least for me as an engineering manager, right, was that by mixing people together, by having some teams that were just pure product engineering that just build stuff, mostly sort of the the more low level things, by having a few teams that were just marketing teams that helped other people or that, you know, looked after our influencers or stuff like that.
But also building teams that now started to have marketing people and engineering people and product managers and data people together in one group. We managed to, at least I hope, sort of speed up the sort of acceptance of this growth thing really fast because people have network.
Right? People talk to each other. People know each other. And by doing this, we built a whole bunch of champions, I guess, hopefully, the company that could talk well about this this methodology and these ways of doing things. And that really sort of lift and breathe, doing these experimental approaches and moving fast to do all this stuff.
So that was an interesting interesting learning. And the thing that came on the back of that is that, you know, those team shapes, right, who is in what team, how do you mix marketing people, product people, engineers, That changes over time with what the team will do.
And a good example of that is our paid media team that we had at Skyscanner for while. This is like a two period or something where we moved from being mostly marketing people who work really well at like figuring out how we work with Google and Facebook and everyone to get ads into the right places and use lots of internal tools and a few agencies to do that, to bringing that in house and adding engineers to that team and adding product people and extending that and building that stuff.
We had a great team built there. Then at some point finding out that actually that team has now gotten pretty big, and we ended up having to split them again because they internally split into two teams, sort of doing lots of marketing focused stuff with the local teams and doing more of the engineering work, right, building the pipelines and making sure all the stuff worked.
And those teams started to become too big and to drift apart. So we had to make the choice again to fit that back, but keep the teams really aligned and they'd work together now. So they were sort of super close together. And that's sort of story of that change.
It's also something I found at Deliveroo, which is interesting, where we took a third approach, right? So Travel Nest was very much moved the whole thing into thinking about growth. Skyscanner was very much pivot marketing into growth and then add engineering in there.
And at Deliveroo, ended up with like a middle way where we built a growth organization underneath the product organization. So we added a bunch of teams that looked after Deliveroo Plus, right? I guess paying a bunch of money to get free delivery. The new user experience teams that looked after activation in the AAR model.
All that stuff was things we sort of built and teams reset. There we found that that actually caused friction. So by building that separate growth organization, we misaligned the teams that built the apps and the websites and stuff like that. And that's and the teams that looked after this new user experience.
And we saw a bit of sort of why are you operating in my space? What's happening here? You're doing an experiment in my on my website that stuff breaks, who's gonna look after this now? Right? So friction appeared, misalignment appeared. So we made the decision to bring all of that together under one larger organization, which still kept the teams as they were.
So everyone was still with their friends that they worked with, and everything worked well. But the sort of larger level of figuring out alignment and figuring out the goals together, that sort of ended up in the right place. So that was a good move.
And lots of those learnings went into what we are now doing at Oda, delivering groceries in Norway. There's a distinct lack of snow there, so it must be summer. And we're going from having like being Norway's largest online grocery to all of a sudden trying to grow really fast in Germany and in Finland as we're doing this year.
So we had a different challenge there again, where we were trying to sort of say, how do we go from having six, seven years to grow in one location to repeating the trick in all of these other places? And to do that, we sort of were quite deliberately mapping out.
Again, don't read any detail on this. This is just an example. But we took sort of a jobs to be done approach, right? Like what is the the things we know we need to do to be successful in Germany, in Finland when we launched there and sort of took a two year horizon and say we want to max out the the capacity of our fulfillment centers because we're putting a lot of money into building all these giant warehouses.
So we have a sort of max cap on natural growth. We can only get so many groceries that we can deliver. So we said, well, a couple of years roughly, let's see if we can go there And what we need in place for that?
And then on the back of that, we try to figure out, okay, what teams do we then have to build and of what size to be able to do these jobs and build the stuff that we need to do to be able to do these jobs and then own these things?
And that sort of was a a good exercise to figure out a lot. There's I've I've plopped a couple of these piles of these teams in there in in the real one. At the bottom, can see, it is really crucial. We also mapped out the the links.
Like, what what teams did this did this team need to have in place to be able to function? Like, who need to enable them? Right? What what do we have to have to be able to? So we need to have an experimentation platform of some sort to be able to experiment with this concept of activation and to build good ways to activate our new users and get them to actually really experience the product and use it well.
And that combined with really mapping out ownership and looking at this thing. So this is a complex thing. Again, I really like drawing super confusing things apparently. It's sort of the the view of, like, if we were to add the the yellow box at the top right, which is a third party messaging tool where we can just send people messages to say, Coke is Coke is cheap now and you buy a lot of Coke, so come come back to us and buy a bunch of groceries.
That seems like something that's super clear to bring in. But it it hits all this other stuff. Right? It hits the the big messaging platform that we have in the middle where stuff has to go, where people's user data has to be somewhere.
There's lots of other messages that go through the system. So like people setting up accounts, people ordering stuff and order deliveries, also things like, you know, substitutions. Like, Norwegians really like their Taco Tuesdays, like a lot, like a lot, a lot. So if you deliver the wrong sort of type of taco shells, people get really pissed off.
So we've put messaging in place to make sure that people actually get warrants upfront if we have to replace things for other things. So all of that has to, like, combine and loads of different teams own these things. So we really had to put effort into mapping all this stuff out and actually figuring out what teams are aware, what is unowned in this space.
Right? Because we've grown super fast over the last six years. So as every company has there's loads of technical depth. We had a really good talk about this yesterday from from Sally. And we're we're trying to deal with that at the same time as doing all this growth stuff.
So how do we build teams who can take some of these bits of the giant monolith and pull them out and build a service around them and do all the good stuff of making a more modern usable service around it? And that sort of led us to this slide, right, where we have teams, groups of teams that enable each other.
So we have a bunch of people working on the data side of things that enable what we call our shop platform, which are the people who build all the apps and websites and the services and the tools that we need there. They in turn enable the growth teams who build on top of that and who figure out like how do we take this value that's created in our shop and how do we bring people into that and how do we expose it to the right people.
And then they in turn enable the local teams who are figuring out how do we get really clear that for the Norwegian context, we are super cheap and convenient. But for the Finnish context, we're focusing more on you don't get massive delivery fees with us.
All competitors chase like sort of ten quid to deliver stuff. We don't. So different angles, but using the same tooling, using all the same stuff. So we don't end up with repeating ourselves multiple times. And more importantly, so over the next years, we can add countries to that without any extra effort, which is where the scale advantage comes in a lot.
And that's sort of interesting. Right? But there's a lot of stuff comes up in that. Like experimentation, for instance, is something that's plopped up a lot in in in the things. And we've seen in all companies, at least I've been, where experimentation becomes a prerequisite.
You need to be able to to experiment, to go through this build, measure, learn loop. So, you know, I've extended it a bit where we put in the sort of steps that come into building, which is going from idea to derisking and implementing and testing and deploying it and running it in production and then measuring and learning from that and then taking the next step.
Really good stuff in there in The Lean Startup by Eric Riese. If you haven't read it, read Because it goes into this concept a lot. And that's the same concept as this slide we just saw earlier. Right? This sort of loop that Andrew Chen proposed for the growth methodology and the growth framework of building, measuring and learning in a sort of controlled way where you build hypotheses and then go through them.
And I guess because you're doing this, right? You're looking at this space of the full user journey through your product and then you're trying to figure out how do I operate in that space? How do I find bits in there where I can step through that space?
And sort of try and learn a lot, learn, learn, learn, fail along the way. You're probably gonna fail a lot when you do this. Learn a bit more from your failure. And at some point, find a solution that's probably vastly different from where you thought you'd be because, you know, you can only be so, right, when you try to think this this stuff up upfront.
But, you know, that is sort of where you want to be. And to do that, each team should have lots of ways of doing this. And if you don't have a good experimentation framework, you'll always be bottom right here. Right? Like, you're building sort of large new systems because you can't really measure stuff, so you're building a big thing to have a big impact.
And the better you are at experimentation and the better you are at having the the systems to do this, the easier it is for all teams to be more on the left here, where you can be faster, where you can deal with more uncertainty, where you can take bigger risks, where you're less afraid to fail because you're investing less time in doing this thing.
So this is sort of an important way, right, because I know one of the big things we had to do at Deliveroo, for instance, was to try to really convince teams that they didn't always have to build large things. You don't have to put a whole thing into production as a working stable system.
And you can actually just hack something together as long as you're happy as a team to say, okay, once we've learned, we either do it properly or we throw it away. We just remove the code and clean it up again. And there's lots of things there you can do.
The the user research or prototyping are lots of interesting things there to go. And I think one key point I wanted to mention, I've stolen this slide from Colin McFarland, who used to run experimentation at Skyscanner and is now doing experimentation at Netflix.
He's great. So we really had to push, push and push and push and build teams and really focus and invest in getting experimentation running. This is our experiments, number of experiments versus time curve. And you can see when we sort of started building our experimentation platform for a few months and then really invested in getting a bunch of teams on board and getting the work out there and getting all teams to work in this experimental way.
And you could see it take off once we got a sort of certain, I guess, number of people who were doing this and it became ingrained and the tooling became mature enough. Enough. We we we had to do without doing this deliberately, we would have never gotten to that upswing.
We had to put teams in place. We had to invest in it. We had to build a platform. And that's sort of the other thing. Right? This is this is a horrible cheesy slide. Sorry for that. Like data is the underlying thing for all of that.
You have to have your data in place to be able to do any of this experimentation stuff. And having a good clear view of where your data is produced, what you produce, why you have all these events, what's in those events, what are you tracking, and then getting into the right places, into the right shape, and teaching people how to use the data at the right places themselves, right, without having analysts around to do everything for everyone.
It's way better to just teach everyone how to do this stuff. That is sort of super important as well. And as you saw on the travel nest example, right, if you do it as well, you can have a cohesive thing that will really help people understand why they're doing what they're doing, why it's important, and give people the confidence to sort of say, okay, hypotheses.
I can I can make guesses? I can start doing things that might fail. That's that's important because there's loads and loads of stuff to talk about in this space and we could chat I could definitely chat for hours am I gonna because we'll run out and it's just after lunch and everything.
But, you know, apart from all the stuff like alignment and OKRs and agile cycles and how it all ties into this stuff, right, because it all ties together. Those experimentation groups are clearly like sort of fitting into an agile cycle pattern where if you're doing just waterfall, there's no point, but it it all fits nicely together.
But there's a few important things I wanted to lift out because these are easy to forget when you're trying to think about this this growth stuff. Psychological safety is an important one. Right? People need to be safe, feel safe, trust each other, and have the ability to use that to do things that might fail and not feel afraid to do that.
And that's the way in which you get people to, you know, think exponentially, think of something new, try that out. And then if it doesn't work, you know it didn't work. That's a really good learning. You should celebrate that together and go from there.
Right? That's important. And the other part of that flipside almost is that as an engineering company, as a as a product building company, you still need to be there for your people. So working in that growthy experimental way doesn't mean that stuff can become unstable because there's nothing worse for keeping people around for retention than a product that isn't reliable, that is that might or might not be up and running when you go there.
So that always needs to be kept in mind. And again, it's building the right teams with the right people then to allow both building in a fast way, experimenting, but also, you know, keeping things alive. Like a big example is there, if you do a pop up that pops up on screen, you know, if it fails, it shouldn't just sit on screen unclickable.
Can't get it away. Your website is now broken. You should build something that doesn't show when it breaks. And just make sure that, you know, then your experiment is broken. Fine. Fair enough. But at least your customer can still do what they were planning to do.
So not gonna run through all of this, but it can feel like a huge change, and there's a load of load of stuff you have to think about. But, you know, it really depends on your organization and circumstances. So you can mix and match some of these things to figure out what's the best team shape, what's the best organizational shape.
Do I use OKRs? Do I not? How do I align these teams? And then build, measure, learn on that. Iterate on your organizational shape. Iterate on the tools you give people to work with. Iterate on all this stuff. Because in the end, you know, it's it's you need to use the best approach for your organization and then iterate as you evolve because the company will grow, people will join, people will grow and learn, and this whole thing will change.
So if you're in a start up, this might be like months where you have to like change your processes and stuff. If you're a bit more settled, it might be multiple months. But still, this is never done. There's never one right way forward.
And you're always sort of looking to figure out where are the things that break as I grow in scale. How do I tweak them? How do I get to the next level? It's good. Well, that's me. Thank you so much. If you want to talk about this, if you've done stuff in this space, please come talk.
Three p. M. Roundtable thing down there. Thank you.