Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I’m sitting down with David Guttman. David, welcome. Thanks for taking the time to talk with us.

David Guttman: Yes, thanks for having me.

Shane Hastie: So who’s David?

Introductions [00:46]

David Guttman: Indeed. So I’ve been working in software for over 20 years. Companies like Disney, where I think you can still see some of my fingerprints of architecting and building systems there. So you go to disney.com, starwars.com; that’s some of the infrastructure that I did when I was there. But I’ve also built big ad servers, 10 billion requests a day, and from then I’ve gone on to start my own consulting company where I build engineering teams for founders. Most recently, one of the co-founders of MasterClass, an education startup. I took that from pre-launch to exit Series B and then exit recently. Now a lot of my focus is taking some of the internal tooling that I built to support those teams and build out a more public-facing SaaS that other people can take advantage of. So still coding, having a lot of fun coding with AI, and yes, that’s about it.

Shane Hastie: So building engineering teams for other people, what’s that entail?

Building engineering teams from scratch [01:50]

David Guttman: So I think of it as four main phases. So that would be the recruiting, the vetting, the onboarding, and the managing. So recruiting is a combination of knowing who you want to attract and the types of people that would be, well, I guess those are the same thing, but what are the problems that you’re working on? What are you trying to solve, and who are those types of people that can help you? And then how do you position yourself in a way that they would be interested in coming? So that’s sort of the attraction part. And so, you mentioned for other people. Yes, I mean, I don’t know, it’s at that point in time; it’s not like I’m separating others and myself. I mean, I very clearly know what the end goal is. I know what the technology is and things like that, so it’s kind of hard for me to say that that point is for other people.

Vetting is kind of the other side of that coin. Now that we are attracting those people, how do we prove that those are the ones, or how do we get a better sense or prediction that those are the type of people who will be helpful? And then that’s the big dividing line. And so after vetting, they’re now on the other side of the fence, and they are working with us. And then that’s the onboarding, how to get them quickly up to speed with the culture, the process, how things are done. And then management is the more the ongoing. So cruising altitude and keeping that going.

Now, I would say for the other people, the first two I think doesn’t really matter. I guess the second two, the onboarding and management, does because then that’s my view of how these things should go and are successful, which sometimes can be at odds with depending on who I’m working with. Sometimes the founder could be bought on, but maybe not product or so on, and that can be a little trickier.

Shane Hastie: So you’ve written a book that is a survival guide for people who depend on devs to get things done. Why a survival guide?

Avoid cargo-cult copying [03:55]

David Guttman: Yes. I think one of the criticisms that I get in the book is that it doesn’t say, like, “Oh, what should I do?” Now it’s a survival guide because I think the most important thing for a lot of founders is not to just look at the big companies, the big successful companies, and just immediately copy what is done. And so, it’s a survival guide because if you’re out in the woods, here’s the mushroom not to eat.

I think often survival is the most important thing. You can last forever, have success if you’re never cut short. I have seen a lot of behaviors that founders copy, and they can just wind up being very detrimental. And I think even without knowing or having someone tell them what to do, I think just removing the easy things for them to hold onto that I think are traps can help a lot.

That’s how I did this book. I looked at the principles that I found to be very successful and looked to see where the traps are related to those and tried to explain why founders may not want to just reach for the easy or the at worst cargo culting and may just think a little bit more about the goals that they want to achieve and then they can build their own systems more targeted for that.

Shane Hastie: Let’s dig into that cargo culting. It feels like this is the way that organizations’ do practices today, though, isn’t it? It’s just, somebody else is doing it, obviously worked for them. Let’s just bring it in here.

David Guttman: Yes. I think the problem is that when it’s full cloth. I don’t think there’s actually much of a problem for that. If it is targeted, we are having this specific problem, we want to solve this specific problem, this is how this other organization solved that specific problem, let’s do it. I think that’s great. I mean, that’s kind of what learning is. I think learning from mistakes is very powerful, and given the option, I prefer to learn from other people’s mistakes and their pain. So that’s all fine. I don’t like it when it’s just the whole cloth, “Oh, this is the whole system that made them successful. Let’s do that”. That’s what I think gets people into trouble.

