Attracting and Retaining the Best Engineers as You Scale with BOX and Plato

Please welcome quan huang, CEO and co founder at play doh and jeffrey kweisser, co founder and svp engineering at box. How's it going? Hey dude, let me.

Sure. Hello everyone. It's a great honor to have you, Jeff.

Great to be here.

Yes. Actually to tell you a bit more about how I met Jeff at plato. We are building a community of engineering leaders. All the best engineering leaders in the world, in the valley, in the world, are in plato. And as you can see, one of them is Jeff. And we have hundreds and hundreds of engineering leaders in the community and we have hundreds and thousands of stories. And when I asked Jeff about some tips, some stories, some things you can teach, you can learn and you can share to the engineering leadership community, he told me about this special thing I like a lot. And we are going to dig in a little bit about what he called the pyramid of needs of engineering organizations. So here we go. What is this pyramid? Can you tell me a bit more about this pyramid? What does it mean?

Totally. And before we get just right into the pyramid, let me just say this because we're here to talk about building out really high quality engineering teams and how you bring in talent and attract and retain them. And I think the thing to keep in mind is that actually building a great engineering organization from the perspective of actually growing it is no different than just user acquisition. So what you really want to do is make sure you don't have a leaky bucket because the worst possible thing is that you have a high throughput churn loop of engineers that are coming into your organization and they're exiting that organization. And so this is kind of a model that I put together about 18 months ago as I was starting to lead our engineering team at BOX to kind of think through what is the dependency graph, what's basically the maslab's hierarchy of what it actually takes to build a really highly functioning, highly retentive and kind of executing engineering organization. So this is what this kind of general view is. So let me just quickly buzz through the different levels and we can go deeper from there. So the first level is your people leadership team and your technical leadership team. And this is at the lowest level of the pyramid. Not because it's like, oh, you're so great, you're a leader. It's that if you've ever worked in a company that has dysfunctional leadership, you have seen that everything is basically fighting gravity. So if you don't have that kind of core kernel right, everything else that you try and do will be way more difficult than it fundamentally needs to be. So that's why that's at the bottom. The next is org health. If you have an unhappy team or people are quitting or high attrition or they're not clear on the mission, good luck actually getting to the sort of top level which is the outcome of shipping product. And we'll get in deeper in all of these. And then now you have the right kind of leadership, you have a healthy organization, but you still need to know where is the ship pointed out. So you need to have a crystal clear strategy. Then you need all the backend systems that are not at all, that are just kind of the plumbing work. But fundamentally if you don't have these systems, everything's way more difficult than it needs to be. And if you do those four things, the hypothesis is then in general you're going to be shipping really great product, delighting your customers. And that's kind of the overall model.

Yes, that's all we want to do to ship great products. So can you tell me what does it mean? What is a pyramid? Does it mean you have to do one thing after the other in sequence? Do you think like what does it mean to be a pyramid?

Yeah, it's a great question. It's not the case at all that you should think about this and say, I will only focus my optic on one level and then I'll go up to the next level and then I'll go up to the next level. Because your organization is way too complicated to do that. I think of it more as a diagnostic tool which is if I have problems up here, can I trace them back to some lower level? And that tends to be a really helpful way of thinking about this. And your goal should just be kind of progressively work on as many of these and try and make the whole pyramid effectively green from your perspective and set up a super high functioning organization.

Okay, cool. In a company we have plenty of stakeholders, co founders, CEOs, really annoying co founders and CEOs running around, product managers, engineering managers, engineers. So do you think that some should focus more on certain layers of the pyramid and others should focus on others, or do you think we should all see that as a global diagnosis?

Yeah, I think I don't know if I'll directly answer the question. I would say I think this kind of organizational model will work for any org. So if you're a marketing team, your top level might be build pipeline. But fundamentally the same sort of steps are applicable for how you think about building a really highly effective Organization.

Cool. So let's get started into the first layer. So you call it the leadership, right?

Yes.

So what do you mean by when I ask you about this layer? The most important thing you told me was that you need to have a good balance between EQ and tech.

Yes.

So what does it mean? Why do you think we are underestimating one among the other against the other, et cetera?

