This session at SaaStr Annual 2018 featured Quang Hoang, CEO of Plato HQ and Jeffrey Queisser CoFounder and SVP, Engineering of BOX. They talk about the pyramid you need to have in your startup to attract and retain the best engineers as you scale.
Also, don’t miss out on discounted prices for SaaStr Annual 2019 tickets.
Transcript
Please welcome Quang Hoang CEO and co-founder at Plato and Jeffrey Queisser co-founder and SVP engineering at Box.
Quang Hoang: Hello everyone. It’s a great honor to have you Jeff. Yes. Actually to tell you a bit more about how I met Jeff.
Quang Hoang: Plato we are building a community of engineering leaders or 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 they asked Jeff about some tips some stories, some things you can teach you can learn and we can you can share to do engineering leadership community he told me about this special thing. I liked a lot.
Quang Hoang: 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?
Jeffrey Queisser: Totally and before we get it just right into the pyramid let me just say this because so you know we’re here to talk about building 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 they’re actually building a great engineer organization from the perspective actually growing it is no different than just user acquisition. So 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 the 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 Maslow’s hierarchy of what it actually takes to build a really high 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 your leader.
Jeffrey Queisser: It’s that if you’ve ever worked in a company that has dysfunctional leadership you’ve 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 into it. We’ll get in deeper in all 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. 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 is way more difficult than it needs to be. And if you do those four things the hypothesis is that in general you’re going to be shipping really great product delighting your customers. And that that’s kind of the overall model.
Quang Hoang: Yes. That’s all we want to do. Yes. To ship great products. So can you tell me what does it mean? What is a parent need? Does it mean you have to do one thing after the other, in sequence?
Jeffrey Queisser: 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 opera on one level it may not go up to the next level and I’ll go 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.
Quang Hoang: Ok. In the company we have plenty of stakeholders co-founders see you really know and co-founders and CEOs running around product managers entering managers engineers. So you think that’s some should focus more on certain the use of the pyramid and others should focus on the others. Or do you think we should all see that as a group?
Jeffrey Queisser: 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 marketing team your top level might be build pipeline. But fundamentally the same sort of steps are applicable to how you think about building a really highly effective organization.
Quang Hoang: Cool. So let’s get started into the first layer. So you call it the leadership right. Yes.
Quang Hoang: 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?
Jeffrey Queisser: Well I think there is a 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 you will not scale. And so if you’re thinking not just about how do I solve from zero to 10 engineers but how do I go from 10 plus 10 to 50 50 to one hundred and five hundred and a thousand and beyond the EQ component of this becomes incredibly important. And so so that that’s fundamental what this means.
Quang Hoang: So we tend to underestimate EQ massively. OK. Why so?
Jeffrey Queisser: So it’s just super compelling to I think see someone who seems like they’re again they’re a great technologist. You missed the kind of big picture and it just blows up in your face later.
Quang Hoang: And do you think it’s the case in all stages when you are in early stage or more investigating this than when you are a native stage you’ve seen older stages in ten years. Right from four Californias to 40 to 50 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.
Jeffrey Queisser: It’s a good question I would say broadly I think about a model where you could literally plot the zero to 10 exploratory phase in the 10 to 50 maybe getting some product market fit and fifty to two hundred and two hundred five where you could absolutely think about the phases of your company as you’re looking for what’s the right leadership and kind of various capabilities. So that’s 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 IQ leadership team things are not going to go well for you.
Quang Hoang: Ok. You seem to be you seem to be a good balance between EQ and tech right. How did you do that? What’s your secret?
Jeffrey Queisser: Yeah. What is my secret? So on the 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 and 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 as you guys are a metric shit platform so. So that’s one piece is you just actually need to have the app out and do this and they needed to make sure that you actually have great mentors along the way who can you can fundamentally help you kind of learn some of the stuff you’re talking learn organically. So I 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.
Quang Hoang: Having mentors. Yes. Okay.
Quang Hoang: You want to go to the next layer? So when I ask you about what is the next layer you told me that is really important to have a healthy organization. And then I like I was a bit confused about how is it different than having good meters. Can you tell me a bit the difference about these two layers.
Jeffrey Queisser: Yes. So I think the leadership team is your core set of people on the people the technical side who are responsible and accountable for driving this. OK. And then I think about maybe you have 50 or 100 or 200 engineers in a team we’re trying to solve some problem. And the org healthcare is incredibly important because the 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 help become something that can no longer be accidental and happen by happenstance. If you if you actually want to drive work health you have to think about it in a programmatic way. 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 asked the question do they have a great manager. They have a great tech leader because if you don’t have a tech lead you’re probably building the wrong stuff. Architecturally they have a great product manager and product counterpart. If you have a product manager who’s not the right person the right fit for that the teams can be super unmotivated as you proceed to kind of Bumble and build the wrong things. Does the team have a local mission. So these are all the things that we look at scrum team by scrum team to make sure that that is all kind of locked down. 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.
Quang Hoang: A local mission?
Jeffrey Queisser: Yes.
Quang Hoang: That is interesting.
Jeffrey Queisser: Yes.
Quang Hoang: How many scrum teams do you have?
Jeffrey Queisser: Maybe 50 or so.
Quang Hoang: 50. So each single one of these teams has one local mission.
Jeffrey Queisser: Yes.
Quang Hoang: Can you tell me some examples?
Jeffrey Queisser: Yes. So let me 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 fast track 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 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.
Quang Hoang: Ok. So how did you come up to this idea of completion of team. You have a manager, a product manager, tech lead and a bunch of engineers. So this what you think is the ideal team right?
Jeffrey Queisser: Sure. These are some of the some of the properties.
Quang Hoang: How did you come up with the best team?
Jeffrey Queisser: Yeah I think I think you end up some of this is somewhat common sense some of this is it’s just you just have to touch the burner and you see this what happens 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 intuitive some you just have to experience it firsthand and then you kind of burn that in memory wise.
Quang Hoang: So be programmatic about organizational health.
Jeffrey Queisser: 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 favorite leadership truisms is that conflict diversion is the root of all evil. 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 is a lack of clarity of roles and responsibilities or something like that. If you fail to deal with that in a timely way you are pushing you’re advocating 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 to make sure the right person is handling them.
Quang Hoang: And I guess the most difficult thing is not to avoid this complex.
Jeffrey Queisser: Yes.
Quang Hoang: How do you do that. How do you encourage your team to avoid trouble.
Jeffrey Queisser: How do you not actually. Yes I think in most cases it’s human nature to kind of avoid conflict. 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 is 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 it all hands. Fundamentally we’re 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 if we fundamentally we place a lot of emphasis on how to actually live by these values.
Quang Hoang: All right. So here we go. We have a healthy org, so, can I ask you about the next layer?
Quang Hoang: So you told me that when you have this it’s very important to build a good strategy not only to build this good strategy but also to distribute. Tell about this strategy to all the teams so everyone embodied. Right. So I guess that 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?
Jeffrey Queisser: Yes. So on the how to build a strategy, volumes have been spilled over this or we haven’t fully covered that but I think the critical pieces you have the right people now from your leadership team you’ve soft on 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. OK. So if I participate in something I’m way more interested in a body in a way where it should and advancing it. And so you want to make sure you have the right level of balance the people that are actually getting involved and kind of thinking through your strategy. But so that’s piece when we go deeper in that but piece to where I see people fail all the time is Can I have a question about this.
Quang Hoang: So does it mean that you include every one of your engineers.
Jeffrey Queisser: You like 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 gonna get to drive something and be able to represent the strategy to why you made a certain decision. Okay yeah yeah. But yeah as saying that 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 sent an email about it. You’re not done at that point. And the most effective kind of approach to take here is to be go shouting from rooftops and do that by a multiple channels. So you need to end up with emailing a strategy in a quarterly wrap up and then 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 to a casual lunch and I’m reiterating and hitting the same points. If you don’t go multi-channel half of the people are going to read your e-mail in the first place at some sort sort of scale because of the total email volume. If you go multi-channel you will fundamentally miss your audience. So it’s not just enough to go have a kick ass strategy if to go actually shout from the rooftops and deliver it.
Quang Hoang: This casual lunch.
Jeffrey Queisser: Yes.
Quang Hoang: So you have 50 teams. So here we go 50 weeks. once a week.
Jeffrey Queisser: More than once a week.
Quang Hoang: Okay cool. And so when I also asked you about the challenges of building the strategy and you told me that the natural way of engineers thinking about the technology and thinking about the strategy before understanding the product. So like what’s your point of view about that?
Jeffrey Queisser: Totally yeah. So this is another kind of common failure. Yes 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’ve alignment on solving the right problem. So whenever we do this we try and lay out first our product strategy. That’s your that’s your requirements document. That is the thing that is engineers need to go get excited about and figure out a back solve. But you can’t lead with a tech strategy that’s just gonna let you do awesome cool whiz bang things. That is completely not tied out. So first start with a crystal clear product of energy use that as your requirements spec and then back solve for. And this implies the following capabilities we need if we’re going to be if our our product energy is B blazing fast globally that will imply a piece of your technical strategy which is beyond public cloud beyond the edge and use multiple cloud providers as an example.
Jeffrey Queisser: Don’t just do part two because you think it’s cool.
Quang Hoang: So like this is something you also try to embody in your culture?
Jeffrey Queisser: Yes yes.
Quang Hoang: And so when do we have this strategy. You build it. You try to imply a direct version and you distribute the strategy and you build it the right way and the next layer is about investing in systems tools and everything like— I said I am having like as the co-founder a business co-founder argument with my CTO all the time about this. ‘Should we spend tech dev’ or ‘spend time on environment development’? ‘Should we spend time on this or that’? It doesn’t bring anything to the company.
Quang Hoang: Do you want to spend money some other time. Right. And when I was talking to you you had a great point of view about that and you think it is real it is a view.
Jeffrey Queisser: Yeah. So. So maybe just as quick pulse check. Who. Who in the last two weeks has had a conversation about the balance between tech debt, infrastructure and then building/ shipping product. Okay. Okay everyone basically happy people. Yeah. So I think this is completely timeless here. Here are a couple of things I’d say about this. One is that I think so tech debt is real and making sure that the kind of environments 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 in and imagine that it is completely pristine and like your screwdrivers are here and your label maker is here and your soldering iron I don’t know you’re making is all here and it’s like completely perfectly laid out. You could work pretty quickly in that environment as a workbench. And then if you did the contrast and the other side of that and you think about a complete like rat’s nest of wires and problems and like literally you can’t even find your microscope your side are going to remember that is that’s going to be incredibly difficult to actually get worked on there.
Jeffrey Queisser: And so the problem is it’s sometimes technical environments end up in that kind of second mode where things are totally sort of spaghetti-fied and the only team that that’s really visible to is the engineering teams their engineering team we’ll be shouting to you saying like this is crazy bad. We have to fix that this is awful we can’t go to the next thing you want us to do. And every else around is like I don’t need to the feature last week like seems like this 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 get it. Actually there’s some real problems here. Here’s three examples of the kind of problems are running into and you just need to be crystal clear on communicating just so there’s a business case for wire investing here. So that would be sort of one piece of this. And just a metal model for how to think about this is it’s fundamentally not visible outside of engineering typically.
Quang Hoang: And this is why you need to have EQ people who can explain this and communicate.
Jeffrey Queisser: 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 you can have everything else right 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 of years ago there was a point in our history where our release pipeline was massively flaky and we were failing 50 percent 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 like do one of two dice roll and see if you’re gonna be able to release code that day that hour that’s massively frustrating.
Jeffrey Queisser: So all these things kind of compound and that’s why it can be really really worth if you’re investing on the leverage side to be able to fundamentally move faster and your ready for engineer leaders how to convince CEOs and business leaders do we need to spend time invest in this I think it’s a negotiation.
Jeffrey Queisser: And so I would always give the the contra advice which is you also see the engineering leader who is like ready to go die on a hill. And like I have to do this and there are times when there are nice to have. And so I think if you approach this as less 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 gonna do and not do with your product organ and the other people that are stakeholders. That’s probably the best path you can. 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.
Jeffrey Queisser: So you really fundamentally need to find a balance here.
Quang Hoang: And that’s the most difficult thing right? Find this balance.
Jeffrey Queisser: Yes.
Quang Hoang: And all right. So how does all of this come together.
Jeffrey Queisser: Yeah I in general. Maybe someone can falsify this hypothesis if but I think in general if you get the four kind of layers to green you have a great leadership team on the people on the tax 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 we’re going to get the top layer. Please come tell me I’ll be super curious to hear what’s going on.
Jeffrey Queisser: 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.
Jeffrey Queisser: They know about 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 what 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. 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.
Quang Hoang: Do you think that any problem that happens to an engineering organization can be sorted into one of these five layers.
Jeffrey Queisser: That’s a great question. I’m sure that there is like a meteor category I haven’t considered. I think it’s a it’s a generally it’s a generally good kind of kind of guy.
Quang Hoang: Cool. Yeah I 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. You want to do want to add something a little?
Jeffrey Queisser: Let me just turn the tables on you and ask you questions.
Quang Hoang: Me. Yeah. OK.
Jeffrey Queisser: So are you a co-founder at a company called PLato. And you guys do engineering mentorship. So what do you see from what is the most common set of questions or challenges that engineering managers first time management managers are running into.
Quang Hoang: So yes at Plato we on a mission to help engineers become great engineers leaders and the three types of problem we usually see are. One is career development. So should I go to management should they go to do IC track or is management something for me? 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 not to lie. So, people management. So like all the skills that we as engineers haven’t learned when we 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 product and process management. So a scrum, how to evaluate the techniques, or the technical difficulty of each task. Those kind of things. And we can see that there’s a 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 V.P. 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.
Quang Hoang: So thank you. Thank you very much.
Jeffrey Queisser: Thanks.
