Every person is an individual and every team is unique. There is no secret sauce or set formula to follow when trying to build a successful team. You need to forge your own path and build your own culture, but you can learn a lot about approaches to try, and pitfalls to avoid, from the experiences of those who have spent time on the wild rollercoaster ride that is scaling a fast-growing software engineering team.
In this talk Olly will uncover some of the lessons he's learned while overseeing the growth of the FreeAgent engineering team from 1 to 75 developers and managers over the past 12 years.
1 / 83 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Hi, everyone. Thanks, Rachel. Okay. So I'm here today to talk about my experience building and scaling engineering teams over the last decade or so. And don't panic, it will include burrito advice. I think that's why half of you are here apparently, so I understand.
So firstly, who am I? Had a very brief introduction there. So my name is Ollie Heedy. I'm one of the co founders of FreeAgent. I'm also the CTO. And here are my contact details if you want to get in touch, talk after the show, or follow me on social media, hear me rant about Brexit.
So a little bit more about me. I'm based here in beautiful Edinburgh, but you might be able to tell from my accent that I'm not a native. I'm from a place called Yorkshire. And as you might expect from a CTO, I have a background in computer science.
I studied before the World Wide Web existed when I started university. That's how old I am. And I spent the last twenty five years or so working in various roles in software development and in various industries. I've worked in video games, media, finance, and most recently, of course, startups.
So my talk is about scaling engineering teams, and you may wonder, well, Ollie, what's the secret? What's the secret to scaling teams? And it's a question I've pondered many years, and it's great, you know, to be able to stand here on a beautiful stage at the world famous Turing Fest, and I admit I actually have no idea.
I'm a complete fraud. I've never found a secret scaling source or a magic silver bullet, but I do have a much clearer idea of what some of the key ingredients are that are definitely going to help you grow your teams, and it's these that I'm going to talk to you about today.
And as per the subtitle, the talk's going to be kind of based around five lessons that I've learned over the years. And as you can see here, I know a little bit about lessons. Here I am, showing my age in a Victorian classroom, being a very diligent student and demonstrating my technical prowess with some sort of early adoption of tablet technology.
I have no idea what's going on there. But anyway, moving swiftly on. The talk's sort of geared, I suppose, towards founders, leaders, engineering managers. But I'm hoping many engineers in the room today, hands off engineers. Oh, loads. So I'm working those of you working at the code phase, as it were, are going take a lot out of it as well.
I kind of want you to think about how your team works, how you feel about the processes that you kind of have, the team structure, how you get stuff done, and so on, and hopefully kind of question your team and try and improve things along the way.
And so although I've worked in software development since the mid nineties, the majority of my leadership experience comes from the past twelve years on the FreeAgent journey. And so if you haven't heard those four of you, then put your hand up. Free Agents Tech Company headquartered here in Edinburgh.
We're literally based just up the road on Fountain Bridge, five minutes away. Here's some pics of our lovely office. It's pretty chilled. Great castle views, and we have a new auditorium, so do come and visit. You're all welcome. And here's kind of an old photo of our lovely happy team, but I really like this photo.
There's a lot more of them now than there are here, but it's a good photo. And at FreeAgent, we build products to make small businesses and freelancers feel smart, not stupid about their company finances, and it's a popular product. Here it is. It looks like that on mobile and web.
And we've got over ninety thousand customers right now, and it's growing quickly, which is good. And we've had quite a start up journey. The three of us cofounded the business and bootstrapped it for a number of years. And then we took on angel investment, seed investment, institutional investment.
We did venture debt. We did crowdfunding. And all of that culminated in our IPO on AIM in twenty sixteen. And here we all are looking slightly bewildered one morning at the London Stock Exchange. It was good fun, slightly weird. And our latest chapter, as Rachel said, was an acquisition by the Royal Bank of Scotland in June last year.
Although we remain operationally independent, this investment that they made in the company has had a large impact on our growth trajectory. So the growth of the Phreesia team has sort of mirrored those investment events over the years. You can see here on this chart, starting with the three founders back in two thousand and seven for a few years, and kind of gradually scaling up to the size it is now.
We're around about two thirty people or so right now. And you can see the big spike in twenty eighteen-nineteen, and that's due to the investment that the World Bank made. Now, the engineering team, which is the blue line on the chart, kind of the growth of that has kind of mirrored the company growth, really, and it's always been quite a high percentage of the team, as you kind of typically expect in a tech company, certainly in the startup and scale up times.
And right now in engineering, and this changes weekly, but it's about ninety staff right now, and that's engineers and managers and testers and support engineers and the leadership team and so on. And if you look at products and engineering as a whole, if we include product managers and designers, UX specialists, We've got about one hundred and twenty five people, so it's quite a huge organization in its own right.
So scaling from the three of us to this size is basically what I'm going to be talking about today. So moving swiftly on, onto the first lesson learned. Number one, hiring is number one. And you might be thinking, Ollie, you're just you're just stating the obvious.
You know, you're scaling, you're growing your team, obviously you need to hire, which is true. But in my experience, it's the importance of the hiring process that's often overlooked. And what's definitely overlooked is the amount of effort it's going to take. And to do the best job, and you really need to do the best job, it's going to consume a huge amount of your time, a huge portion of your time, maybe like fifty percent of your time or more as a leader or a manager.
And this could be ongoing for months, maybe even years, depending on the scale of the task. We've heard stories about delivery scaling to like three thousand people. It's just never ending. And I suppose hiring could be a talk for thirty minutes all on its own, but I'm going to try and condense a few things into five minutes.
And I suppose, why is it number one? Why not just outsource it to recruitment firms, get them to do it all for you, or maybe give it to your HR team and let them handle it? Well, firstly, you need to stand out from the crowd.
And it's a huge crowd, especially in places like Edinburgh, tech hotspots, London, Manchester, and other cities around the UK. Literally, everyone is hiring. So why are people going to choose you? And to answer this, you need to look at every aspect of your proposition.
What's the mission of the company? What's the purpose of the team that you're going to join? Salaries that you're paying, obviously. What are the coding practices? Tech stack, what's your office like? But most importantly, who are the team of people that you're going to be working with?
So this guy, Yishan Wang, he's a former engineering manager at Facebook, and he ended up being bizarrely, like Reddit CEO. He wrote this brilliant essay on hiring many years ago, which is quite an influence on me. You can kind of Google it. Here's one of his quotes.
Think it's the quality of coworkers is the single greatest determinant of workplace happiness. Basically, great people want to work with great people. And this is true. If you can talk to your team, survey your team, time and time again, what would you like about working here at Frasier?
It's the team. It's the people I work with. And I'm talking about team cohesion. When say great people, I'm not talking about 10x rock stars, all that. But if you focus your efforts on hiring these great people like this, you'll find it easier to hire in the future, because basically hiring is a feedback loop.
You have to put in, it comes around. So again, hiring is not a checkbox. It's this all consuming job, and you really need to commit enough time, it's a lot of time. You have to prioritize your calendar and make a focus. It's hugely important. So Yi Shang is here again.
Make hiring your number one priority always. This means it needs to be your organization's first priority, it needs to be each manager's first priority, and it needs to be each engineer's first priority. So you need to get buy in from the CEO down that you're going to be spending this time doing this thing, but also you need to kind of get engineers involved as well.
You need to give them the time, get them involved in the process, doing the interviewing, shaping those interviews, defining what the coding test is. How do you review the code test? How do you score it? All the soft skills as well, they need to be involved in all of this.
And you must be consistent with all the candidates regardless. So if you watched Mary this morning, it's brilliant. You know you want a diverse and inclusive team, but consistency is crucial for fairness and equality in the process. So at FreeAgent, what we do is we have the standard interview process, a phone screen, technical test, we do a review call to talk about the test, and we do an in office interview.
Now actually, had spotted this earlier. I've seen no exceptions, it's not true. Actually, it's completely rubbish, because we had a candidate recently who was disabled, and they just couldn't get to the office. They couldn't do an in office interview, so that's something we'll just do on video, and that's fine.
So actually, there are exceptions. But the standard process is kind of the point here. And then you need to ask standard questions to all the candidates, whether it's technical or nontechnical. Standard questions. And then have a standard test, coding test, with a low barrier to entry.
It needs to be kind of easy. Don't make people kind of spend days on this stuff. And do blind reviews, by which I mean that people are reviewing the code. They don't know the person's name, location, gender, age, or anything like that. And of course, the idea here is to reduce unconscious biases that we know exist.
So I've always kind of strived to be human when hiring, and what I mean by this is when you're communicating with candidates, whether it's just replying to an email that they've sent in or a question, how you speak to them on a phone call, and how you behave when they come into the office, you need to kind of take this friendly, kind, human approach.
And I think, be yourself. It makes people comfortable, and I think also it probably makes you stand out, and you need to stand out. I've already gone over that. And remember, Glassdoor. So if you haven't seen Glassdoor, probably most of you probably have, it's been a real game changer in the last few years.
It's sort of like a review site for companies where staff can leave feedback about what it's like to work there, what the culture's like, what you get paid, because people love talking about that. It's true. But also, interview candidates can leave feedback. What was the interview process like? How were you treated?
What were the questions in the interview, even? So you're being measured whether you like it or not on this stuff, so you might as well try and do a good job, because you are being measured. And so, showing off a little bit, but FreeAgent does really well.
But this is no accident. We've worked really **** ** it over the years, and whenever we get candidates in, we'll tell them, Go and visit Glassdoor and tell us what you think. We're not bribing you. Seriously, we want to know, because where we're not doing well, we want to try and improve.
So like, yay us. And remember, always provide feedback post interview. Candidates invest a huge amount of time, you know, phone calls, doing technical tests, coming into office, days of work, really. And so the last thing they kind of need, if they're not selected, is just an email saying, yeah, thanks, but no thanks.
It's kind of hugely demoralizing, so they deserve this full understanding of why they were not selected, so take the time to explain. Really, why weren't you selected? It's really important. So to recap, be human. Be kind. Be yourself. Put in the hours and invest your time, and I'm not talking about eighty hour weeks.
Right? That's just nonsense. I don't think we've ever done more than like a forty hour week, really, ever, at FreeAgent. You just don't need to. You need to think creatively. You need to stand out from the crowd. You need to get out there, exhaust your network in your local area, talk to people.
What are people doing? But also referrals, especially in startup companies, hugely important, a hugely important part of hiring. That's where most startups can kind of get their staff from that, certainly work for FreeAgent. You need to optimize the funnel. You're going to gather a lot of data during the hiring process, where your candidates are coming from, how long it takes you to kind of from advert to hire.
And so you need to optimize that and iterate and learn from it. Really important. So that's it. Hiring is number one. Number two, no money, no problems. The biggie. So you've invested in your hiring process, and you've hired all these fantastic people, and that's when the real work starts.
But people say hiring is hard, and it is, no doubt, but I still think it's the easy part. Now there's a danger when you're hiring people onto a team that you just kind of pay them kind of what they want, and give them the title kind of what they want, because, well, you need to hire.
Right? Makes total sense. And this is a particularly common theme in startups and scale ups. And it's not a huge problem initially, but what happens when you hire the next person, and then the next person? It will become a problem. Sure. You're going to get disparity in your pace, what people are getting paid for at the same level.
And it's going be unfair, and it will cause a problem. So you need to have a bit of a plan for this at the start. You need to think about what levels your engineers can reach from day one. You might have different levels for different roles, but in this example, this is just for a software engineer.
It's the sort of thing we have at FreeAgent. So you have a junior, mid, senior manager, lead senior manager, principal, head, CTO, VP of engineering. And the point here is about the dual ladder. You'll notice that. And this is that management is not for everyone.
An engineer should be able to have a career, whether they want to be a technical specialist or change on to kind of a management track. And you need to have this in your company. It's essential to allow people to grow in their careers, whichever path they want to follow, because they are different careers, management versus IC.
So have the dual ladder. And once you define these levels, you need to be clear about what's expected with each one. Engineers need to understand why they're at a certain level and what they need to do to grow to the next level. This defines a contract basically between the manager and the engineer, and it facilitates conversations and feedback.
So for example, we have these eight competencies that we kind of have for each role ownership, initiative, problem solving, communication. And for each one of these, at each level, in each role, we have lots of expectations. And there's a lot of things in there, and it's obviously a lot of work.
It takes a lot of effort. So for the time poor, it's great. You can just steal them. Progression, FYI, is an amazingly rich resource of these progression frameworks that dozens of pioneering tech companies, where they publish their own frameworks on there. For example, Basecamp, BuzzFeed, GovUK is on there.
It's a really good one. So take a look at this and borrow it. And so they have your levels and your expectations. Then you need to put numbers against it. This is like debanding. And it's really hard. How do you know what to pay?
So we use a combination of published reports. Recruiters will publish these reports every year, telling you what people are getting paid in certain areas. We pay this company called Radford like a whopping great sum of money every year to get this kind of insight in the industry.
It's kind of interesting. Plus, have our own anecdotal data that grows with every application. So we kind of see what people are expecting from across the country, and so on. So here's an example of what you end up with, for example, a software engineer.
And it's not one true way. It differs by location. This might be what you get in Edinburgh, senior engineer, fifty, sixty five ks. In London, there's probably a lot more. In Silicon Valley, I think you meant to add a zero. I think that's how it works.
But the point is, kind of put your stake in the ground, and that's how you work with it. And you don't deviate. Don't deviate because, again, it's going to cause these problems and unfairness. So review these bands annually, if the market changes frequently in tech, kind of need to keep up, stay competitive, and use these expectations frameworks to discuss performance and progression constantly, the manager and report throughout the year.
Run three sixty feedback, so it's not just managers leaving feedback about engineers. It's engineers leaving feedback about managers and other engineers and in other departments. It's very important. Review their salaries annually. People know that that's at least going happen annually. But do biannual promotion reviews.
And this is kind of important, I think. So especially high performers, they're just not held back from progressing. They want to progress. You don't want them to have to leave just to progress. It's important. So that's number two. Number three. One is the loneliest number.
Now, sadly, this is not about LEGO Batman and his lobster Thermidor microwave meals. This is about the importance of teamwork, collaboration, and dividing up work. If you haven't seen Lego Batman movie, it's amazing. So Brian Fitzpatrick and Ben Collins Sussman wrote this book, Team Geek, back in twenty twelve.
And it's largely about how success as an engineer depends on how you work with people to get the job done. And it's summed up in this great quote that I really like. Software development is a team sport. And this is true more than ever in a team or a company that's scaling up.
So let's imagine for a minute if a team of three engineers, how do you deal with kind of the distribution of work? You've got this big backlog. You want to get stuff done. So logic kind of suggests that you want to paralyze this.
Right? So you can engineer one will do feature one. Engineer two, you can do feature two. And engineer three, can do feature three. And, you know, on the face of it, this might present something of a net gain. You know, you can ship stuff parallel more quickly, and it's it's kinda true at some level, but I used to think this is the way to do it.
It was really efficient, but actually I learned the hard way that these gains are like far outweighed by the negative effects on the team. So for example, you're immediately introducing single points of failure. You can siloing knowledge because an engineer is just focused on this one thing in their own little world, so all this information is just stored in their head.
Because you're kind of expecting them to ship stuff just on their own, you're of putting more pressure on them to do that. They can't really share that pressure. And this pressure is going to perhaps reduce their happiness, demotivate them a little bit. And what's going happen, because you're just siloed in this thing of your own, you're going to get inconsistency creep.
And you're to start doing things, the same thing, in different ways across different people. It's going to drift from standards. And ultimately, it's going to reduce the code quality, and you're going get technical debt, which is ultimately going to slow you down. It's far better to work collaboratively as a team to design and ship each of these features at once, and then do the next thing, and then the next thing.
So think about that the long term. And of course, if a team exceeds a certain size, you might want to kind of introduce streams or separate teams, but within those streams and teams, the same rules would apply. So twenty years ago, shockingly, Kent Beck wrote this book, Extreme Programming Explained, and it was a total game changer, and it's still totally relevant today.
Now, whether you want to adopt XP practices or not, it's up to you. But I think the core benefits that's kind of extolled by Kent Beck in his book are super relevant for working as a cohesive team today. So here's an example from the pair programming section.
He kind of explains what is pair programming, what we want to do, and then he kind of explains the benefits. So pair programmers keep each other on task. They brainstorm refinements to the system. They clarify ideas. They take the initiative when their partner is stuck, thus lowering frustration, and they hold each other accountable to the team's practices.
It's great advice, just as much for a team as any pair programmers as well. So it's a brilliant book. So remember, work as a team, not a collection of individuals. So to wrap this one up, build collegiate teams, not silos, and work together as a team, not a collection of unique individuals.
You need to focus on reducing the single points of failure in people as much as systems architecture, equally important, and optimize for the long term. Think about the long term. You're scaling. You need to think about that destination, not just the right now, for team sustainability and scalability.
Okay. So this lesson number four, how to eat a burrito, which is really about scaling engineering teams by writing things down. But admittedly, it's not quite as catchy. And in fact, I believe this applies to scaling any team, not just engineering teams. Pop quiz.
So in any org, new people joining a team, or even actually existing staff, existing members of teams, are going have loads of questions. Things like, what's our deployment process? When do I get salary review? How do I get on the VPN? Why are we doing this feature rather than that feature?
Or what does a senior engineer get paid? What am I supposed to be doing? Get all these questions. And to answer these questions, two things are needed. The first thing is communication. And the bigger you get, the more you scale, the harder this gets.
And it gets exponentially harder. And the second thing is documentation. You need to write things down. It's still the best way to facilitate communication. But, you know, engineers in the room, I hear you say, I get it. Documentation is terrible. No one reads it.
I hate writing it. Go stale, like, you know, code comments. I love this one, to be honest, the dog. Or maybe this one as well. Now, I totally agree about code comments. I do agree. Steve McConnell wrote a book, Code Complete, and what he said is kind of great advice.
A good code is its best documentation. As you're about to add a comment, ask yourself, how can I improve the code so this comment isn't needed? It's good advice, and I totally agree, but when I talk about documentation, I'm not really talking about code comments.
It's talking about introducing clarity, about bringing clarity to a team and answering all of those inevitable questions. Because when you bring clarity, you bring consistency and scalability, and that's what this is all about. So a team wiki, or a knowledge base, is a great way to start doing this.
Here's an example from the free agent engineering wiki. It's like the guide, all you need to know about how we work, getting started in engineering, development process domain knowledge. And the sort of things you can document in your wiki or your knowledge base, common standards and style guides, dev process, RFDs, I'm going talk about that.
The tools you use, what do we use? How do I get stuff done? And runbooks, really important, like when stuff hits the fan, what do you do? You need to kind of write that down. And another example from our wiki, comment idioms, gives you an example of general code, Edison formatting.
It just prevents syntax wars and editor wars, tabs versus spaces. The answer is spaces. And it creates clarity and consistency. And even important details like, you guessed it, eating burritos can be documented for the uninitiated. This is my guide. So for the uninitiated, here we go, five simple steps.
Unless you're Homer Simpson, you might want to try the lunch size burrito, and you unwrap the burrito from the top like a pack of digestives. Don't just go, like, opening all the foil. And as you eat, unwind to expose more burrito, and always ensure you have something between your burrito and the table or your lap, because it will leak.
And if you have a burrito for lunch, remember to bring enough for everyone. Great advice. Stood the test of time that has. And so once you start building your knowledge base, and as long as it's accessible and with a really low barrier to change, and we use Notion for hours we used to use GitHub, Notion is just amazing you gradually find it becomes part of people's workflow.
So here's an example from our Slack, where someone's like, is there a one liner that will let me reseed my local M? I've screwed it up massively. And then someone goes, oh, bundle exec rate, whatever, we'll do it. And they go, oh, thanks, but I found it in Notion.
So people start to self serve, which is absolutely brilliant. There's like no barriers at all. It's just there. So another documentation game changer for us was introducing RFDs, or Request for Discussion Documents. And the idea was actually completely stolen from Joiant, and it's used by Gov UK as well.
They call them RFCs. The idea is you define a problem statement, and then you kind of outline the context about that problem that you're trying to solve. And then you demonstrate the sort of research that you've done in trying to solve this problem, and then you outline the recommendations that you think you should take to proceed.
And then you kind of publish it for review from your peers and comments. So here's an example. It's just a Google doc, this one, AWS Container Environments. And RFDs are brilliant for collaborating and sharing information across growing teams. That's a huge impact for Agen.
And they're also a form of architectural decision records. And these help you and others in the future. At some point, someone's going go, why did we decide to use ECS, not EKS? Why did we decide to do that? And it's great, because you can now have this reference that you can point people back to that explains all the context around that decision making, and you can kind of understand the thinking at the time.
It's really useful. So it all facilitates discussion. But it's all asynchronous rather than real time in Slack. I mean, Slack's great, has its place, but it's not a place for making decisions, especially in the spur of the moment. We also provide an old school forum for long form discussion.
Again, something that Slack doesn't really excel at. And this is much better than email, because email is just again, it's like a knowledge silo. New people joining the team don't have access to all that email that was written before they joined. But they do in a forum like this, and we use Discourse.
It's really good. And so all this writing offers clarity, but it has other positive side effects too, such as, you know, you write all this documentation. You just become a better writer, and maybe, could take those RFDs and turn them into public blog posts, you can pimp your engineering team on a bit better PR, which helps with your hiring process.
And again, it all comes back around. It becomes part of the culture. And the result of all of it is it allows you to scale more easily. So it's all about the long game, which you really need to think about when scaling. You're trying to scale, the last thing you need is your velocity to decrease, but new engineers coming on board not knowing how things work or having to ask for assistance every time they need to do something, it's just going to slow you down.
So remove these barriers and these roadblocks. Write stuff down. It'll get stuff done more quickly as you scale. Okay. Number five, the last one, pulling the rip cord. So this is about asking yourself the question, when should I let go? And this is for technical founders hiring their first engineer, or engineers transitioning into management for the first time.
It's kind of the same thing, to be honest. And by letting go, mean accepting that coding isn't your primary responsibility anymore. The happiness and success of your team is, and this is a really difficult transition. So when should you let go? Well, think I've learned with experience.
Day one, the day you hire your first engineer or when you first become a manager, you have to consider yourself no longer on the critical path. You have to contribute, but put your energy into supporting your engineers, creating the culture, imparting your knowledge, setting standards, and just allowing people to kind of get stuff done and flourish in their roles.
It's a really hard transition, but you make it your primary focus, and you'll learn, and you'll find it's a lot, lot easier. And on smaller teams, it's entirely possible to be a solid contributor, like a player manager, if you will, but it can't be your primary focus.
The team is now your primary focus. So Basecamp call player managers, they call them moonlighting managers, and this is an article by DHH and Basecamp. And it's good, and I agree with a lot of it. You do need to manage as lightly as possible, but at a certain scale, and for agents like four times Basecamp or something right now in terms of people, you find that full time management, where there's no coding, is essential for scaling effectively.
Just remember, it's team first, technical contribution second when you move into management. Super important. And with that, we're pretty much done. But before we end, we'll kind of recap on these lessons. So hiring is number one. Be human, be kind, be fair, be consistent.
No money, no problems. Set clear expectations, fair, competitive salaries, and operate a dual ladder. One is the loneliest number, LEGO Batman. Software development is a team sport. How to eat a burrito? Scale teams by writing things down and pulling the record. When you move into management, get off the critical path and focus on your team.