What, what do you think? Well, I think this is a failure mode that I see relatively frequently, which is I'm just going to hire someone who's a brilliant technologist and pay no attention to the EQ and the people management side. That pattern will get you so far and at some point you will hit the natural sort of scale limits of what that leader can do that does not have the right EQ and eq, by the way, is emotional quotient. So think of the ability, think of the equivalent of IQ on the people side. And so if you don't do that, you will have a leader who I can guarantee will not scale. And so if you're thinking not just about how do I solve from 0 to 10 engineers, but how do I go from 10 plus 10 to 50, 50 to 100 and 500 and 1000 and beyond, the EQ component of this becomes incredibly important. And so that's fundamentally what this means.

So we tend to underestimate EQ massively. Okay. Why?

So it's just super compelling to, I think you see someone who seems like they're again, they're a great technologist. You miss the kind of big picture and it just blows up in your face later.

And do you think it's the case in all stages? When you are early stage, you are more underestimating this than when you are later stage. You've seen all the stages in 10 years, right? From four co founders to 450 engineers, something like that. So do you think that it's a matter of stage and you need more this type of person for early stage and this type of person for later stage?

It's a good question, I would say broadly, I think, about a model where you could literally plot the 0 to 10 exploratory phase and the 10 to 50, maybe getting some product market fit and 50 to 200 and 200 to 500. You could absolutely think about the faces of your company as you're looking for what's the right leadership and kind of various capabilities. So that's definitely real. I think this is a kind of durable quality which is at the end of the day, if you don't have a high EQ leadership team, things are not going to go well for you.

Ok. You seem to be good balance between EQ and tech, right?

Hopefully.

How did you do that? What's your secret?

Tell them. Yeah, what is my secret? So on the technical side, I was very fortunate to start a box where there was basically no infrastructure built. And so I was the one guy in technical operations building out our data centers, our network, our storage, our systems, our databases, our security, our compliance, the whole stack. And so I think anytime you can own a problem like that completely end to end, it will just push you to get. Not just learn those areas, but get good at learning, which itself is a skill. This is probably a neat plug for PLATO as you guys are a mentorship platform. So that's one piece is you just actually need to have the app ads and do this and then you need to make sure that you actually have great mentors along the way who can fundamentally help you kind of learn some of the stuff you're not going to learn organically. So picked up the tech side by just doing it all and picked up the leadership side by making a huge amount of mistakes and having great mentors to learn from.

Doing a lot of mistakes. Having mentors.

Yes.

Okay, cool. Do you want to go to the next layer?

Sure.

So when I ask you about what is the next layer, you told me that it's really important to have a healthy organization. And then I was a bit confused about how is it different than having good leaders. Can you tell me a bit the difference about those two layers?

Yes. So I think of the leadership team is your core set of people on the people in the technical side who are responsible and accountable for driving this. And then I think about maybe you have 50 or 100 or 200 engineers in a team or trying to solve some problem. And the org health there is incredibly important because if people again are unhappy or unmotivated, you are not going to be shipping amazing product that's going to delight your customers. So here is my key message. At a certain scale, this is not. Org health becomes something that can no longer be accidental and happen by happenstance. If you actually want to drive Org health, you have to think about it in a programmatic way. So. So some of the tools that we use are literally a dashboard where we go scrum team by scrum team. And for every scrum team we ask the question, do they have a great manager? Do they have a great tech lead? Because if you don't have a tech lead you're probably building the wrong stuff architecturally. Do they have a great product manager and product counterpart? If you have a product manager who's not the right person or right fit for that, the team's going to be super unmotivated as you proceed to bumble and build the wrong things. Does the team have a local mission? So these are all the things that we literally look at Scrum Team by Scrum Team to make sure that that is all kind of locked down. And we do quarterly kind of culture pulses and surveys. We make sure that we do this. We talk to people and get just kind of ad hoc data. So fundamentally, you have to own this and you have to drive this end to end. This can't just be a thing that happens for free.

A local mission.

Yes.

That is interesting. Yes. How many Scrum Team do you have?

Maybe 50 or so.

50. So each single one of those team has one local mission?

Yes.

Can you tell me?

Yeah. So let me differentiate local mission versus kind of global mission. So at Box, our company mission is power, how the world works together. So we think about, there are a huge amount of knowledge workers. How do they go out and actually how do they work and get their jobs done? So that's the company's overarching mission. Then we have a messaging team and a database team and a file system team and a caching team. And those teams need to also be tied into what do they get up and start thinking about every morning. And so we have a messaging team, for example, that manages all the events flowing through Box. And their local mission is basically be the veins of. Of all the information flowing through Box. So that rallies them as a team and that connects into. It's very clear how that mission directly ladders to. I'm actually powering how people work together.

Okay, so how did you come up to this ideal composition of team? You have engineering manager, a product manager, tech lead, a bunch of engineers. So this is what you think is the ideal team, right?

Sure. These are some of the properties. Yeah.

Okay, cool. How did you come up with that? The best team.

Yeah, I think you end up. Some of this is somewhat common sense. Some of this is you just have to touch the burner and you see, this is what happens. This is how an engineering team goes off the rails when the product manager is not the right person. This is how you go off the rails with the wrong manager, and this is how you go off the rails without a local mission. And so a lot of this is. Some of it's intuitive, some you Just have to experience it firsthand and then you kind of burn that in memory wise.

Cool. So be programmatic about organizational health.

Yes. And there's one other thing I'd add on this. Programmatic about organizational health. Another kind of common failure mode. And I see this a bunch. One of my kind of favorite leadership truisms is that conflict aversion is the root of all evil.

Conflict aversion.

So when you have a problem in your organization or your team, you know you need to deal with it. Whether that is, that's people that aren't getting along or there's a lack of clarity, roles and responsibilities, or something like that. If you fail to deal with that in a timely way, you're abdicating and you are pushing that problem to be dealt with by your team and you create festering problems that are going to slow down and disempower and otherwise kind of frustrate the whole team. And so part of being programmatic about org health is you have to just have a no fester policy. And as soon as you spot problems that could go off the rails, you have to swoop in and make sure that they get handled or make sure the right person is handling them.

And I guess the most difficult thing is not to avoid those complex.

Yes.

How do you do that? How do you encourage your team not to avoid that?

Yeah, how do you not? Actually, I think in most cases it's human nature to kind of avoid conflict.

It is.

We've actually handled that by baking it into our core cultural values at box. So one of our, literally one of the core box values is be candid and assume good intent. And that means go give crisp, clear, real time feedback and assume that the person is coming from a great place as they're having that conversation. That's something that as boxers are coming into our kind of our onboarding we're already talking about, we're repeating in all hands. Fundamentally, we are living by our values. And as a side note on cultural values in general, if you're not completely living by your values, they mean nothing and they're worthless. So fundamentally, we place a lot of emphasis on how do we actually live by these values.

Cool. All right, so here we go. We have a healthy org. And when I asked you about the next layer, so you told me that when you have this, it's really important to build a good strategy. Not only to build this good strategy, but also to distribute and to tell about this strategy to all the team. So everyone embody it, right?

Yes.

So I guess I have two questions. The first one is how do you build this strategy? And the second one is how do you distribute it to the team?

Yes. So on the how to build a strategy. So volumes have been spilled over this, so won't fully cover that. But I think the critical piece is you have the right people now from your leadership team. You've solved some of the other layers. You understand the market, you understand your customers and the problem you're trying to solve. As you're going through the construction of your strategy, you really want to make sure that you have buy in from some kind of key people in your company. And so another kind of leadership truism is that people tend to support what they help create. Okay, so if I participate in something I'm way more interested in, I'm bought in, I'm way more interested in advancing it. And so you want to make sure you have the right level of balance of people that are actually getting involved and kind of thinking through, through your strategy. So that's piece one, we can go deeper in that. But piece two, where I see people fail all the time is can I.

Have a question about this? So does it mean that how many engineers? 450. So you include every one of those four engineers.

Just the physics of it are you can't include everybody, but you have to kind of think about who are the key nodes and the key people that are going to drive something and be able to represent the strategy and why you made a certain decision. Okay, yeah, yeah, cool. But yeah, as I was saying, the kind of part two and I see people fall down on this all the time is okay. It's not enough to have identified a cool strategy and then send an email about it. You are not done at that point. And the most effective kind of approach to take here is to be go shout it from the rooftops and do that via multiple channels. So you need to end up with emailing your strategy in a quarterly wrap up and the all hands kick off. You need to go physically be present at your all hands and go reiterate the strategy with some inflection on it. I personally, I rotate through all of our scrum teams every quarter or two and I just go do a casual lunch and I'm reiterating and hitting the same points. If you don't go multi channel, half of the people aren't going to read your email in the first place at some sort of scale because of the total email volume. If you don't go multi channel, you will fundamentally miss your audience. So it's not just enough to go have a kick ass strategy, you have to go actually shout it from the rooftops and deliver it.

Yes. Casual lunch.

Yes.

So you have 50 teams. So here we go, 50 weeks.

Yes.

Once a week.

Yes. More than once a week.

Okay, cool. And so when I also ask you about the challenges of building a strategy and you told me that the natural way of engineers is thinking about the technology and thinking about the strategy before understanding the product.

Yes.

So what's your point of view about that? And how can you increase totally.

Yeah. So this is another kind of common failure mode. I think you can have really well intentioned engineers who have a propensity to want to solve very hard problems. And it's about making sure you have alignment on solving the right problem. So whenever we do this, we try and lay out first our product strategy. That's your requirements document. That is the thing that as engineers you need to go get excited about and figure out how to back solve. But you can't lead with a tech strategy that's just going to let you do awesome cool, whiz bang things that is completely not tied out. So first, start with a crystal clear product strategy, use that as your requirement spec and then back solve for. And this implies the following capabilities we need if we're going to be. If our product strategy is be blazing fast globally, that will imply a piece of your technical strategy which is be on public cloud, be on the edge and use multiple cloud providers as an example. Don't just do part two because you think it's cool.

So this is something also you try to embody in your culture.

Yes, yes.

And so when we have this strategy, you build it, you try to employ the right person and you distribute the strategy and you build it the right way. And the next layer is about investing in systems, tools and everything. I'm having as a co founder, a business co founder argument with my CTO all the time about this. Should we spend time more on tech depth? Should we spend time on environment development? Should we spend time off this? It doesn't bring anything to the company. Do you want to spend this amount of time? And when I was talking to you, you had a great point of view about that and you think it is real. It is real.

Yeah. So maybe just a quick pulse check. Who in the last two weeks has had a conversation about the balance between, between tech debt infrastructure and then building shipping product? Okay, so okay, everyone. Basically half the people. Yeah. So I think this is completely timeless. Here are a couple things I'd say about this one is that I think so tech debt is real and making sure that the kind of environments that you're working in is super real. One of the problems that we have is that it is mostly visible to your engineering team and not to your business team. So the analogy I would think of is imagine you're working at like a. You have a workbench and imagine that it is completely pristine and your screwdrivers are here, and your label maker is here, and your soldering iron, I don't know what you're making, is all here. And it's completely, perfectly laid out. You could work pretty quickly in that environment as a workbench. And then if you did the contrast on the other side of that and you think about a complete rat's nest of wires and problems, and literally you can't even find your microscope or your soldering iron or whatever that is, that's going to be incredibly difficult to actually get work done there. And so the problem is that sometimes technical environments end up in that kind of set second mode where things are totally sort of spaghettified and the only team that that's really visible to is the engineering team. So your engineering team will be shouting to you saying, like, this is crazy bad. We have to fix this. This is awful. We can't go do the next thing you want us to do. And everyone else looks around and is like, I don't know, you just shipped the feature last week. Seems things probably seem fine. Why is this necessary? And there's just actually an optics and a transparency problem there. So you want to have an engineering team that can actually understand how to translate that so that the rest of the business can, can get. Actually, there's some real problems here. Here's three examples of the kind of problems we're running into. And you just need to be crystal clear on communicating. Just so there's a business case for why you're investing here. So that would be sort of one piece of this and just a mental model for how to think about this is it's fundamentally not visible outside of engineering typically.

And this is why you need to have EQ people who can explain this and communicate.

Totally great communicators really, really help here on the leverage side. And let me give you one more example on the systems front of just why you can have everything else right in your organization. You can have the right leadership team, you can have the right strategy, you can have the right people. But at some point a couple years ago, there was a point in Our history where our release pipeline was massively flaky and we were failing 50% of our releases, they just wouldn't actually like the machinery to deploy them wasn't working. So you can have everything set up and going. Right. But imagine how frustrating it is as an engineer to actually do a one or two dice roll and see if you're going to be able to release code that day or that hour. That's massively frustrating. So all these things kind of compound, and that's why I can be be really, really worth it here, investing on the leverage side to be able to fundamentally move faster.

Any other tips for engineering leaders, how to convince CEOs and business leaders to we need to spend time and invest in this.

I think it's a negotiation. And so I would almost give the contra advice, which is you also see the engineering leader who is ready to go die on a hill. And like, I have to do this. And there are times when there are nice to haves. And so I think if you approach this as we're same team, same hat, let's go solve for what we have to do as a business and you kind of negotiate on here's the things we're going to do and not do with your product org and the other people that are stakeholders, that's probably the best path. You can also kill a company and kill a product by just only going and investing in the systems and the leverage and never actually shipping anything. So you really fundamentally need to find a balance here.

And that's the most difficult thing, right, to find this balance?

Yes.

All right, so how does all of this come together?

Yeah, in general, maybe someone can falsify this hypothesis, but I think in general, if you get the four kind of layers to green, if you have a great leadership team on the people on the tech side, if you have really healthy organizations, you have a clear tech strategy and product strategy and you have your systems right. I think you get the top piece for free. I think organically, you're building really great product and shipping it to hopefully happy customers. And if anyone actually gets the four bottom layers green and you do not, you're not kind of kicking ass organically on the top layer, please come tell me. I'd be super curious to hear what's going on, but I'm pretty confident that if you nail those things, the rest you get for free.

And the rest of your organization, and the rest of the engineers in your organization know about this pyramid.

They know about this. This is something we talk about and we can Literally see the impact we've had in focusing in a disciplined way. If we reconnect back to. You really want to think about this as an acquisition problem and make sure you don't have a leaky bucket. You can literally see the impact of when you start to focus on these things, things, it will show up in your stats and your numbers. Around engagement, around retention, around hiring because your brand is improving. These things all flow from that point.

Do you think that any problem that happens to an engineering organization can be into one of those five layers?

That's a great question. I'm sure that there's like a meatier category I haven't considered. I think it's a generally good kind of guide.

Cool. Yeah, I love it. I love it a lot. I hope that it will help all of you to diagnose all your problems. So we still have five minutes. Do you want to add something?

Let me just turn the tables on you and ask you questions. Me?

Yeah, There we go.

Okay. So yeah, I don't need notes. Okay. So you are co founder at a company called PLATO and you guys do engineering mentorship. Yes. So what do you see from what is the most common set of questions or challenges that engineering managers, first time engineering managers are running into?

So, yes. So at plato, we are on a mission to help engineers become great engineering leaders. And the three type of problem we usually see are. One is career development. So should I go to management? Should I go to the IC track or is it management something for me or whatever. The second type of problem we usually see is people management. So how to get better at giving one on ones, how to get better at giving negative feedback or how the.

Root of all evil.

Yes. How not to. I have. Yes. People management. So all the skills that we as engineers haven't learned when we were at school or when we started our career and the third type of problems that we usually have in the platform are about people, product, sorry, product and process management. So scrum, Scrum. How to evaluate the technical, the difficulty of each task, those kind of things. And we can see that it's a pretty good balance between the three and all of the like. I can show you this because I think it might be interesting for some of you, all of the people who are VP of engineering at Lyft, director of engineering at whatever company you can see there, we have hundreds of them and they all have been experiencing that in the past and they can help. And you can help after 10 years at Box, from four to 450 engineers, I think you can help. And that's why we decided to build plato. Awesome. Cool. So one last word, actually. So we are partnering with Saster, thank you, the Saster team, to let us do that and offer you some sessions, some mentorship sessions with Jeff and many other engineering leaders tomorrow. So it's going to be tomorrow, Sastor, and many of them are going to come to help to talk 30 minutes with every single one of you who might need it about any problem you might have about engineering management or product management. So of course in 30 minutes we cannot tell you all our tips and secrets, but they can tell you in one on one and they can also, they will also animate group discussions about engineering management, about I'm a first time manager or I'm leading a team of engineers, I want to promote some of them to managers, et cetera. So I have plenty of topics. Go to that link and meet some great engineering leaders like Jeff. Thank you very much, Jeff. I think this pyramid will be really helpful to all the people in that room.

Thank you.

Thank you very much.

Thanks.