The Engineering Leadership Podcast · Episode 25

Growing Into a VPE - Patterns & Anti-Patterns

with Cathy Polinsky, Jerry Krikheli, Richard Wong, Erica Lockheimer & Claire Lew

Sep 06, 2020
A dynamic conversation between 4 current and past VPs of Engineering who cover all things about becoming a VPE! You'll hear how leadership is different in large vs. small companies, mental models to determine your greatest leverage, why you don't need to act like an owner, how to put trust into practice when you’re transitioning into a new role, and about the imperfect path to become a VPE.
Listen On
Apple PodcastSpotifyBreakerGoogle PodcastOvercastRadio Public
ELC
NEWSLETTER
EVENTS, PODCASTS AND MORE
ELC
NEWSLETTER
EVENTS, PODCASTS AND MORE

SPEAKER

Cathy Polinsky - CTO at Stitch Fix

Cathy has served as Chief Technology Officer at Stitch Fix since 2016. From 2014 to 2016, Cathy served as Senior Vice President and Vice President, Enterprise Search of Salesforce. From 2009 to 2014, Cathy served in engineering management roles of increasing responsibilities at Salesforce. Prior to joining Salesforce, Cathy served in various software development and software engineering management roles at Yahoo!, Oracle and Amazon. Cathy holds a B.A. with a special major in Computer Science from Swarthmore College.

SPEAKER

Jerry Krikheli - VP of Engineering @ Houzz

Jerry is the VP of Engineering at Houzz where he oversees all infrastructure, platform, and engineering across Consumer, Marketplace, and Industry Solutions initiatives. Prior to Houzz, Jerry was an engineering director at Google responsible for developing early versions of the display ad serving infrastructure and launching YouTube ads as well as video ads on mobile apps. He has a passion for building high-performing systems, products, and people.

SPEAKER

Richard Wong - SVP of Engineering at Coursera

Richard Wong is the Senior Vice President of Engineering at Coursera. He oversees Coursera's infrastructure and product development. Prior to joining Coursera, Richard held various engineering leadership roles at the early days of LinkedIn, with key focus of scaling Jobs marketplace and Talent Solutions to become its first billion-dollar product. Richard also oversaw the product development for Linkedin international expansions. Prior to LinkedIn, Richard spent over a decade at Microsoft leading various product development teams including MSN Hotmail, Active Directory, Windows Server, and System Center. Richard received his Master’s degree from Stanford University.

“the worst two problems you have in an organization, is number one, you have no owner. The second one is you have too many owners for a problem. So when you see a problem there is already a clear owner... you don't act like an owner. You go support, he or she to actually get the job done. Provide all the support, offer the help to that person so that we can win together.”

- Richard Wong

SPEAKER

Erica Lockheimer - VP of Engineering at LinkedIn Learning

Erica has been at LinkedIn for over 8 years and most recently held the role of VP of Engineering heading the Growth Engineering team, where her focus was on increasing growth in new members and deepening engagement with members across LinkedIn's products. She started the Growth Team from the ground up to now a high performing 120-person team. In January 2018 she moved on to her next play at LinkedIn and is now the head of Engineering for the LinkedIn Learning team, formerly known as Lynda.com. She is also responsible for LinkedIn's Women In Tech (WIT) initiative that is focused on empowering women in technical roles within the company. Prior to LinkedIn, she worked at Good Technology as Director of Server Engineering to securely manage and synchronize e-mail and calendar data between Exchange and mobile devices. She loves the challenge of starting with something nascent and carving out the right strategy, hiring the best people, and plotting a course to drive results. In 2014 and 2015, Erica was also voted amongst the top 22 women engineers in the world by Business Insider. Erica is a San Francisco Bay Area native, has 2 kids, loves to run and is a graduate from San Jose State University with a B.S. in Computer Engineering.

SPEAKER

Claire Lew - CEO at Know Your Team

Claire is the CEO of Know Your Team – software that helps managers become better leaders. Her company, Know Your Team, has helped over 15,000 people in 25 countries at companies like Airbnb and Kickstarter. Know Your Team also runs a online leadership community called The Watercooler with 1,000 leaders and 2,000+ conversations on hiring, firing, business growth and more. Claire’s mission in life is to help people become happier at work. She speaks internationally on how to avoid becoming a bad boss, and has been published in Harvard Business Review, CNBC, Inc, Fortune, among others. Claire is also an adjunct professor of entrepreneurship at her alma mater, Northwestern University.


Join us for the 2020 ELC Summit on 10/15!

Accelerate your growth as an engineering leader at the ELC Summit! We’ll have 100+ incredible speakers, well-rounded curated topics, hands-on practice through workshops plus other awesome immersive experiences. And speed networking with other eng leaders through our own custom-built platform!

You’ll connect with great people. You’ll walk away a better leader. and if you’re not careful… you might have some fun with us along the way :)

Check it out HERE