Shane Hastie: You mean I shouldn’t just try and copy Spotify?

David Guttman: Yes, I think you should. If you have the exact same problems that they do and are at the same stage they were, I think actually that would work out really well for you. And if that’s the case, then yes, definitely.

Shane Hastie: And you made the point: it is the easy way; it’s the things that we see. Where do you bring in the critical thinking? Give us some concrete examples of what we should do and shouldn’t do.

Does the daily standup achieve the intended result? [06:41]

David Guttman: Yes, so most recently I had a post on LinkedIn, got a lot of attention. It was about how stand-ups, daily stand-ups, the daily 50-minute meeting where a team of developers will sync up and identify blockers. At best, I think in the highest ideal state that is where junior developers will have their blockers exposed. A senior developer can say, “Oh yes, no, don’t do that. That’s a dead end”. And you can save theoretically huge amounts of time by intervening early, making sure there’s no duplication of effort or wasted things like that.

My issue with that is that, as a standing, recurring meeting every single day, you’re just with lots of people. That is a very high cost floor that you’re always paying. And if there’s no critical thinking of like, “Okay, this is the thing that we need; this is the problem that we have”. To immediately just jump in and pay such a high cost because other companies are doing it, not as good as what is the specific thing that we need or that we want.

And so in the case that I mentioned, like, okay, we have junior developers that are blocked in the one-on-ones with them or the review, one of the things that we find out is we have junior developers that just go long periods of time going down dead ends and not able to contribute. I don’t know if at that point you would say, “Oh, you know what we need to do? We need to do a daily stand-up where everyone, 15 minutes, share their to-do list, and occasionally we’ll catch these things”. I don’t think it’s worth the hit to flow. I don’t think it’s worth just running up the clock of everyone’s time every day. And I think the critical thinking can happen at a lot of different phases. So I talk to founders a lot, and I say, “Hey, why don’t you just get rid of the stand-ups? You know it’s really expensive; developers don’t like it. You know all of these things”.

And they’ll tell me something like, “Yes, but it’s really the only time I get to see all of them or for them to see each other and to hear each other’s voices. And I think it’s really important for team building”. And again, the critical thinking part that I want to happen is the founder to recognize ahead of time that the team building is important to them. And I want them to recognize ahead of time that if they were to design something specifically for team building, specifically to get the team to communicate with each other, it would not look like developers standing around sharing their to-do lists.

Shane Hastie: So what could it look like?

Practices need to be context-specific [09:27]

David Guttman: I mean, look, it’s really team dependent, and I think that’s probably the core message in all of this is the idea that a daily stand-up works for everyone and is not… Like the best thing wouldn’t be based on your team; I think it’s a little silly. And so, for me, it’s what could it look like? I have happened to work with a lot of devs who really like computer games; they love them. The same thing for me.

A lot of the people that I worked with, we really liked playing Valorant. That is a fantastic way, assuming everyone likes playing first-person shooters; that’s a fantastic way to have people communicate, joke with each other, talk. There’s teamwork; there’s a whole range of benefits with something like that. But the idea that I could say, “Look, I found the answer. Are you having a problem with culture and team building? You must play Valorant. All teams, that’s the one true way play Valorant”. It sounds ridiculous. So all I can say is that depending on the team, if you think about it a little bit, you’ll probably find something. But I don’t think you can just listen to a podcast and be like, “Ah, yes, that’s the one that works perfectly for our team”.

Shane Hastie: You mentioned you’re building, hands-on writing code and this internal software as a service product. What are you doing with that? What’s it going to be?

Building tools to support collaboration [10:51]

David Guttman: So the internal, what I call the internal SaaS, which I guess is a weird way of putting it. So the internal management platform that I’ve been using for years does everything from the super mundane of just tracking who are the developers, when were they onboarded, when was their last raise–all that snoozefest. But it goes all the way into things like we’ve talked about daily stand-ups. I unsurprisingly don’t do daily stand-ups.

