Building a Stellar Engineering Organization with DataBricks, Salesforce and Apollo (video + transcript)

Scott Beechuk, Partner at Norwest Venture Partners, brings together world-class SaaS engineering leaders Claire Hough, Vijay Gill and Weiping Peng for a dynamic conversation on where SaaS technology is headed, how to build top performing engineering teams and what it takes to lead in today’s high-velocity engineering environment. Claire Hough is the VP of Engineering at Apollo and has nearly 20 years leading engineering and development teams at Udemy, Napster, and Netscape. Vijay Gill is the head of engineering at DataBricks and brings engineering leadership experience from Google, Microsoft, AOL, and Salesforce. Weiping leads the engineering team as the top software architect for Salesforce Service Einstein, the company’s customer service AI platform.

Want to see more content like this? Join us at SaaStr Annual 2020.

Scott Beechuk | Partner @ Norwest Ventures

Claire Hough | VP of Engineering @ Apollo

Vijay Gill | SVP of Engineering @ Databricks

Weiping Peng | Software Architect @ Salesforce

FULL TRANSCRIPT BELOW

Speaker 1: Please welcome Scott Beechuk, NVP partner, Vijay Gill. Databricks SVP of Engineering. Weiping Peng, Salesforce software architect, and Claire Hough, Apollo, VP of Engineering.

Scott Beechuk: All right, well thanks everyone. I appreciate you joining us for this session. This is going to be arguably one of the most energetic sessions of SaaStr and so I’m sure you won’t be disappointed. We are very lucky and fortunate to be on stage with some very talented engineering leaders. And you can see with their backgrounds, we’ve got a lot to talk about here.

Scott Beechuk: Let’s just, let’s jump right in. Vijay, Claire, you built some incredible engineering organizations in your careers. What does it take to hire and retain the best engineering talent in the world?

Vijay Gill: Oh boy. We could have started off with an easier question, but …

Vijay Gill: A couple of things I want to point out here. One is, especially at a startup trying to compete against Bay Area offers from Google, Facebook, Amazon, Linkedin, Twitter are, is, is playing to their strengths. I always thought that we should play to our strengths, which is try to play asymmetric hiring strategies. Normally focus on things like differential impact. I tell this to new college grads all the time. There’s like 10,000 of you joining Google every other year. Whether you’re join or not. Nothing’s going to change at Google, for example. Great company, I used to work there. But you join here, you will be a measurable fraction of the engineering work. Your ownership and your impact and scope, you will grow faster, so you’ll have more differentiated impact.

Vijay Gill: And the second thing that we’ve done is go compete in a geographical distributed fashion. For example, there are certain countries, for example, where a lot of these large companies aren’t there, so try and build up engineering offices there.

Vijay Gill: Claire?

Claire Hough: The strategy that I’ve been taking lately at Apollo is actually we have a distributed teams. We have half of our engineering team here in San Francisco, but everybody else is all over the world. I have an engineer in Mexico, Amsterdam, Finland, Australia, et cetera. You find talent where you can, and given this day and age with all the connections we have and all the way you communicate with your teams, there’s no reason why you have to hire here. When you get the right candidate, you have to speak their language, whatever that language may be, because engineers are motivated by different things and you have to find what is it that’s motivating them. And when you can match that motivation with what you’re working on, that’s when you can actually be competitive and make the hire.

Claire Hough: As a small company, it’s always hard for us to hire. If the candidate’s going to go to Google, Twitter, Airbnb, they’re not going to come to us, if that’s their goal. We need to look at what’s their motivation, what’s your goal, what kind of impact do you want to have and what motivates you.

Claire Hough: I was at Udemy about until about six months ago. I was there for five years growing the organization from 13 engineers to 150 engineers. And we built 25% of the team in Dublin, Ireland, and the other 25% in Ankara, Turkey, where there’s top three technical universities. And, so you have to figure out what is your strategy there, and Udemy is a e-Learning marketplace. You should all be taking a course on Udemy. They have SaaS offering. Your company should be signing up.

Claire Hough: Udemy, our mission was, we improve lives through learning. That mission, if that speaks to somebody like “I want to be part of that mission,” then the hiring gets a lot easier. And then you need to speak to what their motivations are, how we can leverage their skillset to really build our platform.

Scott Beechuk: You said something in there that was really interesting. I want to go off script a little bit here. You mentioned remote teams. And I think you know whenever building engineering, a lot of different orgs in tech companies, particularly in modern tech companies. I ask Weiping because you’re with Salesforce. And Salesforce deals with remote engineering teams, both developers and engineering management in remote offices, sometimes in time zones that are on the other side of the clock. What’s the best way to communicate and keep the right cadence with remote teams?

