In engineering we (rightly) talk a lot about how to scale our systems and our infrastructure. Yet some of our very hardest challenges come when scaling the people side of things. How do you survive your team doubling, tripling or perhaps even a 10x growth in a short period of time? What does it take to grow fast AND retain the bits of your culture as a team or organisation that made you great to begin with? How do you know when to change how you do things, without just cargo culting? Having scaled a number of teams at different speeds, Meri will talk through some of the inflection points you'll experience, how to navigate them, and reflect on all the things she wishes she'd known just a little bit earlier...
← All talks 
Build Engineering Turing Fest 2018
Five Things I Wish I'd Known Sooner About Scaling Teams & Culture
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
So this is a talk about five things I wish I'd known sooner about scaling teams and culture. And it's always a little terrifying to give a team talk or a leadership talk on an engineering track, so hopefully you guys will forgive me. I started out as a hardware hacker.
I'd built part of South Africa's first satellite when I was a teenager. It's where I'm it's where I'm from. It's where I grew up. I'm from Cape Town despite the current accent, which which who have you got kids? Fair fair number. I have great advice for you as parents.
Don't let your children do anything cool when they're young. I sold it something that went into space when I was sixteen, and it has all been ******* downhill since then. And then I've had a kind of a weird career. I I was a Procter and Gamble for a really long time.
They're the biggest consumer goods company in the world. I helped build the government digital service, where I think my main achievement was the giant cake with WK on it, but the team seemed pretty happy too. And I've been at Move for a couple of years, and as I said in the intro, I host LeadDev.
Now there's nothing more terrifying than trying to take a selfie with eleven hundred people, as you can see from that. That's not joy, that's terror on my face. But in that time So the tech team at Moo's doubled in my first year there.
A GDS went from thirty to three hundred people in nine months because somebody promised the prime minister a date. Very agile. So I've been through a lot of quite interesting scaling experiences and thought I'd share some of that. So, my first thing I wish I'd known sooner was why the clicker doesn't want to work.
Okay, so I have to point at that, not at that, on it. So my my first lesson is that DRY just doesn't work for human communication. Don't repeat yourself is a wonderful programming principle. I'm from the Python community originally, so it's one I definitely ascribe to.
But it really is a terrible principle for for human communication. You need to repeat yourself. And every time I've been surprised that, like, a weird decision was made or realized that people just really weren't on the same page, it was like, oh, okay.
We only said that once or four times. We needed to say it a lot more.' There's some research that shows that people only really hear you after you've said the same thing consistently seven times. So And people really, when they don't know what they don't know, weird stuff happens.
So I like to joke that the thing that Sorry. Can I ask for some help? AV folks, where am I meant to point? Because this is getting very problematic. Point at the back. Okay, I will try. There's too many of you in the way. Clearly, it's not working.
So, one problem that you have when people don't know what's going on is the only thing that software engineers produce more of than code is conspiracy theories. If you want to explore the great and amazing creativity in your team, don't tell them what's happening.
And then go and ask people what's going on, and you'll hear some fascinating theories. So my advice is be clear, be consistent. It's important to use the same words. This sounds really silly, but it does matter that you're using the same words when you say what the strategy is, or why we're doing this thing, or why that team is moving off to do something different.
And remember that those other people probably still need to hear that message beyond the point where you're really worried that you're being repetitive. And don't just communicate in the present. One thing that I've found really successful in the last six years or so, using architectural decision records to communicate to future generations what the hell we were thinking at the time we decided to do something.
And making sure that in your ADRs, you capture the context that you are in. Because if somebody five years from now, who might be you and you've forgotten, or might be somebody in the team who's joined since then, looks back and goes, why on earth did they choose this database?
Why on earth did they go for this pattern? What were they thinking when they chose this CDN over this other one? If they can go back to something that tells them what the context was at the time, and they're like, oh, those things have changed.
That context isn't what our context is now. It's very easy for them to then make a well informed, good future decision. When you find crazy in your legacy and you just don't understand it, it probably was sensible at the time. Everybody's trying to do the best they can in the moment.
And I mean, I've had to deal with some legacy stuff that it's so legacy, it's vintage. You can steal that. It finance people wince, but it makes engineers laugh. And so, ADRs is probably one of the There's some really good stuff written on it.
The folks at the Government Digital Service in particular have talked about that as a way of working. And I'd highly recommend you adopt it for your teams. The second thing I wish I'd known sooner is that scaling teams is about creating conditions for success.
And I think we all hate bad bosses, and we're very good at recognising the archetype of the bad boss, whether it's the pointy haired boss in Dilbert or You know, we describe them, we say they're clueless, they're empty suits, they're pointless. We're all familiar with the Seagulls style of school of management: Fly in, shout at everybody, **** on everything, fly away again.
I always judge, like, the pain level in the room by what kind of laugh that gets. And so I remember becoming a manager for the first time and having been subjected to some fairly terrible management practices, and deciding that if I had to do it, I wasn't going to do it badly.
This is the best catgif on the Internet, I can confirm after exhaustive research. So my approach to having to do something is I refuse to do things badly, so I'll find a way to do things well. And so when I started leading teams, was like, okay, how can I avoid being the kind of terrible manager that was inflicted on me earlier in my career?
I found this, which is a great bit of advice from Katerina Fake, that there are there are three kinds of managers. The ******** umbrella protects their team. The ******** funnel finds the person that they least like and concentrates all of the terrible onto them.
I see the that ouch noise. Those are people who that's happened to in the audience. And then the **** funnel sorry, the **** fan. Just spread it all around indiscriminately. So, like, step one, be a ******** umbrella. Like, that's that's a good aspiration for for basic leadership.
Right? And then, because I'm a nerd as well as a geek, when I don't know something, I try find research. And so I am nerdy enough that I have a favourite management book. You can all choose to never speak to me in public again, but that's okay.
Which is First Break All the Rules. And it's my favorite book because it's very, very data based. It was based on a Gallup study. They did hundreds of thousands of interviews. They went looking for what made a certain division more profitable than the next.
Why is this factory safer? Why is this restaurant the best in the chain? And went looking for what made teams high performing. And what was interesting is they found a bunch of stuff that also makes teams happy. And the fact that the things that make teams high performing and happy are the same gives me great delight.
They found that there were these twelve predictors of high performance. My reaction to being given twelve things to memorize Everybody who's trying to take photo, don't worry, it'll come back in a second. Is to Oh, great. Now I'm drowning. I can't possibly memorize twelve things.
So let's zoom out in terms of how we create a good environment and understand motivation. Who's read DRIVE and Pink's book? A few of you. So DRIVE is a really interesting kind of pop sci style summary of the psychological research over the last few decades into what motivates people, what makes them get up in the morning excited to do what they do.
Dan Pink basically identified that there's these three things: purpose, autonomy and mastery. There's a great twelve minute long video of a talk of his that's very worth watching if you don't have time to read the book. He says, motivation is purpose, believing in why, autonomy, getting a say in what, and then mastery, being proud of how you're doing what you're doing, And then take away any negative factors that detract.
And that's interesting because it maps with these questions quite well. So, purpose, do I Does the mission or purpose of my company make me feel like my work is important? Do I believe in why we're here, what my team is doing? Autonomy, do I know what is expected of me at work, and do my opinion seem to count?
And what I find fascinating, but it's really held true, I've been leading teams for about fifteen years now, thousands of people in those teams over the years. And particularly for creative professionals, for designers, for developers, for content folks, It really matters that we feel like we're doing the work well, as well as that we're doing good work.
And I think some of this, you can see that the research was done in the late '90s. I think if you asked the question about materials and equipment you need to do your work right, that would have knowledge and people in it if they asked it today.
Do I have the opportunity to do what I do best every day? Is there someone at work who cares about my development? Is everybody around me committed to doing quality work? It's terrible to feel like you're the only one who wants to do things well.
Has somebody talked about my development with me in the last six months? And do I have opportunities to learn and grow? And it's really interesting to me how much of this about motivation is about feeling that you do good work in a good way.
But there's a few things not covered under Purpose Autonomy and Mastery. In the last seven days, have I received recognition of praise for good work? Does my supervisor or someone at work seem to care about me as a person? I love that, like, my super nobody's called the supervisor anymore.
It's very very, like, nineties video shop. Right? You're not my supervisor. And then I love this last question because it is a master class in cultural differences. So in America, apparently, the question, do I have a best friend at work? Is perfectly okay.
In North Europe, it incites a reaction from from you all of like, **** ***, the company doesn't get to choose who my best friend is. So let me translate for a moment for the Northern Europeans in a room. Is there someone at work who, even if the company isn't paying for the booze, I would willingly spend time with and talk about something other than work?
Yeah? Okay? Good. And so this is about being respected and rewarded and this feeling like you belong. Camille Fornier speaks about this stuff as well. She was the CTO at Run the Runway. She calls this community. I call it inclusion. I think it's about feeling like you're somewhere where you can be part of the group.
You can feel like you belong. And so that remix, this is the one to take a photo of if you're desperate to have it before I get to upload the slides afterwards. What we're really talking about when we're trying to create space for teams to do brilliant work is all four of these things.
So, purpose, believing in why, understanding why we're doing what we're doing, how does this team's work fit into the broader picture, autonomy, getting a say in what, feeling like your opinions matter. Mastery, being proud of how. And then inclusion, feeling like you belong.
And getting a broad range of people to feel like they can belong is actually really hard, but really worthwhile. We all know that diverse teams form homogenous teams very significantly. And I suppose underlying all of this is a belief that I have, which is, I promise this is the most hippie slide of the entire deck and it gets a little easier from here, but every person is capable of virtuosity, every role can be brilliant.
There's an amazing story of Disney trying to work out why at their theme parks certain housekeepers were so much better than others. And they realised that the housekeepers who were consistently both happy and outstanding were the only ones who cleaned the ceiling fan.
This is correlation, not course. But it was because they realised that, particularly in the States, lot of the time when you arrive with your family at Disney World, you have just driven with some fraught children in the back of the car for however many hours.
And the worst, the first thing you do when you get into the hotel room is put the air con on and flop down on the bed. And so if dust and grime lands on your face from the ceiling fan, that's not a great start.
And so empathy was the main reason that these particular housekeepers were so good at their jobs and so enjoyed their jobs. They knew they weren't just cleaning a hotel room, they were making someone's holiday better. It was probably the holiday those that family had looked forward to all year.
And so every every person is capable of being great at what they do. Nobody gets up in the morning going, today I'm aiming for just south of mediocre. And if I could **** up everybody else's day along the way, then my life would be perfect.
I mean, sociopaths exist, and you should identify them and then either run away or exit them, depending on how much power you have in the situation. But on the whole, most people want to be good at what they do. And so finding ways to help them be great at what they do is what our mission should be.
The third thing I wish I'd known a little bit sooner is that different inflection points exist as you're scaling teams. For those of you whose Latin either is nonexistent or maybe a little far in the past, is the Latin for always in the ****, just the depth varies.
Goes over great with lawyers and accountants. You're welcome. And there are there are different things that come for free at different inflection points. When there's only ten people in your in your company, or When there's only ten people in your company, or in your organisation, or in your team, everybody knows everything for free.
Everybody knows what's going on, because everybody can hear all the conversations, they know what's happening. The first big stumbling block that start ups hit is when they hit more than ten people. Communication isn't free anymore. Communication needs to be thought about. People get confused or lost or they get their own stick and what's experienced often as kind of interpersonal conflict is actually just because people aren't on a level playing field anymore in terms of what's going on.
Over fifty people, people really start to be like, 'I don't know how to progress anymore, so I need a career path'. And so, we start to need to have more structured ways of having conversations with people about where they're going to go and how they're going to develop, because it's not all just obviously happening hugely organically when you're growing rapidly smaller than fifty people.
Over one hundred people, most people don't know everybody else. And so you have to start building processes and mechanics for people to build trust between teams, even if they don't all know the individuals. And then over one hundred and fifty, which is there's a thing called Dunbar number, which is theoretically the number of people you can maintain relationships with is about one hundred and fifty.
It's why small villages are the size small villages are. That's not work, that's total in your life. If there's more than one hundred and fifty people you work with, you can't maintain a relationship with each of them individually anymore, or the vast majority of humans find that difficult.
And so, again, you have to think about what's going to happen because people don't know each other, what's going to happen because fiefdoms spring up. Almost every very, very large organisation, and I've worked in a few places that are hundreds of thousands of people, it's actually just lots and lots and lots and lots of collections of, like, one hundred and fifty to two hundred people.
And getting them to to speak to each other and to work with each other is the is the thing that gets harder and harder as you scale. We sometimes also get too focused on the problems that are on the much further horizon. So the other thing I wish I'd known earlier was focus on the thing that's about to happen right now, not the thing that I see six months down the road is going to be a problem.
We're going to fall on our faces on this thing way before that thing is going to become the most urgent and most important. Sometimes it's more comfortable to solve the things that are further away because they feel less emotional. It's easy to get focused on the fact that six months from now people won't know how promotions work or people won't understand the architecture and so on boardings change.
But the fact that team A and team B hate each other's guts and can't collaborate properly, that's going to be a problem next week. But we'll shy away from solving it. So, like, pick your focus, but don't try to aim for the super long term.
So much will change before you get there. And I think, I suppose this is the core of the point about inflection points is you've got to focus on the right problems at the right time. I see so many, particularly engineering organisations, trying to emulate Google as they are now.
Find out what Google was doing when they're the size you are. If they were having the same problems you are having, and if the world that they were operating in at the time was the same. There's a wonderful book called Stumbling on Happiness, which is about the psychology of happiness.
And he eventually concludes that humans are pretty terrible at remembering what made them happy and pretty terrible at predicting what might make them happy in future, because we edit the past and we have very rose tinted glasses about the future. And he ends up There's an entire book of how you assess happiness and how you make good choices that'll make you happy.
And the eventual conclusion is just find someone who's basically exactly like you doing the thing that you think you might go do and then ask them, are you happy right now? And that's like the best advice he's got. It's a great book. It's worth reading even to just go, okay, this is not a I'm not dumb.
This is this is genuinely a hard thing. But I see so many teams trying to solve the problem that they might not have for another two years and ignoring the problem that they're already hurting because of. There's very few of us who need to build our own CDN in the way that Facebook or or Google does.
When I joined at MoO, they had a homegrown CDN. I was like, why? We're an e commerce website. It's an important e commerce website. I would like it to be up. Homegrown CDN doesn't seem the way to guarantee that. And the one of the answers was, well, Google built their own.
I'm like, yeah. Do you think we were experiencing the same problems that they were at the point that they chose to build it? Anyway, so be careful of emulating there's a there's a am a am a face a net goo? Whatever. There's a there's an acronym, right, for the for the the big the big tech companies.
So only steal their solutions if you're facing the exact same problem. You could spend all of your time trying to build this massive distributed platform that you aren't going to need until you're twenty times the scale that you are right now in terms of customers and revenue.
And you'll miss the fact that you're missing that key feature that they really want yesterday. So, you're never going to get to 20x scale. And then, the fourth lesson I have, or a thing I took far too long to realise, is that with people observability is much better than testing.
It's quite hard to test on people, doesn't go great. And so, I sometimes have where we plan when we're making a change, whether it's a career path change, or team focus or maybe the product roadmap is going to move or we're going to build things in a different way or we've chosen a different database or solution.
Sometimes have where we plan, have a hard we try, the impact we have doesn't match our intent. And it's very easy to go, but we went in with the best of intentions. What really matters is what the actual outcome was. Matters how people experienced it, not how you intended it.
And so regularly check-in whether what you intended matches up to the actual impact that you're having. I see far too many people spend all of their energy upfront in trying to do it right, and then none of their energy in checking how it's actually going.
The good news is there's tons of tools for doing this well. And the lesson that I suppose the key nuance here is you should do this all the time, because then it's not weird when you do it in the really important times. So use retros.
There's a great talk by Jesse Link, who runs Twitter down in London and video globally, about different ways of running retros. You don't have to stick to the vanilla, what worked well, what didn't, what should we do differently. There's lots of other techniques that you can use.
And if you help your teams have a culture of reflection and improvement, then they're much more likely to tell you when something didn't go the way that you intended it to. You're much more likely to spot it if measuring impact is a regular part of how you work in the day to day and the week to week.
So, use retros. There's things like the team health scorecard that Spotify have written about and have used for a number of years now. There are thousands of engineers and still using it pretty successfully. Lucky enough to know some of the VP engines and similar over there, and I think it's evolved a lot, they don't always publish the evolution, but it's a very useful starting point, and for you to figure out what matters to your teams, not just to grab their list and assume it's the starting point.
And then this is from a guy called Sam's talk called 'People are weird and I'm weird', which is about being an introvert and a leader, it's very worth watching. And one thing he does is have his teams talk about, like, decide what matters to them.
So this is a particular team where they wanted to be proud of the work they were doing, they wanted to feel happy, they wanted to feel like they were learning, evolving and that they were adaptable. And then they, as part of the retro every couple of weeks, would also score on that, so they could see what was getting better and what maybe needed more of their attention over time.
But the key point is it's very, very difficult to test upfront with people, with human related things humans are squishy and so rather than trying to do upfront testing, figure out what are the right ways for you to observe what's really happening and to make that observation normal, so it's not only when the really precarious thing just happened that you're asking, how are things?
Because that's weird. And then the fifth thing that I think I've probably been fairly aware of, I like to joke that I'm the one the Daily Mail warned you about. Right? I'm an immigrant. I'm a woman who works in tech. I have a job, which I think is worse than if I was living off the state, but I gotta check the headlines pretty regularly to be sure.
I'm queer. I'm disabled. My wife is British, so I'm over here stealing your women and your jobs. And I actually have I have a shirt in the Daily Mail font that says, I'm the one the Daily Mail warned you about. And when I worked for the government digital service, civil service HR formally requested I never wear it.
They were very worried I was gonna get, like, a photo taken of me leaving leaving the office in it. But I grew up white in apartheid South Africa, so trust me, I understand undeserved, unasked, unearned privilege. The happenstance that meant I was born this colour meant I had more educational opportunities, I had more I had so many more opportunities than my friends who happened to be born a different color.
And so, for straight white dudes in the audience who feel like you're always getting a hard rep, I hear you, I get you, but, like, we have to face into the fact that we were playing life on the easiest setting for a hell of a lot of the time.
So I worry when I hear teams saying, well and I get a lot of startups in London who are like, we just don't understand why we can't hire any women engineers. And I'm like, have you looked at your website recently? And they they go, well, we just can't find anybody who's a culture fit.
And culture fit started to become like dog whistle for discrimination. Right? It started to just mean not like all of how exactly we are right now. And so, switch that around. Culture add matters a lot more than culture fit. You don't need someone who's just the same as you.
I'm not saying hire the people who will cause huge ructions in your team, but hire someone who's different enough to add something new. Ask how will this person add to our culture rather than how will they take away. Because after all, the unit delivery is the team.
We don't achieve very much as individuals anymore, so it's not the millennial way. I'm an elder millennial, as I saw at a comedy special recently. I'm just in the generation ballpark. And so if we think about the units of delivery being the team, and my favourite question from those twelve that I showed you earlier is this one: Do I have the opportunity to do what I do best every day?
And so if we think of our teams as our unit of delivery, then we need to stop levelling people out to being equally and consistently mediocre. If you you always focus on what someone is not good at, it takes a lot of energy to take someone from bad at something to okay at something.
It takes the same amount of energy to take them from okay to great. From great to excellent. And so, focus on getting the most out of how people are different. You don't need everybody in the team to have the same skills, need the entire team to have a whole bunch of skills at that great or excellent level.
And then together they will be brilliant. We need that shift in perspective, because for a really long time, like the 80s and earlier, people were very focused on 'find the thing you're not good at' and focus completely on that. And it just levelled everybody out.
I hope you've all seen that before, in terms of a shift in perspective. We're not interchangeable resource units. And for those of you who are managers in the room, if you call your people resources, they get to call you overhead. So stop it.
So we're colors or we're flavors. We're we're better in complementing concert with each other. I I use this slide to go like, the Avengers are cool because they've got different different abilities, but I would watch the hell out of a Seven Hawks movie.
I gotta be honest. But, you know, they are a cool set of superheroes because they can all do different things. You know, mind blowing arrogance in Tony Stark's case, Captain America is super strong, Black Widow can kill you with her eyes, whatever. But if we think of this as people, if we think of people and roles and teams as a matter of casting someone into the thing that they are going to be best at, we're much more likely to end up with a high performing team.
How do we assemble that great team with complementary abilities? Those of you who follow me on Twitter know that my Twitter account basically turned into a Ghostbusters twenty sixteen, like, booking bot for a while. I was very annoyed at people on the internet thinking women couldn't be funny.
And we I took so many people to watch it with me. There's some poor data scientists somewhere in the center of the Odeon going, why the hell did Ghostbusters run for sixteen weeks at Leicester Square? And it's because if you fill a cinema once a week, that that movie keeps running for another week.
And it ran for it literally ran for sixteen weeks. It was amazing. Anyway. So, in terms of how do we how to so how to think about this a bit more broadly. When you're crafting inclusive environments, think about whether people looking at you, at your team, at your organisation, do they feel expected?
Is it obvious from how you talk about benefits that you're expecting working parents? Is it obvious from how you talk about your office that there's a prayer room for someone who needs it? How are you giving messages that lots and lots of different people are expected?
Treat people respectfully when they're in interview process or anything else with you. I had a hilarious example recently from the candidate side actually, of a candidate so clearly not listening when introduced, and assuming that my VPN, she happens to be a woman, and the engineering manager who works for her, who was interviewing this architect, he assumed that she must be more junior and also must be not non technical.
And repeatedly, when she asked a question, we'd go, this answer's too technical for you', and then answer the question to the guy. The guy who is both very aware that his boss is a lot more technical than him. And then he's just like, I don't understand that explanation, and looking to her for guidance.
And it was hilarious, because like And it was hilarious to see it from a candidate. Very sadly, lots and lots of people encounter that when they're being interviewed, when people assume that they're a role that they're not, assume they're more junior than they're not.
Treat people well when they interact with you, because otherwise you've got no chance. And then remember that everybody's asking these three questions. Wherever they're when they're deciding to join somewhere, stay somewhere, take that promotion, leave and go somewhere else. They're also asking, can I be myself and be successful here?
And given I'm the one the Daily Mail warned you about, I don't find a lot of people who are like a direct role model for me. I'm an interesting Venn diagram, right? But I look for whether the leadership team are all the same or not.
And when you can see some types of difference or some indication that there's differences in the people leading the organisation, you're more likely to go, oh, okay, there's multiple routes to success here. If you have that, but people in your organisation, your team don't know that yet, figure out how you make it more obvious.
One thing I really enjoyed at MNS Digital at one point, we realised that people didn't know our leadership very well, and they wanted to help them be known more as people. One of them was like a, for his age group, a world champion windsurfer.
And so when his video was all about his windsurfing, everybody was like, oh, wow. And then the best one, our COO, breeds giant rabbits. Nobody ever wanted to talk to him about work again. He has a whole bunch of giant rabbits. And he's a huge guy.
He's like six four. And when he holds a rabbit that's like this big, it's an amazing picture. I was like, I'm not sure this helped productivity, but it definitely helped team bonding. And now a whole bunch of people know how to breed giant rabbits that never knew before.
So, how people know people as humans helps people to be more convinced that they can be themselves and be successful. So in summary, these five things I wish I'd known sooner. Dry doesn't work well for human communication. Scaling teams is about creating the conditions for success.
A great gardener doesn't tell plants how to grow. A great gardener figures out how to make sure there's good enough irrigation and sunlight all those kind of things. These inflection points exist, make sure you're focused on the problem that's right in front of you, or the problem that's in the near future.
Don't just try 'cargocult' or 'copy' people who are experiencing different problems at different scales at different times. Their solutions won't help you. Observability matters more than testing. Make it normal in your organisation to figure out how things are going. And then remember that culture add matters a lot more than culture fit.
Thank you very much. What an amazing talk to finish our day of engineering talks. Thank you, Mary. I think I found a new role model. Thank you.