Becoming a Staff Plus Engineer with Joy Ebertz

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Joy Ebertz. Joy is a principal engineer at Split and a recent QCon speaker. Joy, welcome. Thanks for taking the time to talk to us today.

Joy Ebertz: Thank you for having me.

Shane Hastie: My normal starting point in these conversations is, who is Joy?

Introductions [00:45]

As you mentioned, I'm a software engineer. I started my career at Microsoft on a team doing a bunch of R&D work, which was extremely interesting. I moved from there to a super tiny startup. I left when there were four people, so if that gives you any idea. From there, I went to Box and I was at Box for a number of years. When I joined, it was still fairly small. By the end, I don't even remember the numbers anymore, but yes, we were a public company and significantly larger by the time I left. While at Box, I started as a full stack engineer. I took a trip through management, ended up as a backend engineer at the senior staff level.

From Box, then I went to Split, which is where I am now, again, doing backend engineering things mostly. At this point I am a principal engineer, and throughout the backend engineering time, I've done a lot of interesting things around enterprisey features, so a lot of compliance governance features. I've dug a lot into authorization and authentication, as well as some more microservices stuff. So splitting monoliths into microservices, domain driven design and thinking about architecture. And when I'm not engineering, I think the thing that most people know about me is that I run a lot. I'm an ultra runner, so if I'm not engineering, I'm probably running.

Shane Hastie: What's it take to be a principal engineer to get to that height in terms of your technical career and technical job? What do people need to work on to aspire to get there?

What’s needed of a staff engineer? [02:17]

Joy Ebertz: There's a ton of things. That's super broad. But I would say to dig in a little more specifically. As you advance from just a software engineer through Senior Suite, a lot of it is just about getting better and better at writing code, at building the features you're given, really being able to do stuff independently, being able to design within your space very independently. Beyond that, I feel like the job starts to shift a little bit and it just keeps shifting more and more, where, as staff, you're starting to think cross team, and I know a lot of people, both my current company, past company, other companies I've talked to, they really struggle with this idea that the rubric is pretty clear getting up to Senior Suite, but once you get to staff, it's like, what do I actually need to do? I don't understand what I need to do.

But the tricky part of that, is that's actually a little bit of the point is starting at staff, you're expected to deal with a lot more ambiguity and you're expected to be able to take a problem with very little idea of what's happening and be able to run with it, be able to figure out what's happening, figure out what's needed, figure out where to go from there, and you could almost see your career as being one of those problems. It's a little unclear what you need to do, but you just tackle that and you understand what does your business need, what does your larger team need? What kinds of skills are they missing? What sorts of problems do they have that people don't seem to understand? And then identify those and then start to dig in and really move those forward. I know that's easier said than done oftentimes.

And then on top of that, I've also seen the mistake of people trying to get into some of this space before their team needs it or understands or they've built up the street cred, maybe is the way to say that. And the other side of this then is being able to actually influence people and convince people that this is the right way to go. And in general, I would say the soft skills and the people skills almost become more and more important as you get higher and higher on this track. In a weird way, it starts to get a little bit more blurry with management. You're not actually managing people, but there's a lot more of managing the projects, managing politics, managing relationships, so on and so forth.

Shane Hastie: You said that you took a leap out into people management for a little while and then came back. What were the insights that you took from that diversion?

Insights from a diversion into people management [04:46]

Joy Ebertz: I went into people management in the first place because my manager at the time thought it would be a really good fit for me. He saw me doing a lot of project management and some of that side, and so he really encouraged me to try it out and I wasn't sure, and my mentor at the same time also was like, "Yeah, you should really do this." I then got into people management and realized that I absolutely hated it. I spent about a year and a half to two years doing people management, depending on how you want to count it exactly. And a lot of it was just the more fuzziness around being able to feel accomplishment. So when you're engineering, it's much clearer, like, "I did this thing. It's out there in the world." And even if it failed, it's clear, "This thing failed, it blew up. I had a production issue," versus management, "Well, even if my team succeeded, did I really help them? I'm unsure. Maybe they would've succeeded without me." So that's what I struggle with management.

But you asked about what I took from management. I feel like a lot of what I gained there was more of this understanding, like I was mentioning around the politics and how things actually worked and how people understand things. To go into some more detailed examples, promotions is one thing. The company I was at, I was at Box at the time, and we each had promotion cases. So the engineer would put together this large document saying that, "I should be promoted and this is how I meet the rubric and this is why." And then the manager would put together a thing and then a promotion committee would review it, and then you go, a decision is made, the manager can appeal and so on, and then you get your final decision.

And I'd obviously seen the promotion packet side of it and later I saw the promotion committee side of it. But the management part is interesting too because you start to see the questions that the promotion committee is asking about, like, "I see this as the gap." For one person it was something about like, "Yeah, but what exactly did this person do for the project?" The project succeeded. It was great. You're saying that they helped a lot, but what are the specific examples? And being able to understand that then helped me to be able to say, "Okay, if I'm going out for the next promotion, I need specific examples. I need to be recording this stuff so that I can give it to my manager so that they can help support me." And in fact, one of the promotions I went through, I wrote up my case and then I gave my manager a supporting thing that was like, "In case you get questions about any of these things, this is the answers to all of them." And so I was able to navigate that much more cleanly.

