If you are not subscribed, join the community by subscribing here and share it with your fellow SaaS enthusiasts.
In fast-growing startups, the structure of the organisation changes constantly.
In your early days, agility and innovation is enough. In your later days, this has to be supplemented with practices and processes.
As a CTO, this means the ‘hands-on-everything’ approach that works well when you have 5 employees won’t get you to 50+.
“When you start, your hands are on keyboards and in the code. There’s no process, no HR or competencies. As you evolve, and the business grows, you realise you have to form some sort of hierarchy” – Neil Turner, CTO, GoCardless
Implementing structure is challenging. Engineers might not be happy with their place in the new organisation.
They might have joined your team because they loved the free-spirited start-up ‘hacking’ mentality. So, how do you get them to buy-in-to change?
“As leaders, we have the responsibility to identify where the right places are for processes, and give our engineers the freedom in other areas to go forth & hack” – Vicky, CTO, Zego
Scaling an engineering organisation is a real balancing act. You need to ensure you give your team enough autonomy, and as a leader ensure people are all sailing in the right direction. It’s a tough job!
This was our biggest takeaway from an electric discussion between Maxime Le Dantec (Principal, Balderton Capital), Neil Turner (CTO, GoCardless); Vicky Wills (CTO, Zego) and John Abel (Technical Director, Office of the CTO, Google).
Grab your notepad and learn more about overcoming the challenges of scaling your engineering team below.
Watch now:
This discussion was sponsored by Google Cloud.
You can also read the full transcript of this video below.👇
Transcript
Maxime Le Dantec:
Hi, everyone. Can you all hear me okay?
John Abel:
Perfect.
Vicky Wills:
Okay.
Maxime Le Dantec:
Great. So thank you for joining us today. So I’m Maxime. I’m a principal investor at Balderton, which is a multistage venture capital fund investing across Europe. And today I’m really excited to sit down with two amazing technical leaders. So we have Vicky from Zego, Neil from GoCardless and John from Google who I will let introduce themselves in a few seconds. But before that, I wanted to give you a quick overview of what we’re going to discuss today. And it’s all about growing and scaling engineering organizations. So CTO and VP of engineering are very important roles in building and delivering amazing product to users. But for fast growing startups the structure of the organization constantly varies along the company journey. So from a small and agile single team composed of three developers up to an organization of hundreds of engineers with many cross-functional teams there is a world apart.
Maxime Le Dantec:
And this ever-changing environment implies constant intuition on organization design, of course, but also people management and culture. And we’re going to touch upon this topic today. So we will have 30, 40 minutes of discussion. And after that we will keep time for answering some of the questions. So don’t hesitate to enter your question into the open chat on the right end of the screen, and we will make sure to address them at the end. So without waiting further, let’s start with a round of intros with our panelists. So, Vicky, if you want to have a start.
Vicky Wills:
Thanks, Maxime. Hi, everyone. Great to be here, looking forward to meeting you all. I’m Vicky, I’m the CTO at Zego. We are an insurtech in the commercial motor space. And for today’s talk about growing teams, we’ve just blown past the 300 mark. We’re growing very rapidly and haven’t taken our series C round this year. And we’re in for innovative insurance products, especially in the gig economy is where we started and where we’ve grown our products out across commercial motor, which has really given us a unique perspective on the understanding of risk and access to data in that space. So as the products have grown, obviously that’s seen a real need for the team to grow as well. We’ve got some incredible projects going on at the moment. So growing engineering teams is a huge topic for us at the moment seeing it’s really close to my heart and really looking forward to the discussion today.
Maxime Le Dantec:
Thanks a lot. John, if you want to…
John Abel:
Yeah, good afternoon. So my name is John Abel. I’m one of the members of the office of the CTO, which is an engineering function with Insights Google. We are a team of CTOs that help Thomas Kurian, our CEO of Cloud, to do things like emerging technology. We also work with some of our most leading brands on their technical challenges. So it’s great being here today.
Maxime Le Dantec:
Calling in Neil.
Neil Turner:
Hi, I’m Neil. I’m the CTO at GoCardless. So we do payment technology. The size of the org at the minute, nearly at 200 across all the product development with over 100 engineers growing by about 50% by the end of the year and then new expansion into 2022 as well.
Maxime Le Dantec:
Amazing. So looking quickly at the people in the audience, I can see CTO from [Suburb 00:07:00] coming from every stage it’s right. So I think what would be interesting to start with is to evoke the different stages and intuition of the organization each of our panelists went through, right, from the very first days where the CTO is the lead developer and everyone is going into the same direction without much process up to the scale at which Neil and Vicky and John scale the company with hundreds of people where obviously you need some layer of management processes. So I don’t know which one of you want to start and frame what were the different stages you went through. And I think what would be also particularly interesting is to understand how you made the transition between the stages, whether it was something seamless and easy or something painful which require some heavy changes. So I don’t know who want to take it first. Neil maybe.
Neil Turner:
Yeah sure. I can start. I joined GoCardless when it was in the tens of engineers. But I’ve done blinkbox before that, where we started I was employee number three. So I’ve done that a couple of times, that scale. As you said, when you start you’re hands on keyboards, you’re in the code, you’re pulling the all-nighters, you’re working hard with everyone. And you have no process, you have no HR, you have no competencies… Everyone just gets on with whatever’s the next most important fire is, right? And as you evolve, you start to then realize that you can’t have 30 reports and you have to form some form of hierarchy. That’s the point where we started having people move into people management roles.
Neil Turner:
And when they first started doing that, they had been engineers and they had natural talent or previous experience of being managers, good communicators, cared about people, often came from tech leads. So we had this hybrid model. And as we’ve evolved more, we’ve skewed more towards the people management, mentoring, guidance, pastoral care, servant leaderships style topics than pure, raw, recent technology experience. Everyone that’s an engineering manager at GoCardless has coded, has done the job, has got the cup, but they don’t do that day-to-day these days. I can talk some more about where we’re going, but I’ll be quiet now.
Maxime Le Dantec:
Amazing. And, Vicky, and, John, when you think about the transition between the different steps of growth, what were the weak signals that we used to see that things were not doing well and that you had to enforce some changes?
Vicky Wills:
Well, for me, I think Neil’s hit one of them on the head, which is the number of direct reports people end up having. I think that’s a really good indicator if you’re looking at growing the team. And interestingly, I joined Zego in the tens as well, so similar to Neil’s experience. And it was just at that point where we were outgrowing the model of hands-on CTO and 20 people in the team. And as Neil says, I think you’ve got to think about what do the team need? The team’s need change because of the number of connections and the number of people. So whilst you can all sit around one table, be one team, know what everyone’s doing, at the point where that’s no longer possible you do need things like competency frameworks. You need to know leveling within the team. You need people management. You need to keep the culture as well really tight between the different teams.
Vicky Wills:
So I think it’s just looking at what do the team need at the different stages? Because it will change because there’s a limit to how much any one person can hold in their head and at one time. So I think trying to preempt those is difficult, but it is really important to try and get ahead of those things because none of them are quick. And we found it took us about six months to really land the progression framework in engineering at Zego. It didn’t take six months to write a nice spreadsheet with all the different levels and the competencies, what takes six months is all the iterations you go through, the conversations, people understanding it and people being able to work with it and it really landing in the team. And if you’re doing that to the point where the fire is burning, you’re six months out of seeing any of the benefits. So trying to preempt those things is really important as well for me. I don’t know about your experience, John.
John Abel:
Everything you said resonates really well because I think it… And it’s different for me because I’ve never been in a startup. I’ve always been in the big mega corporations, et cetera. But in my role, much of the emerging technology that I’m having to invent, I’m having to code. I don’t have a development team with me. I’m like a one-person start up where I have to build it, I have to write the specs. The thing I have to have in mind though is how I scale it. So it’s like there’s many things that I have to do in my engineering day job where I have to give up certain things as well. When you’re looking at scaling teams, you have to be accepting to give up quickly. I’m not going to scale something that goes to planet scale on my own.
John Abel:
So I have to set the right starting point so I can then scale as the team gets bigger. Always the aspiration is to have great successes like Gmail or et cetera. But actually in the real world, majority of the work we have to do, we generally get through to design or we get it through to proof of concept. And then we just give it up to an engineering team. So slightly differently, but everything that’s said is super relevant because it actually relates really well to even big end corporations like Google. We’re still micro corporations with insight. So it’s not just one big team working on one big mission statement. We’ve all got our own OKRs as we call them, objective key results.
Maxime Le Dantec:
Great. And I guess how do the three of you think about the trade-off of basically letting developers… Letting them their own liberty? Because when you see at the beginning of a startup organization, there’s pretty much no process, right? Everyone knows everyone. Really 20 developers can code all the day long, make things [inaudible 00:13:32]. And obviously as you grow there’s more and more process, you need to write more documentation, everything need to be written and so on. So from a manager point of view, how would you handle potential resistance to change of developers? And how would you make them understand that processes are important?
Vicky Wills:
I can weigh in on that one. So I think this is all about picking where you’re going to put the process as well, because with all the will in the world you can’t have everything buttoned down and running beautifully the whole way whilst you’re scaling an organization, I’m sure. Well I think I’m missing something, Neil disagrees with me. But there was a lot of chaos that goes on with growing a team quickly, especially an engineering team. So you can’t possibly hope to have everything process-driven documented all the time. So it’s about picking where the important areas are and making sure your team understands why it’s important as well, because as you say, I think you mentioned the innovation piece. A lot of engineers are at their best when they do feel like they haven’t got those boundaries and they can really run into a problem.
Vicky Wills:
So I think as leaders we have a responsibility to identify where are the business needs, that type of mentality, and to make sure that they have the right environment to work on in that space for the type of engineers that really, really go through those problems. But other places like you have an insurtech, right, security’s important, we’re audited, we spend a lot of time with the regulators… I can’t really throw my hands up and be like, “Go forth and hack.” It doesn’t matter if you don’t write anything down. And I think just making sure the engineers understand why things are important and making sure you’re clear about what’s important as well as a leader, that’s one of the most powerful things I think as well.
Neil Turner:
I think you have to find a way to have that conversation where it’s not about the process, the process is what happens. We care about two things, we care about impact and outcomes and how many lines of code you write. If you’re doing great work and everyone else can’t work because they need your brain to be able to do that, you’re not having the impact that you should have. So it’s like the best engineers make everyone 10% better as opposed to getting to the end state first and then waiting for everyone else to catch up. So we try and find people that understand that. And the other bit is you’ve got to find some firebrands or agents of change that want to help you on this. If you as a CTO are going, “I need more process.” You’re going to [inaudible 00:16:15] a ditch on your own because no one’s going to want to work with you.
Neil Turner:
So you need to go, “I want this outcome. Do you all agree we need this? Then how do we get there?” The process is just that. It’s not the end state, it’s the way you get there. And you still will lose some people. It’s unavoidable that some people love the startup hacking mentality. And we’ve lost great engineers who’ve gone back to new startups over time. And you have to wish them well and let them go on with it.
John Abel:
It’s really interesting, everything Neil’s said I agree with. The only thing I think I’ve changed my mindset in the last few years-
Maxime Le Dantec:
We lost John.
Neil Turner:
Where’s john?
Vicky Wills:
Just a [crosstalk 00:17:03].
John Abel:
Okay. Time to [inaudible 00:17:11]. Yeah, just at that point. Yeah. I have had to give up certain engineering aspects that I used to want to be involved in because actually it doesn’t answer the job in hand. Let me give you an example. I used to think that we would have to develop everything. And actually now I just accept certain things I’m just going to use a service that might give me that because it doesn’t add anything to my business value. And bluntly, I’m not going to build the best database on the planet or the best security. If I can just adopt that as a service, I’ll just do that. The challenge then as an engineering leader is when do you give the freedom to innovate? And when do you actually give the instruction to follow a standard? And that’s the one thing that I feel, as a CTO, we have to really think about that balance of not constraining the team, but also not making the team reinvent the wheel that everybody has agreed the wheel today is good enough or is more than good enough, it’s brilliant.
John Abel:
So it’s a really hard balance to have. And I really like the way Vicky talked about the balance of not giving the engineers too much flexibility, but also not giving the engineers not enough flexibility, they don’t feel like this is an interesting place to be. So it’s a serious consideration, but if I can get a service for core aspects of what I’m engineering, I’ll take it every day of the week. And I think that’s when the mission statement, and I’m not thinking of corporate mission statement, the objectives of what you’re trying to do is crystal clear where your unique IP actually is. And everybody wants to drive into the unique IP. So I think it’s a really tricky thing because CTOs now aren’t just technologists. I don’t know what Vicky and Neil’s view is, but you’re also business leaders, which means you have to think of the ramifications of what you’re investing in. It’d be great to hear your insight because I’ve not lived in your world, in your hot seat. So it’d be fantastic to hear what you think.
Neil Turner:
All right. I’m going to be quick on this one because I’ve got a very, very locked philosophy on this. We run on Google Cloud, but pick your vendor. But if Google can do it for me, I let Google do it for me because it’s way easier, they’ve got more engineers than me. Next down is if Google don’t do what I need, I look at open source. And on the end I do buy versus build. And John’s exactly correct, I go, “Does it make us worth more money? Is it secret source? Is it IP?” If not, unless it’s prohibitively expensive, I buy a service to do that. And it’s that quick. We use TESSY for our email security. We use that because they do it really well and we don’t want to do it. It’s like you pick what you can out of the stack as soon as possible. Then I’ve got more to do than I’ve got time to do so why pick more things up?
Vicky Wills:
Exactly. I completely agree, Neil. I think, as you say, when you’re running quickly you can’t build everything. So identifying where the IP is and making sure people know that as well. And I think that the only thing I would add to that is that engineering teams cannot effectively work in a vacuum, they can’t work in a silo. So all the decisions that you’ve just outlined, Neil, to your point, John, as well around being business leaders, those conversations are always with people outside of technology in my experience as well, especially at that C level. Obviously for some of the more technical aspects people might not engage, but when you’re making a business decision about how an operational process might use a particular tool, you’re no longer in the, “Oh, well, technically it’s going to click together like this.” You’re looking at things as end-to-end business concerns, which is super interesting as well.
Neil Turner:
It’s interesting. You said earlier Vicky about there being many distractions, and you could go and do loads of things and it’s always that, but we can build anything anyone wants. But building our own workflow, our own reconciliation engine makes no sense when it’s not all of what we do.
Vicky Wills:
Exactly. And it isn’t always clean cut as well, I find the decision, right? Sometimes you’ll be weighing up third party options. You might be looking at buy versus build. And I think it’s something that all of us have as engineers, right? Like, “Oh, if I could just build it, we could make it do this.” And it’s super exciting. And I think all of us have that itch of to feel like, “Yeah. But we can make it so much better.” It’s like yeah, but should you? And I think as a CTO you’ve got the angel and the devil sat on each shoulder having arguments about these things as well. So self-discipline is probably an important point in this conversation.
Maxime Le Dantec:
And to your point, Vicky, because the two of you are working at technical organization that are quite big right now, how do you make sure that you keep this innovation coming from the bottom with people that are encouraged to propose new ideas, push for new ideas while making sure everyone is going in the same direction, that nobody’s going into their own direction. So how would you maintain this creativity and innovation at the core of your organization?
Vicky Wills:
For me, this might sound counterintuitive, but I actually make sure that the team’s bounded to a particular area of the problem they’re trying to solve so that nobody’s trying to solve Zego. Because I think that’s where the distraction comes, if you’re trying to operate across the entire stack. So we’ve gotten to a size now where we can have dedicated teams for the different business lines, we’ve got platform teams and everybody knows the domain they’re operating in. And it’s really important to me they have complete ownership of that. I don’t sit and dictate how everything’s going to be built or architected. And there are much better people in the room than me who are much closer to the problems that they’re solving in a particular domain as well.
Vicky Wills:
So my answer to that question is actually by bounding the context and empowering people to make decisions, make sure they know the principal’s life. If you can buy something off the shelf, please buy something off the shelf and come and tell me that you bought something off the shelf and we can manage that to a more senior layer. But I think it is really important that people do feel the ownership because that’s when even if you are buying things off the shelf and plugging together, innovating on little bits, they’ll spot those opportunities, and that creativity can really come through.
Neil Turner:
We have a few red lines like you don’t get to pick observability technology. The platform team decide what we’re going to use for monitoring and observability, you fit into that. You don’t get to write your own encryption algorithms. Please don’t ever write your own encryption algorithms. There’s some red lines that we just put in place to say, “These are the pits of success that we want you to fall into. And our platform team should see you as their customers and provide what you want.” And you’ve got to keep an eye on the CV photo of somebody deciding a new language is what they want to write it in. And then you have to explain that, “Well, that’s great for you, but no one else knows it. And how are you going to support it? And what happens in two o’clock in the morning.” But you just put a few boundaries in and then let everyone else innovate on the problem space, not necessarily every single technology choice. So more of a toolbox for them than anything else.
John Abel:
And I think what’s really nice about this is that those constraints aren’t about the innovation constraints, they’re just about scaling constraints. They’re just about the things that we know as leaders will catch us out later down the line. So they’re super important to us. The other thing as well which I always do when I come up with new ideas is I think about the S-curve of the typical… And every company goes through its S-curve. When we’re in R&D there’s like three times the effort for one time yield, everything feels really hard, you’re having to explain it, you’re having to really immerse yourself in actually more than just the technical aspects, much more about what you’re trying to do as a business. When you get into growth the pane flips, it goes from like one times effort to three times yield. But your effort now is much more about the scaling of what you’re doing and removing the constraints of scale.
John Abel:
The most successful companies I’ve worked with and the most successful startups that I’ve mentored is where the founder or the leader of the engineering side is actually like on page 30 of the book while the current engineering team are on five. And they’re starting to think about navigating like a Minesweeper the next set of issues that the teams might come against and then start guiding them. And I think the important thing as a leader it’s about guidance, not about as… I think, Vicky, you said you’re never going to be the expert across your teams. It’s about guiding them. And you talked, Neil, about this and red lines. It’s about that guiding aspect of the leadership.
John Abel:
The other thing I thought I’d say, which is a slight pivot but it’s quite important, people at Google, we review everybody’s code by human eye, every bit of code that’s ever written as a human eye. We all are desperate to hear LGTM, which is looks good to me. It’s like the magical moment of when you’ve read some code because actually readability is core aspect. Because back to Neil’s point, if someone writes in something that no one actually understands or code is developed in such a hacked way that the next person to pick it up has to re-engineer it because they don’t even know what it means, that’s like core trigger events there. And it was a question that was asked, what are the core trigger events? Those are the ones I look out for because they’re the ones that catch you out later down the line. And I don’t think it’s the CTO’s responsibility to do all code reviews, but it’s those principles you defined for the engineering principles that you want to just get some boundaries in there.
Maxime Le Dantec:
That’s a great transition to now speak about the second topic of the panel today which is about people and culture and how to remain human-centric as you scale an engineering organization. And the first thing which would be interesting to mention is, so we often speak a lot in the startup world about startup culture and the importance of defining it early. I was wondering, within your engineering organization, what culture have you defined, and what behaviors or values are you trying to encourage?
John Abel:
I can throw one out while Vicky and Neil are thinking. Empower people to remove friction. And what I mean by that is friction cost money, it does not earn money. So one of the things we talk about is in the own engineering, if something’s causing friction engineer it out, don’t accept it. This was a principal to find by liability engineering. More than 50% of the toil or time spent on toil, don’t accept spending time on toil. So as you scale, removing friction is super important in every opportunity because as you scale greater and greater you need more human effort to manage friction. So one of the key things to do is that you want allow the human to spend as much time on the innovation part as possible and automate. And I don’t believe, and again it’d be great to hear Vicky and Neil’s point, even if you’re a two-person startup with one engineer, there’s still no real right to be sloppy in what you do.
John Abel:
There are still good enough aspects out in the industry to guide you on the principles of good engineering. And the effort you put in is a bit more than what you’d have to put in to be a more non-quality engineer. And I believe in that. And I might not be right, but I’ve always felt that it’s so easy now to develop good engineering projects. Having those principles even laid out even if they’re not written is super important even for very small startup size. But it’d be great to hear what Vicky and Neil’s views on that are.
Neil Turner:
[inaudible 00:29:08].
Vicky Wills:
Okay, cool. Yeah. For me, I broadly agree. I think there is a level of what’s appropriate for the stage of the company and how established is the product for me. So if something is experimental as a product and we haven’t established product market fit or we’re not sure quite which direction it’s going to take, there’s a high possibility that everything you write is going to get thrown away. I’m in favor of the learning that you’re going to do. So for me in certain situations, the code, it comes second class to getting something out there as quickly as possible to get the learnings from it. I’m not dismissing, there are good engineering practices, but if speed is the most valuable thing to the business at that point, I would much favor some tidy up post-fact because the chance you’re going to have to rewrite it anyway because you won’t have got it right the first time as a product.
Vicky Wills:
But I think if you’re certain on the product, then I’m with you, John. There’s so much written down or there’s so much accepted knowledge of how to build good systems and having the discipline within an engineering team to achieve that. It also just makes things so much easier down the line as well, especially if you’re going to grow the team. Because it’s all very well if you’ve got a small group of engineers and they’ve pushed something out. And it’s all in their heads, but they can’t onboard anybody because they haven’t followed good practice and principles that can cause huge problems as well for teams. What are your thoughts, Neil?
Neil Turner:
I agree with what you both said. And I lean on your side of the world, Vicky, which is we’ll build it rough as long as we know we’re going to get the time to fix it later if it succeeds. That’s how we do the product growth stuff. That’s how we do the experiments, et cetera. The things that I think fly really well for us, I steal from Reed Hastings on this one, no brilliant jerks. We just don’t hire people that are not going to get along with other people however good they are at writing code because writing code is 10% of shipping product. And the other one is, and I’ve seen both sides of this, we hold the product manager and the engineering leaders accountable for the outcomes.
Neil Turner:
You cannot succeed as the product manager by shipping, by having a large number of customers if the product quality is awful. So that means that we have a focus on shipping, but you also have a focus on making sure that you’re dealing with your tech debt and [NFRs 00:31:48] and everything else. Otherwise, you end up with… It’s not tech debt, it’s product debt. We don’t decide to quote it badly for fun. We do it because of trading speed versus quality, et cetera. So we have to make sure that we own the entire problem space and we hold people account, myself and the chief product officer, Duncan, for making sure you’re making progress in all of those things, not just on future shipping.
Maxime Le Dantec:
And how would you measure product debt? Does it mean that product leaders they’re, “Okay, our objective.” You measure the numbers of time the product goes down or things like that?
Neil Turner:
There’s a bunch of stuff out there that does that. There’s talks about number of incidents you measure your proxy for product. I’ll find a different way of doing it. You’ve got to go back to commercial outcomes. So the way I think about this is if we want to sell our product to the largest customers in the world, they’re going to ask some things around availability, reliability and security that are not product features per se but things about our platform that we build. So if I can get the chief revenue officer on my side of the table arguing for SOC 2 compliance because it enables him to sell to customer X, then I’ve won, right?
Neil Turner:
You’ve got to tie these things back to numbers in the end because we’re a business that goes, “If you want to do this thing as a business, I need to do this thing to our platform or product to enable that to happen. And what that means is it becomes very much a numbers game, essentially dollar value, which allows us to compare features versus non-functional work that we need to do. And it’s really hard to do. And we’re still trying to build the framework for that, but it gives us a way to talk about our product maturity separate from our product feature set.
Vicky Wills:
That’s a good point. Because there’s also an opportunity cost, right? If you rush something out and you don’t go back and fix it, it’s slowing down everything else that’s built on top of it. I don’t sit here and pretend to know the answers to exactly how you measure that, but talking to stakeholders, to product managers, you can usually get a read on how their satisfaction is usually tied to the speed at which we can deploy changes to a product and push something forward iteratively. And if we’re not being able to do it, if we’re constantly being slowed down, projects are constantly delayed or we’re going over the allotted time to deliver things, that’s usually a good indicator that you’ve got some product there as well.
Neil Turner:
We’ve started to track enable work, toil and new product feature delivery as a way of modeling the curves over time. And you want new products to go up. As your enablement work increases it should enable the toil to be reduced. And it’s never perfect, but you can model it over months and see if you’re going in the right direction or not.
Vicky Wills:
I like that. I might steal that.
Neil Turner:
I’ll send you some [inaudible 00:34:49].
John Abel:
The one I also like is the concepts of giving engineering team not just commercial budgets, but product budgets. So one of the things we talk about is like error budget, the acceptable amount of time that you could have errors in a platform at certain scale, and actually have the engineering team have a fiscal budget. And that drives a certain due diligence because once you start talking about budgets people think in the financial context, but actually in the context of products or coding there’s an implication to it. The other thing is well, Neil, you said at the start. I loved how you said it. And I don’t know if you picked it out, but observability verse monitoring, that actually these days observing something, not only the technology, not only the solution, but the people, is equally as important as a leader more so now than ever before, especially in this virtual world where we don’t really bond in the same physical landscape.
John Abel:
But the observability and seeing degrading levels of performance over time and how they’re starting to tell off is also super important because nothing in technology is ever on, off. There’s always a time it starts, you start seeing. And that’s the same with people, process and technology. But that’s really interesting.
Maxime Le Dantec:
Great. I would like now to tap in to address from a more personal topic which is how you as technical leaders have grown into your role, right? We often say that startup leaders, because of this ever-changing environment, has to revisit and change the role on a really regular basis. So for the audience, any practical tips that you have for helping people to scale themselves faster. And what could they do to do that?
Vicky Wills:
I can have a crack at this one. So first of all I think the most important thing to recognize that this is people, right? When you’re scaling engineering team… We’ve spoken a lot about the processes and the most technical aspects. And at the end of the day we’re adding people together to work together. And every single person who’s going through any sort of start at this scaling is going through a unique personal journey as well. I think acknowledging that and being able to have the conversations with people to really learn about what they’re experiencing right from junior engineers right through to a CTO, right, everybody’s growing through the process. And I think it’s not an easy thing to be part of a scaling they have started, but it comes with a huge amount of opportunities for personal growth as well. That’s what we’re all here for as well as the excitement of the company growing, the product growing, but also the opportunities you get as an individual as well.
Vicky Wills:
And one of the things that is really important to me is that people do feel that they are going on a positive journey through the team growing. I think to Neil’s point earlier, you’re not going to keep everybody. It’s just not for everybody. They will work for a fundamentally different company every six to 12 months if you’re going through rapid scale. And some people just won’t want to work in the company that we’re aiming for, and that’s fine. But making sure people can approach that positively as well, because nothing worse than having resentment for the way things used to be or any negativity in the team.
Vicky Wills:
And one of the things that I always tell people around me is that as soon as you land in a position in any startup, it doesn’t have to be tied to a job title, your responsibilities are constantly changing. As soon as you have something, the first thing you have to do is start writing yourself out of that job because in six months you need to have handed over everything you’re doing today if you’re going to carry on with that path that’s longevity and scale with the team. And that’s something that I’ve found really useful as a mentality. So to really look at what you’re doing and think, “How am I not going to be doing that in six months?” If you approach it with that mentality, you’ll find that you grow the team, you develop the processes. And it’s really healthy as well because you’re giving people the opportunities to step up as well. So that would be my advice.
Neil Turner:
I agree with all of that. Our jobs are all building. We’re not coding anymore. We’re not anywhere near the technology. We are finding the best people and putting them together in the best combinations we can. I don’t know if this is a British thing. I think it probably is, but we avoid certain conversations like the conversations of where do you want to work next? Because if you can actually answer that question, we go, “Well, cool. You want to get to here? And you’re now here.” We’ll set up the tour of duty, It’s often called in some of the books. And I’ll help you get there. And then you will leave. This is not a family that you’re joining. This is a sports team that you’re joining. And you move on to another one and do a different role. And eventually you end up as coach at the new one.
Neil Turner:
But having the conversation about what do you want to go do next? And if I can keep you interested and engaged in learning and growing along the way, then you’ll stay for a very long time. But at some point you will go. And that’s not a bad thing. We want you to go as a great ex, whatever company it is, that people want to try and take because we’re seen as somewhere that builds great people that other people want. So it’s having that slightly uncomfortable conversation about where next, when will you leave us and why? And I will try and keep you for as long as possible, but also I appreciate that you’ll go somewhere else.
John Abel:
Yeah. A slightly different tack, but going on from where Neil and Vicky’s in, I always believe it’s critical to have, even if it’s not written down, your succession planning. I think, Vicky, you’re right, engineering yourself out. I spend a lot of time as a leader. Our role is to have a successor. If you want to move up in the organization, someone has to take over what you’re doing. And by the way, succession planning doesn’t mean it’s the person that reports to you. It could be external. Spending time externally as well as internally is super important. The other aspect, you have to blend all elements of leadership, coaching and manager. And actually at certain points you’re dialing up more coaching or you’re dialing up more leading and you’re dialing up more managing. But it’s super important to reflect on where you want to go next with the team and how you want to scale it and be open in discussion.
John Abel:
The best teams I’ve led is where there is an open discussion of what we need to do next as a team. One thing a team does not like is a shock of XYZ on a Friday that we’re going to do now on a Monday. So they like to have just even a bit, the mental coaching of we’re going through change, we’re going to have to adapt. The other thing as well, culture is not static. The amount of companies I’ve worked with over the years, hundreds of hundreds of companies, where even I’ve spotted the culture adapting over time. Because when I first met them to how they scale. And actually appreciate that culture does adapt. And that adapting is good or bad, it’s depending how you view it. But it does adapt. It’s not static. And there’s a lot of people who believe it is static. It’s not. It’s dynamic like everything else in business.
Maxime Le Dantec:
Great. So I think we are close to the last 10 minutes of the session. We can now take some of the questions. So please people don’t hesitate to write them down. I think we had a question from ProTech that gets back to the first part of our talk which was as the product market or new signals that trigger engineering scale. And maybe if I try to appropriate to be the question as I am an investor, would you say that funding events for your company, for your startup, also influences your roadmap in term of scaling the engineering organization?
Neil Turner:
Yeah, definitely. So whenever we’ve gone through a funding round it tends to be, “What do you want to do with it next?” As it were. And that tends to come with our, “We have product ambition. We want to do new things and new markets. So we’ll need to grow some form of product.” It’s quite a painful period because unfortunately investors assume that by giving you the money, they get the product like the next day. And it’s a laggy system, right? Building a new engineering… Growing an engineering organization and then getting them effective, dealing with all the challenges along the way… It takes quite long time. So it’s quite a pressure cooker environment when you’re doing that. But yeah, it definitely causes rise to a exponential growth at that point.
Vicky Wills:
Completely agree, Neil. I think when you go into a funding round, you’re usually going into it with an ambition to achieve the next step, right? If you’ve got technology at the core of any product, that’s usually going to involve a lot of technical build. I will say, I think it is, as a very obvious point to make there, always know what you’re hiring your engineers to do. Growing an engineering team for the sake of it is not a good plan. And so, “We’ve got those of money, let’s hire some more engineers and see what happens.” Is never going to result in anything. Because it’s all about the cohesiveness of the product and the structure of the organization to make sure you can handle that product growth as well and render the opportunities. So yeah, completely agree, Neil. It does coincide with funding rounds obviously. It’s not cheap to grow engineering teams either, which is why we all go in for the VC funding.
John Abel:
Yeah. I have very little to add other than saying it’s an ecosystem because as you scale you need new capability as well as expanding existing capability. So I’ve helped startups go through funding rounds, and I find them exceptionally interesting. And back to Neil’s point about when can you turn on the tap for the next level of innovation? And then you say, “Well, six months to 12 months out.” And then you could see your founder sitting there going, “Why did they say that?” Just say it’ll be there by Monday. And it’s like we can’t magic this stuff up. So yeah, but no, brilliant point.
Maxime Le Dantec:
So the next question from Jake Clarkson is if you go back to when you had around 10 engineers, A, what one thing would you do differently? And, B, what one thing are you delighted you did with the insights? So what would you do differently when you were at the limit of 10 engineers in the company?
Neil Turner:
I’ve got a controversial one on that one. Okay. So at blinkbox, when we were about 10 engineers, we were streaming movies before Netflix, Netflix won. So our tech was better, and we got there first and we still absolutely lost. And the reason is looking at your product market fit and looking at your marketing and how you approach brand, et cetera. Every engineer thinks it’s someone else’s job and is really uninterested and boring, and it’s not scientific, and they don’t know what they’re doing and everything else. If you can’t market your product and get customers, it doesn’t matter how good the tech is.
Neil Turner:
You need to think outside of the box of engineering and product development and actually engage with the rest of the business and the experts that you’ve got and work at what they need as well. And it’s really easy to forget about it and go, “They don’t understand. More product, more product.” But if no one’s buying it, it doesn’t matter. I’m not sure I’ve got an answer to B. I’ll have to think about that one, but that was my A answer anyway on that one.
John Abel:
Do you want to go next, Vicky?
Vicky Wills:
Can do. By the way I don’t think that’s controversial at all, Neil. I think engineering teams siloed in a black box, “Oh, that’s the engineering team over there. Don’t disturb them. They’re doing terribly important work. None of us understand it, but it’s terribly good.” It is a really easy playtime, we joke about this. It’s a really, really easy trap to fall into because as engineers your heads are in a million technical problems at once. The last thing you probably want to do is speak to somebody in the commercial team. But I completely agree, Neil. But at the risk of making the same point again, where else would I… I think in terms of something that I would perhaps do differently is not heavyweight, but have people understand what it means to be an engineer at different levels.
Vicky Wills:
So you’ve got 10 engineers. I’m trying to say you probably have got some that are more senior than others. And whilst I wouldn’t advocate for putting a heavyweight progression framework, and it is quite difficult to retrofit when everyone’s been operating and thinking that they’re all at the same level. And I think you’ll get a bit of realism into some people in the team, but you’ll also get the opportunity because leadership skills are really important regardless if you’re going down a managerial or an individual contributor track. And nurturing those leadership skills in your senior engineers early on will help them progress and emerge as the dominant leaders as you scale the team up as well. So I think just signposting web seniority in the team is something I would say for A. Haven’t gotten anything for B either. I’ll pass over to John.
John Abel:
I’ll do an A and a B. And both of them are not technical actually. Well, they are… No, they’re not actually. One is if you spend time on creating a diverse mindset team, and diversity is critical, you get much better outcomes. When you have the same style of engineering everyone you hire, you get a very standard outcome. And actually the one thing I’ve learned over the years is the effort I put in to developing a team that is diverse from the start has actually yielded so much more. Because you get less caught out because someone is thinking about it in a different way. The other one that I learned, and this is the A one, one thing would you do, don’t allow the water cooler conversations to be ignored. And what I mean by that is an engineering team when people spot issues or challenges, they talk about it generally at the water cooler or the coffee machine.
John Abel:
And actually you hear them as well. They assume as a leader you don’t hear it. They say, “John’s not really thinking about these.” Actually if you know about it, talk about it openly with the team. Don’t hold back on things that you know are issues. If the team know these issues and you know these issues, deal with it when it appears. Because the more it boils, the more you get taken off the job in hand that you’re trying to deliver. So I’m a big believer now in having an open leadership style where actually it’s not so much about servient leader, but it’s much more about, I hear the things as well. I just shouldn’t ignore them as a leader. That’s just poor form. So those are the two things I’ve learnt over the last quite a few years.
Maxime Le Dantec:
Okay. Maybe one last question from [Eric Robison 00:49:48] is did you find silos between departments within the company, so engineering, marketing, sales, ops, developed as the team grew? And do you have any ideas to mitigate these that worked for you?
John Abel:
Yes to both. Yes to all. My only view there very quickly is communication. I hate to say it, regular communication and communication when you don’t need to communicate. So make it more human communication e.g. don’t just turn up at someone’s desk when you need them. Actually invest in understanding their world. Invest what pressure they’re under. Invest on that even if it’s outside your job. So yeah, communication and engagement outside the day job.
Neil Turner:
I think the question is interesting because I don’t think silos develop. I think by default they’re there. This is just a function of my job is my job, and I’m really busy, and there’s loads of important stuff to do, and I don’t need to spend time on studying our engineering or brand work because I’m doing this other thing. You need the shared goals. We also do some stuff like… We do a lot of town halls where people talk about what they’re doing across different parts of the business. And we do them week in, week out with the whole company there. It’s actually better on Zoom because everyone can be there all at the same time, right? And they help, they’re expensive, and they’re time consuming to prepare and everything else like that, but they actually get us to where people understand what customer success is doing and what product development is doing. And you have to put a lot of effort into those things to share the context continually.
Vicky Wills:
Yeah. I completely agree with that. I think silos exist because it is quite natural to think about departments within a company. But so much of the modern auto-management thinking and product development relies on cross-functional teams and multidisciplinary teams as well and those skill sets coming together. That’s when you can really hope to land something amazing, is when you do have, as Neil put it, shared goals. Are you all solving the same problem? Because you do need all those disciplines to come together to create an amazing company. So as much as you can communicate, if you can actually work together as one cross-disciplinary team… It’s not easy to achieve in every scenario, but they’ll create opportunities, I think, where you can bring people together and have them share the problem and deliver an outcome together because they’ll learn about how each of the work, they’ll learn about the problems within all the different disciplines.
Vicky Wills:
One of the things that always gets me with engineering is it’s the easiest one, maybe with the exception of some of the data disciplines, to go, “Oh, well, nobody understands what they’re doing.” And it can get on from our side as well. We can become lazy with it. It’s like, “Oh no. Don’t worry. It’s complicated.” And we’d all go further. Or engineers will be congratulated for doing something magical, and you’d think, “Well, it wasn’t actually that difficult engineering.” So there’s a very odd dynamic that can evolve. But trying to keep to the point of town halls, keeping the communication open, it’s really important. So invest in it early, I think. And make sure it’s part of your organization culture to be curious, at least, about what other people are doing in other teams, if not actually working with them.
Maxime Le Dantec:
Great. So I guess we have no more question. And we’ve already overrun by five minutes. So thank you very much, Neil, John, and, Vicky, for your insights. What I will take away from this discussion is that scaling and doing all this innovation is all about setting the right balance between giving enough liberty and autonomy to people so that they are on power to keep innovating while also making sure that as an organization everyone is going in the same direction and basically working as a team. So thank you very much. And see you soon.
Neil Turner:
Thank you. Have a good-
Vicky Wills:
Thank you.
John Abel:
Thank you very much.
