This story was recorded in March, 2020. Learn more about Ritu on her 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 Staff Engineer at Dropbox. I actually was a Staff Engineer at Dropbox, left to join a different startup, and then recently came back to Dropbox just a few months ago. I came back because a really interesting opportunity opened up within Dropbox to launch an internal incubator. We’re working to foster innovation within the company. Dropbox has become a strong brand in the file sync space, but there’s beginning to be a lot of competition there now, so we need to do more and branch out into new products. The incubator works directly with the CEO, and is a very small team.
I’d been at Dropbox long enough that I built really close bonds with a lot of people here, so when folks pitched me this role it sounded really fun. I’d also been a manager for a couple of years and was getting a little itchy to code again. Putting those together led me back to Dropbox.
There are two parts to the incubator.
The first is a more classic incubator where engineers across the company can pitch ideas and get funding to join the program, and try to show product-market fit or other forms of progress to continue getting funded every few months. The goal is for successful projects to graduate into their own lines of business, although we’re still early.
The second part is engineers who are permanently part of the incubator, and are always generating ideas from within the incubator and operating with a lot of autonomy. I’m one of the two engineers on that permanent “scouting” team, and we’re planning on growing over the next year. It’s very different from anything I’ve done before, which is why I wanted to sign up for it. It’s a huge paradigm shift for me. Honestly, the first few months have been a combination of really fun and really frustrating because it’s harder to measure obvious impact when your primary goal is to very quickly try out a ton of new ideas, many of which will not go anywhere. I’ve had to learn to think of impact in longer timescales - not in terms of what I’m shipping today, but what I could influence the company to ship in the future.
What does a Staff-plus engineer do at your company?
I’d say there are two different profiles of Staff Engineer at Dropbox. One is a tech lead who does a lot of coordination, designs work for their team, and spends time driving projects. The other is more of a specialist.
The tech lead was definitely my profile when I initially became Staff where I took a team of about eight engineers and drove an eighteen month project. That project had a lot of dependencies, a lot of gnarly parts. I had to control the communication around the project, as well as figure out how to allocate pieces of the project to the team in a way that both helped them grow and got the project done.
The specialist is deeply specialized in a particular area, for example Guido van Rossum, the creator of Python. Specialists would take on really complex projects and execute it themselves, often projects that no one else could take on effectively. There were fewer specialists than tech leads.
Were the specialists predominantly external hires?
There were some specialists that came in from industry, like Guido and a lot of very experienced folks on the ML team, but a lot of specialists ended up being homegrown. That might be related to rolling out titles relatively late at Dropbox, which gave folks longer to develop deep context in our technology.
How do you spend your time day-to-day?
In my current role within the incubator I’m spending all day prototyping, but in my previous tech lead role I did a lot of different things.
I was coding, but I wasn’t coding very much, maybe 20% of my time. I was the tech lead for the desktop client area, and spent a lot of time coordinating and providing guidance on projects. I also spent a lot of time partnering with recruiting, which was something that I did because I was interested in it, not because it was required.
For example, I worked on designing specialty interview loops, moderating debriefs and candidate screening. I also did a lot of work on diversity initiatives. That’s one of the reasons that I’ve tried engineering management multiple times during my career, because I enjoy participating in organizational growth.
Where do you feel most impactful as a Staff-plus engineer?
One of the things that I’m really proud of having worked on was a big revamp of our engineering levels. Back in 2017, I was one of the few individual contributors selected to work on an engineer levels refresh, most everyone else was a director or manager. I’m proud because the new ladder impacted every person at Dropbox working in Engineering, Product and Design.
It was also just really interesting to think deeply about how company growth changed roles and responsibilities. We were starting to bring in people from a lot of different backgrounds, and we wanted to be able to reward everyone in a healthy way. That was very different from my normal day-to-day responsibilities and pushed me outside of my comfort zone pretty significantly.
I’m also proud of my Staff Project, which was very technically complex. That project also gave me a chance to help a lot of people on the team grow. Years later, I’ve had engineers who left the company email me and say how much more confident they are or how much they learned because of that project.
It was also on that project where my manager helped me understand that my first impulse as a tech lead didn’t scale. Initially I was thinking, “I’ll break it into twenty pieces, assign out eighteen pieces, and keep the two hardest for myself,” and my manager pushed me to delegate the hard pieces to the team to stretch and develop them.
Do you spend time advocating for technology, practice, process or architectural change?
As a tech lead I spent a lot of time advocating for change. I would jump into a lot of different architecture and technical discussions, even in areas that weren’t directly within my area of expertise, because people seemed to trust my intuition. I know tons of engineers who have amazing technical intuition and don’t have the Staff Engineer title, but the title does formalize having that intuition.
I do prefer for the team that’s going to own a project to make the final decisions about it. In cases where I have a very clear “right decision” in my head, I’ll try to lead the team towards that decision rather than going in and saying “this is the right decision.”
How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?
I definitely think of myself as a sponsor. Execution is one of the most rewarding parts of my job–I love building stuff–but I’ve always loved helping people grow. I feel really proud when I see somebody who I informally mentored or helped on a project go on to do something great.
As a Staff Engineer, and especially as a woman who is a Staff Engineer, I feel like a lot of people look up to me. There seem to be a lot more role models on the manager career path, so I try to make being a role model part of my responsibilities, instead of just keeping my head down coding. I mean, I could just keep my head down coding and that would be great, but I want to help other people, especially people with imposter syndrome.
I often get people coming to me and saying, “I don’t know how to make the next step.” or “I don’t know how to become a staff engineer, so I’m going to go be a manager instead.” I want to try to help them figure out their path. As a Staff Engineer, I think being visible and available for people to ask these sorts of questions is an important part of the role.
What’s something you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done earlier in your career?
There wasn’t anything I wasn’t able to do without the title, but the title did give me confidence. In addition to the title, the other thing that gave me confidence was realizing that everyone else is also struggling with imposter syndrome. The latter I learned in a pivotal conversation with someone who I thought was the most confident engineer I’d ever worked with, and when I talked with him about it he said, “I question every single thing I do. I go home and agonize over what I said earlier that day, and whether it was silly.”
It was really that conversation in combination with the title that pushed me to believe in myself as a Staff Engineer. Together they gave me the confidence to ask for the harder projects, or to ask my manager to give me more projects to work on.
What was your process of getting promoted to Staff engineer at Dropbox?
They rolled out external titles a while after I joined Dropbox. In the first review season with titles, they gave the Staff title to a very small number of engineers. They were really still calibrating the titles at that point. It was in the second review season that I got my Staff title.
By the second season, I’d been a Tech Lead for a while and my manager and I both felt that I had clearly been executing at the Staff level. We did go over the new career level definitions to identify any gaps before the review cycle, but overall it went pretty smoothly.
What two or three factors were most important in you reaching Staff?
One of the big factors for me was definitely visibility. Part of that came from doing so many things outside of normal engineering responsibilities.
For example, I helped recruiting with running the intern program one summer. During the program I worked with a ton of intern mentors across different teams, and since Dropbox tended to have very large intern classes, that ended up meaning that I gained visibility across pretty much the entire company. The hiring work helped too. If you’re moderating dozens of hiring debriefs every month, and driving hiring and calibration conversations, then you’ll get to interact with everyone in engineering. I also helped with onboarding, giving a core engineering presentation to incoming new hires.
Having a sponsor was also definitely important. My manager and I had a fantastic relationship, and I also had a great relationship with my skip-level manager. I think that played a big part as well.
Was that work, which some companies would call “glue work,” directly valued?
This work was highly valued by leadership at Dropbox. Leadership and many of the very senior engineers were heavily involved in these efforts, especially recruiting, and it was not considered glue work. That being said, it would not have gotten me to Staff on its own. It was a question of finding a good balance between having cultural impact and having something technically strong to showcase.
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?
There isn’t an explicit expectation, nor is it listed anywhere as a formal requirement, but it is understood that you’ll complete a Staff Project to get promoted. I can’t think of any Staff promotion that didn’t include a really strong project, typically a multi-person project where the engineer was the Tech Lead.
I definitely had a Staff Project. Back in the day, Dropbox was initially a consumer product that people downloaded and installed on their machines. When we launched Dropbox for Business there was a request for both your personal and work Dropbox accounts to work simultaneously, including being able to switch across them without needing to log out and log back in.
The initial implementation was written under immense time pressure, and it ran multiple Dropbox processes. One for your personal account and another for business. My Staff project was to make it so a single Dropbox process could run with multiple users logged in. The hard part was that the project stretched from the kernel all the way to the user interface. I had to understand every single layer of the Dropbox system.
Initially we thought it would take six months, and it ended up taking eighteen months. It took up most of the Desktop Client team’s resources for quite a while.
Would you share a piece of advice on reaching Staff that was particularly helpful for you?
Early in my career, my instincts were to ask for projects that I felt I would be able to execute well on instead of projects with more ambiguity that would push me to grow. The advice I got was to push myself out of what I was comfortable with, and to ask for the hard projects on the team. To reach Staff Engineer, you have to know and do more than what you currently know. It’s important to always push beyond what you’re doing and not be scared of asking for things you think are too hard for you.
This is tied into imposter syndrome, where you might not want to try anything until you’re absolutely sure you’ll excel at it. But you have to get comfortable with the fact that you might crash and burn. That’s okay, you’ve got to try it.
What about a piece of advice for someone who has just started as a Staff engineer?
People frequently come to me and ask, “What should I do next to reach Staff?” One of the things that I tell them is to be super open and honest with your manager about what you want from your career. A mistake I made early on in my one-on-ones was telling my manager what I thought they wanted to hear, instead of what I actually felt.
They’d ask me if I was interested in a piece of work, and I’d wonder why they were asking, did they want me to take the work? So I’d say I was interested even if I wasn’t. Or they’d ask me how a project was going, and it might be going horribly, but I’d tell them it was going fine to avoid disappointing them, instead of saying I needed help.
Somewhere along the way I realized that your manager is really on your team. They’re looking for a way to make you grow, be productive, be happy and become the best engineer you can be. The way to have an effective relationship with your manager, including having them sponsor you, is to be super honest and open with them.
This became particularly obvious to me when I became a manager myself, because I wanted everyone on my team to become a Staff Engineer and to get promoted. I wanted to find reasons to promote them, and worked with them on that.
Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?
I do pendulum a decent amount, because I’m interested in so many things on both sides of the career ladder. I’m interested in growing people, I really like working with recruiting, I’m one of those engineers that actually enjoy interviewing, I like understanding how teams grow. But I also really like writing code, and after I spend some time managing I want to get back into the code and hack around a little bit.
Once I started mentoring and managing I definitely found myself thinking about career growth very differently. The pendulum has helped me see a lot of different perspectives. As a manager you have very explicit responsibilities for things like headcount and performance reviews. Staff engineer responsibilities are really fuzzy and differ across companies. That ambiguity around Staff roles leads many folks to make the lateral switch to management who would have been happier staying as an engineer. That’s why it’s so valuable to get more information on the Staff role out there for people to read.
What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?
I read a lot, but my reading is very recreational. What’s been most impactful for me is having a lot of people who I think of as mentors, usually friends, former managers and folks that I’ve worked with. I have a decent number of recurring monthly lunches, coffee chats and dinners with people who’ve worked with me in the past, know me, and I trust. It’s those conversations about career challenges and growth that have gotten me to where I am in my career.