Joy Ebertz - Senior Staff Software Engineer at Split

Story recorded in March, 2020. Learn more about Joy on her blog, Twitter, and Linkedin.

Tell us a little about your current role: your title, the company you work at, and generally what sort of work does your team do?

I’m a Senior Staff Software Engineer at Split.io, working on the backend of what we call the COE team. Split is a feature flagging and experimentation framework. We focus on enabling our customers to separate deployment and release in CI/CD and also enabling A/B testing. My team is responsible for most of the main business logic of our web application, including everything from data storage to the APIs. There is a separate team that focuses on the experimentation side, including all of the detailed statistics that goes into that, so we’re able to focus more on the main platform.

What does a Staff-plus engineer do at Split? How do you spend your time?

I’m still somewhat new, so I’m still working to define my role, which is part of the beauty of more senior roles. Today, I’m still ramping up, so I’m probably spending around half to three quarters of my time on tasks for my specific scrum team, just like any other engineer here. With the rest of my time, I’m participating in conversations and working with other engineers to define a lot of our longer term architecture and strategy, including our future API and platform strategy, how we want to develop our authorization framework, breaking up and decoupling our builds and more. I’ve recently also taken over leadership of our backend chapter and now co-lead it with another engineer and we’re working to put together a backend technical vision, prioritize tech projects and lead standards discussions. If that wasn’t enough, I also continue to write regularly on my blog and speak at conferences.

Where do you feel most impactful as a Staff-plus engineer? What’s something you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done in earlier roles?

I feel most impactful when I can facilitate setting a technical vision for an area and get people moving toward that vision. I think we would all agree that we want our code to be better architected than it is or improved in some way. However, I’ve found that often people have some vague sense of wanting better without having a clear idea of what that thing they want is. I like to help the group decide on a shared understanding of where exactly they’re trying to get (it’s actually okay if we never get there) and come up with a general game plan of how to get there. This way we’re all marching in the same direction. Having a clear idea of what we want allows us to work with Product to get it prioritized. Even if we never get the whole thing prioritized, knowing how to get there, allows us to slowly make changes that will lead us in that direction. For example, if I’m touching a file anyway and can make a few tweaks that brings me closer to that vision, I will. Without knowing that vision, those tweaks would never happen. The vision alone isn’t enough, we need everyone to understand that vision and internalize it. Part of the power of those small changes I just mentioned is if everyone is making them as a part of their normal coding. Suddenly we have everyone working toward a common goal.

I think the biggest thing that differs between now and when I was more junior is my sense of ownership and responsibility. I’ve always been willing to push back or to drive for improvement. However, when I was more junior, I would often just assume that something was someone else’s problem. Now, it’s all my problem. I may choose to not prioritize something because I think that it’s less important than something else, or I may choose to delegate or pass a problem off to someone else, but I still see it as my problem. I no longer ever assume that someone else will handle something. I’m still a big believer in picking my battles, I won’t work on everything - that’s too much. I also, however, won’t assume that anyone else will either, so if it’s worth getting done, it’s up to me to either do it or to pass it on to someone else.

Do you spend time advocating for technology, practice, process or architectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

Yes. All of those. In my current role, I would say this is a huge part of my job. While, as an engineer, I am also contributing on a scrum team, I would say a lot of my job is to keep an eye out for pitfalls I’ve seen before or larger patterns of problems. I see my job as making all of engineering more efficient - be that through technology, through architecture or through process. However, I should never be making changes for the sake of changes. I’ve advocated for a number of things over the years, from rewriting our email notification system to rethinking testing to reworking several authorization frameworks.

For some things, like the email overhaul, I didn’t do anything big or grand, I just reminded Product every time they wanted to add a notification that our system was ready to fall over and that we really couldn’t add any more until we fixed it. As I pushed back, engineers around me also realized that they could push back. At first Product mostly opted to not add more notifications, but eventually they decided to fix the system. In this case, it was mostly a matter of explaining to them the risks of the system and sticking to what I thought was the right course of action in terms of keeping our systems running.

For other things, such as the authorization frameworks, I was tasked with finding a solution. In these cases, even when people want a new/better solution, you still need to convince them that you’ve picked the right thing. With incredibly complex systems, people will often think they’ve found things you’ve forgotten about (and maybe they did), so it’s really important to seek feedback early and often and to carefully record and communicate both what you chose and why but also what else you considered and why you didn’t chose something else. People need to feel heard and they need to know that you fully considered their concerns. They also want to understand what your thought process was, but even more important, they want to understand that you did thorough research and didn’t just pick the first thing to come along. In fact, when I’m vetting someone else’s design, this is one of the things I really look for - what else was considered?

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