Instead, a robot or AI sends a Slack message that’s like, “Hey, here’s what you said you were going to do yesterday. Did you do it, yes or no?” They say yes, great. “It’s what are you going to do today?” They give their answer, then, assuming it’s a good enough answer, then everything’s good. The robot AI says, like, “Cool, talk to you tomorrow”. That has sort of, as I was alluding to, has some intelligence where what we really want in that interaction is the dev to be as autonomous and accountable as possible, but for themselves.

And so the AI part of that is really just a mirror. It’s not as if the robot is the manager or it’s the avatar of the manager or anything like that. These all come from the same types of techniques that I’ve found really useful for myself when working for myself, who’s not necessarily a good boss, but these things are helpful. And so, it’s things like that. One of the super weird things that people might think that I do in management is all of our one-on-ones are written.

I think a lot of people react very strongly to that, have a hard time imagining that a one-on-one can be anything other than in person. I think some people have moved on to video being possible, but I think for a lot of people, just text only is the bridge too far. But since we do that, we have tools for our managers to kind of keep track of the themes of those one-on-ones and make sure that some of the areas or touchstones that we find very important don’t get neglected for too long.

And so that’s another area, then reporting for all of those things. So that’s what we’ve had internally for a long time. And so you asked what’s the public, more released one that will exist. That’s going to be, what I consider, the antidote for the daily stand-ups part. Where you can define these sequences, marry it with AI so that you can have these more predictable check-ins that allow the developers themselves to see what they said their plans were, see if they keep getting interrupted or blown off course by a product manager or life circumstances or anything. And then they can self-correct before it turns into anything else. That’s really the first one that I’ve been working on.

Shane Hastie: So you’re putting together development teams; you have your own organization doing this. This is the Engineering Culture Podcast. What are the key elements of a good engineering culture?

What makes a good engineering culture? [14:12]

David Guttman: I think it’s really tough because I want to say teamwork, but you’re going to ask three people and get four opinions of what that means. I think one of the most common criticisms that I get when I post about this stuff on social media or anywhere is someone will say, “Yes, but you’re describing something where they’re not working as a team”, or like, “Do you have a team, or do you just have a collection of developers?” I think teamwork is incredibly important, but I think my view of what is really important, I guess, the way to define that is that you have a team of developers who are each individually accountable, autonomous, they can communicate freely with their other teammates, and it’s very clear and very transparent what everyone’s doing, where the shared responsibilities are, but more importantly where the individual responsibilities are, where people make commitments and they stick to them.

And so it makes it much more of this, like, predictable machine, which I think some people might have an issue with that. I think they want everything to be a little bit more humanity, person-focused, and to describe a team as these gears or something like that is much more impersonal. They may not like that, but for me, I think looking at a business, looking at output, looking at workflow, having that teamwork where all of that effort meshes together, everybody trusts each other, everyone’s accountable, they don’t default to group psychology committee thing where it’s like no one’s fault, nobody’s responsible. And it leads to this tragedy of the commons thing. That’s, for me, I think some of the more important elements. So it’s like teamwork, but teamwork that comes from individual autonomy and accountability.

Shane Hastie: How do you create the space for that to happen well?

David Guttman: I think there are a couple of ingredients for that. I’ve alluded to two of them. The one, the daily stand-up tool that I was talking about, or the sequences as I call it… That allows individuals to… Basically, it prevents their brain from tricking them; our brains constantly are trying to conserve energy because we’re humans, just natural of the universe. We have our egos that like to be protected. There’s a whole host of psychological constants that work against us.

So in the sequences one that I’m talking about, that’s the mirror in the sense that you have to write every day what your goal is, and then the next day you have to say whether or not you’ve achieved it, and nobody’s forcing you to reach really far and be like, “Oh, I’m going to build the whole end-to-end everything today”. But if you constantly have to write, “No, I didn’t do it”, and then the reason why, because product manager told me that wasn’t important anymore and had to switch to something else or something in my personal life, you’ll be able to see that pattern and you’ll be able to self-correct.

That internal twinge of having to say that you didn’t do what you said you were going to do helps. So there’s this internal transparency that I think is required, and that internal visibility, and it’s almost like a fractal where you want that at all of the levels. And so, there has to be a lot of transparency on the team, what the team’s working on. Some of the pushback that I get when I talk about removing daily stand-ups is, “Well, how do you know that work isn’t being duplicated? Or there isn’t alignment?”