Weiping Peng: Well, that’s a tough question, but at the same time I think it’s actually, there are many ways to deal with it. One thing, it’s almost like a culture-wise, make sure you are very inclusive. When people are remote they’re at a disadvantage, for sure, because when you have hallway conversation and all that, you might be just missing that one piece, communication. Don’t even worry about … There are so many different channels nowadays. Slack and Salesforce has a chatter and there are many different tools for different way of communicate. And I think communication is the key. Make sure you always have the other side of your team informed. And sometimes go have a little fun, get people together. And, face-to-face time helps a lot, too.

Scott Beechuk: What is the one biggest fail that any one of you has experienced in dealing with a remote team? What is the one thing you always want to avoid?

Vijay Gill: Oh boy, so many failures, kind of hard to catalog.

Vijay Gill: There’s two or three main failure modes I’ve seen and experienced over time in large companies, small companies, doesn’t matter. A number one thing is I think terminology matters. I learned this lesson never called them remote because remote implies they are like remote from some center of gravity. I always term them as distributed teams. You’re a distributed team, which balances out the verbiage weight of being remote.

Vijay Gill: They’re already far away. They feel disconnected. Calling them remote just, in the taxonomy itself, puts them at a disadvantage. From a taxonomical perspective or an ontology of teamwork, I always called them distributed teams. And it takes a lot of reinforcement with my engineering leaders to stop using the R word. Right? So that’s number one.

Vijay Gill: Number two is, is people tend to use offshore or distributed teams as infill, right? Okay. “I don’t want to do this maintenance work. Hand it over to the distributed team and they can work on it.” Communications, to Weiping’s point is, is massive. If we just give them crap work, you will eventually end up with crap people. That’s just how it goes. Because anybody who’s good and ambitious, they’re not stupid. Right?

Vijay Gill: I assume you’re not hiring for stupidity. If they’re not stupid, they’re going to find out they’re getting the work that is not going to be materially helping their careers. They’re either going to transfer it to your office or they’re going to leave, or go over a period of time. What you’ll end up with is essentially people who can’t leave anywhere or people who are demotivated and just show for the paycheck. The productivity starts falling and that’s one of the key things you want to track.

Vijay Gill: The things that I’ve done, which is on the positive side is, make sure the taxonomy is correct, make sure you overcommunicate. Make sure you give them accountability end to end. And this is going to be painful because you’re so used to everybody being local that when somebody is distributed and you give them autonomy, you’re like “Oh my God, they’re going to mess it up, so give them like small insignificant work.” And this is where you, as a leader you have, you’re going to step over that chasm of giving them stuff that is actually material and then … And they’ll mess it up, absolutely for a couple of times. It takes about a year to 18 months to get a working bootstrap distributed team on a small component. Start small, make sure the interfaces are narrow. Make sure that the interfaces and APIs are clean. The money you save, you spend on flights back and forth,

Weiping Peng: And then you have one, too.

Vijay Gill: Yes.

Scott Beechuk: Good point.

Scott Beechuk: Let’s bring it back home, then. Let’s talk about, doesn’t matter where your engineering leaders are and, let’s talk about though, and I love to oversimplify things because it makes it harder. What is the one skill that every engineering leader, whether IC, manager, executive, what is that one skill that every engineering leader must have? Let’s start with Weiping.

Weiping Peng: Okay. Well, if you have to say just one thing, I would definitely put it on, stay on top and stay alert on all the different technology trends. Technology has been changed for so much and the development is very amazing. If you think about a few, probably less than a decade ago, everybody running your own data center and all that. And then just a few years, Amazon and Google, they just, all the Puppet clouds, everything is there. If you stay to say that I like my way without the knowing other people has been very quickly developed new different ways, you could be falling behind.

Weiping Peng: And there’s so many open source library, and a lot of communities, they’re [inaudible 00:10:21], many different fancy stuff. You cannot single handed reviewed everything yourself. And try to stay on top of it and be aware of what are you can leverage, who you can partner with, and what kind of open source library you can borrow. Whether you are a individual contributor or a technology leader or manager, be able to speak towards that and understand what impacts your business units. And in the end of the day it’s about customers are served.

Scott Beechuk: Yeah. What I’m hearing there also is, nobody knows everything. Keep your ego in check and always be willing to learn and keep an open mind.

Scott Beechuk: Claire, any other ideas?

Claire Hough: Yeah, it was actually very similar. We chatted about what’s most important. To me, it’s growth mindset. When you have growth mindset, you’re always learning. You’re open to learning, you’re open to admitting that you don’t know something, like you said. And ,I think that’s super important when technology’s changing all the time. And I’ve also gone from startup to startup doing very different things. You have to be really open to taking on the those different challenges, and also learning from different types of people. We have a very diverse community of developers and we need more diversity, so you need to be constantly learning about not just the technology but what motivates people. What are the backgrounds of people that you’re working with? And in order for you to be a motivator in order for you to set an example of being a leader, you have to be open minded. Be able to say you don’t know something or when you make a mistake, be able to admit your mistake and, and reset and make progress.

Scott Beechuk: Yup. Vijay, any other thoughts?

Vijay Gill: Well, they said everything I was going to say. I’ll add one more component, which is actually, I think, underrated, empathy. You must be able to empathize with your folks and why they’re there, what they’re doing. This goes back to Claire’s point. Connect them to the mission, connect them to the vision. Empathize with them. They have challenges. You have challenges. Make sure that we don’t go into a us versus them management as a leader

Scott Beechuk: Easier said than done, but I understand. I agree with you.

Vijay Gill: We’re all imperfect, right? We have to try to not not mess it up on a regular basis.

Scott Beechuk: The next topic I have is a controversial one, and I love this topic because we just happen to be sitting here together with a team of very senior engineering leaders. I want to see in the audience, do we have any product people in the audience? Okay, good. Do we have any UX people? Designers? Okay, a few, a few.

Scott Beechuk: Let’s talk about this. Let’s talk about this. What are some of the best practices for, related to how an engineering team should work with and communicate with product and UX? And there’s more buried in there and I’ll get to it in a second, but let’s start with that.

Scott Beechuk: Weiping?

Weiping Peng: Okay. Well, I think the first thing coming in my mind is, always remember you are one machine. Or you can say I’m just one body, your left arm versus right. A lot of times engineers can geeky out, “I can make this go so much faster if I try this method.” And product manager would be like, If you built it out, one thing can be stupid,” but customer loves it. How do you reconcile in the middle? You ask the same thing. If you make this one click, right click or left click, it all make a difference. It can wow a lot of usability stuff, too.

Weiping Peng: In the end of the day, I think what we really needed to be understanding is, we’re developing one product and, makes money or not, getting the market or not, but the people going to like it or not. It’s the most important part. And if you keep that in mind, you will be willing to hearing each other out. And somewhere in the middle we will get to a point to say, maybe next release or maybe this release.

Scott Beechuk: But in a situation, I’m talking to you now, Claire, in a situation where engineering, product and UX all have really solid points. The points that make complete sense from a customer perspective, maybe from a technical perspective, maybe from a market perspective, everyone’s got a great idea. Is engineering always right?

Claire Hough: Mm-hmm (affirmative).

Claire Hough: I actually, I’ve been a product manager, because I was hired by a founder who wanted engineering minded or engineering driven product organization. I ran a product for a little while alone and then I ran a combined organization. In my last few jobs, I’ve been calling, I’ve never, we never distinguished product design and engineering as separate teams as much. We sit together, we call ourselves PDE, product design and engineering. We do one status report and, sure, there will be some disagreements about how we might do implementation or what technology we might adopt and all that. But at the end of the day our end goal is to serving our customers. I think if you anchor on that and really doing the right UX research, really listening to your customers, it’s difficult to come at this like a lot of differing opinions.

Claire Hough: And I would say let the people bring their expertise to the table as a team. If engineers know how best to implement that, let them do it. A product manager knows what are the competitors doing, and what do our customers want, and they’re bringing that to the table. Let them own that and really drive that within the team. If designers know how to actually design the product that’ll be easiest to use and it will really satisfied our customers, let them bring that expertise. It’s about bringing that great talent together to make the great product.

Scott Beechuk: Good points.

Scott Beechuk: I’m going to put you on the spot, Vijay. I know the last three companies you’ve worked for have been incredibly successful, and you’ve been in roles where you had to directly interact with product in those situations. Tell us a story. Tell us a story of a scenario where you, where engineering had a fundamental disagreement with product and how did you resolve it?

Vijay Gill: Oh, boy. Thanks for that, Scott.

Vijay Gill: Well, I mean, I don’t think we need to go too far back. One of the things we can constantly run into is, I’ll give you one fundamental disagreement is stability, availability, Aka, go-to-market and expansion versus new feature and landing new go-to-market space. One is land and expand. So that’s things like enterprise features, security availability, reporting, audit logs. AKA. The go-to-market people love that, right? Because they’re already in the account. They don’t have to do new customer logo lands. They know exactly who the champions are and how to build that in.

Vijay Gill: But, you also don’t want to be looking backwards. You also want to acquire new logos. And building new logos and acquiring new logos sometimes require new capabilities or features of product. The massive disagreement we have here is, depending on how strong the go-to-market team is, you spend a lot of time on what I would call RASS, reliability, availability, security and stability features. And how much engineering capacity you carve out for those versus engineering capacity for keep the lights on, like interrupts, escalations, break-fix, versus how much capacity you use to reserve for new features, new products.

Vijay Gill: And so that balancing, that tension is actually, it’s painful. And so the way we been doing it, to put it very, in concrete terms, is that all PRDs, we do joint PRDs. One engineering leader, one product leader for the PRD. The product spends a lot of time inbound and outbound work. Then they take those lessons learned, we write a joint PRD. Then the engineering team does joint capacity planning.

Vijay Gill: We reserve some capacity planning and we have it documented because, well, we are a data processing company, so I know exactly, for example, that about 30 to 25% of every team is what I would call KTLO. And then we carve out the remainder for features and for RASS. And the RASS is, our champion for RASS is go-to-market. Our champion for new feature expansion is product.

Scott Beechuk: When you all get together to write that joint PRD, how thick is the padding on the walls in that room?

Vijay Gill: So far, it’s actually working out because I think to Claire’s point, if you anchor on the customer, what does the customer really need? It, instead of going like this head-to-head like, “I’m right and you’re wrong,” or “You’re right and I’m wrong,” of a zero sum game, you pull back to the side and then you look at the problem. And without putting your ego in the way.

Vijay Gill: Now, and of course if you have revenue numbers with the problem, mixed arguments are somewhat easier to to tiebreak.

Weiping Peng: I might even add a little more. I do believe that there are three arms in the … Three pillars in as a whole machine. And you want them to freely talk about the different things, sometimes even getting into arguments, it’s very healthy. And if you see people don’t argue with it, there’s actually a problem. Because there are different things, exactly like Vijay was talking about. The technical data sometimes, it’s so big that there. If you don’t, as a technical person, if you don’t speak up from the business perspective, they don’t see it. They see, “We sold it. Customer sign up for it.” And when this big mansion is going to collapse? If you don’t say it, nobody will know, so it is your job, everybody’s job, to speak up and debate.

Scott Beechuk: All fair points.

Scott Beechuk: I want to continue, though, talking about … We’ve been talking a lot about things that mature engineering leaders do. Okay? In a perfect world we’re all playing nice together. We all have had the experience that this collective group has had, and we’ve figured out how to make it work. But, let’s talk about engineers who are just starting their careers because we’re all hiring in our companies engineers at all different levels. I want to know what you all think it really takes to bring an engineer from just fresh out of college, getting the first experience, what does it really take to grow from an engineer to what you would consider to be an engineering leader?

Scott Beechuk: Let me start with Claire.

Claire Hough: I’ve been recently exposed to … Apollo’s an amazing company and they hire a lot of college grads from top schools and we’re talking MIT, Carnegie Mellon. And, I’m just so impressed with young people these days. They’re just super motivated. Right? How do you grow them in becoming a leader? And I think a lot of them just come and they want to soak it up. They want to learn as much as possible.

Claire Hough: And sometimes some of those skills just don’t come just being super highly motivated. You got to be exposed to different problems over time. I think there’s a little patience that is required. But some of the things are really difficult to teach, like Vijay talked about empathy. I think that empathy is actually a skill that you can teach. I believe you could teach compassion, but they need to be exposed to what it means to have the real empathy. They need to understand that people come from different backgrounds and people have different challenges. And you have to work with them and find the right motivation for people to become the leader.

Claire Hough: I’m part of, I think, growing young people into leadership is exposing them with as many problems as you can, but also helping them deal with difficult situations that allows them to expand more their diversity of skills. When it comes to, it’s not just the technical skills, it’s not being exposed to different technical problems ,but also different people’s situations, as well as customer situations.

Scott Beechuk: Vijay?

Vijay Gill: A couple of things, again, to make it very concrete. What we do is in our job ladder, we have have a job ladder, which I wrote up a couple of months ago, we have explicit gates. For example, if you’re level three, which is NCG or level four, which is new college grad, PHD, there are certain things and expectations that we do. But if you go up, for example, at senior, you can start authoring design docs and to get to senior and authoring design docs, all seniors must be able to mentor a junior person to write a design doc, for example. And then, as you get to senior staff or principal, you can then do things like, “Okay, I want an autonomous group to run with this idea.” And you get to design and you get to architect the entire thing end to end.