Show Notes

  • What Cathy means by “the best leaders spot patterns, understand problems, then build systems to solve them” (3:55)
  • Jerry’s view on how the practice of leadership is different at large companies vs. small companies (7:30)
  • Erica’s perspective on how the transition to VPE is different than other eng leadership roles and how to put trust into practice (12:27)
  • Why Richard resonates with “act like an owner” and what it actually looks like in practice as VPE (16:40)
  • Cathy’s top 3 priorities as VPE that determine how she spends her time and how to refocus your team (23:50)
  • Richard's mental model to determine where he has the most leverage for impact and why being technical isn't always about writing code (26:16)
  • Jerry's 3 key hiring traits and how to create an environment where you're the first to know when something's wrong (30:10)
  • The imperfect path to become a VPE and Erica’s advice for engineering leaders with an “unconventional” background (34:01)
  • The common struggle to balance being a problem solver and being the bottleneck as a VPE (39:11)
  • How they cope with and manage stress (42:55)
  • Takeaways (45:00)

Transcript

Claire Lew: I'm honored to be here tonight with these four other lovely panelists. I have a lot of things.I want to ask them. And so we're going to try to get through it as much as possible. And then at the end, of course, would love to hear what you would want to personally know as well.

So the topic of tonight's discussion is patterns and anti-patterns, which I think is interesting in the sense that we here in this room are obsessed with patterns.

we feel like if we can figure out the pattern, then we have the answer. But I think there's something a little bit deeper. And that's what I want to uncover tonight.

Which is we want to figure out what the patterns and the anti-patterns are around being a successful VP of engineering, because we want to know how to actually think differently. And perhaps do something differently.

So our conversation tonight is about personal experience. It's about being really concrete about what has worked and not worked and being a little vulnerable and honest about both of those things. And hopefully, for all of you tonight, you'll be able to form your own sense of what patterns or anti-patterns may work or not work for you.

What Cathy means by "the best leaders spot patterns, understand problems, then build systems to solve

So I want to start off with you, Cathy, as the CTO of stitch fix or stitch fix over the past, I feel like it's a tongue twister for some reason. It's liike, I look at the word and I'm like, I know how to say this company's name. I'm pretty sure.

but for the past three years you've been the CTO of StitchFix and. previously you served, companies like Amazon and Oracle, you were the SVP at Salesforce. And I was listening to a podcast that you were on recently where you said, and I'm going to paraphrase you here. hopefully not putting words in your mouth, but you said that "the best leaders find patterns and understand that they're not just solving for one problem."

And I heard that and I was like, Okay. What does she mean? Yeah. So tell us what you mean by that, and then talk about how you figured that out. And when you personally struggled with understanding that concept.

Cathy Polinsky: Sure Yeah. how many of you have read Martin fowler's "Refactoring?" so the best engineers are folks that are not building out these large scale architectures before it's needed, but they're also the ones that are realizing that you don't want to solve the same problem again and again, like after you solve it the second time, maybe you need to start thinking about building out a more generic system for the problem. Instead of if Alice. littered throughout your code base.

And it's the same thing with engineering leaders, except that you're not always solving the problem about code.

so whether you're solving a problem with how you deal with,

Claire Lew: yeah, we should example promotion.

Cathy Polinsky: Yeah. So like we were a small company. You might not need a really large system for how to deal with promotions. but when you're getting to a larger system, you want to be able to talk to field people about, what makes a good promotion and you don't want yourself to be the one, having those conversations with every single person in the organization.

So it thinks about, okay, how can we build out just the right amount of process and just the right amount of systems to make sure that we've got the, consistency that you would want from a promotion process, that people understand the expectations of the role that, you don't have a lot of people who are like upset that some people are getting promoted, but others aren't, or that you have, unclear expectations of people thinking that they're at that level, but they're, really, missing, a huge portion of the capabilities that you want at a lead engineer level or something like that.

I think that there's a lot of tools in place for you to find these patterns. and, I'm a big fan of blameless postmortems and team retrospectives and start, stop, continue type of methods. so whether or not you're looking at something from a people side, like a promotion process, or trying to figure out patterns of, Hey, we keep having the same, incidences and keep getting called for the same type of events, that is bringing down our systems.

You want your leaders to be asking those questions? Not on a, like, A casual letter of rapid fire I'm just gonna, fix this, fire and always be the one who has to solve the fire, but really asking these deeper questions, these five whys of like, well, why did that happen? And why did that happen to really get to the underlying situation?

Claire Lew: Absolutely. I think the image that comes to mind for, myself you know as a CEO, but then also, for any executive is you can and feel like you're playing whack-a-mole right. Like, it's just like, there's no time to pause. it's all these problems. And to your point,

it's like, you don't need to hit the same mole five times to then realize, okay. Yeah. Maybe we should have a promotion process in place. Like what I love about your insight about really internalizing this idea of every one problem could potentially have a pattern behind it. And what's the system I could build around it..." is it changes your lens for every single problem. And it prevents future problems from arising.

So I thought that was brilliant. Thank you.

Jerry's view on how the practice of leadership is different at large companies vs. small companies

So Jerry, your transition into being a vice president of engineering, I thought was fascinating. So you've helped build Houzz for now... yeah. Almost three years as well. But previously, as was mentioned in your bio earlier, you served as the VP of engineering for Google.

Jerry Krikheli: Director of engineering

Claire Lew: excuse me, director of engineering, little different.

but nonetheless, I thought, really, an interesting, it's something that was mentioned earlier today, right? To go from a giant organization to one that. Is smaller, still larger maybe than some of the companies, for folks in the room. But I was curious to hear organizationally, like what did you have to change about your leadership style or practices in that transition?