Yes. As soon as you get to any sort of more senior role, this is always a part of your role assuming you chose to take advantage of it. Since I’m still new at Split, I haven’t had much of a chance to here, but I’m positive that will change. Sometimes sponsoring is the big stuff - recommending people to lead projects or manage a team, but a lot of sponsoring is smaller things - encouraging someone who is a little unsure of themselves, showing off their accomplishments to more senior people they wouldn’t normally have access to, finding ways to delegate your work to people who could get a growth opportunity from doing it. I think it’s possible to be a senior staff engineer without sponsoring, but I’m not sure it’s possible to be a great senior staff engineer without sponsoring. Sponsoring is one of the most powerful ways we can grow those around us and I would say that growing others is one of the most important aspects of our role.

You first got the title Staff engineer at Box. What was the process of getting promoted to Staff?

At Box, we submit a promotion case that outlines how, based on the engineering rubric, we’ve already been operating at the next level. Our managers also submit their recommendation and the two go to a promotion committee made up of managers and ICs (at least one level above the level we’re applying to). They review the case, call in the manager to answer any questions and then make a recommendation. Our VP was able to change any of the decisions (although to my knowledge this never happened). If the answer was no, feedback was given as to why and you could repeal the decision with additional information or try again the following time. Appeals did sometimes go through, so if you disagreed with the feedback, it was worth trying. I liked this process because it allowed the person with the most context on our accomplishments be the one to write them up and it allowed you to go up for a promotion even if your manager didn’t agree. On the other hand, I didn’t like the process because it subtly discriminates against those with a little less self confidence and those who struggle with self-promotion. It also resulted in managers taking a little less initiative in starting off the promotion process (letting engineers come to them saying they wanted the promotion rather than suggesting it).

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

I would say that my location probably hasn’t mattered too much. Education helped me a lot in terms of getting interviews when I was more junior, but a lot less so (at least directly) since then. I would say that the three biggest factors for me were company, visibility and opportunities.

I think it’s possible to advance at a lot of companies. However, I found that being at a fast-growing startup really helped me out. When I joined Box, engineering was around 30 people and when I left, 8 years later, it was at a few hundred, but much of that growth was in the first half. This allowed me to come into a smaller engineering environment where it was possible to really get to know the environment, people and code. Then, because we were growing, there were lots of leadership opportunities and technical challenges for those motivated and willing to take them. Because we grew, the opportunities grew with me. At the same time, there were also enough people around me for me to learn from (I was previously at a really tiny startup - 2-4 people, where that really wasn’t available).

By visibility, I just mean finding some way to be known. I’ve always worked onsite, which I find makes this a little easier, but I think this is possible even if you are remote (although possibly a bit more challenging). If you do really great work, but no one knows about it, when it comes time for promotion, you’ll be passed over. Furthermore, as you become more senior, part of your job becomes mentoring and teaching others and helping your company to create a tech brand - all of these are by definition, visible. Visibility can take a number of forms, but for me I would say that a few things contributed. I was very active in our Slack discussion forums, answering questions for people wherever I could. I also did a lot of blogging and some speaking both internally and externally. Finally, I was active in our women in tech group, which allowed me to form connections with various people throughout engineering.

Finally, opportunities. These can look vastly different as well. For me there was one in particular that was really helpful - I joined our API standards committee. I was actually a bit hesitant to do so at first because I didn’t think I was an expert at APIs, but after reading a few (short) books on REST, along with my work on various APIs previously, I had a pretty solid grasp. The powerful thing about this group is that it cross-cut many teams in engineering, which gave me a chance to work with a lot of different engineers (and gave me that visibility I just mentioned). It also allowed me to have something clear to point to in terms of influencing others and being someone who fights for quality. Our projects there had broad impact across engineering and allowed me to think about something (our API, in this case) holistically.

There is a popular idea that becoming a Staff engineer requires completing a “Staff Project.” Did you have a Staff Project, and if so what was it?

I actually didn’t really have a Staff Project. At the time that I was promoted, I had transitioned back from management around 6 months prior, so I referenced some of my time managing for leadership. At the time, I was leading (from the technical side) the very small Box team on a cross-company collaboration project, which involved understanding another company’s development team’s requirements and figuring out how to build as little as possible while meeting their needs. I was a member of an engineering-wide API working group responsible for establishing and maintaining our API standards and I had several side projects going on. I would say that all of these contributed to various parts of my promotion and together helped me establish that I could demonstrate all aspects of what they expected.

Can you remember any piece of advice on reaching Staff that was particularly helpful for you? Is there an easier path to Staff that you could have taken?

One piece of advice I got at some point was to amplify my strengths. All of us have strengths and weaknesses and we spend a lot of time talking about ‘areas of improvement.’ It can be easy to feel like the best way to advance is to eliminate all of those. However, it can require a lot of work and energy to barely move the needle if it’s truly an area we’re weak in. Obviously, you still want to make sure you don’t have any truly bad areas, but assuming you’ve gotten that, instead focus on amplifying your strengths. How can you turn something you’re good at into your superpower? The other thing to think about is how can you use something you’re good at to compensate for something you’re weak at? For example, I’m a giant introvert and don’t particularly like mingling with people I don’t know. I’m terrible at networking with strangers. However, I’m good at writing and enjoy doing it. I’ve used writing on my public blog to meet people I wouldn’t otherwise and get exposure more broadly. In fact, I’m sure I’ve gotten far more from that than I would have by going to many, many meetups.

