When engineering systems grow large enough, leadership stops being about control.
That is one of the strongest messages from my conversation with Tamar Bercovici, VP of Engineering at Box. Her team supports a platform used by tens of millions of users and stores massive amounts of enterprise content. At that scale, leadership becomes a different discipline.
From individual contributor to organizational leader
Tamar describes two major transitions in her career.
The first was moving from individual contributor to manager. Like many engineers, she found the transition awkward at first. The work changed. The definition of success changed. The challenge was no longer writing great code, but enabling others to do so.
The second transition was even bigger: moving from managing teams to managing organizations. At that point, leadership is no longer about direct influence. It is about creating the conditions where many teams can succeed simultaneously.
Each step required Tamar to rethink what she was accountable for and how she measured her own impact.
Scale changes the leadership game
One striking aspect of the conversation is the ratio between scale and team size.
Tamar leads a core platform organization of under 200 engineers supporting one of the largest content stores on the web. That reality forces a very specific leadership approach: you cannot control everything, and you should not try.
Instead, leadership becomes about context. If engineers understand why something matters and what outcome they are aiming for, they can make good local decisions without constant oversight.
Change is the job
Large-scale engineering leadership, as Tamar puts it, is largely about leading through change.
Infrastructure migrations, cloud adoption, evolving customer needs, new technologies like generative AI – none of these are static problems. They require continuous adaptation.
Tamar emphasizes three principles when leading change:
- Make the change your own, even if it was not your decision
- Be transparent about why the change is necessary
- Avoid both sugarcoating and venting
Leaders must own difficult messages while still providing a credible path forward.
Clarity beats control
One of Tamar’s most practical insights is deceptively simple.
If you stop someone in the hallway and ask them what the next milestone is, they should know the answer.
That level of clarity allows leadership to scale. It enables teams to move independently while still rowing in the same direction. Without it, leaders are forced into constant intervention, which quickly becomes impossible at scale.
Risk is not the problem
Another powerful reframing Tamar offers is about risk.
Risk is not a sign that an initiative is wrong. Anything meaningful carries risk. The real leadership work is to name the risks explicitly and then de-risk early and continuously.
That can mean prototypes, pilots, staged rollouts, load tests, or customer design partners. Whatever the form, the goal is the same: reduce uncertainty before it becomes failure.
This mindset turns large programs from fragile plans into adaptive systems.
Innovation on top of foundations
After completing a full cloud migration, Tamar’s teams are now focused on optimizing and innovating on top of a more consistent platform. The emergence of generative AI is a natural fit for Box’s role as a content platform.
What stood out was Tamar’s realism. AI is both hype and substance. The technology is moving fast, best practices are still forming, and customer expectations are evolving in real time. Leadership here is not about having all the answers, but about learning faster than the environment changes.
Advice worth remembering
When asked what advice she would give her younger self, Tamar did not point to a specific career move. Instead, she spoke about reducing the emotional weight of decisions.
Careers, like software, are iterative. Choices are rarely irreversible. What matters is making a choice, committing to learning from it, and adjusting when needed.
At scale, leadership is not about perfection. It is about intentional progress.
Here is the transcript of the episode
Alexis: Welcome to Le Podcast on Emerging Leadership. I’m your host, Alexis Monville. In today’s episode with Tamar Bercovici, we’re diving into the art of leadership within the tech industry. Tamar, VP of Engineering at Box, has led her team through groundbreaking transformations, bleeding the art of building high performing teams with the science of developing innovative technologies.
Join us as Tamar shares her journey from a software engineer to a visionary leader at Box, revealing her strategies for building teams and steering her team towards continuous innovation.
Welcome Tamar. Could you share how you typically introduce yourself?
Tamar: Hi, it’s wonderful to be here. My name is Tamar Bercovici. I’m a VP engineering at Box where I lead the core platform. So at Box we’re building out the, the content layer for the enterprise and the core platform is [00:01:00] the underpinning of our product. So a lot of Distributed systems type challenges high scale challenges, but also the backbone for the product.
So thinking about what the right abstraction layers are been at box for 13 years. Yeah, that’s me.
Alexis: Excellent. So what drives your passion for technology and leadership?
Tamar: I think the technology space is just fun. You know, it’s a really unique combination of, hard, interesting, intellectually challenging problems combined with a lot of customer empathy and, and human empathy and, and a lot of creativity. So I think there’s just a really unique mix that we get to, to think about problems from a lot of different angles and a lot of different perspectives.
And then leadership is something that I, You know, at some point in my career, I shifted into a managerial position and sort of as an experiment, but I think I learned [00:02:00] that there’s something very compelling about teams and how you bring people together and align their energies and their passions and their talents to accomplish a goal together.
Like there’s, there’s, it’s, it’s a really unique type of challenge in and of itself, how you do that. But then there’s also something very. I think gratifying of working in that way. It’s something that I like. So you know, being in a leadership position is enables me to create that for myself and for my team.
And it’s something that I’ve really enjoyed over the past years.
Alexis: So me a, give me a sense of the scale of what we are talking about. That’s what are, what is the size of your team? And on the other side of how many users do you, do you have? How many customers are we talking about?
Tamar: So, so box focuses primarily on enterprises on businesses. And we have, you know, businesses all over the world as customers all different industries, all different sizes from, you know, very small companies to. [00:03:00] Some of the largest organizations that we have and and then the users are the employees at that in those companies that have seats at box, plus, you know, individual users, of course, as well.
And so in terms of the scale of users, it’s in the tens of millions, but some of the interesting elements of box platform specifically is that is the scale of of content that we store on the platform. So we’re probably leading one of the largest just content stores on the web and that has a lot of interesting challenges just It’s straight up in the, in the storage itself and uploads and downloads and managing copies and encryptions.
And it’s just a, a very sort of unique challenge in and of itself, but then also the system and the product and the, the, the metadata around that, that enables the product experiences an interesting scale challenge as well.
Alexis: With users in the tens of millions what is the size of the team managing that core platform?[00:04:00]
Tamar: so we, we run a relatively lean engineering team, I think, for the scale of the company. My team specifically on the core platform is just under 200. And that’s again for Sort of all of those core parts of our infrastructure, the storage infrastructure that I mentioned our data stores eventing systems search index metadata stores and then kind of the, that core backbone business logic layer.
So recently AI platform thrown in there as well. So a lot of those, those sort of fundamental components and then within box engineering more broadly, we have. Teams that are focused on just kind of the pure infrastructure layer to make sure we have the right environment to operate our systems.
As well as of course, all the teams that build out the product experiences themselves.
Alexis: I still find that incredible that that’s, that’s a very small team compared to the challenges. But yeah, that that’s perfect. That’s really good. Tell me more about your, your transition from an individual contributor [00:05:00] to a management role and the.
pivotal moment in the decisions to do that.
Tamar: I joined box as an engineer and I was actually coming off of finishing up a PhD in theoretical computer science and my goal at the time had just been to, you know, To kind of get back into industry, get back into a startup environment. I had a previous experience working at a startup company before, and I really like that sort of somewhat more chaotic and flexible and dynamic experience, and then also just being.
Very connected to the business and the customer and what we were trying to build. So that was sort of what I was looking for. And I specifically wanted to get into web, like box is actually the first web company that I worked at. And after joining as an engineer, my first biggish Project was around building out the initial scalability layer for a database infrastructure.
And one of the interesting things that you go through in an early stage company, you sort of shift from [00:06:00] very generalized roles to incrementally sort of more specificity in, in what you own. So I joined a, a six person backend engineering team that kind of owned all of it. So, you know, at any given time you had one person who happened to be working on the storage infrastructure, one person who was working on databases.
Right. But it wasn’t like, There was a lot of specialization there and it was fine. It was appropriate because it was a much simpler stack. But then as the company was scaling and we had to scale out the, the infrastructure to support that you’re now building more complex systems. There is more value in investing in those systems, but then also as you make those investments, you increase the complexity.
You now need people who specialize in the system. So you sort of go through this process of all of a sudden having differentiated teams. And I have a team that owns storage and a team that owns databases and so forth. And so again, I had kind of Thank you. Been a part of that, that database project that [00:07:00] shifted it from very simple, single database to a somewhat more complex infrastructure.
And I was faced with that decision point of staying on the technical track or, or, or trying my hand at management. And I debated it a fair amount. And I, I feel like actually it was hard to get good advice on this. It It felt more consequential at some level than it should have, because honestly, this is the kind of decision that you can undo.
Like I’ve, I’ve I’ve had multiple people who sort of shifted into management and then decided at some point that that was no longer the path they wanted. They went back to being individual contributors, but that experience actually gained them a lot of, I think, insight and perspective on what it takes to, To lead an engineering team to have a healthy engineering team.
And so it enabled them to be better engineers, I think. And then there was also a lot of muddiness in the conversation around is engineering management, a technical role or not. And I wanted to stay in a [00:08:00] technical role, but at the end of all of that debate I decided that management was going to be a bigger departure from what I had done thus far.
And I was curious. I wanted to try it out. And I think that initial transition is awkward for almost everyone that, that I have ever either talked to or, or, or managed who was going through that. And definitely for myself, it, you need to redefine what it is that your job is and how you. Assess your success or failure in your job.
I think it becomes a little difficult to separate yourself from the people on the team that are doing the work. So it took a little bit of time. But I think once I wrap my head around that, I found that I really enjoyed it because again, it let me. Look at the same set of problems, but from a more kind of well rounded, multiple angle type perspective.
And I just I like that. And so I, I [00:09:00] really enjoyed it. I felt like I was learning and growing and decided that this was the right path for me. And I think that that was sort of the first big transition. And then I think that the second big transition is sort of further on when you shift from managing teams to managing organizations.
And again, understanding what that requires and how you need to shift what you do and what you hold yourself accountable. It’s again, to some degree, a different role. So I’d say those were sort of the two big, big moments.
Alexis: Excellent. Thank you. Thank you for that. Can you discuss some strategies you’ve employed to foster a thriving engineering culture?
Tamar: I think. This is the 1st thing is you have to work at a company as a leader in particular. If you’re not the CEO who’s sort of setting this tone for everyone, if assuming you’re working. You know, for someone, I think it’s important to find a place that your values [00:10:00] align with that, that, that the culture aligns for you, because as a leader, it’s a, it’s really important that you are modeling and reinforcing that culture and those values.
And so finding a good place to work is, is I think key so that the investments that you’re making are synergetic with what’s happening more broadly within the company. And then I think a lot of it is. At the end of the day, all of us, no matter what our role is, I think good employees, like what do we want?
We want to be challenged and have opportunities to grow. We want to work with a good group of people and we want to make sure that we’re having impact, that our work matters, right? People, if you’re working at a company, then, then, then generally you want, you want that to, to be somehow contributing to what’s important.
You want to understand why, what you’re doing is important. But by the way, because any job has. Sort of the less interesting parts, like any job, every, every single role, every single job has the exciting bits, the challenging bits, the, the, the, the flashy [00:11:00] ones. And then the more run the business aspects or the more the, the less exciting aspects.
And so you have to be somehow motivated by the importance of what you’re trying to accomplish. And so as a leader, Yes, making sure that it’s, it’s sort of that good, good cultural DNA and that you’re reinforcing that within the team and setting that tone from, from yourself, but then making sure that the team has a, a compelling thing.
Goal or set of goals to strive for and that people really understand how what they’re doing fits in with what we’re trying to accomplish as a business and have that context. I think that’s how you get engineers or whatever role they’re in at the company that understand what we’re trying to accomplish and can hence.
Make better localized decisions, feel more empowered, be more engaged and actually deliver better results. So fundamentally that alignment of what we’re doing to business impact, it [00:12:00] sounds sort of straightforward, but I think it’s, it’s very foundational to having a healthy culture and engaged engineers.
Alexis: And so I assume that as a, as a lot of people managing through through changes is can be challenging. Do you have examples that you can share that, and that were really challenging and what have you learned through those, those examples? Hmm.
Tamar: I think a lot of leadership is. Chain leading through change, right? You know, our organizations are very rarely stagnant, right? There, there’s an evolution of what we’re trying to solve for, what our goals are, what’s challenging, what isn’t you know, ups and downs in the business that you need to contextualize as well as just, you know massive challenging projects that you need to lead the team through that, that cause big shifts.
So it, whether it’s sort of a. More of a like corporate context or a people, [00:13:00] HR or process or technology at some level, a lot of that is what we do as leaders. And I think there are some commonalities for all of those, which is you have to understand whether it’s you sort of driving, like you’re making the decision and causing the change or whether you are.
You know, you have to make it your own, you have to understand why it is that we’re doing what we’re doing, why do we need to make this change? And what are we solving for so that you can be very transparent with the team? Again, change is always uncomfortable, we all have a little bit of that reaction of like, oh, you know, what’s happening?
I feel unsettled. I don’t know where this is going. But having that context on why we are dealing with this problem and, and what we are. What we are hoping to accomplish sort of transparency, even if it’s about the challenging things is really important, but then in particular, if it’s challenging.
You know, striking that balance of making sure that you’re, you’re not sugar coating and kind of glossing over [00:14:00] the critical parts, but then that you’re not over almost like over empathizing with the negative and effectively like venting or ranting to your team. Like you have to, you have to own the difficult message if it is difficult and then you have to.
Show sort of why are you optimistic that we are going to navigate this change successfully? What do we need to do to make this work? What are your expectations of the team? And then everyone kind of understands, understands that context and knows how to approach it. I think specifically in the context of, of sort of, I’ve had the opportunity at Box for, for whatever reason to.
To lead us through several sort of big infrastructure migrations, which are, you know, think, you know, very large scale efforts we had some that were sort of shifting. Between various on prem data center environments, which is still a quite complex endeavor to shift your entire infrastructure from one place to another.
And then more recently, [00:15:00] we completed a sort of a full migration from all the workloads that we had on prem into the cloud. And that’s something where. You need everyone across all of their different services and, and, and, and tool sets and libraries and, and, um, corpuses to, to, to figure out sort of the right set of things to do localized while also having it be part of that, like overall migration cadence and how do you wrangle something like that?
And so again, it’s, it has to start first and foremost with a. With a ruthless clarity of goal. Like everyone needs to know what we’re trying to accomplish and why. So that as they’re making localized decisions, they make them in a way that’s synergetic with the overall goal. There’s no way that you can go control every little last thing that, you know, hundreds of people are doing.
Even 30 people, I don’t think that’s feasible. So definitely not a whole organization. And [00:16:00] so having that clarity of goal and then having even clarity of like, what are, if there are any sort of interim milestones that we’re trying to hit as a team, like really making sure that those are simplified to the point that people, if you ask them, if you stop them in the hallway and you ask them like, Hey, what’s the next milestone we’re working towards, they’ll know what that is.
And that can give you the confidence that because we trust that we’re building a a high performing team across, across the, the, the floor, if people know. what they need to solve for, they’re more likely to be able to make those good localized decisions. And then it all kind of like connects together and you’re able to steer that, that unwieldy process to a successful conclusion.
Alexis: Yeah. I like, I really like. How you framed it. It’s very interesting there’s the need to understand why we are doing something and to own it and to make it your own. That’s not, even if the changes is pushed on you in some ways at some point you need to make it your own. And and you need to make [00:17:00] sure that finally everybody knows why we are doing something and what we are aiming at.
And there’s those intermediate milestones that we’re aiming for. That will really enable decisions by the people who are, who are doing the work. And I, I feel there’s a lot of things to connect there that are really important. I am capturing all of that.
Tamar: Yes. Yeah. Yeah. That was a a great recap. I think it’s, you want to increase the chances that all the decisions that are being made, you know, you scale out by enabling people to make good localized decisions. And you do that through context and, and through that sort of drum, like the high level drumbeat and through a lot of communication.
And then, you know, Of course, there’s, there’s more to this, right? You need to have some, some signals that you’re rolling up to tell you how things are going so that you know if a particular area is falling behind and maybe you need to dive in more like it’s, it’s never as simple as it sounds in, in the podcast.
[00:18:00] But, but I do think that sometimes we almost like, Jump over that 1st part and start diving into the hard problems that we know exist. But then if you, if you do that too quickly, and you don’t take the time to set that overall context for everyone, you’ll, you’ll have more problems as you go along. I think maybe 1 more thing that I would call out in the context of any.
And he’s sort of large scale change. They’re always risky in some way, right? Like there’s, there’s some element of risk on will we be able to successfully make this change and will it have the impact that we expect it to have? And I think sometimes people interpret the risk as a sign. That this is a bad idea, or that maybe we shouldn’t do this or they sort of make plans that assume no risk and then say, but this plan is at risk because there’s a lot that we don’t know.
There’s sort of this kind of Handling of risk that’s maybe not what it [00:19:00] needs to be. And I think it’s important. And this is something you can do as a leader as well, again, to sort of frame that for everyone to take a step back and say, there’s nothing of value that is without risk. So the fact that there is risk is not a problem because we know that this is risky.
We have to ask ourselves concretely, what are the risks that we’re concerned about? Right. And then once you’ve called out the risk, you make a plan to de risk. So it’s not about knowing everything. You sort of assume that as you’re going through this process, there’s an ongoing level of risk that you’re managing.
But managing the risk is not just acknowledging that it’s there, but rather figuring out it. It’s usually about de risking as soon as you can, right? So is there a POC that I can do? Is there an initial test? Is there a load validation? Is there an integration point? What can I do to, is there a customer? A user study, a customer test, a design partner, like depending on whatever the project is, it [00:20:00] doesn’t matter if I’m rolling out a new process change, can I roll it out with an individual team to help them iron out the kinks?
Like what is the risk of the thing you’re trying to take on? What are the ways it could fail? Actually spelling those out and then putting in place actions that help you reduce the risk of that happening. And at some level, that’s how you manage the program. And so if you have clarity of goal. And you have clarity of everyone within their own areas, de risking towards that goal.
That is the best way that I know of to increase the chances of successfully hitting that, that outcome that you were hoping for.
Alexis: I really love that that idea that there’s things that, you know, that’s good. You need to make sure that, you know, why, why you know them and there’s things that you don’t know, and then you need to conduct experiment and so that, you know, a little bit better, those areas you don’t know. I really love that.
That’s that’s perfect. Thank you very much. Looking ahead What are some, some of the key areas of focus for you and your [00:21:00] team, and how do you plan to continue innovating
Tamar: I think there are some areas that are almost a constant, but that is a good thing. If you’re running any kind of large scale infrastructure platform system, you’re, you’re always thinking about, you know, Performance availability, efficiency, you know, all of those kind of fundamental foundational components.
And the reason hopefully you’re always thinking about them is because the scale of the business is growing. The scale of the customers is growing that the types of. Especially in an enterprise context, the type of work they’re trying to do on top of your platform is becoming more sophisticated, more critical, and hence their demands of you are growing.
So all of these are good signals. Like if you constantly feel like you have a More to do to, to keep kind of ahead of the business needs in terms of the scale at which you can operate, then that’s a [00:22:00] good sign. And so that is often and always a key focus area for us. I think in this year, in particular, after.
Completing our cloud migration. There’s obviously a lot of optimizations and, and improvements that we’re now able to make by having everything in sort of this more consistent modern environment. So we have a lot of focus there. And then at the product level, we’re at a really exciting inflection point at the company with a lot of interesting momentum coming together, both from kind of macro trends, as well as just things that have been building up within box to, to really.
Enable our users to leverage, to, to get value out of the content that they have on our platform in new ways. The whole sort of AI generative AI hype cycle that, that we’ve been in, it is a hype cycle on the one hand, but on the other hand, it’s, it’s It’s a real sort of kind of suite of technological.
It’s [00:23:00] technologies that are building up for years, but they’ve sort of gotten to that point of capabilities as well as kind of market recognition where all of a sudden, it’s really compelling. And, and if you think about it, they’re, they’re very good with unstructured Content with, with, with human text.
And what is, what is box, if not the platform where you put all of that data. So, you know, when this, when this was kind of exploding you know, around a little over a year ago, we were kind of, you know, we were all just as, you know, anyone who’s a technologist and following the field is like, wow, this is, this is so exciting.
I didn’t think that we’d so quickly get to the point that, you know, things like the Turing test maybe need to be rethought in terms of what they mean. But then at the same time, we realized how relevant this was to our product and to our users and really thinking about how to completely shift the paradigm around what type of value you can get from the content that you have on Box.
And it’s, It’s really interesting to try to [00:24:00] connect like the technological capabilities to solving real customer problems and delivering real value in a space that’s so emerging, right? There isn’t a paved path of here’s what, you know, successful use of this looks like. Here’s what the customer expectations are.
You’re, it’s kind of, you’re figuring out all layers of it all at once. The, the underlying, excuse me, the underlying technology is, is just. Shifting so quickly and then the best practices on how to leverage that and how to build product from that are shifting so quickly. And then, and then what the customer wants and even how to price it like the whole thing is in a state of flux.
And so it’s just been really fascinating this past year building out the foundation for that. And then looking forward, I think we just have a few really exciting ways in which we’re going to Continue layering intelligence through our platform to really enable new and compelling use cases.
Alexis: Excellent. I love it. [00:25:00] So to close what advice would you give to your younger self?
Tamar: it’s always hard for me to answer those questions because at some level, I’m a bit of an optimist and so I think even the challenges and the bad decisions that we make or, you know, the places where we derail a bit, I see the value of the learning from each of them. But maybe at some level, that is the advice to not.
I think sometimes when you’re at the beginning of your career, a lot of decisions feel very consequential. It’s like, I’m now making this choice and this is like, this is going to be the trajectory of my life. And it feels. the emotional burden of that can, can feel high. And it’s true that , when you’re further through and you look back, you understand how each and every one of those choices built to where you are today.
But that’s not to say that had you made different choices, you would not have Similarly, been able to have a [00:26:00] compelling path. So I think just like software development is a very incremental process, right? We’ve we’ve sort of collectively as an industry with the advent of web learned this process of iteration and making small changes and and getting it Data validation and then tweaking and adapting and adjusting.
And at some level, our careers are no different, make a choice and then optimize for whatever choice you made. And if at some point it feels like that’s not the right thing, you know, make the next choice, but you’ve, you’ve learned something and get, as long as you’re intentional about what you’re doing and you.
Apply your energy and you stretch yourself to learn and grow sort of with every phase then that even the ones that don’t go so well, I think end up adding another rung in your ladder to wherever that ladder is leading. So I think that the advice would be to not be too worried about those things and just make a choice and move forward and see where it takes you.
Alexis: I love it. That’s a very [00:27:00] beautiful one. Thank you very much for having joined Tamar.
Tamar: Thank you. Thank you for having me. This is great.
Photo de Jeremy Bishop
Thumbs Up to show their approbation.
Thumbs Down to show their disagreement.
Flat Hand to show they are ready to support the decision of the team.
I also worked with teams that introduced a variant of the flat hand signal. With the Palm up, it then means that the participant will follow the team but would prefer not to, but does not have strong objections.
A good addition to the classic: I want to speak!
