In our latest Digital Lighthouse episode, Sarah Hale, Senior Director of Engineering at Unity Technology joins Zoe Cunningham to talk gaming, career paths, and the importance of clarity when leading a team.
Sarah reflects on how she’s needed to evolve as she’s worked her way up to an engineering leadership role, while still regularly drawing on the skills she learnt early in her career.
This episode is a must-listen for anyone in a technical or engineering role thinking about where they’d like to go next in their careers, and for engineering leaders looking to learn from someone in a similar position.
You can listen to the full podcast on this page, or wherever you get your podcasts, and read the full transcript below.
Digital Lighthouse is our industry expert mini-series on Softwire Techtalks; bringing you industry insights, opinions and news impacting the tech industry, from the people working within it. Follow us to never miss an episode on SoundCloud now: See all Digital Lighthouse episodes on SoundCloud
***
Transcript
[music]
Zoe Cunningham: Hello and welcome to the Digital Lighthouse. I’m Zoe Cunningham. On the Digital Lighthouse, we get inspiration from tech leaders to help us shine a light through turbulent times. We believe that if you have a lighthouse, you can harness the power of the storm. Today, I am super-excited to welcome Sarah Hale, who is the Senior Director of Engineering at Unity Technology. Hello, Sarah, and welcome to the Digital Lighthouse.
Sarah Hale: Thank you so much for inviting me on. I’m excited to chat with you today.
Zoe: Amazing. Can I ask you to start by telling us a bit about your current role and also about Unity, for people who don’t know about it?
Sarah: Sure. I’m a Senior Director of Engineering at Unity, which is the world’s leading platform for creating and operating interactive, real-time 3D content. Although most folk know Unity for the video game engine, we actually do a lot of things across a lot of different industries. I, myself, lead a globally distributed team working on the analytics LiveOps and game backend products within the Unity Gaming Services platform. Unity Gaming Services itself is an end-to-end platform with a suite of products that help game studios of all sizes build, engage, and grow successful live games.
Zoe: It’s very exciting because I think for lots of engineers, particularly engineers working in maybe very business-focused or corporate-focused jobs, working in games is one of the most exciting things. I guess at Unity, that’s what you’re doing?
Sarah: Yes, I know. Most people assume that I’m working on really exciting game development, but actually, the whole point of my role is helping build the tools and services that help game developers build their exciting, cool games. Most of the skills that I have or utilise, I learned in previous roles, like running SaaS-based software. It just happens to be not for the travel industry, it’s now for the gaming industry. It is exciting but it’s adjacent to game development. It’s not actually game development.
Zoe: You’ve actually touched on my next question there, because I wanted to ask how you got to do the role that you do now. What’s your journey been to get there?
Sarah: Cool. I think I probably have a fairly standard journey in some sense. I started as an IC – an individual contributor – as an intern at Yahoo. Then I headed up to Scotland to work at a digital agency for a few years, working mostly on web development, a few different clients there, before moving to a relatively unknown startup at the time, Skyscanner, which is a travel search engine. There, I was part of Skyscanner’s growth journey, which also helped accelerate my own growth journey.
I levelled up every couple of years of the IC path, to become a principal engineer, before moving into the management track. Then after Skyscanner, I moved to another travel company, where I was a director of engineering for a few years before joining Unity in May 2020, peak pandemic-time, as a director of engineering, and then got promoted to senior director. Fairly typical, I would say, but lots of different pockets of different experiences.
Zoe: How would you say the kind of work that you’ve done has changed along the way?
Sarah: I think effectively, that the really obvious one is that I no longer write code. I don’t spend my days in an IDE. Generally, I spend my days on Zoom now, and spreadsheets or documents. A lot of the skills I think you learn as an IC are still applicable when you end up on the management track. Most of what I do is still problem-solving, but the problems I’m trying to solve and the systems that I’m thinking about are more people-oriented, rather than necessarily problem-solving bugs or things like that.
I think as you grow up the track, or level-up through the tracks, again, you’re shifting from being really tactical, where people are giving you the parameters to operate within and you can learn how to be successful operating within those parameters, to then actually having to learn how to define those parameters for others. Then eventually, expand out to the even more ambiguous context of trying to create that clarity and flow for people. You’re shifting from being really engineering-focused, to being more business-focused. I think [this] is also the key difference.
Success is no longer me being a really great problem-solver for working out front-end coding-nuanced bugs. It’s now actually about, “Am I creating impactful value for the business, and am I doing that through driving change and outcomes through others, rather than just doing it myself?”
Zoe: I think that’s a really interesting way of describing it, because I’ve not heard it referred to in that way before, that you are moving from dealing with something in a tactical way, to dealing with it in a more strategic way. Also, I guess, moving to being more proactive rather than reactive. Rather than someone just rocking up and saying, “Here’s the challenge, here’s the problem, here’s something that needs to be built, off you go,” you almost have to be saying, “What is the challenge? What are we building?” Starting from that side.
Sarah: I think that’s what is actually really hard and difficult, because there’s no guidebook that you can read. You can’t just read and then suddenly be good at that. It’s a skill that you have to continually practise. I guess it’s top of mind for me, because that’s the thing I’m quite conscious of in my role at the moment, is as I have more products to look after, and my teams are more varied, how am I making sure that I’m not doing my comfort zone, which is just tactically executing and getting good outcomes, and [instead], actually creating the environment where we’re thinking longer-term, we’re being deliberate, we’re being strategic with what we’re choosing to do and what we’re choosing not to do, and having to do a lot more of that, creating clarity myself rather than just expecting someone to tell me to go operate in that little box over there.
Zoe: Yes, exactly. There was something else you mentioned that I thought was really interesting. You said that the skills you had as an engineer are still useful, you’re just using them in a different way. How do you think that being an engineering leader with a very technical background makes a difference, versus being an engineering leader who maybe doesn’t have that background?
Sarah: It’s a really great question. I think one of the key bits it does is establish that credibility. I think if you’re coming in as a new person, and you don’t have the technical background, I think sometimes it can be quite hard to build up that trust and credibility with teams, which ultimately is really important if you’re trying to get anything done. I think it helps shortcut that a little bit. There’s obviously different ways you can build that trust and credibility, but I think it just gives you a little easier starting point, perhaps.
Then in terms of the skills, I don’t know if everybody thinks about problem-solving in the ways that I do. Maybe they don’t. Effectively, it’s just systems thinking, but just applied to a different context. That’s how I see the world. Continually looking at like, “OK, what bits can go wrong? How do I move these pieces?” It’s like a giant jigsaw puzzle, but it just happens to be with either services or pods or teams, and you’re just trying to move all things around to create that flow in the system. That’s basically the same skills as when I was trying to work out how to ship a service to production, but now it’s just making teams ship services to production.
Zoe: Very interesting. Except for this key difference, [laughs] which I definitely learned as soon as I moved from engineering into management roles, is that people are a lot more complex than a piece of software.
I thought it would be really cool to chat about the key things you need to do to get the best out of your team. You already mentioned trust and credibility, but what are the key things you’re thinking about in terms of skills for leading a team?
Sarah: Really good question. There’s a whole bunch of things. I think it’s really important that your team feels empowered and accountable, but they’re working sustainably. I guess what I’m thinking about [when] creating high-performing engineering teams is trying to recognize that having different shapes of individuals, with different experiences and different ways of working, is positive, even though sometimes it can cause more headaches when you’re having to do more people management, or coaching, or mentoring, and things like that.
I think that is important in order to get the right outcomes for the customers, which is ultimately what we’re trying to do at the end of the day. I think by making sure that you’re practising empathy, showing up in the way that you’re expecting other people to be showing up inside the teams, is quite an important part of that transition.
I think one of the other things that I learned was that sometimes, I think, it is important as a leader that you can say, “I don’t know,” but actually sometimes if you’re the leader and you’re going, “Oh, I’m not sure,” all the time, it’s actually creating a load of uncertainty, and the environment isn’t great for people understanding what they should be doing, or why they should be doing it. A lot of what you actually have to do is make educated guesses. Admit maybe when you get it wrong, all that stuff, later, but you’ve got to say something.
People want clarity, and it’s better to go, “We’re doing X,” even if you’re not entirely sure, rather than, “I’m not sure, let me get back to you.” Obviously, sometimes it’s appropriate to do that. That’s one of the things I had to, I guess, teach myself, was making a decision and showing up and making a call, even if I wasn’t feeling completely certain myself.
Zoe: I think that is a key difference between being a good technologist. Having an open mind, and being willing to say, “I don’t know,” is such a key skillset. It’s so important. I think it’s almost that we all have to learn that doing the job of going, “Actually, I need to make sure I am open-minded and not closing off doors,” then to have to turn that around again and go, “Oh, OK, I’m not actually putting myself forward as infallible,” and saying, “I now magically know everything.” But like you say, I am responsible for setting the tone of the team.
As human beings, the computer doesn’t care whether you know everything or not. It really doesn’t make one difference one way or another. As human beings, we need, like you say, that certainty to know what we’re supposed to be doing, and how we’re contributing within a team.
Sarah: Yes, definitely. I think it’s particularly important after reorgs, for example, after you’ve found large structural changes, particularly if it’s large structural changes off the back of redundancies or things like that. Of course, you probably don’t actually know what you’re planning to do for the next six months, or how we’re planning to still ship X, Y, and Z, because you haven’t had time to really think about it.
Telling people that, when they’re already in a state of lots of uncertainty, there’s lots of fear, all that stuff doesn’t help provide clarity and a feeling of calmness, or even momentum towards the new goals and outcomes. I think it’s quite important to effectively project certainty and confidence in certain situations, even if you end up then having to pivot slightly or change it later. Because people are looking to you to be a leader, to be that calming influence, and reassurance that someone knows what they’re doing, even if you don’t necessarily feel like what you’re doing yourself.
Zoe: I guess one of the differences is about the scope becoming broader. Actually, the higher level you are talking at, the easier it is to be definitive, because you are saying, “We will do this,” but the details of how you’re going to work it out are the bit that’s undefined. Whereas then once you get down to the detail level, as soon as you start being too prescriptive, you’ve suddenly really limited yourself in terms of what you can do.
Sarah: Yes. I think that’s why I like seeing it as transitioning through the phases of being tactical to operational to being strategic. Also, learning how to be strategic in itself is actually quite challenging. You could just say, “Ah, I’ve come up with a glorious north star. [unintelligible 00:11:24] strategy done.” In reality, strategy is never done. It requires continual practice and focus.
I think, especially when you’re an IC and developer, you get really good at being tactical. Even if there’s suddenly unexpected fires, you can deal with an incident swiftly, make sure that things are running well in production, etcetera, etcetera, and think you can just apply that to people. Like you said, people are incredibly complex and don’t work like computers.
Zoe: Well, that brings me onto my next question. I think one of the most important things in dealing with people is the concept of responsibility and accountability. As a CTO, what are the responsibilities that you have to your team, and to the people who work for you?
Sarah: I think one of the key bits is making sure you have a really good understanding of the business. I think maybe that’s where some people really struggle, because it’s no longer going to be good enough to be really good in any technical field. Because if you’re responsible for people at a company level, then you really need to have a solid foundation and understanding of business and all these terms. Definitely understanding cash flow, making sure that you’re keeping your engineering costs down and helping drive profits for the business, as well as understanding the other business outcomes you want.
Then, for me, it is around building that empowering engineering culture. Getting that balance between being the person who’s setting the direction and writing the strategy, but also making sure that you’re identifying the correct people in your organisation, or I guess hiring them in the first place, that can help you define that strategy and then deliver and then execute on it.
I think it’s a very complex and varied role. It probably also, I think, changes depending on the stage and maturity of the company as well. The role that I do at Unity in a massive organisation is potentially quite similar to what a CTO in a smaller company might be doing. We have different titles, but [when it comes to] the responsibilities, there’s probably a fair bit of overlap.
Zoe: I think it’s very interesting to me how some of these responsibilities, I think, cut both ways. You’ve obviously got a responsibility to the business to make sure you get the right team into the right role, so that they’re delivering. Would you say you also have a responsibility to your engineers to help them find places that they can grow into, and roles that will challenge them, as well as just roles they’ll be good at doing?
Sarah: Yes, absolutely. I think that another key point is that part of the role of being a senior leader in engineering is actually advocating for what your engineering teams are saying, to your cross-functional partners, who may not understand or care about the intricacies of any of the stuff you’re doing in engineering. Effectively, it’s being able to tailor your message to your different audience and make sure you’re advocating the business, but also for your engineering teams, for sure.
Zoe: I’ve come to generalise a lot of what you do at a leadership or management leadership level, as people skills. Would you say, the skills that you use with your team, or with other people within the engineering team, are the same or different to when you’re talking to other stakeholders in the business or other functions within the business? Which obviously, once you get to engineering director level, it’s not just about talking to engineers.
Sarah: I guess you probably are using those same skills, because effectively, it is all around tailoring your message. I think one of the key things that was taught early on, even when I was on the IC track, was in order to be effective, you need to understand the motivations and needs of the person or the team that you’re trying to influence. It’s basically that skill, but with different individuals at different levels, or maybe it’s just that their needs and wants would be more vast and more varied.
I find myself having to switch hats quite a bit. A lot of what I’m trying to do right now is making sure that I understand why sales are telling my bosses that engineering are terrible. Often it’s no ill intent or anything like that. It’s just because I’ve fundamentally misunderstood something that is really important to them, or just unaware. It’s about going and making sure that you understand what their perspective is, and then advocating for your engineering teams.
Sometimes if you hop on a customer call and then your client partner is going, “See, this is what I mean. We’ve been telling you this for ages,” and actually, they haven’t. They tried translating it back to us and then completely missed what the actual customer was trying to say. I think a lot of communication and relationship-building and active listening are all super-important.
The ways that I would frame things with my directors are going to be different from the way that I frame things for my wider engineering team. Or I don’t have to be as careful with my framing, and get it as precise, when it’s a team of trusted people, because they already know me and my terrible jokes, they already know that it’s just part of my humour. Whereas if I’m doing an all-hands with the whole engineering team, I try to be a bit more sensible.
Zoe: Exactly. Also, it’s about how closely you work with people and how often you meet with them and work together and all of that. If you’re meeting someone only very occasionally, you haven’t had the time to build up that trust and that relationship.
Sarah: Which if we think about one of the questions you said around the people, it’s actually quite interesting because I started this job peak-pandemic, and so I had no opportunity to meet anyone. I’m quite used to being remote or working in globally distributed teams. At some point, you would meet the people in real life. I think it was two years before I met some of my peers in real life.
It was a bit odd because I didn’t feel very distant from them. It was quite surprising to me how easy or straightforward it felt building quite strong relationships with people that I’d never physically met in real life at any point. When I was talking to people about that, some people found it incredibly difficult to feel like they belong, when they were only a little box on a screen.
What was quite interesting to me as well, is how do you balance wanting to be globally distributed, but create a cohesive team, as well as how do you make sure you have time to understand and build these relationships with all these different people, with all their different needs and wants, and parcel all that information at the right time? I think it was quite interesting.
Zoe: Very complex again and very back to how people are not interchangeable. You learn Python [once], but you learn how to deal with one member of your team and suddenly, you have to learn it all over again once you have a new member of your team, because they have different requirements and different ways of seeing the world, and all those things.
Sarah: I think also, there’s no real “just learning how one person is.” If something happens in a person’s life, for example, I’ve got members of my team who went on maternity leave, and when they came back, they were slightly different than when they went on maternity leave, which is completely understandable and acceptable. Effectively, again, it was like tailoring how I managed them to make sure that I was recognizing their new needs and desires of how they see the world, and what they want to do, and how to help them grow.
It all subtly changed since they’d had that time off. I think people are incredibly complex and continually changing, whether they realise that or not, including myself probably. I’m sure I’m a pain to manage though.
Zoe: Well, now we’ve set out all the challenges of the role. What would you say to someone who is maybe at the individual contributor level and they’re saying, “This is where I want to get to. I want to be a CTO, I want to be an engineering director,” what would you say to them are the key skills to start to build and how to go about that?
Sarah: I’d probably ask them to try and understand their motivations, in terms of wanting to level-up and become a manager of managers. Sometimes I find that when you’re having those career conversations with high-level ICs, and they’re wanting to level-up, they automatically pick management because they think that’s the only way to continue to have progression. Whereas I’m fortunate I work in a company where the IC track is pegged alongside the management track, and you’re still becoming a leader but you get to focus more on the technical leadership, and you don’t need to deal with the people-management path, the M track role.
I think that would probably be the first thing I’d want to do: really understand what is their goal and what is their motivation for moving on. If I think more onto, I guess, the core of your question, I think the thing that I wish I’d learned, or been told sooner, was actually that understanding of the business is actually important. Or maybe people did tell me and I just didn’t absorb it, I didn’t realise it.
I do think the non-technical skills are really important, but when we say non-technical skills, I think people just say, “Oh, learning how to be a better manager or have one-to-ones with people.” Actually, it is that, but it’s also about understanding the business. I don’t think you can get to senior levels of management if you don’t pay attention to the non-engineering parts of the role.
Zoe: If we roll back and we imagine Sarah, the intern at Yahoo, looking forward in her career, how does your role now compare to how you thought it would when you were starting out?
Sarah: That’s a really good question. I think with me though, I have never really been deliberate in terms of what my career was going to look like. Basically, my usual strategy is to replace myself and then work out what I’ll do next. That’s pretty much how I’ve ended up going from different industries or switching teams. It’s generally that I just try and level-up the people around me, so that I can be replaced. Then I work out what I want to do next.
I don’t know. Well, I guess the intern me would probably be incredibly surprised that I am doing a podcast and I actually said, “Yes, that sounds fun.” I don’t think intern me would’ve ever believed I would’ve said that.
Zoe: Oh, well, on that note, thank you so much, Sarah, for coming in and for helping us to shine a light for others.
Sarah: No worries. Thank you so much for inviting me. It was a fun discussion.
[music]
ENDS