Jerry Krikheli: So to clarify, one thing, I started at Google when, It was still a startup or it's still definitely considered itself a startup. And it had, I think just under a couple of thousand people relative to, I think over a hundred thousand that it has today. So at that point, the company was actually functioning relatively comparably to, I would say where Houzz is today in terms of processes, it was a little bit more chaotic.

I remember, I think Eric Schmidt at one point quoting Google as being controlled chaos. And I feel that Houzz is in a similar way, maybe slightly more controlled chaos because I recognize the chaos now slightly better having gone through it the first time.

But, having stayed at Google over a period of time, I've seen different processes being adopted and I've seen them be useful in many instances. So it's very fun when you're at a startup and everybody's moving at 120 miles an hour. And nobody really knows what anybody else is doing, but because they're doing it 24 hours a day, a lot of stuff is getting done.

But then over time, what happens is that you end up on this collision path where so many things are being built and there's very little cohesiveness. And so you have to pull things together. Some things you have to pare down because everybody is running in separate directions.

And at least with Houzz, what I try to do was on the one hand instill some sense of discipline where yes, we're a startup. Yes. We want to move quickly. Yes. There's a lot of things that we could do because the industry is nascent. At the same time, we want to focus on a core set of problems that are going to make us successful and a core set of products that are gonna make us successful.

And in order to do that, given that it's a startup, one of the things I try to avoid doing was introducing heavy processes. So at Google, we would have a lot of people, we would have, quarterly, annual planning meetings, there'd be a lot of people involved. You'd have a lot of cross team dependencies. You want to make sure that the infrastructure team, the security team, the legal team, all the other interdependencies that you have, if you're launching something, it probably has a cascading effect on a bunch of other teams... you want to make sure that everything is consistent in terms of how it's launched.

Whereas at Houzz we can just pull a group of people together from every different part of the organization or the relevant people, and just say, look, here's what we want to do. Let's talk about a plan. Let's commit to doing it together. And then we just go and do it. A lot of times we don't even document the decisions that we're making, which are things that we're changing as we're scaling.

But historically that's actually worked fairly well for us because we're a constrained organization where everybody knows everybody to a large extent and there's a lot of trust within the organization. And so when people commit to each other, we don't need written agreements that "I promise I'm going to do this." And we don't deliver. We know exactly who made what promise and we know exactly what it is that they promised, and we can hold them accountable to it.

Claire Lew: Absolutely. So it sounds like foundation of trust, the degree to which knowledge of, who you're working with is sort of the lever to how much process you create versus not.

And here's the other thing that I find interesting about that answer is I think instead of, listening for... cause I was listening for sort of the, Oh, you should do X when and you, and your answers suggest rather to default to having less process when you have that trust in place.

Would you agree with that? Did I sort of draw the right thing or would you push on it a bit?

Jerry Krikheli: So I think it's fairly accurate, right? I think Einstein once said "make things as simple as possible, but never simpler."

And so I believe the same concept applies to process, I believe in minimum process, but never more than that.

And so to Cathy's point with respect to promotions, we tried to take a similar approach to promotions between what typically startups do, which is nothing. And what large organizations do, which is way too much. We try to draw a fine line between, well, we have to have better than nothing because people want to get promoted and it has to be consistent has to very quick. We want to make it simple. We want to make it explainable. And then we want to move on and we do the same thing within engineering, whether it comes to post-mortems or it comes to software development.

So I don't want to say I'm not a believer in process. I'm just a believer in minimal process.

Claire Lew: Absolutely. And I think, to pose a question for the audience to reflect on would be, what. Would you consider minimal process for your organization to be, and where on that spectrum might your team be? For better or for worse?

Erica's perspective on how the transition to VPE is different than other engineering leadership roles, and how to put trust into practice

Erica, your transition to vice president of engineering is really remarkable in the sense that you just became VP of engineering at LinkedIn learning literally a few months ago. So congratulations, but you've spent the past eight years in various leadership roles at LinkedIn. So no shortage of leadership experience.

I am curious though, how was this particular transition is a new vice president of engineering, sort of fresh into the role different if anything, from previous transitions into the leadership roles that you've had.

Erica Lockheimer: Yeah, So that's a fantastic question. And thank you for the congratulations. Yes. And yeah thank you! I appreciate that!

Funny, just funny story is, we had this leadership meeting where they were going to announce my promotion and the day before I broke my leg... and so this is the first time I was able to drive a car, but they're like, Yay! Erica was so excited. She broke her leg. So I'm like, okay, thanks.

Richard and I used to work at LinkedIn, so we both worked on growth together. He was on the international side. So it's great to see you here.

so I've been running the, of engineering for the LinkedIn learning team for about a year and a couple months. And before that I built the growth team from the ground up.

we didn't have a growth team and built it and. Hit, we all hit those numbers together and got that, made that happen. But there was a point where, when you build the team, it's like, I knew every single person I hired when it was like zero to 130 plus person team. I knew everybody, the culture was strong.

It was just like, we were just hitting the ground running. And I knew everybody and it felt really good. Came to a point at LinkedIn where, you really have a point where you feel a little bit stagnant and when you get that to that point, either expand your role. Do something different at the company or leave.

