#20 - How I became a VP of Engineering at Box | Tamar Bercovici

Thinking inside the Box

Hey friends!

For once, that’s me

Jean-Baptiste Coger

— cofounder at Plato, who’ll write today’s article. And the format is a bit different, with an article based on a chat I had with Tamar Bercovici, VP of Engineering at Box. When we launched Elevate 2023, we wanted all talks to follow two formats: “How we do [Topic] at [Company]” — with actionable insights and step-by-step guides on specific topics; and “How I became [Role] at [Company]” to learn the personal stories of leaders and how they got where they are. This article follows the latter. It’s a first for me, so once you’ve read it, feel free to share your feedback in the comment section… and to subscribe to Plato Newsletter if you haven’t yet!

From Backend Engineer to VP at Box

I won’t spoil the interview, but take a look at Tamar Bercovici’s LinkedIn page and you’ll see what looks like a linear journey—in her 12 years at Box, she went from software engineer to Vice President of Engineering, spending about two years in each role along the way. But of course, LinkedIn just shows us the milestones and not all the work and challenges it took to achieve them. I had the chance to down with Tamar at Elevate and learn more about her career progression and advice for all the aspiring engineering leaders out there.

You can follow Tamar Bercovici on LinkedIn.

---

How I Became a VP of Engineering | Tamar Bercovici, VP Eng at Box

A quick side note about this interview: we made minor edits to bring more clarity to a few points.

Let’s start from the top—you have a PhD? 

In theoretical computer science. Formal language theory. It was super intense. There was no coding involved. It was basically math, though it was technically in the CS department. So I get to say that I have a PhD in computer science.

And then you wanted to go into industry?

After I finished my first year of undergrad, I started working at a startup company. I think I was employee 17 at the time. I worked summers and part-time there—a bit like an elongated internship. I eventually took a semester off to work there. 

I really loved it, and yet I took a complete pause and decided to do the PhD thing for a bit. I wanted to dive into a hard challenge all the way to the depths of it. But when I finished my PhD, I was pretty clear that I wanted to go back to industry and that startup environment. I was explicitly looking to join as a software engineer at a small, early-stage company. I got a lot of quizzical looks when people looked at my resume, like, “You realize this is not a research position?” I had a bit of a strange background, but luckily I found Box.

So how did this happen?

I met the folks from Box when I crashed a career fair at Stanford at the advice of my husband. I was pretty worried because I wasn’t a student, I wasn’t at Stanford, and I wasn’t looking for an internship, but he told me I should just go anyway. In the end, it was great because it was an opportunity to talk to people and explain my background and what I was looking for. I met the folks from Box, interviewed, and ended up joining.

Box was on the larger end of what I was looking for. There were about 130 people, but only 30 in engineering, so I told myself that I’d still have that experience of knowing everyone. Having the flexibility to find my path was important because I didn’t have a clear notion of where I wanted to head to. I learned from my previous experience that when you come to this chaotic world of startups, you can end up doing unexpected things. 

In the 30-person engineering team, I joined the back-end engineering team which consisted of six people. I was the first woman on the team, which was fun — but it was a different phase of the company. 

Only six months in, we started growing fast. And when I hit the four-year mark, we had roughly 10x the number of employees, so that was an interesting adventure for sure!

And is the team you joined 12 years ago still part of your org?

In the beginning, I (somewhat randomly) ended up working on building our first scalability layer for our database tier. When I joined, we were running on a single SQL database at any given time. That was still working, which was surprising, but we could see where we were headed if we scaled further. I thus started building our sharding infrastructure and the foundations of our database service layer. When we finished that project, it was a little more complicated and needed more continued work. I advocated that we should build a team to own that and the evolution of that team is still part of my team today!

This was the time when you decided to go into management?

Yes, it was about two years in. I debated it a fair amount—we all have that decision about staying on the technical track or going into management. I actually got a lot of surrounding feedback to stay on the technical track. There was this meme that managers aren’t technical. 

At the same time, I had the sense that it would be a bigger departure to go into management and I was curious. I wanted to see what it was like. I figured I could try it and in the worst case, I could always go back. 