And I understand that there’s some trickiness with how do you do that transparency, too much transparency and there’s too much noise and not enough signal. But there are ways to do it right where the team can self-organize in a way because the information is there. You set up the situation where the team is very much in the habit, and they understand that the norms are that you communicate as soon as you’re stuck; you don’t wait. And some of this is done via onboarding and making this clear just in telling someone that this is how it is, but also making sure that as soon as they come on board, these are the behaviors that they’re seeing. Everything is modeled, and that communication happens; that transparency happens; that accountability happens. And I think those reinforce themselves when those elements are there.

Shane Hastie: I know from the correspondence we had getting to know each other that you had some opinions about the mythical 10x developer.

The myth of the 10x developer [19:11]

David Guttman: Yes, sure. The origins of that are a study I think from, if I remember this correctly, it was from the 1960s, had to do with the U.S. Air Force. They had mainframes the size of an entire floor of an office building. I love the government and the fact that they do studies. They wanted to look to see, like, “Okay, we have all of these developers and programmers”, or whatever they called them at the time, “and we pay them all the same”, because it’s the government and very narrow salary bands. “What’s the output that we’re getting from these people? Does it vary? What is it?”

Maybe a lot of people know this already or not, but what they found was that for particular tasks they had, I think they had two different tasks through, and one of them was something like a maze. And the other one I think was something related to algebra. For one of those tasks, the developer who did it the fastest with the lowest number of errors or did it 10 times faster than the slowest developer.

And again, remember, those developers are making the same amount of money. So you got one that can produce 10 times the output for the money as this other one. Now, the reason… I have many reasons for not really wanting to go all in on the 10x developer based on its origins. One, that’s not the computing environment that we live in today. Certainly not for me when I’m programming; I’m not trying to get time on a mainframe that’s the size of this office building and punch cards or whatever. It’s not the same as the 1960s, but even if you ignore all of that and just, look, computer science is the same. That hasn’t changed. Fine, we’ll go there. But what they found, I think what’s more important is not that banner headline of the 10x. When you looked at it, it actually was skewed much more towards the tail, meaning the worst developer on one of those tasks was way worse than the median.

Meaning the best was much closer to the median and the worst was much farther away. And so, even if we were to just stop there, I would much rather we stop talking about the 10x developer and talk about the 0.1x developer, because I think that’s more of the lesson from this particular study. You can also go further, which it wasn’t even the same developer, being low or high on both tasks. You had one, ace the maze one, and then not do so well on the algebra one, which I feel like should be obvious for anyone who’s coded; anyone who’s coded has to know, “Oh, these are the things that I love to work on; I am better at. And if you ask me to do drivers or something at the kernel level, I would be terrible”.

Or vice versa, “You want me to do UI in React or something? That’s not what I do”. And so the idea that you are going to get a 10x developer across the board as opposed to just one thing that they love, I think is unrealistic as well. And then just to sort of sum it up, I think people just forget that this was all based on the developers being in government and getting paid the same. This doesn’t work in the real world; if you have a developer who is actually doing output, that’s 10 times the rate of your other developers because you would wind up wanting to pay them more, or they would want to wind up leaving to where they’re paid more.

And at the point in time where a developer is getting paid commensurate with their output, you no longer have a 10x developer. I do understand that there are advantages to paying one developer 10 times as much to get it done quicker than 10 different developers. And there’s a difference between things that are parallelizable and things that aren’t. I mean, I get that, but it’s really no longer a 10x developer if you’re paying both the same rate.

Shane Hastie: David some really interesting thoughts and some great ideas in there. If people want to continue the conversation, where do they find you?

David Guttman: So I’m on LinkedIn. You can just find me, David Guttman. It’d be easy to find on there.

Shane Hastie: I’ll make sure that’s in the show notes. And I’ll also include the link to the book. So David, thanks so much for taking the time to talk to us today.

David Guttman: Yes, this was a pleasure. Thank you so much for having me.

Mentioned: