Episode 25 | Reviving Engineering Teams & Overcoming the Fear of Shipping With Craig Kerstiens

Craig: [00:00:00] I'm envisioning like the Warriors just now, right? Like it was- was Looney taking all the blocks, right? Like you're not Steph Curry. You practice, you practice, you practice and you build that muscle, but Steph Curry taking the game-winning shot is from the last 15 years of constant conditioning, right? And it's the being the role player. Kevon Looney is so ecstatic when he lays out an awesome, you know, screen or block, and it's just like, man, he's just going back up the court like smiling, like, "Oh, yeah. I got him good," right?. It's not going to be in the highlight reel, right? But it- it's what wins the game and what gets you unblocked.

Intro: Welcome to Developing Leadership, the podcast for engineering leaders where Eiso Kant and Jason Warner share their lessons on the ins and outs of managing software teams. Today we have Craig Kerstiens on the podcast. Craig runs product and engineering at Crunchy Data, and has been incredibly influential in the postgres community over the years.

The guys chatted about how to take [00:01:00] over a demoralized engineering team, implementing positive cultural change, why you need to get your teams to ship more, and how to pick North Stars. As always, this episode comes with accompanying show notes, with a deep dive into the main topics, mental models and key moments from the episode. Find them at developingleadership.co, and linked in the episode description.

Eiso: Hey, everyone. We're back again with another episode of Developing Leadership. Today we have Craig Kerstiens with us, who runs product and engineering at Crunchy Data. I'm particularly excited to have you on, Craig, because Jason and you have some history, so this should be a pretty fun episode. I would love for you to talk a little bit about your background, and then we're going to parachute into some of the topics that I know you're uniquely capable of talking about.

Craig: Yeah, sure. So, my background, I'll give the kind of extended history, and then fast forward to the relevant stuff. Originally from Alabama, so we can talk about barbecue if we want. Or- or, you [00:02:00] know, Alabama football, either of those. But, came out to the bay area. Started at Accenture, inside one of their R&D labs. I was told it was, you know, a startup inside a big company. Every big company says that. It's never like a startup at all.

Craig: Left there a couple of years later to go to a startup that I joined in the database space. During the- the last kind of crash in 2006, 2007 range. Joined when they were about 10 people, grew to about 30, dwindled back down to 10. So I saw that up and down ride. Little bit later, found myself at Heroku, in, you know, the early days of Heroku, around I think employee 20, 25, something like that.

 We had, you know, functional engineering teams, and then we had like myself and another one person kind of as the first product managers floating around. Not really a product team per se, but it's like, "Oh, we're going to figure out how to do this product team, as we've got a bunch of engineering teams." ran a whole bunch of product areas at Heroku. Most of my time was building and running Heroku postgres, but ran their API team, their CLI team, their add-ons marketplace. [00:03:00] So touched most areas of Heroku over the course of about five and a half years.

 Left there to go to citusdata, which turned postgres into a sharded distributed horizontally scalable database. Built their cloud product. They were acquired my Microsoft a few years ago. You know, was in a lot of meetings there. Decided to get back to building. And, joined Crunchy Data a couple of years ago to- to come on and build out their cloud service. Really kind of doing everything postgres there, so I support a lot of on-premise postgres customers, have a fully managed cloud service, and running product and engineering there. So, have overlapped with Jason I guess at a couple of places. I guess technically twice, at- at Heroku and- and Microsoft. But come at it from different angles.

Jason: Yeah, and- and Microsoft, where it was a startup in a startup, right?

Craig: Exactly. Exactly.

 And, I think come at it from a different angle, right? Myself typically earlier stage than Jason, often wearing that product hat. Jason coming in from the engineering side. But I think both of us at times coming in and- and tackling a lot of the same problems, where, [00:04:00] cool, here's a, you know, nonfunctioning group, or a- a area of the org that's stalled out, that we've got to get cranking and turned around, right? Jason, well, he's, you know, commonly runs engineering. I- I think he also dips into that product side, right? Here's a product vision. And 

Jason: so-

 Yeah, I- I think y-you and I have like overlap, 100%, I think, but you're like product-oriented with the engineering sensibilities, and I'm engineering-oriented with the product sensibilities.

Craig: Yeah. And I think you look at Jason and he comes at it from a slightly later stage. I'm that earlier stage, where we're just figuring out product market fit. Jason, you've got product market fit and then scale it. So, I think we'll- we'll probably agree on some things, mostly football, and then disagree on- on a few others. 

Eiso: Fantastic. So Craig, you said something really interesting, right? Like parachuting into a company that isn't running optimally. First of all, let's maybe start with, what does it mean not to be running like a well-oiled machine?