That's pretty much where the options are. And I started thinking about what that's going to be. And I started having transparent conversations with the organization, the leaders, and they actually gave me opportunity for LinkedIn learning. It took me a while to figure out what it was and if I should be doing this, he's like, Erica, can I give you a fricking swing? Like, what's your problem? Right?

But it took me time because I'm just very methodical about what I wanted to do. And so I decided to do it, but going into a team that you did not build. It's kind of like, who are you? you don't have the trust, you don't have the relationships. And all of a sudden, now you're running the team.

And so that is what was really different for me going through that transition. And I'm all about people and I felt disconnected. I needed to understand the strategy. The business was new. There were sales there's marketing. My goal was I wanted to learn how to run a business at the end of the day and it had all the components, all the check boxes.

But I had to go in to this thing that was already running. So that was what was different. And I realized what was the most valuable thing for me to do was to start building relationships as soon as possible and gain the trust of the people. I went in. Of course, it's hard when you go in and you're like, Oh, I've seen this playbook before, you know, you don't have your metrics, you don't have your dashboards. You don't know how are you executing? It's like so easy judge.

I had to take a step back and I said, you know what? I'm going to seek to understand. And I'm getting the trust of the people. Then I'll start making decisions. And so getting trust with the people was very key. And I feel good now, I made some major changes in the team, reorganized, the team, made some choices on leadership and other, such things.

But I feel in such a good place where I'm connected and we're building, we're getting results and they trust me and I feel in a much better place. So I think trust is really key and going to the team and building up.

Claire Lew: That's I think phenomenal advice. And I think actually advice that is really difficult to put into practice because for many of us as leaders, I think the assumption is, "Oh, I'm put into this role to provide answers to, have vision and execution and to deliver on results."

And to your point. Trust is the currency and really the oil of the machine in order for you to even have that happen. So I think the foresight and the wisdom to understand that you needed to sort of sit on your hands.

we run a, an online, leadership community with thousands of managers and they say something really simple or similar, which is go on a listening and learn tour, right? Ask more questions and you, then you give answers and don't talk about vision at all for the first it's two weeks. So I thought it was remarkable the way that you actually put that into practice. Cause doing it. Is there a difference? It is only hard.

Erica Lockheimer: I like your thing also about cure. Yeah. About oils oil in currency.

So that's a good way to look at trust. I like that. It's like, it works.

Claire Lew: You can take 'em.

Why Richard resonates with "act like an owner" and what that actually looks like in practice as VPE

so speaking of advice and putting advice into practice, Richard, I was, yeah, I was reading something really interesting about some of, what you called the best advice you've ever received. And so Richard is the VP of engineering at Coursera previously though worked at LinkedIn alongside Erica.

And in this piece it was mentioned that the best piece of advice that you ever received was from LinkedIn CEO, Jeff Wiener. And he told you to act like an owner. Okay. I feel like that could be on a motivational poster somewhere, but I was, I wanted to dig into this more, like why this resonate with you?

And I also wanted to challenge you. Has there been a moment in your career where you have not. Lived up to that advice personally?

Richard Wong: Sure. You can talk about is I think a big part of that is probably is related to the experience that I have going through. I think many of us actually here has developed your career and take on bigger and bigger responsibility.

So naturally at some point you feel that, something that was not related to you in the past, now it becomes part of your problem. Like you need to deal with those problems, right? This is actually especially more important when you transition from a bigger company to a smaller company, to an even smaller company.

So I personally make two transitions like that from Microsoft to LinkedIn, when LinkedIn was still early. And on LinkedIn to Coursera, I told people that every time I pick a company, I pick a company that is an order of magnitude smaller than before.

but actually I think when you actually go into these, when you go through these transitions, you actually feel one thing very strongly is... something in the past that someone else was taking care of. There's a system there's processors owners. There are teams that only, that no longer exists in your new team. So for example, right? When I first actually a company joined the LinkedIn, I was on the jobs team responsible for building the jobs marketplace. We have like five engineers working with me together. So it's much smaller team than what I had at Microsoft.

One day, , the build broke. So when I say that, okay, so let's talk to the build team and figure out what's going on? Well, there's like the build engineers over there, but he's on vacation so there's no appeal to you, so you figured out what to do.

and then when I came to Coursera, we were very aggressively tried to hire people, get talent, you do on a station.

And we are not filling the recs. So then I just, go to your recruiting team and say that, Hey, what's going on?

Because in the past, when I worked at LinkedIn and Microsoft, usually what happened is this is my 20 recs help me to fill it. And this is the job description.

And, two weeks later there'll be like interviews. but nothing happened, right? So like, okay, what's going on?

So, well, we actually, you know what, we only have one recruiter working for you right now. And then she's also responsible for our data science team and their product team and the legal team as well.

So at that point, I said, well, maybe we should actually sit down together. I think go what we need to do together so that you make it successful, like what you are going to do, what I'm going to do. So I need to sit down and go through the, LinkedIn profiles, source candidates, myself. And have her to help me do, I'll bring some of the logistics.

So many of these things actually may me think that, when you are in a different situation, you need to play different roles. Sometimes you have people supporting you and do that job and then collaborate together. But there are lots of times that what you really need to do is really step up and try to solve the problem that you're facing. And at that point, maybe at lots of cases, is the owner does not exist. So you need to actually step up and try to solve the problem and act like an owner.

So now, when you ask the question about like when is the time that I don't do that. Absolutely. I don't do that every day. Like, because you don't do that when there is actually already an owner.

Well, so it may sound funny, But actually it happens a lot. and especially if you work for a bigger company, a bigger organization is the work the worst two problems you have in an organization, have a problem.

is number one, you have no owner. The second one is you have too many owners for a problem. So when you see. A problem There is already a clear owner you don't act like an owner. You go support, he or she to actually get the job done. Provide. all the support, offer the help to that person so that we can win together.

So don't try to be an owner when there's already an owner. So that's my advice

Claire Lew: I think that's tremendous advice. (applause)

I find it actually ironic that we were all laughing because I don't think it's as obvious as it sounds. I really don't. and here's the point that I'll make. How many times is it that someone, an employee comes to us with a problem. And our immediate instinct is to sort of roll up our sleeves and go, Oh, I'm on it. Got it. I'm going to, I'm going to get in there. It's...

and your point is we'll know there's already an owner on that problem. That's the direct report who brought you that problem.

And I was, interviewing some of you may know Wade Foster who's the CEO of Zapier. He was on the podcast that Irun called the Heartbeat, and he said something really similar. He said, Claire, when you are solving problems for other people. You're not doing your job actually, as a manager. You're actually failing people.

And so to your point, it sounds so obvious. Oh yeah. Don't you don't need to own a problem or act like an owner of someone's already owning the problem, but it's not as natural for us to resist that tendency.

So I want to just sort of pause here for a moment. we may have all laugh. We may have all gone. Oh, I love that Richard yeah duh, like so good. But it is really difficult to actually translate that day to day when someone is coming to us with problems, even though they are the owner of that problem. So I thought that was brilliant advice.

Cathy's top 3 priorities as VPE that determine how she spends her and how to refocus your team

I have like a million questions. I want to ask you all. And there's some questions on here, so we're gonna run through a few of these as quickly as possible. I think the biggest question that I first want to start off with, it's something that it doesn't show up here, but it's something that gets asked a lot. And it's for you Cathy around time.

So you were recently also interviewed on this podcast where you talked about how you spend your time as a vice president of engineering. And the three things that you said of the way you spend your time is around team building, strategic priorities, and then making sure systems are reliable.

Is that still true since you last shared that, does it change day to day? How does it change over time? Yeah, I'd love to hear about that.

Cathy Polinsky: one of the things that we do at stitch fix is we do a collect and reflect period instead of, the normal performance review. So everybody, is in charge of going out and getting their own feedback about their role.

And the first thing we start with is everybody writes their roles and responsibilities. so I do it myself, all my directs do it. And, I thought that was just, a, extraneous part of our process. And then I realized reading these of like, huh, I had a different expectation for people in their role than they had of themselves. so I highly recommend that for all of you.

but, when I looked at engineering leaders, I care about three things. One is people and culture. The second is around delivering execution. And the third is around technology. and I would say that there is, a tactical aspect of all of those, as well as a strategic aspect.

and I think, what I'm spending on my time can depend on how well each of those pillars is doing. but I think it is important for everybody to thinking about that as like, want, am I recruiting the right people? Am I able to, onboard them, am I retaining them? Am I developing them? Like, there's so much there about making sure that you have that for each of your people and you have the right cultures and practices in place.

On the, delivering execution side, it's so important for you to like, we're there to deliver software. Like that's, our job is to deliver product and make sure that you're having it impact. and so how do you do that for each make sure that each team has the right strategy is working on the right things.

and, just has the velocity and agility. and then the last is, technology of like, Okay. How has your reliability, scalability, performance security. do you have the right systems in place? Are you collecting technical debt? having a lot of bugs in place. and so, yeah, I think that those are all the key pillars that you should be looking for as a great VP of engineering, but also as a great engineering manager and what it will look like for a small team versus a large organization varies.

Richard's mental model to determine where he has the most leverage for impact and why being technical isn't always about writing code

Claire Lew: Let's. Yeah, that's perfect. So team building strategic priorities and making sure that systems are reliable around the technology.

So one thing you didn't mention was actually writing code. So I want to turn back to Richard here because I've, I found this blog post, I get up on the internet that I was sort of giggling at and was. I wanted to ask Richard about it in front of all of you tonight. but it's about writing code.

So there's a 2016 blog post. that a Coursera colleague wrote about how you do make essentially your equivalent of hackathons. And, the person had said that in the past three quarters that almost every engineering manager participates in these megaphones. And that you had in fact won best of show in one of them. And they were talking about how they loved your live demo.

And I'm sitting here reading this blog, post thinking, this guy is the VP of Engineering at the time maybe director of engineering, but still I was like, this is so interesting. I'm so curious, because we get a lot of, this question, know, to Cathy's point. Well, how do you spend your time?

Make-a-thons and hackathons were not part of her answer. So for yourself,

Were your direct reports voting for you?