I guess that's a very self-serving career side, but in a more general organization side, there's also stuff like you get to understand not just what are the teams, but who are the influential people on those teams and how do things get done? If I have a problem that involves infrastructure, who is the person that I should know on the infrastructure team, that sort of thing. And you get much more exposure across organization. I guess this also dips into a little bit of my identity. The Women in Tech group at Box was also a great way for me to get to know some people across the organization, 'cause especially by the time I was post management, we were starting to get fairly large, and so it gave me an in on a bunch of different teams, which was useful as well if I needed to find out information and put that together.

I think there was also a piece of being able to better help my manager help me. I remember I would get a question from a lot of my direct reports that was like, "Do you have any feedback for me?" And my initial response is like, "I don't know. You seem to be doing fine. No." But I realized then that if they asked more direct questions, I did have answers. So if they said, "How did I do at that presentation that I gave last Thursday?" I'd be able to give them a lot of feedback. "This is what went well, this is less well," and so on and so forth. And so it taught me that I shouldn't expect much if I ask my manager, "Do you have any feedback?" Instead, I should identify what are the things I want feedback on and ask much more directed questions.

The other thing related to that is I think every single person I managed would say, "I want opportunities," or, "I want a project that's going to help me get to the next level." But then when I get the projects, how do I match them with anyone? Any of them could go to anyone. But if the person was much more specific, again, and said something like, "I really want to work on my presentation skills," then if something that's going to involve that comes up, I know who to match it with or even, "I really want to dig into databases more." Then again, if there's a project involving databases, I know exactly who to give that to and they're much more likely to actually get something too. So being specific in what you want and being specific in asking for feedback, generally being specific, is going to really help your manager to help you.

Shane Hastie: What was the experience stepping out of management back into the technical stream? Was it the same company or did you shift organizations at that point?

Stepping back from management to the technical stream [09:37]

Joy Ebertz: It was within the same company. It was a different department, within the same company. So previously I had been in what we called the enterprise team. I'd been there for a long time. They were responsible for all of the features that large companies cared about. So like I mentioned before, the governance, the compliance, those sorts of features. When I came back, I moved on to a fairly new project that was spinning up, that was around more workflow and specifically it was a partnership with IBM that we were working on a joint thing. So it was new space, new manager. I was still somewhat working with everyone that I had before, but it was a chance to reset a little bit at the same time, which was useful.

Shane Hastie: Often that shift back is somehow perceived as being a step back. Was it? Or was it just a sideways shift?

Joy Ebertz: It was actually a little bit of a weird case for me in that most of the time at our company, people would go from staff engineer to manager, and then when they went back, they got shifted back to staff engineer. If they went back. Not very many people did, but a couple did. I, however was a Senior Suite and then got promoted to manager. And so when I went back, they were like, "Well, everybody else is going to staff engineer, but you weren't actually a staff engineer before." So what they did was they left me with the manager title for about six months, and then they had me do a promotion packet, but they called it slotting instead. And at that point they decided whether to give me the staff title or the senior suite title, and I managed to get the staff title at that point.

So I would say because of that, it didn't really feel like a demotion to me. It felt like more of a sidestep because it was still above where I had been before. If I had been a staff engineer before that, especially if it had been a while, I might've viewed it differently to be honest, but because of where I was, I would say it really did feel like a side step.

Shane Hastie: It sounds like the organization had a pretty clear set of metrics and guidelines for workers?

Joy Ebertz: Yes.

Shane Hastie: You mentioned the rubric more than once, having those sorts of things in places is going to enable it.

Joy Ebertz: Yes.

Shane Hastie: That touches on a topic I know that you're blogging about at the moment, and we'll make sure we include a link to your blog in the show notes. Incentives and aligning incentives. How's that showing?

Aligning incentives [11:50]

Joy Ebertz: I've actually thought about this since fairly early in my career, but especially recently, I've been thinking a lot about aligning incentives. Basically every staff plus forum that I'm in, I feel like people are always talking about like, "Oh, it's so hard. I have to influence without authority, blah, blah, blah, blah, blah. I can't get anything done." Honestly, two random thoughts on that first. I don't really feel like I had that much more authority as a manager. Maybe that's a little bit less true now, but back when I was managing, the job market was hot. If people didn't like what I was asking them to do, they could leave. What am I going to do? I didn't actually have that much authority over them. And so you're still trying to convince people to do things on some level. So I think that that's a little bit of an illusion and everybody is influencing without authority to some extent.

The other thing I would say is it's also possible to influence with too much authority in some ways. I'm mindful of this sometimes now in that sometimes I want to get something done and I just want to push it through and, "Yes, whatever." But there are a lot of times when I am, "I think this is the right direction, but if somebody really disagrees with me, I would love for them to challenge me so that they can test where I haven't thought something through all the way or whatever." I don't want to shut down all of the other thinking because that's less useful. We're better together. So thinking through how do I make sure that I still leave a little bit of room for opposition, even if I'm trying to influence people and get things done. So influencing without authority, people talk about that a lot.