Craig: I- I think there's a couple of things, and it's product and engineering are different, right? If I think of the like sales and marketing orgs, [00:05:00] right? Like a new VP of sales comes in, and he's bringing in his whole sales team. You see the announcement that a new VP of Sales is hired, and half the sales team is looking for new jobs because they know they're gone. And same thing with marketing. Like I saw this actually a few times over like within Heroku, where there- we went through iterations of five different marketing departments before one kind of stuck, and it was bumpy. 

And you hire a new VP of Engineering, and it's, you know, if you've gotten rid of one and hired a new one, it's- it's because you want to kind of change your trajectory and your course. And same thing with product. But that VP of Engineering, that VP of Product doesn't have the ability to can all of engineering. It's, here are the pieces you get to work with.

And I think when it's, you know, not working, not functioning optimally, oftentimes I've seen it, there's this unicorn project, right? There's this thing that the org's have been trying to do for two years, for five years, and it's this North Star, and they've been trying it over and over and over. One of those projects was teams and orgs back at Heroku. Like [00:06:00] it was six years for us to- to ship that, right? It eventually happened and not in the most elegant form. There was another one within the add-ons team that I was responsible for, it's, it's- it's funny, because one of my, co-founder- or one of the founders at Crunchy Data says, you know, "your reward for winning the pie eating contest is- is more pie."

So at Heroku, I had Heroku postgres as a well oiled machine, right? And we've got like six, seven, eight different engineering teams. The Heroku postgres team, we ran our own marketing, our own product roadmap. We were pretty well carved out. And the rest of the org looked over at us and they were like, "How- why are they doing everything so great? Like why can't we do that? Why can't we do our own stuff?" And they were just kind of stuck in stagnant, right? And so, some of the leadership came in and said, "All right, Craig, you've got Heroku postgres well oiled, well functioning. Now come fix this other area." I'm like, "That's not what I wanted. I- I wanted to relax. I wanted to enjoy this."

[00:07:00] And came into the team, and they're like... it was really funny, because I- I laid out this vision. I came into the team, I know what they'd been working on, right? We were in the same company. It wasn't like I was new to the company. Laid out this vision, and one of the engineers just like, was like white faced, pale, like frozen in their steps, deer in the headlights. And it was three months later that they- they came to me and said, "Craig, you terrified me. Like we couldn't ship anything to production, much less accomplish this project, and you're laying out this like six month vision for it."

And I had to step back and like, "oh, they don't see step A, B, C, D, E to get there," right? They've been so beaten down by this inability to ship and make progress, that they were just demoralized. And this is a great senior engineer, right? Like tech lead within the company, can make good decisions, good refactoring. And it was just that- that emotional beat down that they'd taken, of how do we start to make progress there? And- and we [00:08:00] were talking, you know, right before we- we started recording, that you just ship something. Like doesn't matter what it is, ship something. And that was the- the first thing that like, that first week, we shipped some things.

Now, I had to actually, as the product side, had to tail back that vision. It was weird for me. Because I use- I'm used to operating really transparently, "Here's where we're going, here's the vision, here's the roadmap." Nothing's hidden. And I had to tail that back and keep that to myself for a little while, while they built up this confidence for the ability to ship stuff. 

Eiso: One of the things you're mentioning is your tactic is get someone to just ship something. But getting to ship something is one thing. What comes after that, and- and what is the kind of cultural change that you're- you're trying to get? And honestly, how difficult is it to get it through? Like is just this notion of we're going to be able to start shipping things enough? Or is there a lot more work that needs to be done? And, I suspect there is. 

Craig: Yeah, there's definitely work along that journey. I- I do think that like shipping things is a super important [00:09:00] first step. I look at it and it's like, I've seen people try to fix teams, and they're like, "We're going to refactor, we're going to create a plan, or we're going to, you know, do this on a new framework," or- or whatever it is, and they're still just stuck. That first step...

 Yep.

 ... so important. You know, after that, I think there's a lot more. But that first step, I can't underestimate that. Because every time I've come in, there's just this inability to ship. And for me wearing the product hat, I'm curious on Jason's side, right? Because he often comes at it this like engineering kind of mindset with a product emphasis, me product with an engineering, you know, kind of mindset, you know, tacked onto it. How much do you layer in that roadmap and that vision, or is it just get something out the door, right?

Jason:  I think shipping is probably the most important thing an engineering organization can do. You know, when you combine with product and engineering together, I think if they were 80% oriented towards just continually shipping stuff, the other 20% is going to [00:10:00] make up for that. The 80% is just like so bedrock for them. But if they're only oriented towards 20% for shipping and 80% for like strategy conversations or- or longterm initiative thinking and all that sort of stuff, they are going to become an underwhelming, very below mediocre organization super quickly.

I think it's a classic mistake many organizations make, which is, well, engineering or X, Y, Z is focused on shipping, so let's have- let's have the predominance of our time be focused on these lofty high level conversations, and they just don't- they don't keep track of just continually moving it forward.