I’d already had the experience of going into theory and back into practice, so I wasn’t too scared to go into management. If necessary, I figured I could go back to being an IC. I felt management would probably give me a more well-rounded view of what goes into building a successful engineering team. I switched to a management role and ended up loving it, and never switched back. 

You mentioned that Box didn’t think you would want to be a manager?

There was shaky confidence in my conviction here. I went up for a promotion to a manager title and they ended up giving me a staff engineer title at the same time. And the narrative was: In case I decided I wanted to go back, they wanted to make sure I had the right level to return to. 

But it ended up working out and you opportunistically started opening up more teams under you?

Management is funny in that it’s very opportunistic—you can’t manage a team that doesn’t exist or doesn’t need a manager. So there’s some amount of organically growing the team that you have. Sometimes someone quits or takes a different role and there’s a gap somewhere in the organization and you need to take it on. 

I’ve had an interesting mix over the years of growing teams as well as taking on teams. You learn more when you take on a new team. It’s kind of like running more than one experiment at a time. 

One of the interesting processes for me each time is trying to figure out whether the combined team made sense. Sometimes if you’re on a management track, it feels like you should be optimizing for scope and for the number of people that you manage, but not all scope is created equal. 

If you’re managing two teams that don’t have a strong relationship with each other, then the fact that you’re managing both of them doesn’t give you any leverage. It doesn’t give those teams any leverage. You’re doing double the job. Yes, there’s a certain amount of accelerating your learning by doing double the job, but you’re not doing the bigger job. 

Whenever I’ve taken on a team, I like to think of it as a systems view. Does this make sense into a bigger unit from which I have more leverage or more ability to align strategy or provide a rationalization for the scope? If so, great. If not, my job is to refactor them out of my team and figure out what’s a better home or place where they can align. So I’ve done a lot of taking on but also shipping out.

At one point, I cut my team in half and handed off 40 people, which is a big change if you’re managing 80. I had a little bit of cold feet as I was doing it, but I kept telling myself, “This team doesn’t make sense. I’m not going to be able to support these two organizations.”

It’s a good lesson—to think about whether your team makes sense. Can you build a narrative out of the people who are under you? And if not, consider how you can refactor them. It’s also interesting to see the parallels with technology and how you build infrastructure.

What do you think made you successful as a manager?

When you first switch into management, it’s very much a different role and you almost have to re-understand what it is you do on the team. The first time you sit down to write your self-evaluation, what do you put down there? You didn’t ship the code. You don’t want to take credit. It’s a strange perspective shift. 

When you’re an individual you have all these expectations from what you want your manager to be for you. And you become a manager and you think you’re going to become that for everyone, so you become the amazing coach of the five people you have on your team. 

And weirdly enough—though coaching and investing in people is an important part of the role—that’s not the job. So a little ways in, I realized that I now own this scope. And this scope is expected to deliver business impact. 

As a manager at any level, even as a first-line one, it’s all about how you maximize impact. A lot of that is about maximizing the abilities of your team, so for sure the people element and the coaching and mentorship come in. But you have to shift your perspective to think about how you can take the scope that you’ve been entrusted with, align people, facilitate their ability to execute well, facilitate how they interface with other parts of the organization, and how you’re surfacing and receiving information. 

Focusing on impact in my mind is the best way to progress. If people see that they give you a team and the result of that is a team that delivers impact—which also implies a healthy team and a team that’s executing well—they know that they can entrust you with more. You build the trust of the organization in you as a leader slowly over time and that’s what leads to more and more of those opportunities.

It’s getting away from ‘I’m managing those five people’ to ‘I’m managing that scope and impact.’

Sometimes people think either you’re investing in your people or you’re a shill for the business, but what do we want on teams? We want to know that we’re working on something of value that’s delivering impact to the business, that we understand why what we do matters, and that we have the context we need to do our job well. 

All of that comes from having a manager who owns that scope, sets that context with their team and also provides the coaching, perspective, and growth on an individual level. But whatever you’re solving for, it all aligns together. The success of the people on the team and the success of the team go hand in hand.

After engineering manager, your next role was senior engineering manager. How would you describe that role?

The manager that I had at Box when I joined was great. He had these clear ways of framing things. He always used to say that whenever there’s a title name that’s the “senior” version of a role, it’s like the expert mode of that role. 

If you’re a manager, usually you’re just starting, you’re managing a team. As a senior manager, you’ve built up more experience. Either there’s something more complex, more high-impact, or high-risk about the particular team that you’re managing. Or oftentimes maybe you’re managing a couple of adjacent teams so you have a larger scope. Maybe you’re starting to manage other managers because you’ve built up that expertise so you can start training others. 

To me, senior manager is very much the same role but on a more advanced level, so that’s what was reflected to me in my path.

Quickly after that, you became a director. What sparked this transition?

The shift to a director role is that you need to start driving. And it’s not that you can’t influence or contribute to strategy at the manager or senior manager or even at the individual engineer level. We should all be thinking about why we’re doing what we’re doing. 

But at the director level, that now becomes part of the job expectations. You need to understand the broader context of the organization within which you’re operating. And you need to understand how to set the strategy for your team within that broader context, again to maximize impact. 

You’ve got to build up experience, manage more teams, manage larger teams, and make sure the organization trusts you in achieving that. I also had an opportunity to lead a larger cross-functional effort that was scoped larger than the team that I officially managed. Showing that I was able to pull that together and deliver impact with this broader scope was another element of trust showing that I could drive at that more advanced level and I think that ended up being a big part of the director's promotion.

It sounds like you were doing the director job before you got the title. 

I’d recommend that whenever you’re presented with an opportunity, to step up and take it, even just as a personal learning and growth opportunity. If you have a chance to learn from something that’s put in front of you, why not? It’s an opportunity to show that you’re a leader who the organization can trust to deliver. And of course, if you’re in an organization that doesn’t over time recognize your impact, keep in mind that no one’s forced to stay where they are. 

Sometimes we think too much about what it takes to get to the next thing. We’re aiming for the next thing, and that ends up being more confusing and leads to actions where it feels like you’re trying to check the box on whatever your career rubric or your career ladder is. 

It’s almost like when you’re driving a car, you don’t look where you are, you look ahead. It’s all about where you are, what are the opportunities you can step up to, what are the ways in which you can influence? It doesn’t always have to be an official leadership role. Sometimes you’re in a team that needs to figure something out—how can you contribute? How can you help drive in a good direction? And that compounds over time. And then at some point you realize, I’m already doing the job. And in a good organization, you’ll be recognized for that.

And then the expert mode of that—senior director?

I’d say it was similar—bigger team, more experience. I was always that person who was thinking about why we were doing what we were doing and showing some of that strategic thinking even earlier, but there’s a difference when you’re accountable for something. Being able to lean into that and thinking about what should my team be working on and how can I stretch them further. We all set goals for our teams and it’s so easy to overshoot or undershoot, so it’s important to hone that skill of knowing how to challenge a team while staying connected to what’s realistic and build up a stronger leadership team under you. 

I think that’s also a crucial element of becoming more senior—to build a team that enables you to operate at a higher level. And another, different cross-functional effort. Folks who don’t know me from Box don’t know that I’ve weirdly had a career of migrating from one thing to another. We were going through a large migration that I was able to lead and that also showed leadership at a broader scale. 

And then about four years ago you became VP. What was that change like?

So that one is a new role. Interestingly, I got the promotion without necessarily getting another team or more scope. I became a VP with a relatively small team—I mentioned earlier that I had cut my team in half. So it felt like a relatively small team compared to my peers.

When you take a more senior role, you need to reconsider what constraint you need to solve, versus what is within the scope you're accountable for and that you can influence and reshape. I think I was still in this mode of trying to follow some process or decree from a nonexistent VP until I realized it was me. I realized if my team is scrambling at the last minute to finish our planning, to align on some decision, or to figure out our headcount, that’s because I haven’t set a structure and a process for us to be able to do that. 

So my role involved creating space for the leaders who report to me to be able to drive their organizations but still allowing ourselves to come together as a team for me to influence what they’re doing, and to weigh in. It required changing that perspective. It took me a little bit to understand what the role was, but it’s been fascinating. 

Generally, you’ve been given roughly what you’re supposed to do and now it’s more about how do I break this into something I can execute on, how do I set my team up, how do I track that execution, how do I also make sure all the systems I own are healthy? 

And then at the director level, it’s a bit more on: What are we going to do? What is the set of things that I need all of these teams together to do so we can deliver on this impact that we need for the year? It involves understanding what that impact should be, but also which steps, components, and elements go into it.

And then I think with VP there’s thinking further out—if directors are thinking in the one- to two-year range, you have to be stretching out a bit further and creating some sort of coherent narrative for the team that helps them focus and align their efforts. And thinking more about the structure and the ways we work.

I’m a big believer in teams, and at Box, when you become a member of the leadership for the engineering team as a whole, that prompts us to think about how we operate successfully and what we do as an organization.

Reflecting, what were the biggest step functions for you and what were the smoothest transitions?

For me, the weirdest ones to wrap my head around were the first time I became a manager—because that’s very much a perspective shift—and becoming a VP. It took me time to not be frustrated and realize that I had a lot more control over my destiny in the role in ways that I didn’t realize initially. And then it became fun because I realized I could set this up well for my team. 

And the director transition felt like you were already doing the job before?

Yeah, that one felt smoother. 

Now what? You’ve been in the VP role for four years. What’s next for you?

It’s funny. Because when you hit ten years, you get a lot of questions. It just goes to show that it’s not all about getting the title. For me, the opportunity to do something that I find challenging and that I feel like I’m learning and growing from has always been front and center. 

We’ve just completed a massive migration of all of our infrastructure to the cloud, which is probably funny for newer companies since there hasn’t been such a thing as an on-prem to cloud migration for them. But Box was founded in 2005, so that was a fascinating next step on this exciting journey of starting from the stack we had when I joined and everything we’ve been building up to, building more scalability, building in the right platforms and capabilities and also building in the right environment. 

Now I’m very excited about a lot of what’s on our roadmap. AI is such a hype cycle right now, but also thinking about what Box does—we deal with unstructured content—it’s technology that is very appropriate. Having the opportunity to take something that’s so hyped and thinking about how to productize it in an at-scale product with an established enterprise customer base, is also a fascinating challenge. For now, I’m having a ton of fun and I’m okay with the LinkedIn ladder not updating every two years.

To sum up a few key takeaways:

1. Focus on the narrative you’re building.
2. Take opportunities when they come, even if you don’t have the title.
3. Do not see yourself as the manager of people, but as managing the scope.
4. And stop chasing titles and look for ways to make an impact—good companies will recognize that. And if not, maybe it’s time to move on.

Are there any resources you’d recommend to aspiring engineering managers?

One thing that’s exciting for us as engineers is that we’re in a field where there’s not only one way to do things. I like First, Break All the Rules by Marcus Buckingham for managers because it explains you’re not trying to be a one-size-fits-all manager. It gave me permission to look at my team for who they were and figure out how to set them up in the best way to get the most out of what we were trying to accomplish. The Five Dysfunctions of a Team by Patrick Lencioni is the foundation for all of our jobs. It’s a classic for a reason.

Final question: is any of your code still in production 12 years later?

I’m going to guess there is. But every time something I built gets replaced by the team, it’s my moment of maximum pride because the code is aging as soon as we put it in production. All of our jobs are about this dynamic adjustment towards where we’re heading. If we’re not adjusting our code base, our architecture, our systems, our platforms, and our teams, if we’re not all refactoring everything on an ongoing basis, it means that we’ve stagnated. So I always love seeing when my code gets deprecated.

---

That’s a wrap. I’m forever grateful to Tamar for her time and will to give back to the community. And I’m curious now, what did you think about this format?

See you soon!

JB and the team at Plato & Coda