And I would say the biggest thing I've always noticed, or I've always thought about is a lot of that just comes down to aligning incentives. What are people incentivized to do? What are their driving motivators? I have a lot of examples. The first one, this goes way back. My first job, I was at Microsoft and we were supposed to be testing ideas, and we were supposed to be testing risky ideas. The idea is if we're testing ideas that are risky enough, about half of them should fail. Only half of them should be good ideas. But we found that we had to really, really, really push to even get 30% failure because as humans, we like to see things succeed and you start to dig into an idea and you really believe in it, and you're likely to just keep iterating and keep pushing on it until it's a success somewhere.

So to balance that, even to get to 30%, we had to, as a full team, celebrate every time a project failed and really make a big deal about, "Isn't this awesome? This is so great, it failed," and just counteract the natural human desire to succeed. So there's things like that that are just innate drivers for people. There's other things, like for example, this is a funny one involving feature flags, which I guess is what my current company does, but this was at a previous company, but we had the problem everybody has with feature flags where you end up with more and more and more in the code base, and that's just more tech debt, more branching code paths you have to deal with, et cetera. One of the teams was like, "We're going to fix this and we're just going to put a cap on the number we can have. We can't add any more than 150, say." And if you try to add 151, you have to remove one first.

And this obviously had some of the intended results in that we did cap it at 150, but it also had some unintended results as well. For example, if I was then making a very risky but small change, I was suddenly much less incentivized to wrap it in a feature flag and suddenly I'm really questioning, "Is it worth the two weeks it's going to take to pull out another one in order for me to add a little bit of safety on top of this?" And because people are incentivized to move fast, they're suddenly thinking, "We're making this speed safety trade-off and different things happened."

The other thing that happened is while people were sometimes incentivized to remove them, I also definitely knew people who were saying like, "Oh yeah, my team knows that we have to add one for this new feature coming up, and we have this really easy to remove one that we know about, so we're just going to leave it in the code base until we have to add that new one." And so even though, before this they might've just removed it because everybody knows that cleanup is good, they were suddenly like, "Oh, we're going to hoard these things and we're going to keep them." So the incentives were changed towards this hoarding pattern, which is an unintended consequence.

So things like this just really get me thinking about, "Where are people's incentives? What do they want to get done? What are they going to do as a result?" In a situation if somebody is really pushing back on you, you're asking them to do something, they're really pushing back, "Why?" What are their incentives? What do they want to get done? What do they want to happen? Why are they not doing this? Especially if they say like, "Oh, yeah, that's a great idea, but I'm not going to do it." Then it's a good point to dig in and say, "Well, why aren't you? What's stopping you? What can I do to change the situation so that suddenly you are much more interested in helping us move that direction."

Shane Hastie: Advice to the mid-level software engineer who's looking to grow their career and move towards the principal engineer role. Where do they go? What do they do?

Advice for aspirant staff plus engineers [17:01]

Joy Ebertz: Few different things. One, I already touched on a little bit is embrace ambiguity. Be a little okay with that and be willing to just dive into a problem, even if you have no idea what's going on or where you're going with it, break things down and take it step by step. So that's one thing. Another thing I've realized quite a bit is communication matters a lot. Being able to write, being able to speak, being able to just communicate is huge in terms of being able to advance your career. I know I blog a lot. I actually enjoy blogging. It's part of why I do it, but part of it is it helps me organize my thoughts. But even apart from all of that, I think it's a very valuable thing to practice writing. If you're not comfortable blogging, practice writing in other ways and make sure that you polish that skill because if you've done really, really great work, but you can't tell anybody about it or you don't tell anybody about it, it didn't happen.

So sadly, we like to think that the best people are always rewarded within our industry, but that's way less true than you would hope. A lot of it's actually, "What do we know about that happened and what got visibility? What do other departments know that happened?" I was talking about some of that promotion stuff before, but it's immensely helpful if all the people on the promotion committee already know about that project that you did and already think it's a big deal. They're going to be like, "Oh yeah, she did that giant authorization move. Of course, that's awesome. Of course you should get promoted." Versus if it's some project nobody's ever heard of, suddenly it's much more of a struggle to be like, "This is why this is hard. This is why this matters. This is why this should get promoted."

But also back to the incentivizing people side of things too. A lot of that is communicating and convincing people and being able to talk to people about, "These are my ideas, this is why it's important," and also listening like, "Why do you disagree? What should we change?" And being able to combine all of that. So communication, being able to, I would say, practice that as much as you're comfortable and maybe even more than you're comfortable, to be quite honest.

Shane Hastie: Joy, some really, really useful advice here. Thank you very much for taking the time. We'll make sure that people have your blog and of course they can find your QCon presentations as well. Thanks so much.

Joy Ebertz: Thank you so much for having me. It's been fun.

Mentioned

• Joy’s Blog
• Joy’s Qcon profile