but I would love to, I would love to ask to what it's like, do you still code today? Like, so is that true? Do you still participate in the, today as VP of engineering? To what extent do you think it's important for a VP of engineering to still be active?Technically?

Richard Wong: yeah. so you know, I will answer your question directly. What do I still write called it today? But, the way I always think about, or as an engineering leader, you're always thinking about the leverage and influence and impact that you're creating for the organization.

there are times that when the team needs you to do certain types of things in order to make the team successful, you do it no matter what that thing it is.

So now when you think about the team when, it is really small. So I have this mental model in my mind thinking about myself as a mathematical operator. So you can be addition and subtraction and you can multiply, or you can be, with division. So when the team is really small, when he has like zero people, when I actually first went to Coursera, my job was to build the team there to start from zero engineer.

The first thing I need to do, and we have a product roadmap and before the people actually come and join, join us. So I have to write some code at the very beginning, because what do you do if you actually have no people working with you together at that point? And you need to ship something, right?

So you are doing a plus one operation, orplus two operation. If I'm a very good engineer, but when you actually have a team that is growing and you have a team that is working for you, you need to be careful about what you 're doing . Like you don't want you to be a plus one or plus two, and actually worse in many cases, right?

You are actually at subtraction, get a team. That's what you are doing. You are not as familiar with the people that are very familiar with their technology familiar with the product itself. And you'll actually causing destruction to the team on, to actually provide the feedback and say that, Hey, Richard, actually, what you did is not right.

And they need to actually, and they need to actually deal with the chaos that you create. If I make a bug and then they need to fix it. yeah,

so I think that is actually a very important part of that is like, you need to actually think about the impact that you are making to the team and create the best leverage.

So now. if I think about for the last couple of yours, like the evolution of the team is the team actually have grown a lot. The only occasion that I really actually try to, there are two occasions that I do write code. Number one is in our hackathon. So I try to, there's no liability once you actually get through it is our prototype. It doesn't work. It's okay. That's exactly right.

The second thing I do is that I do, write code for my home automation at home. And, that is my self. Like I accomplished something at home, although my wife and my kid is not very happy about with the outcome of that sometimes. Because of bugs.

but, when you asked, whether a VP of engineering should be technical. I think the answer is yes, but technical is not necessarily about writing code. I think there are many form to express about your technical capability to help the team, to make them successful.

Claire Lew: I so appreciate that distinction and I'm sure folks will want to maybe talk to you afterwards or to everyone up here afterwards about how they might define what those forms of technicality might be.

Jerry's 3 key hiring traits and how to create an environment where you're the first to know when something's

Switching gears a little bit to what Cathy was saying was what a disproportionate amount of her time goes into, which is recruiting and hiring and team building. Jerry you gave this talk actually at SFELC maybe some folks caught it in January I unfortunately missed it, but luckily there was a writeup and you did talk about hiring.

Jerry Krikheli: There's also a video

Claire Lew: and a video... and I thought it was interesting. You boiled down essentially what you saw as the three most important traits to hiring as integrity, reliability, and sincerity. And I was curious. How did you learn to hire for those things? what experiences have you sort of amass that caused you to say those three traits in particular? And then to one of you not hired for those traits and what happened?

Jerry Krikheli: So I think just to get a little, a bit of background that the context of that talk was building distributed teams. And those descriptors were actually specific to finding an engineering lead that would be capable of building a team and a distributed site.

And so the context for that is that if I'm going to find somebody that I'm going to entrust with a group of engineers to basically operate independently in a distributed location, I said, it's very critical, right that you have that independence. Then I want to be able to have that person be reliable, trustworthy, and be somebody that has a lot of empathy for their team and also for the remote team, because there's always this kind of you versus them phenomenon whenever you have a distributed or remote team.

And so you have to have somebody that really understands what it's like to be on the other side of the aisle. And look at things from both perspectives to see if it's a misunderstanding or if there's kind of cultural issues or what the specific issue is.

Now. I think the three elements that you mentioned were on either the left or the right side of the slide. And then there was also the opposite side of the slide, which had things like competency and ability to deliver. And so to me, those are basically table stakes. You have to be somebody that's, that's capable of delivering a product. You have to have a consistency in your ability to say something and then do something. Right, which basically, engenders trust.

And then if on top of that, you have the emotional intelligence. In other words, you have trust, you have empathy, you're able to relate to the situation. You can be adaptable. And I think adaptability was one of the things I also listed.

Then you're going to be in a position where I can definitely trust you to run a team. I can certainly rely on you to run a team. And then when something is broken, you're going to be the first person to come back and tell me. Because I always tell my team that if something breaks or if something is not right, I want to would be the first, definitely not the last person to know. Because otherwise I'm not going to be able to solve it quickly enough.

So in that particular respect, I think you asked in terms of, how did I come to this conclusion? A lot of it is just by experience.

I think over the years I've worked with and managed a variety of different teams and I've discovered that I'm generally pretty good at reading people. And if I can't read the people that I'm interacting with, that's a big problem for me. Because I need to be able to understand when somebody is happier when somebody is unhappy, or if they're frustrated with something or if something is not working.

So if somebody is so good at having a poker face, that I don't know whether something is working or something is not working. I'm not able to do my job particularly well. And in that respect, I tried to optimize for finding people that have a sense of integrity and transparency. That way when things are going great I know. And when things are failing, I also know, and then I can help them solve that problem.

