In episode 4 of Swimm Upstream, Host Tom Ahi Dror speaks with Tamar Bercovici about the challenges of keeping engineering teams motivated, productive, pushing forward, and sharing knowledge as VP of Engineering at Box.
Hello everyone, and thanks for joining us on this episode of Swimm Upstream, a podcast devoted to engineering team leads and dev tool enthusiasts. I'm Tom, co-founder of Swimm, and today we're talking with Tamar Bercovici. Tamar has a Ph.D. in Computer Science from the Technion, which she finished while working as a software engineer at XMPie, an Israeli startup that was bought by Xerox. She then started working for Box as a Senior Software Engineer and has gone through several managerial roles until reaching her current role as VP of engineering. During that time, she saw Box growing from less than 300 employees to more than 2000. She's also responsible for several groundbreaking patents in cloud computing and appeared in several top people in tech lists over the past few years. Hi, Tamar, we're excited to have you on. Thanks for coming to speak with me today.
Hi, I'm excited to be here. Thanks for having me.
So we have an interesting set of questions for you today. And we'll jump in. But we'll start with some regular questions that we have. So we take coffee very seriously at Swimm. And some of you might not see this, but Tamar had a cup of coffee just a moment ago with her. So to start things off, if you could have coffee anywhere, not necessarily the room you are, where would that be this morning?
Clearly, coffee with you is what I'm having. Why would I be anywhere else?
Okay, that's, that's the first that we've heard that. That's a big compliment. So thank you very much for that.
So and moving to a different subject, this past year and a half, you know, have been mostly focused on adjusting to the new realities of COVID-19. So what's one thing you've learned to live without that surprised you since this started?
It's definitely been a strange and interesting year for all of us, I think. I learned to live without separation from my children during the workday. I remember when this - we have two young children and when this started, and we were all thrown together, it very much felt like survival mode. And I was proud that we had survived the first few days and everyone was still alive, and we still had our jobs. But it's been - it's been interesting sort of going through that process being more intentional about how we set things up and how we give ourselves the right structure. I think a few months in, I realized I was still sitting on a dining room chair in a hallway, and I was like, this is very short-term thinking. So I put in motion to consolidate a child consolidation plan. So I moved them both into the same room, which gave me a home office, but now it's shared with my daughter. And so I just think it's sort of when you expect that it's going to happen, you think about how to set things up so that everyone has their own space. And now all of my coworkers know my children and vice versa. It's been an interesting, yeah, an interesting year, but I think there's something positive about it too. But don't get me wrong. I'm very much waiting for them to go back to school, you know. We each have our own space back. But I think it's been an interesting process.
Okay, I think long-term thinking might be a theme of this conversation, but we'll wait and see. Okay, so could you please describe what you do at Box now, without using your title?
Yeah. My daughter would say I talk all day, which is probably true. But I think what I do is make sure that all of my teams are aligned around, you know, a direction like what are we shooting for? What are we trying to solve for? And making sure that that is something of value that is impactful to our business. Making sure that the team is structured and resourced in a way that enables them to accomplish those goals. And then investing in building a healthy team, right? Like how do we have a good culture? How do we invest in good collaboration? How do we support the individuals and their growth path because I think this sort of having an impactful direction that you're excited about, you know, the resources you need to get there and a team that you want to be on that journey with like - that's what we do as leaders, I think. And so that's some combination of all of those is what I spend my time on. Some of it very short-term tactical, some a bit more long-term strategic, but like ultimately, it tends to fall in those three buckets.
I wonder if some of the people hearing this might be team leaders, directors, like mid-management. And I wonder if you could help them understand their own VP engineering better - what's like one thing that you would tell them to take into account?
I think for all of us, wherever we are, whatever level we're at, thinking about the broader problem and how you fit in within that broader problem is always a good idea. Because otherwise, you're narrowing your perspective too much, right? So sometimes, you might not see that there's actually a more interesting opportunity if you sort of look a little bit sideways of where your team is right now. Maybe that requires taking on a new area, maybe it requires collaborating with another team, but you sort of need to stretch your thinking to think more broadly than your current scope. But then also understanding that whoever may be managing that scope does not have the unique insight that you have on your team.
So you are always better informed on what's happening on your team than anyone above you. And so you need to be stretching your thinking, thinking broadly, but then leveraging the insight that you have proposing what you think we should do. And not sort of going to your manager at whatever level to make the decision for you. Like they'll tell you if they have an insight that differs from yours or if there are other constraints that they're looking at. But I think seeing, you know, what is the highest leverage that your team can deliver within a broader context, than what you technically own, I think is how I would want everyone on my team to operate. And I think that's how you get that, that leverage and that insight. And that also enables if you get that from the people that report to you, now you have a better view of what's actually happening - everyone is thinking more broadly with more of that ownership mindset. And then you can sort of help influence and guide it at your level.
Amazing. That's like a one minute management course. That's great. Okay, so you've seen, I mentioned this before, you've seen Box growing at a fast rate for a long time and being almost ten times what it was when you joined. And so you've hired a lot of new engineers. And sometimes you manage them directly, sometimes as a senior manager, and what have you been doing to help develop new developers reach their full potential as quickly as possible?
Yeah, that's always an interesting challenge. You know, you get excited about bringing a new person in, and then how do you set them up to be successful? And I mean, we're still iterating on this. I think, as an engineering organization, we've gotten better. You know, when I joined, I got like a printed out page of information that I was supposed to work off of that had multiple mistakes in it. And I was, I was pretty nervous because it was, you know, my first day at this new job, and you know, what can I ask? And is this going to be a silly question? You know, all new hires have these challenges.
So we've definitely invested more in our onboarding experience since then. In a way, I think it's almost more important to onboard as a member of the team. And so trying to connect to the culture, how we do things, what's expected of you, and then connecting to the actual humans that you work with. Because, again, creating as much of that environment for being able to ask questions, and get insight and get input, I think is a big differentiator in onboarding success. And you know, there's a lot of difference between people. Some people feel more comfortable going in and asking questions and being overly confident, and others are maybe a bit more nervous and worried. And so, trying to put some structure around that. Like we do pretty standard things like having new hire mentors and having a buddy system.
Another thing that happens and this is another focus point for us. Particularly when teams grow or - and when the code becomes more and more complex - and then its modules become, you know, more and more complex themselves and so on. Knowledge silos are created and then are broken. So, like, there are two aspects here that are interesting to hear from you. One is how do you feel about knowledge silos? Are they a bad thing? Or not necessarily? And once you decide to break a knowledge silo, how do you go about doing that?
Clearly, knowledge silos are problematic, especially if they're siloed to an individual person or a very small number of people, because then if that person, you know, walks out the door to their next adventure, or, or is just out for a period of time, like you don't want to have - I like to think of teams as systems, right? So you don't want to have a single point of failure in your system. Having said that, through that same system’s lens, you do want to have separation of concerns. And so I think sometimes you can get - I've definitely made the mistake in the past of trying to say, hey, we don't want to have silos. So now everyone needs to know everything. And that is also limiting because it stops. As you grow, you'd sort of need to find that right point where you can let people specialize a little bit and sort of be able to go deeper in a particular area. And then maybe they don't have to know as much about other things so that they can focus more.
So it's sort of - you start from a very generalist team, where everyone kind of knows a little bit of everything. And then, as you grow, you have more people to focus - you also have bigger challenges that require more focus. So it's sort of a process of some - to some degree specializing over time. I feel like I learned this sort of in a reverse situation. I - one of the first projects I worked on at Box was together with the first engineer that had been hired at Box. And we had partnered on a sort of evolving this system that he had originally built himself. And towards the end of this project, he moved to work on something completely different. And he sort of had this moment where he came to me, and he said, "Tamar, this is my baby, you now own this baby. Good luck." And from that point on, it was very impressive. Any question that he got, he would not answer. He would reroute that person to me. But he told me I could ask him as many questions as they wanted.
And so he sort of forced - like he forced the organization to reorient to talking to me, which already is a big difference, right? If you're the person that knows the most about something, and you're always going to answer all the questions, and everyone's always going to go to you, then you're also building up more of a perspective through that process of talking to people and understanding their questions and engaging with them. And so he sort of forcefully - like rerouted that to me, but then provided me support, so he didn't leave me hanging. And I thought that was such a good pattern.
Yeah, it sounds like an excellent methodology. It sounded like you approach the issue of when knowledge silos are bad through the lens of risk, right? Like business risk? Is that a good approach to understand if the knowledge silo that was created is actually damaging or might be damaging?
Good question. I think it's, it's, um, it can manifest in both ways. So there's sort of the risk one that I described, maybe on sort of knowledge being concentrated to too small of a number of people. But there's also other instances where knowledge silos just slow you down, where you do actually have a larger number of people that need this information - the way things are set up right now. And then, if it's concentrated in too few people, then that just becomes a bottleneck.
There is something though about - you want to cultivate having some sort of almost like organizational historians where they know - they've been around for a while. I acknowledge I'm one of those at Box with it. Thankfully, there's others where they can sort of give that context on, like, how did we end up where we ended up? Like, why are we here? What choices did we try? And it's not that we can't redo them? Like, perhaps some of the constraints are no longer correct. Some of the goals are no longer correct. So we absolutely should be rethinking and reevaluating past choices, but also not just repeating them without the context. And so I think having some of those people that can contribute to conversations and inform on sort of past choices is very valuable as well.
Okay, so, you know, if you have an idle volatile, you need to break or a methodology that needs fixing, or an onboarding plan that needs creation or other situations where, you know, you're trying to create new habits, or trying to install new procedures, this can be painful. But also it's necessary. So, you know, how do you deal with, you know, with specifically - with engineers that you know, sometimes don't appreciate change? How do you deal with those challenges?
Well, I think engineers, in general, we like to solve for leverage. Most of us don't like to repeat the same thing ad nauseam. So and that's often the time where it's, it's right to invest in something. Like, if you're only onboarding one person a month, maybe it's fine to have that via a custom hand-holding process. But if all of a sudden you're onboarding, you know, five people a week, then it's gonna get tired really, really fast.
And so I think what we try to do is - assuming you're going to have sort of a manual first instantiation, see if you can record it, write it down, document it in some way that we can then iterate on. Every so often, you'll have a more specific effort around, you know, let's create more of an onboarding artifact or training artifact. And you set that as the goal in and of itself. I think some people like to work on those things more than others. So there's also an element of like finding the teachers on your team.
But I do think all of us, no matter who we are, like, we're always onboarding, answering questions, doing things like that. And so giving the team the tools where they can sort of put in their insights, and then have that be referenceable by the next person, and then empowering everyone to edit those, like making that not precious. So like we've experimented with - you know everything from like, obviously code documentation and confluence pages and whatnot to leveraging things more like StackOverflow with like, question and answer format, knowledge repositories, recordings of toxin presentations, creating a place where if I'm doing this once, can I make it so that it can be reusable the next time? And then, for the next person, can they be empowered to go in and edit it? Gives sort of that iterative process.
And so the last question for today, I guess, would you know, and this is a good segue is, you know - what's like the best thing to keep engineering teams happy and motivated?
I mean, I think it's back to - you asked me what I do, right? I think all of us want - and I include myself in this, right? We want to work on interesting, meaningful challenges with an opportunity to sort of grow and develop our individual skills. And with a team that we like, with the people that we like working with. Not necessarily, like as best friends. Like, I think that's not, that's not a scalable concept. But being a part of a good team where you know, you're going to come together to deliver the value, and you're going to support each other in that process and support each other as humans. I think that's what we're looking for.
And so I think, happy engineers, again, they need to understand why the work they're doing is valuable. Like it needs to matter. It needs to be relevant to what we're building in the business. And that's one of the main ways that I think managers can - because at any level, right, we need to contextualize how was what we're doing important. And if it isn't, then that's a different problem that you also need to solve, right? You need to make sure your team is working on something important that they know why. And then being able to take on bigger challenges and grow and develop and having a good environment to do that within. So I think that's a hard mix, but also what we're all I think striving to create for our teams.
It also closes the circle from the start of our conversation very well. So thank you. That's all the time we have for today. Tamar, thanks again for coming.
Thank you very much. It's fun.
Thank you everyone for tuning in. And I hope you'll join us for our next episode to find additional episodes and full transcripts or if you'd like to be a guest on our show, find us on our community page at Swimm with a double m dot io. Bye for now.