The other more tactical thing that comes to mind is directly related to the process we have at Box of writing a promotion case. A few things were suggested to me - first to write the promotion case well before I was sure I was ready for the promotion. This allows you to see where there might be gaps and can give you very tangible things to work on. (Or maybe you’ll be surprised and realize that you’re ready for promotion before you thought you were). The second is to be very aware of where those gaps are. When a promotion committee is reading through promotion cases, all of the cases are going to be very positive. No one says anything negative when they go up for promotion. So instead of looking for negative things, that committee is going to be looking for what isn’t said. Where are the blank spots? What seems to be avoided or talked over. Take a look at your case from that light - what things might be missing? What things are you brushing over? Be sure to work on those. Finally, tell your story.

Our promotion cases had templates with pointed questions, but, especially at the higher levels, everyone isn’t the same, nor do we want them to be. Instead of just answering the questions, think first about what your strengths are. What are your superpowers? What is your story? Then figure out how to fit that story into the prompts. You’ll have a much better overall case if you include your best strengths in it.

It’s possible that if I hadn’t taken a meander through management, I would have gotten to Staff sooner. That said, I don’t regret doing it and I learned a lot about how people think, how organizations are run and how larger projects are prioritized. All of these have continued to help me do my job on the IC track and likely helped me further get promoted to Senior Staff. While I do think it’s distinctly possible that it slowed down when I got to Staff, I’m actually less sure for the next level - I think there’s a real chance I would have hung out at Staff longer without it. All of this is to say that even though I didn’t take the most direct route, I still learned a lot that has helped me out long term.

What about a piece of advice for someone who has just started as a Staff engineer?

The more senior you get, the less your job is about code. Sure, unlike a people manager, you still have a very technical slant and even through principal, you’ll likely be doing at least some coding. However, the higher you get, the more your job becomes about mentoring and growing the people around you (and more broadly), building your team through building your company’s public tech brand, noticing larger technical trends that can be improved upon or corrected, helping to set the tech vision for your team or the company and advocating for resourcing for tech debt projects. It becomes much more about seeing broader things and getting others on board. Suddenly, communication, leadership and persuasion are even more important than they were previously.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I actually managed for about a year and a half in the middle of my time at Box and found that I hated it (you can find more about that in my blog post on that topic). That said, I found that there is actually a lot of overlap between management and staff+ roles in most companies. Both roles require mentoring others, leading and the ability to persuade people. They require thinking bigger and more attention to longer term - both in terms of technologies and people. While I don’t plan to go back to management, I did learn a lot during my time managing and the experience has actually helped me as I’ve advanced to Staff and beyond.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I don’t tend to follow any particular person, but instead learn from and find inspiration from almost everyone around me. I’ll list a few here, but in all honesty, I would say that I’ve learned from countless different people at all levels (including many more junior than myself).

I had a manager who every time I came to him with a problem, he would always turn it around on me and ask me what I thought I should do. This got to the point where I could hear him telling me to give feedback to someone directly or telling me to figure out how to fix something without me ever having to talk to him. He really taught me that while, as a manager, he was willing to support me, I would learn the most and be the best version of myself if I could do it on my own. He taught me to take responsibility for everything.

As a counterpoint, I would also mention a principal engineer I worked with, who later taught me that I didn’t need to try to do everything myself. After I learned to take responsibility, I started to forget that I wasn’t alone. Of course I had heard people talk about delegation, but it’s one thing to hear about it or think about it in terms of sprint tasks, but it’s another to delegate getting something prioritized or delegate figuring out tech vision for a team or delegate following up on an initiative.

There was another co-worker that I worked with who would drive me completely bonkers sometimes because her approach to solving problems was so different from mine. She would ask for clarification when I thought it was obvious and she would ask for detailed explanations when I thought everyone was on the same page. However, she’s also one of the smartest engineers I’ve ever worked with and working with her made me realize that not only can different styles be just as good, but that sometimes putting together two clashing styles can result in much better results than either of us would have gotten on our own. She found holes in things I thought were obvious and while she drove me nuts sometimes, we got some amazing things accomplished and I am better for it.

Next chapter: Ritu Vincent - Staff Engineer at Dropbox

Previous chapter: Dan Na - Staff Engineer and Team Lead at Squarespace

Book

If you've enjoyed reading the stories and guides on staffeng.com, you might also enjoy Staff Engineer: Leadership beyond the management track, which features many of these guides and stories.