Claire Lew: Absolutely. I love that sort of, check of encouraging folks or figuring out how you personally can also create this environment as a leader of how do I make it so that if there is something that goes wrong, that I'm the first person to know instead of the last. And is this person a kind of person who would feel encouraged to do that? So I thought that was wonderful.

The imperfect path to become a VPE and Erica's advice for engineering leaders with an "unconventional" background

So Erica, I was doing lots of reading about you and your story.

And what I found very unique about your path to becoming vice president of engineering is how you were actually the first in your family to go to college and that you almost dropped out of college. And I found that inspiring, obviously on a lot of levels, but also extremely unconventional, especially for a vice president engineering in Silicon Valley.

So wanted to know what advice do you have for folks here in the audience tonight who might similarly feel like they don't have the conventional resume or may have taken the most traditional of paths who aspire to be where the four of you are sitting today?

What advice do you have them for navigating that?

Erica Lockheimer: I think, it's important to understand like what got you somewhere and it's that grit and tenacity. It's like, I didn't have a plan of. I'm going to go to college, I'm going to do these things. I'm going to graduate. I'm going to be VP of engineering.

Like that path did not exist. I was just, I'm going to graduate for college because no one else in my family has, right. Like that is going to be step one. It took me seven years to graduate. I was working, I went to San Jose state everything and I was trying to figure it out all at the same time.

But really what clicked for me is I had the will to want to learn. And whatever capacity I can learn, I was curious. I was always constantly curious and I didn't have to have this perfect path.

And so I remember multiple times, I almost dropped out to just trying to make ends meet and then especially the diversity of the classroom was not always so great. but I managed to get through. And I remember in those times when it was really hard, that there's always somebody else that helped me get through that.

And so that's why it's really important for me in where I'm at is like, for me to recognize when other people are struggling to help them succeed in their new path.

And so for me, I just felt like it was important for me to give back. Like for instance, I give back a lot of my time to San Jose state. And that's where I went to school and I felt I would see so many people struggle because they didn't have that traditional path. They didn't go to that four year, Stanford college and everything. And so I give a lot of my time back.

And it's interesting one of my first years at LinkedIn, what did we first do is we'd have hiring committees. And they're like, Erica, you're gonna be part of this hiring committee.

I'm like Great! Yeah. I'm a man senior manager at the time and they're like, and we're going to review talent, it's going to be the best talent, we 've got to hire the best team. And we start looking through all the resumes. And they're like, Stanford. Yeah. Bring that over here. San Jose state. No, put it over here.

And I was like in that room and I'm like, awkward. They don't know where I came from. Do they?

and it was that moment of, I didn't say anything, you know, I was like, gosh, maybe I'm like fricking lucky to be here. but it happened again and again. And I just got tired of it. I'm like, you know what? And I finally raised my hand in one of those meetings, I was like, guess what? I went to San Jose state... awkward again.

And. And then that was a moment. There was a recruiter in the room and she said, wow, Erica, like you here, you are leading such a massive team at LinkedIn. And the results, like talent can look different and it could look diverse. It doesn't have this box that it represents. And we need to think about things differently.

So I said, great. the thing that happens is the sourcing. As soon as you get those candidates, that's where you need to start. Because it then gets to us.

And so she did this exercise. She's like, okay, I figured it out. Guess what I do. I talked to all my recruiters I'm in a meeting I'm coaching them. Let's find diverse candidates. So I decided to throw up blind profiles, here's a profile that looks like this. Here's a profile that looks like this. And we, okay, which one would you hire? Like that one!

And then when we revealed the profiles everybody said no to you. Thanks. I was the person that they said they did not want to hire. And they're like, look, that's how they started changing it. And then it turns out. Fast forward. What's amazing being at LinkedIn is that's why women in tech and diversity is so important to me because talent is different.

And now I look back at our stats, cause I know all our stats, there's like 30% plus that come from San Jose state and these other schools. And now we're thinking about like, let's go and get these other demographics schools.

And bring them in a fact, another program that I helped incubate is a program called reach. Because there's a lot of people that are trying to get in technology and maybe they chose, being, majored in a different way. or They took a bootcamp or they had a different major. And then they, someone has that checkbox against them again. And it's like, how do you get them into the field?

So we actually created a program. We basically put it out there. They said, tell us your story. Why do you care? Why do you want to be in tech? We had like 700 applicants apply. We brought it down to 25 and we said, we'll teach you how to code. And if you meet the bar in nine months, we'll hire you full time. Isn't as at LinkedIn, as an engineer.

And then guess what happened? We basically hired all of them. They're all engineers at LinkedIn. We're running a second cycle, of that program, but that's how you look at things differently and you get these different results. So we're always challenging the norm. And that's how you have to think about talent quite a bit.

So it's just these inspiring stories. Just don't get stuck on a path that is not perfect. Because there's so many imperfect paths. And I think about like our head of our SVP of product of engineering, didn't graduate from college. My husband didn't graduate from college. We're both misfits at home. That's perfect.

You know, so I think, remember that talent is different and it can come from anywhere.

The common struggle to balance being a problem solver and being a bottleneck

