With success comes growth, but what got you "here" will rarely get you "there". In this talk, Graeme draws on 25 years of experience in startups, midsize and big tech companies to explore the different challenges we encounter as we scale (from a handful of people to several thousand), the signals to look out for, and ways to overcome those challenges.
← All talks 
Build Turing Fest 2023
Scaling Product & Engineering Teams
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Good morning, everyone, and what an amazing vibe. It's a real pleasure to be able to talk at Turin Fest, which is in my home city of Edinburgh today. Today, our topic is scaling product and engineering teams, and despite some of the many companies I've worked for today, I'm talking on my own behalf, not on behalf of any particular employer, and so everything you hear today is my independent point of view on the best ways to scale these teams.
And I don't know about anyone else but whenever I've come along to Turing Fest, the thing I want to do more than anything else is to rearrange some of these big letters back here. You can make some amazing anagrams but we don't have a lot of time together today so I'm going to just ask you to feign trust in me as we get into our topic.
So I think scaling teams is a bit like the dead lifting of our world and the reasons I say that is one, it's best to get it out of the way before you have a big lunch, But also, two, when you're scaling teams, you're activating more muscles of leadership and management than any other activity that you can do.
If you think about it, when you're scaling teams, you are setting the mission and vision for your organization. You are the keeper of the culture. You are defining the product engineering lifecycle. We are going to talk about all of this today. You are setting up teams to delegate to them, to be empowered to do their best work, but you are also adding the right minimal number of controls and processes to keep everything moving in the right direction.
You are constantly listening for feedback and adjusting. It is a huge subject, and so the way we are going to manage the thirty minutes is we're going to focus on fundamentals. This is unashamedly not about any fancy framework or methodology or quirky org structures, because whenever I've seen teams that have struggled a bit with scaling, it's not some complicated reason.
It's something going on in one of these fundamental attributes. So story time. I'm going to tell you a little bit about my career journey over the last twenty five years with startups, mid sized companies, and big tech. And this is just the ones I've worked for.
I do some advising companies on the side, and the reason I'm doing this is because I've scaled some teams along the way. I've seen some things. I've made a bunch of mistakes. I hope I've learned some, and what I show you here is going to help you understand the conclusions I've reached about what the fundamental techniques are for scaling teams successfully.
I started my career in a tiny startup in Aberdeen. I was still a student, and they were a reseller of software development tools. And they very kindly let me build their first of their own products, and we built a software metrics tool. And we had great customer feedback from their sales team, and we were starting to see product market fit.
But when I graduated, they said, hey, why don't you scale your engineering team? And I had no clue what I was doing. And I made two fundamental mistakes. The first, I hadn't put the right foundations in place. We hadn't even componentized the software.
It let multiple people work for us. It took a long time to get proper version control up and running, and it took even longer to get anything resembling automated testing. So a failure of the foundations that would let you scale a team. And also, when I hired, I hired the smartest people I knew.
Right? Classic error. I hired friends from a degree course. They were very smart, really smart. But if I had a structured approach to hiring and interviewing and I'd hired more diverse talent, we'd have had a better chance to think our way out of some of the challenges we had.
Well, we made some money despite ourselves, but it was time to move on. I spent six years in financial services and consulting, and so I was fascinated to see how they to scale to thousands of people. And they'd been pretty successful overall. These companies were making money, but I had two different observations that I encountered in these places, and parts of these businesses, not all of them, but some of them, had scaled by introducing very heavy top down controls, very big methods.
This was mostly pre agile, remember. And they'd managed a certain degree of risk and they kept things moving in the direction they wanted, but my goodness, it was slow. You even had to get permission to fix minor bugs in some places, and I found that quite hard to deal with.
And in other parts of these businesses, there would be teams that could act like business units, and this was fascinating. These teams were allowed to behave almost completely autonomously. They could choose their own technology stack, their architecture. My goodness, they did. And they chose multiple different vendors, different messaging technologies, and they were empowered.
So those teams knew their business and they could run very fast and these were fun teams to work for, but my goodness, when you wanted them to collaborate with other teams and connect or you wanted to move people between teams, it was tough.
And I thought there has to be a better way than this. And in two thousand and five, I joined Amazon where I spent the bulk of my career so far, sixteen years. In my time at Amazon, the company grew from twelve thousand employees to one point two million employees, probably more like one order of magnitude in corp.
Most of my time at Amazon, I led the development center right here in Edinburgh, and we grew it from thirty odd to over three hundred scientists, engineers, product managers, and UX people. And what really struck me about my time at Amazon, right, was how they scaled.
No matter what we were getting into, whether it was ad technology, whether it was personalized recommendations, talent management tools, storyboarding for the movie industry, we went about it the same way. Amazon had a very strong culture that they drove through the organization in hiring, in the way we worked with customers, in the way that we organized our work.
They delegated to teams to let them be autonomous and owners and you had multidisciplinary teams with the skills that you needed, but it wasn't just Wild West delegation, this was delegation with some standards. We all logged in the same way, we all looked at our operational metrics in the same place, we all used the same wiki, the same version control and there were some regular check-in meetings so you knew everything was going in the right direction.
And sure, there were some downsides to this approach, right? It wasn't all rosy, but this was the most successful scaling I'd seen. Towards the end of my time at the company, I became CEO of Seismic. This was a four hundred person global advertising business that Amazon acquired, and I learned some things there.
If you think your company might get acquired, if it's going to be an integrating acquisition, being acquired is actually very much like hyperscaling because suddenly you are operating in a much larger environment, there are things that you can do to prepare your business so you're more palatable and an easier journey into one of these companies if you get acquired.
And we'll talk about this today. Last year and a half has been at Google working on YouTube, and again, a company that scaled very successfully, but some differences, right? They're known publicly for having quite a functional organization structure, so you have reporting lines with product, with engineering, with UX.
And often the people who lead a particular area are matrixed in from that to lead it, and so three people, three in a box lead together, and so getting things done in that environment was interesting to see how that worked. I'm actually changing roles and I'm going to scale up part of my career journey, and in August, I'm joining OXA.
OXA is a company based in Oxford who work on software for autonomous vehicles. They took some Series C funding in February, and I'm really excited to be joining them on the next part of their scaling journey, and we're hiring. Okay, so getting started.
This talk split into what do you do with your first fifty people in the org and then what do you do beyond that, right? I said this was going to be fundamentals: mission and vision. Remember, your mission is why does your organization exist?
And your vision is how do you see the world in a few years, and how are you going to get there? And even if it's really early, you've got to always be able to articulate that. And the reason is, if you can't articulate it, how are you going to inspire anyone to come and work with you?
How are people who do work for you going to know what matters and how to make decisions? And you're sure as heck without this, you're not going to inspire customers to get interested in what you're building. And yes, it might change. In fact, it's going to change. It should change over time.
We all know Flickr started out as a game, right? Not a photo sharing site. That's fine, but you should always be able to articulate it, and you've got to write it down and constantly repeat it. And I don't know, has anyone ever tried random sampling and asking members of their team to tell them a bit about the mission or the culture or goals or roadmap?
Anybody here done that over time? Right? Keep your hand up if everyone was able to perfectly answer that simple question that you asked them. Okay, we've got about one there, so yeah, repetition is super important for this stuff. Next up is culture, and this quote is often attributed to Peter Drucker.
And what he means by this is even if you have a great business strategy, at the end of the day, it's the culture, and it's the people and the values and behaviors they bring to your business that's going to be the biggest determinant of your success.
The emphasis on breakfast is mine. He didn't say lunch, and I say if you don't start early with culture, it's going to eat you too. Because I would say as soon as your first three external hires, you've got to be thinking about culture because otherwise you're going to get the default of whoever you've hired and whatever they think is acceptable.
When we think about the companies we admire, we often think, hey, we know them for maybe customer obsession or simplicity of design or inclusion or some of these positive values, and when we think about companies that have failed or faltered, we either don't know much about their culture or they've had to change some things along the way.
Enron had a company culture, right? But I think you could argue that they didn't drive those values throughout the organization. Uber had a big reset in twenty seventeen where they got rid of some of their more, I guess, edgy cultural values like toe stepping, for example.
So again, I think this is very important from day one, and you're the keeper of the culture driving it through the organization. Of course, you've got to put some basic people structures and process in place. People are gonna want to know what their role is and sure in the early days people got to roll their sleeves up and do whatever is needed but they rely on you to provide a bit of basic information.
Am I a software engineer? Am I a product manager mainly? What am I working on? How are we structured? This one is less obvious, a people directory. People directory is a place on your intranet where anyone can go to discover the other people in your company.
So they can see their job role, they can see a photo, they can see the reporting lines, the teams they belong to, and maybe something a bit personal about them if they've shared something. It might seem like a weird point, but let me tell you this: every company I've worked for or advised where we measured the traffic to the company's intranet, The number one most trafficked site in the entire intranet, constant use was the people directory.
People love this. You might know this is a bit about empathy. You might know as the leader of the org who everyone is, especially when you're small. But that forty ninth person who just joined, they sure as heck don't, and they need to be able to navigate and meet people and explore your org.
Very important. And having a simple hiring process like I didn't in my first role at that startup. Plenty of good material on the web there about how to think about the competencies you're looking for, to design an interview loop, to write good feedback, to try and mitigate bias in the process.
Every mid sized company I've advised who's introduced this say they wish they did it sooner because they made some bad hires for the lack of just basics here. And I spoke earlier about standards and tooling. I think you've got start early with this or it can really get out of control, right?
You don't want to standardize on too many things too soon. You don't know what you're going to need or what your team's necessarily going to like, but I would suggest that you should get some basic standards in place like having one wiki for your organization, for example, having some standards for how people describe their teams and their work, one version control system, one build system, and all of this.
If you think about growing and if you think about being acquired, if a company is going to acquire your business, a much larger company, and they look at that business and you've got multiple different architectures and forty different vendors, then all they see is huge migration projects and they see that every one of these vendors who was fine and well behaved when they're working with you, when you get bought by the big company, those vendors are just gonna jack up the prices and hold you to ransom and they see that and so really just having a little
bit of control here early makes a lot of sense. So what goes on beyond fifty people in a team? Changes in people, process, and structure. The big one is you're going beyond line of sight management now. You can't possibly know everyone in your organization, even more so and sooner the people who are joining your organization can't know everyone and when they join, they can't automatically be expected to, oh yeah, I now magically understand this company and why it exists and what the culture is and how to set things up and what my role
is within that and how I should take decisions. And our job as leaders is to put that in place, and that's what I'm going to talk about in this next section. But kind of ahead of all of that, listening is absolutely key because remember, you can't know anyone.
You everyone anymore, especially when you get beyond fifty people. And so you have to be quite structured about how you listen in different ways. If you are lucky, you will get explicit feedback. I had two teams working in my organization and as they grew and they were succeeding and doing quite well, they started to run into each other.
They were both getting into the same part of advertising, and they were both ambitious. And I was lucky they took that to me. It was a symptom of scaling, but we were able to resolve it. You're not always that lucky. You've got to be looking for implicit feedback.
So this is things that no one is actually telling you, and you can find that in metrics like you look at attrition throughout your organization. Are there pockets where people are leaving? Could that be a signal you've got some challenges? What about mean time to resolve failures in the production system?
If that's going up, is that maybe a symptom of scaling and not knowledge sharing, not having the right processes? What about the amount of time it takes to get a line of code that's been committed into production? How's that looking? So you can look for all these implicit bits of feedback and figure out maybe what's going on.
Something that not everyone talks about is regularly surveying your team. Really encourage you to follow a leader called Leah Melvoin. Leah runs a business called Voice of the Developer. Best place to find Leah, I think, is on LinkedIn. She's got a lot of great content there.
Leah designed the very famous Amazon tech survey and now talks a lot about what makes a successful survey in a product and engineering org. Leah's found a lot of success where you have a survey where the questions are designed by the people who it affects, so product leaders and engineers have a chance to write some of the questions, where it's anonymous and people really trust that it's anonymous so they can speak openly.
And every time before you give this survey, leadership says, Hey, last time you told us these things were wrong. Here's the concrete changes, remember, that we made as a result of that. So people trust that you're actually going to do things that will change the world and make it better for them, so they'll participate.
And of course, cultivate back channels. You can try and be as approachable as you want. Sometimes people just won't tell you stuff that you need to hear. And so I've had really good luck with admin teams in the past and support teams, and they came to me one time and said, Hey, as this team has grown, honestly, people don't know what the other teams are doing, and they feel a bit disconnected.
You really need to set up a monthly social and share a bit what's going on, get people together, and I was pretty doubtful about this. But I did it and it worked so well. We kept that monthly social in place for years, so cultivating back channels can be really valuable.
Also, as you grow, you've got to start to establish what I call heartbeats in your organization, right? You can't just do things ad hoc anymore, set goals, have planning meetings. You're beyond fifty people, you can't get everybody in a room and just plan together off a single backlog.
And so having a regular cadence where you say, well, we look at goals, we set goals once every three months or whatever it is, we review them every month, right? And here's where we keep them in one place, not like twenty different spreadsheets and tools.
That helps everyone relax into how goals work at your organization, right? And suddenly, that's really helped you scale that part of the world. Planning, like I said, when you're small, it's relatively easy. You get people together, you do a scrum scrums, whatever it is that you do, but when you're large, you want to write down how does annual planning work in my organization?
What happens with quarterly planning? Simple questions like how does one team get another team to do some stuff for them if they don't really want to help them with that? And how often do we look at rebalancing resources between our teams to make sure we've got the right people in the right place?
And all of that you can do ad hoc, and it can be pretty chaotic. Or you can just write down something simple and have a heartbeat in which that happens, and it works so much better. Establishing demos. We all know we go to the hot part of the team, right?
The bit that we think needs our attention. I've made that mistake in the past. I neglected a team that I thought was doing okay. And if I'd established a regular demo from all of the teams that could do them, I would know because I'd be seeing vertical slices of functionality coming out.
Is this team succeeding or not? Right? Do they need maybe a bit more support? We spoke about listening, but information dissemination is at least as important. How do people figure out what's going on in your organization as you scale? Because you can't know everyone.
You can't see them all the time. They might be around the world. Well, you've got newsletters. You've got all hands meetings. And something the comms team advised me to do after we bought that ad serving company, said, Hey, why don't you do three minute video shorts once every two weeks and just talk about, Hey, here's what's going on.
I want to recognize some achievements of some people and teams in the company. Here's what's top of mind for me, some of the things that probably should be top of mind for you. And the feedback from that was really positivejust simple information dissemination mechanisms, whatever works for you.
And of course, you don't want silos of knowledge to develop. You want to be sharing knowledge and information between teams as you scale. That won't happen by magic. Right? So again, regular heartbeat, get some product and engineering talks going. Something that I've done in multiple teams is have an engineer rotate into another team for a couple of weeks at a time, and they bring with them to that other team.
They bring a bit of insights and context and tooling and ideas, and then they bring more insights, context, tooling, ideas back from the team that they've visited. Sometimes they decide to transfer and that is a wonderful way because the only way that you can harness all those big brains that you hired and they can have ideas about the whole thing of your organization is if they've got a better context.
They've spent some time in other teams and this makes it happen. And the final bit of heartbeat I want to talk about is lightweight reviews. This is the most powerful tool I have found over twenty five years in helping to keep a large organization running smoothly at scale.
Many places do different versions of this. I'm going to tell you what it is today. We've got a whole slide about it. It's a short document, typically two or three pages in the body, and you ask a team to produce it for you weekly, monthly, or quarterly, and all that's in it is the Restate the Mission so we're all in sync about what this team exists for.
Quick summary, right? What's going on as if they'd met you in the elevator for ninety seconds or whatever. The highlights and the lowlights of what's going on in that time period for the team. Workstream updates. So the major things they're working on, what's going on with that, and what are they going to do before the next time period?
And a little check-in. Does that make sense? What are the discussion topics they want to raise? Remember, this is not just status reporting. I should be very clear about this. This is for their partner teams in the organization to come along and hear what's going on as well, and it's very powerful because if you do this on a regular cadence, people relax into it.
Suddenly, they can prepare for this difficult conversation they might need to have. They can bring some data. Partner teams come along. You've got the right people in the room who might otherwise be hard to book, and you make good decisions. And of course, you can have appendices with all the UX designs and metrics that you want, and anyone who couldn't come to the meeting, they've got this really nice permanent record of what was discussed.
Very powerful. I don't just use it for projects and products, by the way. I've used this to run recruiting like a business as well. So looking at the pipelines of candidates coming through, looking at who's dropping out where in the interview process, and really optimizing that.
I've used it to run diversity, equity, and inclusion as part of the business as well. So what went well for that in the last month? What didn't go so well? What are the initiatives that we've got going on to improve that? So it's a broadly powerful tool.
And of course, you're inevitably going to have to think more about organizational design when your org is bigger. And this could be a whole series of talks, right? So I don't have very much time for this, but I'm gonna just share a top five things that I believe to be true about organizational design in large products engineering organizations.
One, I've seen nothing better, nothing that works better than this word soup here. So teams that are streamlined, they're aligned to delivering some value, so typically they own a product or a group of features. They're cross disciplinary, so in the reporting structure where primary loyalty lies, you've got your engineers, your product managers, your scientists, your UX people, whoever you need, working closely together.
You get machine learning scientists working with engineers, and suddenly you have much more scalable machine learning systems that tend to perform better at runtime. The teams are durable. They stay around for a long time. They learn how to work well together. And crucially, they have single threaded leadership.
There's one leader of that team who could come from any one of the disciplines product, engineering, science, UX and they take the decisions. Ultimately, they're for the decisions of that team, negotiating with partner teams, that helps you to move fast. Now, of course, no org design is perfect.
You're going to have a mix of things. Very often the thing you compromise there is something like UX. There are never enough UX people who go around, right? So often they end up in a functional organization kind of matrixed into your other teams.
That's an example of a pretty normal thing that happens. Another type of team that's valuable to add: accelerator teams. What I've found is when you get beyond about one hundred and twenty people in a product engineering org, it can be really powerful to add like an engineering That's a very powerful pattern.
Watch out for platform teams. As you get bigger, you're going to find there are teams in your organization that become a bottleneck. So these are teams that everyone depends on. Maybe it's for data, maybe they're a portal or an app that everyone wants to deliver into.
But in the early days especially, quite a common problem is whenever a team comes to do something in that platform, it's not ready for them. It doesn't have the capabilities. And so every new use case, they're having to add capabilities to the platform.
You've got to be really careful about that because those can become a scaling bottleneck. And of course, you want to minimize layers in your organizational design. Every layer in your reporting structure has the potential to slow down communication, result in misunderstandings, and slow down decision making.
Now, you can't have infinite spans of control for leaders, right? You can't have complete horizontal org, but you do want to be seeking and minimize those layers for the reasons that I described. And of course, you're going to mature your people processes beyond fifty people.
People are going to want career paths. I encourage you to develop a career development framework as soon beyond fifty with job roles and levels. People procrastinate on that because they think it's hard and a lot of work, but actually there's lots of great inspiration out there on the internet.
Look at progression. Fyi, for example. Just choose something idiomatic that minimizes the cognitive load on your people because this is not an area where you probably need to differentiate. Structured onboarding. So this is a really important tool as you scale. I spoke about how can people magically be expected to get context when they join your team, when they join your org.
Well, if you can have and it amazes me how big companies get that do not have structured onboarding plans for people. It's kind of wild, but you want to be able to join that company and say, here's how I set my laptop up on the first day, here's how I learned about the company culture and the mission, here's how I learned about my team, here's some videos I should watch, and here's some people I should meet and who I should build relationships with, and that really will help you scale.
Having a more sleek recruitment and interview process, I spoke about running recruitment like a business. You might be lucky. You might have recruiters who are systems thinkers and they run it like a business and they look at pipelines and who's dropping off where in the interview process and refine it, but sometimes as product engineering specialists, we can bring some systems thinking there and it is our job because hiring is super hard and sometimes we have to take a lead on this.
And of course you're going to need performance management becauseand I encourage you to keep it lightweight. I don't know about youbut I never encountered a company that attributed their success to having some really complicated, fancy performance management system, right? It's the basics. People expect to get feedback regularly.
They expect recognition and reward for doing good work, and you need to be able to identify and manage underperformance when you see it because, frankly, as you scale as well, some of the people who got you here who could be great people when you were smaller, some of them could go on to be great people as you get larger, some of them might not be the people who get you there.
I'm going to leave you with a couple of book recommendations. Scaling Teams is excellent, and one of the authors is a former Amazon colleague, and they go into more detail on hiring and developing talent than I've been able to do today. Team Topologies is very popular right now.
We're using it at Oksut, where I'm going, identifies four different types of teams and how to reason about setting them up and how they can interact together. It would be great to see some of you in the breakout session. Encourage you if you're interested, connect with me on LinkedIn.
Although I have a day job, I do have some limited time available where I do executive coaching and company advisory services, so if that's something that's of interest, then please feel free to reach out. Otherwise, thanks very much for coming today. I hope you found that useful.