Vijay Gill: Making it explicit on a job ladder makes people, see how this progresses. That’s number one. Number two, mentorship and pairing them up with good strong leaders. And the third thing is, not everybody’s going to be a great leader, right? You want to figure out, you play to their strengths, not try to make everybody the same. And that’s how at least we been managing to do it.

Vijay Gill: But the biggest differentiator is, who they’re pairing up with and the opportunities they get to learn. This goes back to taking sometimes a risk. You have to push people slightly beyond their comfort zone for them to get them to grow. And sometimes when you push them beyond their comfort zone, they will be failures. That’s why you have a more senior engineer to catch them when they fall.

Scott Beechuk: Yeah. Mentorship. I mean I’m hearing a lot about mentorship. I’m hearing a lot about teaching the more difficult soft skills, things like empathy and working within teams, all very important.

Scott Beechuk: Weiping, anything last to add there?

Weiping Peng: Well, you two covered a lot. I think those are really good advices. One thing I can speak from the technical side of it, it’s actually just like a whole … It reminds me, how do I do technical interviews sometimes. It depends on the person’s seniority. And the question can start with just about any question. You can start it with very simple, and you can always have more things to add. You should, it’s a way I … If I were to mentor a particular junior engineer, usually it’s give them some ownership so they feel that’s something they own. However, you can always modularize the whole problem. Give them a very specific one or for more complex one. Just gradually add to it. There’s always more to add it to the complexity. And it’s amazing, people actually learn.

Weiping Peng: I was seeing a lot of engineers just grow very quickly. They have the hunger, they always wonder why. And sometimes you’ll be amazed before you ask the question, they ask you this, so like, “What about that?” Yeah, it’s a pleasure to work with what’s a lot of those amazing engineers.

Scott Beechuk: Okay. This has been great. We have time for one last question and just to kind of wrap things up, I would like to ask each one of you, we have, this is, this is … By the way, SaaStr is a great community of entrepreneurs, of investors and of people who just love building great companies. What is the one thing that you’d like to leave everyone in this room with when it comes to building a great, great product and technology organization? What is the one ingredient? It doesn’t have to be the only. Let’s just choose one.

Scott Beechuk: Anybody can start.

Claire Hough: I’ve done a lot of startups, so maybe some of your entrepreneurs and you’re at a startup. I think startups are made of people with grit. It’s hard, right? Startups are hard and you got to really dog it every day with different problems and trying to figure out where the product market fit is in the early days. And then how do you scale your operation and actually serve your customers? All those things will come in time, but you got to stay in it. You cannot have 90% of your foot in, you got to have 150% in and you got to tackle each problem that comes.

Claire Hough: And again, like I keep saying, you got to stay in it. I really encourage everyone to go into a startup with that resilience and that any problem that you will face that there is always a solution. Then you will figure that out. You may not know everything in the beginning, but with that determination that you’ll figure it out, I think that is key ingredients for entrepreneurs and people who are joining startups.

Scott Beechuk: Motivation goes a long way.

Scott Beechuk: What do you think?

Weiping Peng: Definitely.

Vijay Gill: Oh. I think number one factor is try to be lucky. If you’re going to be lucky. luck strictly dominates over every other thing that you’ve heard today. If you can be lucky, at least try to set up success, factors for success. And specifically, each team that I build has to have five ingredients, mission and vision, somebody who is good at execution, somebody who’s good at tech lead, somebody who’s good at product and somebody who’s good at engagement, HR and people. If you have those five elements on a per team basis, you will probably be less likely to fail. Although the default state of any startup is dead, and this will make it less likely, I guess.

Scott Beechuk: Wow, that’s very uplifting. Great way to end.

Vijay Gill: It is true.

Scott Beechuk: Not untrue. Not untrue. I agree.

Scott Beechuk: Weiping?

Weiping Peng: Okay. Well,, for me, actually I have not started a startup company before. However, knowing, I’ve been working with so many different big companies, I do see it doesn’t matter how big, how small the end organization is. One thing I always learned is, find as a group of a people. There’s a few, and it doesn’t to be everybody, but find as a group of people that that you are very tight. You always can trust, always can rely on. And they might find the other ones, so together you build that tree and get all the things done.

Scott Beechuk: The commonality here is trust. Trust the people you work with, trust the mission you’re on. Be Willing to put in the hours, the hard work, the motivation, the grit as you said, Claire.

Scott Beechuk: I want to thank our panelists here. Let’s give them a big hand.

The post Building a Stellar Engineering Organization with DataBricks, Salesforce and Apollo (video + transcript) appeared first on SaaStr.