Claire Lew: That's incredibly inspiring and, (applause) and I think, so wonderfully true and counterintuitive to the whole topic of what we've predefined as patterns in our head for being successful.

So I want to flip that question around to actually a question that's Oh, it looks like here is actually the number one voted question for tonight, which is.

Okay. So you've talked about success, Erica, and for all four of you on the panel, whoever wants to jump in on this. how about failure, right? When have you seen or noticed for yourself struggling to grow into that vice president role?

Jerry Krikheli: think one thing that I'll mention, or one thing that I've discovered about, being a VP of engineering is that. I would actually, if I could choose my own title, I would probably rename myself as VP of problem solving. because at the end of the day, I think, and whether it's at large companies or small companies, a lot of things just boil down to different types of problems that you have to solve. And I think people that will fail to graduate into the role are people that are going to limit themselves in terms of the types of problems that they are able to solve.

A lot of the problems for those of us that kind of come from a technical background. As you're growing through your career. A lot of the problems that you're solving are all technical problems. They're all technical challenges. You have to learn something, then you apply it. Then you learn something more complicated then you apply it. Then you learn how to apply it to a system, et cetera, but they're always technical.

And then as you end up running an organization, you realize that a lot of the problems that you have are actually not technical. They're probably either people problems or process problems or a combination with both people and process.

or other people that you're interact with, but at the end of the day, it all comes down to issues that you're going to have to solve that come up all the time.

And we've had great product plans, great execution. great direction that we want to follow. And then every once in a while there's a monkey wrench that gets thrown in that just distracts the whole organization.

I think last year it was a GDPR and we've got some people, all of us have GDPR.

Claire Lew: We're all nodding our heads.

Jerry Krikheli: The difference between larger organizations. As I know at Google people started working on it like three years prior, we basically had maybe, We can, we knew it was coming, but then we ignored it for, 12 months, then 11 months, then 10 months, then nine months, then eight months. and then at some point we said, okay, if we keep it going at this rate, we're never going to do it. And we had to mobilize nice and really pivot the entire organization to saying, look, this is something we just can't avoid and we have to get it done.

And at that point I sort of jumped in and said, look, my problem right now is this problem. And it's more important than any other problem I have to solve, because if I don't ignite that process, then it's just never going to get done organizationally. So I have to give it that gravitas. And we've had kind of lots of instances of things that have just randomly come up that for lack of anybody else taking it on, I basically said, look, this is a problem.

We need to solve it organizationally. I'm just going to go and solve it. whether It's part of my job description or it's not part of my job description.

Cathy Polinsky: So that's important, but let me balance that because the other anti-pattern I've seen is you become the bottleneck and the chief problem solver, and don't build your team to solve problems.

and so I'd say if you are not good at hiring and you have a junior team. You can't elevate yourself to that VP of engineering role. So you really want the leaders under you that can help you take up that bigger step. and then, can you actually use those people, and delegate to your team and start to take on a more strategic role.

I think that's another anti-pattern that I've seen.

Claire Lew: Absolutely. I think that's a wonderful counterbalance. So for no I, in the most perfect way, again, like tonight is all about the variety of paths that there isn't just one set pattern that there are many.

How they cope with and manage stress

And so I want to end though with a question that was earlier up on here where I thought, Oh, people must really want to know the answer to this question.

stress. So yeah, it sound familiar to anyone? So in the. one sentence or less, I'm going to hold you to it. One sentence or less. I'd love for you to describe how you handle or cope with, or sort of manage stress. It could even be a word for myself. I'm like, Oh, I have one word, but, would love whoever to start, but I'd love to you for everyone. One Sentence.

Erica Lockheimer: I have time for me. I don't take any meetings before 10 o'clock. I run every single morning now that my foot is getting better. And that's, I run away from everyone. That's my thinking time. So I need time to myself. By myself. No one else.

Claire Lew: Amazing. Thank you. Awesome. Thanks Erica.

Richard Wong: So my one sentence, is simple. I play with my kid.

Claire Lew: Yeah, that gets claps too. That gets claps too,

Jerry Krikheli: I would probably say two things. One, similar to Erica. I tend to run in the morning and that tends to help. the other is for pretty much everything in life. I have this saying that this too shall pass. And no matter what it is that always tends to be true.

And no matter how stressful kind of you are in the moment, I just tend to look, either an hour or a day or a week or whatever it is past that moment and figure that look at some point, I'm going to look back and these things are not going to look as bad as they are right now. And so that tends to level out the level of stress.

Claire Lew: Very long sentence, Jerry, but it was a good one.

Jerry Krikheli: It's a very long run on sentence.

Cathy Polinsky: So I do a bootcamp and I also play with my kids, but the big thing that helps me with stress is just talking to people. So I have my mentors and friends that I can just talk out problems. And that's super helpful for me to realize that I'm not alone and that other people are dealing with similar issues.

Claire Lew: Well, I hope tonight was somewhat stress relieving than for you for Cathy but can we please give everyone up on this panel, a big round of applause.

more to listen
Discover
EventsVideosSpeakers

Contact Us


Get social

Copyright © 2019 SFELC. All Rights Reserved. / Privacy Policy / Code Of Conduct
Home for engineering leaders
Login
|
Sign Up