For our new series, 1:1 with Engineering Leaders, Code Climate and Codecademy for Business spoke to managers and VPs about their career journey, leadership strategies, and advice for the next generation of engineers. Below is an excerpt from our conversation with Tara Ellis, Manager, UI Engineering at Netflix, who discussed her strategies for building trust on an engineering team. Edited for length and clarity.
For Tara’s advice for early-career engineers, visit the Codecademy blog.
Tell us about your current role, and how you got there.
I currently lead a team of engineers in the growth space, and I work specifically on payments. As I like to tell people, we are the money of Netflix.
I manage a UI team. How did I get here? I actually I had never worked in growth before, even though I had been managing UI teams before. But the Director in my current role is someone I had worked with before in my prior job, and he had spent a lot of time trying to get me to come to Netflix. Eventually I decided that it sounded like an awesome challenge, and I wanted to try it out. I took the plunge.
But it took many, many years of doing lots of different things to get here. I’ve been in this role for four years, but I am moving from the product side over to the studio organization at Netflix. I’m working on a new initiative, and I basically have the opportunity to build out a whole new team that’s going to be a part of a whole new organization. I’m super excited about it, because how often do you get the opportunity to have a start up experience while still in the safety of a company?
Can you tell me a little bit about your transition from IC to manager? Did you always know you wanted to be a manager?
Absolutely not. I actually was someone who was pretty hostile to management for large portions of my career. I think if there are a lot of not-great managers in the room, I think sometimes it gives it a bad rep. I actually think management and leadership are really awesome things to do.
So no, I did not want to be a manager. I wanted to basically go as far as I possibly could technically, because I was a grade-A nerd, and I really loved the intricacies of the craft. But eventually after a number of years, I came to this realization that I had solved all of the problems that I was interested in solving, I mean certainly not all of CS’s problems, but all of the ones I wanted to solve. My day to day became taking things out of the database and putting things into the database, and it didn’t matter what platform, what language.
At that point, people started to become really interesting to me. I got a little taste of that when I was a tech lead. If you can do technical leadership first before moving into a people manager role, it’s a great path, because it’ll allow you to get a sliver of that job and decide if you like it, and then keep getting into the harder part of the job, which is the people. I really enjoy growing, and leading people. I would not have thought that 10 years ago, but now I think it’s amazing.
It sounds like a little bit of your fear — in addition to not having great experiences with certain managers — was leaving the technical side of things.
Yeah. A lot of engineers don’t really understand what managers do, and I was absolutely one of them. So it feels like, “Oh, you don’t produce a thing, right? You sit in a meeting, and then you tell me what to do.” Because I had this very narrow conception of what that role was, it felt certainly less noble than being the one making the thing. I’ve since learned that both jobs are awesome, and even though I’m not hands-on making the thing, I make it possible for the makers to make the thing. That became far more compelling. I do still code though because I’m a nerd. I just don’t code professionally.
So you code on the side, as a passion project?
Yeah, I just love learning new things. I’ve been going back and forth on my multi year quest to decide if I want to learn Android development. I have a good friend who builds mobile games, and keeps trying to get me to do a few screens for him as a learning exercise. So now it’s more about finding the time. But I’ve traditionally been a front-end engineer, so I think mobile is an interesting space from the perspective of, “Oh you can control everything,” as opposed to the web where it’s not that simple.
It’s great that you’re able to pursue your passion on the side. To broaden out a little bit, now that you’ve been a manager, what do you see as the role of a manager on an engineering team?
I will say I definitely think there’s some overlapping duties, but it does depend on the company. So in my prior role as a manager before coming to Netflix, I did a lot more technical leadership. The engineering team itself was a variety of backgrounds, from interns all the way to the super senior people. Because I had junior engineers, I spent a little more time in the weeds than I do at Netflix. In that role, and that job, my role was to deal with resourcing, deal with planning, deal with technical leadership, that kind of stuff.
I was so in the weeds that when I actually came to Netflix, my first four months I was like, “What is my job?” I would argue that this is much more of a leadership role than a manager role, because it’s a little less tactical.
With my team, my job is to lead them, inspire them, motivate them, help them grow their careers, push them in the ways that will make them more well-rounded developers. If I’m doing my job right, then they will eventually leave, because they’ve grown.
So how did you discover who you were as a leader?
I’m still trying to figure that out. It’s been an ongoing multi-year, perhaps multi-decade process, because my career has morphed. A lot of it has come down to having different experiences and really trying to evaluate what they mean, and how I’m motivated. A through line for me is that I really care a lot about performance. Towards the end of my coding career, a lot of my specialty was squeezing milliseconds out of things, and I think that hasn’t changed. I’m just now doing it with people — how do we become the most efficient, well-performing team.
I had to really introspect and figure out over a lifetime of work of who am I and what do I value, what do I bring to the table, and how do I serve the people that I work for? I said it’s shifted, because my roles were very different. It’s funny, when I became a manager, the joke is that I became so nice. Not that I wasn’t nice before, but the job now is about motivation.
So when you figured that out, you said you value performance, for example, how does that impact your day to day work as a leader and a manager? How do you help people boost their performance?
I have the fortune of working in a place where most of the engineers already come with that mindset. But as a general rule, it has been my experience that people respond really well to expectations. They just want to know what is required of them. They want to know how they’re doing. One of the first things I do is to lay out, “This is what it means to be succeeding. This is what I’m looking for.”
I say “These are my expectations, and my assumption is you’re going to be able to live up to this. If you can’t, let’s talk about it.” It’s not, “Hey I have this expectation. You haven’t hit the bar. Goodbye.”
One thing we talk a lot about at Code Climate is how it can be hard for managers to have visibility into the work that’s getting done. That visibility is important not just in getting the product to market, but it’s also important in the kinds of conversations that you’re having. How do you get enough insight into what’s happening on the team and on an individual level to have that conversation?
I’m a big talker, as you may have noticed. I’m also a big fan of multivalent points of view. I talk to an engineer individually, and I talk to the people around them. I’m lucky that I work in a culture where it’s normal for people to talk about how other engineers are doing, and to give managers public feedback. So for example, an engineer emailed another engineer and his boss and me to say how great he had done on this project, and exactly what he had done that was really great. I just got that unsolicited, so that helps.
If it feels like something is going on, you have to be really careful about that, because nobody wants to feel like they’re snitching on someone. It’s really about setting the context of, “Look, he’s not in trouble. I just want to make sure that everything’s okay” and then also asking really transparent, candid questions.
You’ve got to really want to know the answer, and sometimes you have to ask multiple times, multiple different ways in the same conversation to get someone to tell you the truth. It doesn’t always feel safe to tell you the truth. They don’t know what you’re going to do with it. So you have to do the work to build up rapport before you get into deep conversations. High level I think it’s a curiosity. It’s a genuine non-transactional curiosity. When people know that you care about them, they’ll be more responsive. I’m not trying to find this out because I’m trying to fire you. I’m trying to find this out because I want to help you.
How do you build that trust and safety on your team?
I really try to build a strong sense of loyalty between the devs themselves, irrespective of me. I’d rather you be loyal to each other than me, because then you will work really hard for each other. You won’t want to let each other down.
Then with myself, I feel the best when I feel like someone is telling me the truth. When they’re not telling me what I want to hear, and when they’re comfortable being vulnerable. So I try to mirror that back with my devs. I’m a firm believer in the 1 on 1. It’s their time, it’s not my time. As I like to say when I’m setting those up for the first time, “I don’t want to talk about your project. I have 14,000 other ways to learn about your project, but I only have this one 30 minute block to talk to you.” I want to spend that time building trust, getting to know each other.
Maybe for the first one on one, people are a little taken aback by how direct I’ve been. They’re like, “Okay cool.” Then the next meeting they’ll come in and they’ll start giving me a rundown of their projects. I stop them and say, “Nope, we’re not doing that. What’d you do this weekend?”
It takes a while. But eventually, we start having real conversations.
How does your strategy for building safety and transparency differ when you’re coming into an existing team with an existing dynamic, and creating a new team?
I might go about it a little more sideways with a team that exists versus one from scratch. If I’m building a team from scratch, then I’m setting the tone, and I’m setting the culture from the beginning, and so from the first person I talk to about a role, the narrative is what I’m putting out there. When I’m coming into a team, I’m the one who’s new. So I have to figure out what the narrative is, and then over time, you can change that culture.
When I join a company, I’m a firm believer in not saying anything for a month, soaking it all in, learning all the things, learning all the people, asking tons of questions, trying to build your context as quickly as you can. I’ll meet with every member of my team within the first week or so, and ask them all the same question: “What is the single biggest thing I can do to help you right now?”
I want to understand what challenges they’re facing, and how I can be of most use to them while I’m ramping up. I think the focus is opposite when you’re building a team. You’re bringing people in, and you’re setting all of that for them.
One of things you can do to build trust with your team is to take their growth seriously, and show them that. Once they feel like, “Oh you do actually care about growing me as a person,” people are more open and trusting.
Is there any wisdom you impart to people to get them excited about their own professional development?
A lot of times I see people get into a day-to-day, they get into a rut, and they stop thinking about where they want to go. I try to really always engage in those conversations. I ask, “What do you want to do, really?” Throw out all of the reasons why you can’t do that thing, and let’s talk about what excites you.
Anything else you want to add?
I had given this talk on authentic leadership, and how important I think authenticity is. The thing that I didn’t go into in the talk because of the time constraint is that not every organization has the room to allow you to really practice that. Life is too short. There are a lot of places that will support you as a human being. Invest in trying to be in those places, as opposed to places that are trying to make you fit into a cookie cutter box. You want to find a place that celebrates diversity of thought, and encourages different ways of thinking and being. I think it’s as important as your salary.
For more of Tara’s advice for the next generation, visit the Codecademy blog.
Trending from Code Climate
1.
How to Navigate New Technology Expectations in Software Engineering Leadership
Rapid advancements in AI, No-Code/Low-Code, and SEI platforms are outpaced only by the evolving expectations they face. Learn how engineering leaders can take actionable steps to address new technology challenges.
2.
Mapping Engineering Goals to Business Outcomes
Understanding how engineering activities impact business objectives enables engineering leaders to make informed strategic decisions, keep teams aligned, advocate for resources, or communicate successes.
3.
Unlocking Efficiency: Optimizing Pull Request Reviews for Enterprise Engineering Teams
As engineering teams grow, so can the complexity of the code review process. From understanding industry benchmarks to improving alignment across teams, this article outlines strategies that large engineering organizations can use to optimize Review Cycles.
Get articles like this in your inbox.
Get more articles just like these delivered straight to your inbox
Stay up to date on the latest insights for data-driven engineering leaders.