So, you know, Heroku- Heroku, when I joined, was already a really good organization. It was- it had a lot of stuff going for it, and still there were things that we could do on the engineering side to increase the efficiency of shipping. GitHub was an entirely other story. Entirely different. And I remember like my- going in and my very first day was just like, just ship something. Just ship anything. And GitHub, you know, as an organization, hadn't shipped anything meaningful for probably a two year [00:11:00] period. It had shipped some pockets of things, but it was also famously got a Dear GitHub letter in the- in the middle of all of that, and a bunch of other turmoil.

And so it's just about, you know, decalcifying the organization to a degree. Go do this, go do this, go do this. And then killing possibly a whole bunch of things too. Then you can layer on what we're doing longterm. Here's where we're going, here's why we're going and doing all that sort of stuff. And then there's- there's ways to kind of like, you know, root yourself five years out, but ground yourself, today and then build a path towards that. You can't do it all at once. You've got to do it incrementally as well. So you can maybe like give a semi-opaque vision for five years out, but a very concrete go do X, Y and Z today.

My last comment on this one would be, one of the more famous things that GitHub did in about the 18 months or so before we got acquired, was we had this Paper Cuts project, led by an ex Heroku person at GitHub, which was, we're just going to go and pick [00:12:00] off hundreds of small little nits around GitHub and get those things shipped. These were not strategic things. These were small little nits, but it broke the non-shipping culture of so many different teams down, and the community felt it and a lot of other organizations felt it. And you just, it- it may sound strange, but you've really got to do that stuff. 

Craig: You- you said two things in there I absolutely love. One is saying, "No, no, no." Like when there's that culture of like, "Hey, we've got this large project that we're going after and we can't get it out the door and it's making no progress," you know, it's like, full on stop, ship one thing. And you do one thing well, you earn the right to do two. You do two things well, you earn the right to do four. You earn- you do four things well, you earn the right to do eight. Right? And it's like, and I do this with other areas that- that have reported to me, at times even in marketing, right? It's, cool, you're doing too much, stop. Here's the one thing. Here's the two things. Here's the three things. And then, you know, on that Paper Cut side, I- I love that. Like I, I think it's- it's [00:13:00] Cathy, right? that drove all that-

 Yeah, it was Cathy. Cathy did it, yep.

 I like- I- I keep nudging her, like talk about this more, blog about this, write about this. Like it's a wonderful approach, whether you're, you know, later stage and you've got a mature product and it's like, okay, how do we just make it better instead of all these big projects? But I actually love that for the start shipping, right? Like what's the small thing that- that we had a support ticket on, that we could not have a support ticket on if we built this feature, right? Like forget the big projects to start.

The other thing you mentioned in there is like pick a thing, right? As product, like when you come into those orgs, they're like, there's a bunch of North Stars. And it's like, doesn't matter what they are, just- just pick something to go.

Jason: Yep. When I joined GitHub, so thankfully GitHub had a couple of really good things going for it. So one is the infrastructure team at GitHub was world class, like literally just like out of this world, world class. And no one actually knew who the GitHub infrastructure team was, but they just- they did their work, and they understood it, and they were- they took care of themselves. And then sales, the sales team [00:14:00] was, was very good. And they were continuing to sell, and, you know, enterprise revenue was high, even if some of the other stuff was slowing down the business.

 But from a strategic standpoint, sales didn't actually know what they were selling, they just kind of made up stories because there was no North Star for GitHub. In fact, there was still conversations of GitHub for lawyers, GitHub for doctors, GitHub for various other industry verticals. And while I was not the CEO, and, you know, there's that- not quite public, but kind of sort of public how the- the transitions were happening at that time.

Just got to kill all of those conversations and say, "We are a developer tool. We're going to become a developer platform. We're going to be an end to end suite. We're going to do X, Ys and Zs. GitHub for doctors is not for us. That's for a doctor to go build, or somebody in that industry to go build and address that vertical. We're here to address developers and anyone who cares about the practice of software development. That's what we're going to do. We can become one of the most important software companies in the world doing just that."

Craig: I'm laughing because I can imagine all- I mean, so many friends that have been at GitHub over the years, and I can imagine just the GitHub engineering [00:15:00] team trying to build GitHub for doctors. It would be a- a fascinating circus to watch, with like, you know...

Eiso: So Craig, I want to throw something in the middle. None of this has to do with how great the engineers are, right? I mean, you- you can find this calcification, inability to ship in lots of organizations, where hands down, any of the individual engineers, we would consider fantastic engineers. So before we go into further like how do we- and how we're fixing it, like how does this get to that place, where you have well meaning PMs, you know, solid engineers, and all of sudden we're finding ourselves at either a startup, or maybe a larger organization perspective from you Jason, without the inability or without the ability to ship continuously anymore?

Craig: That's a great question, that I don't know how you stumble into, right? Like I've found myself through my career like- coming into it, and then like digging out of it, right? I don't know that I actually have a great concept of... I think maybe it's just you- you stagnate, right? Or, [00:16:00] I think when you have certain engineers, and I- I love to think about like senior engineers, not as the smartest person in the room, right? Not as a person with a great... and I've worked with some amazing, amazing engineers, and I keep them around me, right? But they have this desire to ship and keep shipping, right? And you can take that engineer and drop them into another team, and it will gradually start to be infectious, you know?

One- one of the ones that I- I call kind of my- my work-wife, you know, Daniel Ferina, he- you drop him into, a- any engineering org, and he's just gutting stuff left and right, and then shipping stuff. He's like, "Why are we doing this? It doesn't make sense. Just ship this out the door." And the one caveat with, "Just ship something. Just ship something," the one caveat I put on it is, can you undo that later? How much does it like take you down a road that you can't come back down?

And if you can come back from it, awesome, great, ship it. Don't care. And as a product person, I'm encouraging that left and right. Like as long as we can unravel it, [00:17:00] great, go for it. That's the only guard rails I'll put up in the ship something.

Eiso: So I like what you're saying, Craig, because you're- you're mimicking Eisenhower here, with kind of the two types of axis of decisions, right? Like easy to reverse, hard to reverse, high impact, low impact, right? And it's- it's exactly that. Like hard to reverse, we have to be incredibly careful about in our project engineering orgs. But when we're talking easy to reverse, then all of a sudden speed and velocity can matter a lot more, and we don't have to spend a lot of time discussing stuff.

Jason: Heroku had a th- I think it was from Adam Wiggins who said this. It might have been from, James, but it was decisions in 30 seconds or less. It was something along those lines. I- I can't remember who- who wrote it, but it was- it was very- it was very poignant, because basically it was like, do not overwhelm yourself or the organization with making an easily reversible decision. Just up and go do it, and reverse it. That's the whole point of like Heroku, if you think about it from a systems perspective, it was like that- that stuff was [00:18:00] supposed to be really to go do.

And if that's the case, don't spend time on it, go do it. Experiment with it and come back. If it- you can't undo it, yes, spend time on it, but don't If- then there's a tendency... by the way, in larger organizations this gets cover your ass political really quickly, which is let's gather 90% of the information before we can go make this, which can become years to gather that much information. But you're supposed to gather just enough information where you feel comfortable making this decision going forward, and the person who's making it should basically feel embolden to go do that.

But you've got- if you're really good at your job, you're able to do it with like 20 or 30 or 20- 35% of the information, not 90. And there's- they're two different modes of operating entirely. And 99% of all of the things in an organization should be in the bucket one. You- you are able to go on and do them rather quickly.

Craig: Yeah, I think it's really important on- for me on the product side and the velocity I bring, it's like, I don't have to be right 90% of the time. As a- to be a good PM, [00:19:00] I've just got to be right 51% of the time. Just slightly more than I'm wrong. Because if I take that l-long to, you know, to Jason's point, right? If I take that long to analyze the data so I'm right 90% of the time, we've missed the market. We've missed the opportunity. Like our customer is like, we're getting Dear GitHub letters, right? Because we're not doing anything, because we're so paralyzed.

And I think you- When you go from startup to large enterprise, right? You go from playing, Jason, you talked about this a lot, right? You go from playing offense to playing defense, right? Where as the- pull the goalie, right? Like the stats, like no ones going to pull the goalie in hockey, you know, in the- the middle of the second period, even when the stats say you should, because there's this macho mentality around it. But that playing offense and making forward progress, it's... and I don't know why smaller companies get stuck there.

Jason: It's interesting, because we talk about this in venture, the venture tech scene quite a bit, which is saying only a founder could make that decision. You know, like Zuck going all in on the Metaverse. Like no- brought in CEO could make, that type of a decision. And I don't think that's [00:20:00] necessarily true, that's a different topic entirely, but what I actually think it comes down to is fear. And it has nothing to do with that, because look at Slootman, what he did at Snowflake. Now, Slootman is a pure executer, but he was not afraid of making decisions, and, you know, and- and things of that nature.

Now, they're not strategic maybe product-led, product-oriented decisions, but they're still massive decisions, company level decisions. I think it comes down to fear. It can be bucketed into a bunch of different reasons why that fear exists, but, you know, the couple of times I've seen it, one was fear of why don't know why this worked, we don't know what actually worked. We're afraid of F-ing this up. We're- and we're so afraid of F-ing this up, that we're going to go pure defense. We're- you know, and that means not making bigger decisions, because we don't know what's going to happen there.

And then like kind of killing things that were quasi, we're getting mixed signal on from other people, because they don't have the convictions themselves. And, you know, there's other types of fear- fear at play, fear of losing your job or fear of politics or fear of blah-blah-blah, and all that sort of stuff, but I think fear kind of plays a root in it.

 [00:21:00] I've always said l- before too, the best head up manager is one that doesn't necessarily need a job, because they can be fired because they've got something else to fall back on or whatever. They ended up being some of the best managers out there, because they will actually say the stuff that goes unsaid, or do the things that need to get done, even though it's not the most favorable thing in the organization at the time. When it comes to high level leaders, PMMs or, other execs, I think that's triple true. 

Craig: Yeah, I think, as we've, you know, we started talking about, "Hey, you've got this stuck part of an engineering org, right? That- that can't ship." The first thing is shipping. I think the second piece of that is that north star, right? And like, Jason, you basically said, you came into GitHub and you said, you looked at a whiteboard and said, this, this, this. Don't know what they are, just those things, right? That gets a team rowing that same direction, right? And that rowing in the same direction, moving the same and- and communicating about it, right? Like a lot of those broken engineering teams also have broken communication. So saying here's the north star, right?

 Yes.

 Gets [00:22:00] them headed in- in that right direction. So you mentioned, high impacts, low impact. There's actually an exercise I love to do. I adopted this at Heroku, stole it and introduced it everywhere. Where it's a three by three grid for effort impact that I do with, engineering. So it's low effort, you know, high engineering, or low engineering, you know, high impact. And just super corse.

 It's funny, because those engineering teams that have been like down in the detail, right? And they've refactored things three times so they can get velocity, so they can get something out the door, and they haven't actually shipped something, they're like, "Okay, well this is two and a half weeks, versus this is three weeks." And I'm just like, no. It's high effort, low effort or medium effort, right? And you just start to put all these projects on the board.

And it's amazing the first time you do this with an engineering team that's been stuck, because there's a whole bunch of this like low- low effort, high impact stuff. There's like four or [00:23:00] five things. And we do this- this process every six months. And the granularity is like, okay, high effort is like three months of, I don't know, two engineers, right? Low effort is less than a week. And like, that's the granularity. We're not going to go and write a PRD for it, we're not going to scope it, like... and then they look and they're- it's like one hour and we've planned a roadmap for six months, and they're like, oh, we can ship something and now we have a direction to all go after.

Jason: So one of the things you just said there too, so 100% agree, it's basically just like it takes you very little time to actually be able to do this. One of the things that I- I noticed over my years, is if I were to go into an organization and, you know, going into something like GitHub, which is larger, if you don't have a lot of the pieces around, you've got to put people in place in various... at various places too, or bet on people or em-empower them.

If you walked into an organization, or a team, and you basically... I were to say that, but I weren't able to sit with them, I would say, "Hey, I want to give you a deadline. Two weeks from now, you need to ship five things." [00:24:00] This still won't happen, because somebody on that team has to step up and say there were the five things. There's still, for whatever reason, there's- it- it generally won't happen. So if you've just spent the next hour saying- picking those five things that will happen. And it's- it's literally the difference of just saying, "You have to ship five things, you know, in the next two weeks," or, "You have to ship these five things in the next two weeks."

And, you know, by the way, if you actually want to assess who leaders are in organizations, you go and say you need to ship five things in the next two weeks, and see who pushes to get that done, if anybody. And if someone does, they're likely going to be a leader that you can back on some point in the future. But if nobody does, you've got to- you've got to break that out and show them what it takes, and maybe give them one more iteration, maybe you could find a leader. But it's- it's kind of remarkable how simple it really is, but also how it's- it's n-not intuitive for some people to- to pull themselves into that situation and make that decision, for a variety of reasons. Maybe cultural inside the organization too. 

Craig: [00:25:00] Yeah, you mentioned, there, like, Hey, you- you drop in and you- you say that, and you give the extra hour and they get there but you- you don't give them that direction, and maybe you find out who the leaders are. We kind of hit on this, of like dropping in other engineers, right? To chain one-

 Yeah.

 ... one kind of, you know, just external force to drop in, that is used to shipping, right? Whether it's PM.

 Yes.

 Whether it's engineering. The other approach I've also seen is like where you set up, like you come into an org, right? As a new- new leader, a VP of Engineering or Product, and you- you set up one team as the model of how we want to shape all the others, right? Now it's... I- I don't know that one is right or wrong. I think it really depends on the dynamics of the company. But I've definitely seen both approaches, where you drop in individual pieces to kind of infiltrate and- and shift the culture gradually of these existing teams. Or you say, here's the model team that we're going to set up. Now we're going to cross pollinate, right? Now at the- the middle management layer, we're going to have them [00:26:00] meet, and this one kind of share how it's working and how they replicate that.

Jason: I mean, I think in general you're going to end up doing a multi pronged strategy when you're- when you're inside and organization that's large. So, good example here, as I mentioned, the infrastructure team at GitHub was incredibly good. Well, I took a couple of those more senior engineers and started putting them in other teams, just as you were saying there. And one of the most important external hires, in GitHub's history is, we share him too, Max Shoening, you know, ex Heroku Max. And Max was at Google, he had a startup, and he was my- my number one person to go recruit for a variety of reasons.

He's got a- he's got a strong product aesthetic and taste. He was a vision as well, and we kind of mind melded on those sorts of things. But he is allergic to not shipping. Like allergic to it. And so, you know what the organization needs, he's got a bunch of the overlap, he's got passion for it, but he also just cannot sit idly by. And, you know, he's got the high [00:27:00] frenetic energy type of feel to him. And so, you know, it's- you- you end up doing a bunch of those different things at once. And, you know, it's- it feels weird to be in the middle of doing it, but when you get to the other side of it, it also feels really good too 

Eiso: but- but Craig, Jason, both of you have been in positions where you're- you're the head honcho, right? You can come in and start making change happen. But I'm willing to bet that the vast majority of our listeners are not, right? And- and they might be stuck in environments, where it's not about not shipping, but it's definitely probably calcified, or where, you know, we're stuck on a release train, or we're getting stuff out only every couple of months. Like they're somewhere in that gray area. It's not the extreme that you encountered at- at GitHub, but neither like have the full autonomy to- to go and say, "Hey, let's go make these changes. Let's bring people in."

Like, you know, Craig, Daniel Ferina that you mentioned, your work-wife, who I think everyone's going to write on LinkedIn now, by the way yeah, not everyone ha- 

Craig: he- he's heard it for years, so it's no surprise to [00:28:00] him.

 Yeah. 

Eiso: so, you know, not everyone has a Daniel. Like, what do you do? What do you recommend to our listeners who are kind of in that- that middle, like stuck in the mud in the middle?

Craig: I- I think Jason hit on it. It's- it's simple but it's hard. It's- it's fear, right? It's make that decision and ship something. And if you've been in that organization that's calcified, you're going to get pushback of like, "oh, is this the right decision?" And you- you need to make one. And you're going to have to defend it extra, right? And you're going to have to say, well, here's why, and here's the, i- I love, you know, Barbra Mento, SCQA, right? Like here's the situation. Here's how I thought through it. And if- if you've got an exec over you, they're also calcified to that and probably have that fear, right? And you- you need to basically... you're going to lose sleep at night. Like you're going to wake up, you're going to have nightmares about it of making the wrong decision.

 Like if you- if you have the track record, right? And you-you're a good manager, and you can leave tomorrow and have a new job, right? Then you [00:29:00] have less of that fear, right? Like I'm- I'm betting on me, and I know I can, and if it goes wrong, well, I'll- I'll move onto the next thing, right? But I have this track record. And for me, building database companies, right? Like at Heroku, I was part of an incredible journey. I- I think I impacted some of it, but man, everyone around me and everyone bettered and challenged everyone.

Then I went on to citus, and it's like, I think I know what I'm doing here, but I'm not sure. And every few months I'm having this fear and panic, even having done this before, having, you know, a good track record, it's, am I making the wrong decision? Like these methods should look this way is six months with us doing this, but I've got to wait six months to know for sure.

And then it all- it shockingly went according to plan, right? But we made decisions, we followed the process. You know, now doing it again, right? At Crunchy Data, it's like, okay, I'm- I'm a little more relaxed, less anxiety, losing less sleep. Apparently I'm relegated to just doing databases, but, you know, it's... okay, it's a little easier. [00:30:00] That first time, it's easy but it's hard. It's- it's hard on the- the emotional toil, the mental, the losing sleep, the n- like literal nightmares, right? The amount of times I woke up worried about attachable resources for add-ons at Heroku, so they could be shared across apps, right?

It was a project that had nev- like for five years it had been tried. And it wasn't like, "Craig, you're the head honcho, everyone's going to follow you," it was like the team was beat down, right? I had to get the team up and excited and engaged and- and figure out the process for that, and try different things. But making that decision of like step one, two, three, four, is- is huge. And you're going to take an extra beating and defend it extra hard that first time you do it, if you're not in that position of power.

 Yeah.

 But dig in and do it. Like you'll- on that other side, right? You'll look back six months later.

Jason: I think this one is- is, hard, because people think that it's hitting the game winning shot is what it's about, when it's [00:31:00] in fact it's actually making, you know, it's making the block or the cut or the other things in basketball. So like if you're an- you're- you're an early engineering manager, or mid level and you're stuck in a calcified organization, what do you do? Well, you can't look for the big project that's going to save it, or any of those. That's not what it's about. It's literally about fixing spelling mistakes, or changing the- the 400 paper cuts, or looking at the support cue and seeing, like we- we talked about earlier, and seeing that you've got these couple of things.

That decalcifies it, and that's- that's the work that no one's actually going to really see, but it's going to matter for the internal operation of the organization. And somehow that slowly starts to seep out. But again, if you're looking for that moment, that game winning shot moment of the, you know, walk off three run homer type of deal, that's never- that's not what it is.

 You- you- you- you-

 You might earn the right to be put in a position to do that later, but that's not what it is. 

Craig: Yeah. I mean, I'm- I'm envisioning like the Warriors just now, right? Like it was- was Looney taking [00:32:00] all the blocks, right? Like you're not Steph Curry. Like you practice, you practice, you practice and you build that muscle, but Steph Curry taking the game-winning shot is from the last 15 years of constant conditioning, right? And it's the being the role player. But coming in and like doing that, right? Like Kevon Looney is so ecstatic when he lays out an awesome, you know, screen or block, and it's just like, man, he's just going back up the court like smiling, like, "Oh, yeah. I got him good," right?. And that's the small thing that, you know, yeah, it's not going to be in the highlight reel, right? But it- it's what wins the game and what gets you unblocked.

Eiso: So Craig, you touched upon something, and- and Jason, you mentioned- I think you kind of skimmed over it when you spoke about Frank Slootman. By the way, as a Dutchman, we're all totally mispronouncing his name, but that's okay. 

Jason: Well, it- it- is it- is it Frank? 

Eiso: That's right? Frank 

 It's- it's- it's Frank Slootman. Oh my god, I even hear myself-

 Slootman.

 ... the Dutch accent. No, but the- the thing, I mean, Frank is known for the [00:33:00] fact of amping it up, right? And Craig, you were talking about that beat down engineering team, that hasn't been able to, you know, get things shipped. And all of a sudden, you as a leader are responsible for- for bringing the energy back. And, you know, how do you do that, and how- and- and is it something that has to be innate in your personality, or is it something you're consciously trying to like show up with, I mean in the past in the office, but I guess these days on- on Zoom? 

Craig: There's- there's a few tricks I use, and it's usually not like come in and amp them up and excite them, because they're like, they're beat down, right? It's like-

 You know, you lose 20 to nothing in a soccer game, you're not like, "Guys, we'll get them next time," right? It's like, that's not... it's like, here's what we did good, here's what we can build on, here's the small things, right? I have a whole bag of tricks. Like when I come into a new team, I'm- I'm inviting the team over for dinner. Like Jason's been over to dinner at my house. Like I love the come over for dinner, let's just hang out. Let's build a rapport. How quickly can we build that relationship, right? Here's my world view and where I'm coming from. Here's, you know, what's yours? [00:34:00] And just the whispering in their ear of, that's a great play, that's a great move.

 As the PM side, I'm the biggest cheerleader. My goal is- is not just to tell them, you know, here's the roadmap. That's a small, small piece of it. 

Jason: I'd say this too. I the... let's talk about like the- the category of turn around, right? Turn around at a company level or a project level or a team level or any of those sorts of things, because that's effectively what we're talking about here. And the overall strategy of the turn around might differ based upon contacts and situations of where the team, the company, and all that sort of- and project, and all that sort of stuff are.

But, techniques are similar, and you can employ the techniques at various stages too. So the- the humanizing yourself, that- the- the getting to know people, the shared contexts, the rah-rah-rahs, the- all that sort of stuff. There's all those- there's a category of all these things that we need to- to employ as managers and leaders. But you don't- it's not universal all the time. It's not like I'm going to be humanizing myself 100% [00:35:00] of the time. It's important in certain situations to do it early, or not to do it early too if you're going to be... you know, there's a variety of ways to think about this.

So like when Slootman, Slootman's, amp it up, what he did at Snowflake, it's important to recognize that Snowflake was actually a good company and it was decently well executing. And his ability to amp it up at that moment in time was because it already had a certain trajectory. They just wanted to do one of these on the line. He was able to do that. But he walks into a different type of company, which the line is looking like this, not from a sales perspective but from a plane about to crash- from a culture perspective, it's very different, because that is a completely different type of turn around. That is a- that's a- we can't- we've got to like safely level out the plane before we can actually start to do this again. So I think you've got to recognize those things, but the techniques are, you know, employable at certain different stages, and they're all kind of universal, because we're all humans at the end of the day.

Eiso: So, Craig, you've- you've shared a lot with us, and I think, to be honest, for a lot of [00:36:00] engineering leaders listening to this, and also like product engineering leaders, there's a lot of practical kind of roadmap, how to get out of, you know, some form of calcification back to shipping. Now we are back at a stage where we're shipping, we have momentum, how do we- how do we make sure that as we start going through that like hyper growth or like serious growth phase we don't lose these efficiencies and like momentums that we've just managed to build up?

Because we're- we're all of a sudden finding ourselves with a whole bunch of extra priorities, other challenges coming our way. How do you keep this momentum going as you scale?

Craig: I mean, I think it's the- the challenge of any scaling, right? A ton of it is communication. Like what worked at 10 breaks at 20, what worked at 20 breaks at 50, what works at... I remember, you know, when the Heroku all hands meeting was, cool, we ordered pizzas on Wednesdays and sat around the lunch table. Right? Like, and then it's like, wait, we don't fit around the table. Now we have to like have a meeting invite, and and I guess we have to do [00:37:00] slides, right? Like that sounds- feels corporate for, you know, for- for where we were coming from, right? 

 And then it got to the point where like, great, we've got 150, 200 people, and we're going to have an hour. This is high value time. We're going to make everyone that presents do a dry run. Like, wait, I've got to do a rehearsal the- before an all hands meeting? I used to just like throw the slides together.

 I think the communication is the biggest piece, right? And once you get the cadence of velocity, it's pretty easy to maintain that. Then it's layering on that strategy, that vision, right? That's where you- you- you start to- to try to take the, you know, the home run, right? The- the grand slam. The, what's this big ambitious thing. And by that point, you've learned who those leaders are, right? It could be down in engineering, it could be up at the exec level. You know who those special players are, right?

I actually build out a list of who are my impactful players, right? And I have it up of like, okay, if I need something, I can go to this person, I can pull them out of this team, place them in this other [00:38:00] one. I can create a- a impromptu project team, or like I want to go to them for ideas or feedback, right? And it- and it goes all levels down, right? Like you can go down three, four levels and know that impactful player that you need. And so, you take those kind of key pieces, right? And it's not that they're a better engineer or worse, but it's like they know that- that vision, and they know that ability to ship, right?

And- and they see the problems in other ways that compliment you, then you build that into the big vision, right? Where are we going, what are we trying to get to, what's the, you know, what is the grand slam that we can go and- and tackle, because we can build these things on layers, right? And it gets more complicated and you need more pieces there, but you need to know who those all star players are, and then you need to kind of have that process where you're congealing that into a bigger vision.

Jason: One of the things that I took away from Heroku, Salesforce and then tried to apply that at GitHub, and I think I saw there too, was this, was that processes protect certain things in many ways, and we have this false sense of [00:39:00] security over like over done processes. But at the end of the day, it's going to come down to betting on people, and having those pillars of people. Like Ferina, Dan Fernia's a really good example here, that he's somebody that you can take and pluck and put into other organizations, and they get better from an engineering perspective really quickly because of his sensibilities and what he does.

Inside your organization, I have a very strongly held view, which is, you want to take on initiatives and get stuff moving at any size, there is a set of people that you would bet on to drive those things to completion. And then the other set of people would help and enable that and be useful along the way, but that set of people generally is not bet-able on terms of like completing the project and driving it with initiative.

 So the strong held view I have is like you can only achieve so many objectives that you have people that you can bet on to go achieve those objectives. And I'm not talking about like VPs or Directors, I'm talking about people. And these are like, as Craig said, engineers or PMs or marketing people. Every organization has them, and they kind of know who they are, and, you know, the good leaders know who they are and spend time with them too.[00:40:00] 

You know, that was the other thing is, somebody at GitHub asked me like, why are you spending so much time with X, Y and Z, marketer, an engineer and a sales person. Like, because they ship. They get stuff done in each one of these organizations, and I kind of need to understand what they hear, see and feel on a regular basis. And yeah, they don't directly report to me, and they might be three or four chain- three or four levels below, but I- I need to understand what they're doing, because they're the ones who are hitting all the friction and road block in the organization, so I can kind of synthesize it.

Craig: I think that's a huge piece right there, like I- I've seen, you know, executives that know who they are, and say, "Yeah, that's a good one, so let's promote him, let's give him a raise. Let's, you know..." but don't spend the time with him. And I think that's huge to- to have that better holistic picture, and steer the ship from a broader perspective. I think that's a- a big one, where you may know who they are, but spend time with them.

And there's- there's a balance, so you don't go and, you know, alienate the other executive that they report into, right? Like you've got to do it in a balanced right way. You've got to manage personalities. At the end- at the end of the day, we're all people, right? And you've got to coordinate and navigate [00:41:00] that. But spending time with them is a- a huge one.

Eiso: I love this. I think it's also a fantastic place to- to end today's episode. Craig, is there anything you would like to share with all the engineering listeners, engineering leader listeners, that we have with us today?

Craig: No, I think it was a great conversation. I managed to troll Jason so much less than I- I, intended.

 So I- I think I kind of was- was well behaved. I think one friend described me and Jason as like the Statler and- and Waldorf of tech Twitter. I don't know if that's actually true, but that's mostly all our conversations are on Twitter. So it was nice to have a good productive conversation.

Jason: It- it helps that it's not football season.

 Yeah, it's helpful that it's not football season right now, because it would be a little bit worse if it was football season, so.

Eiso: Fantastic.[00:42:00]