#204 - Stop Inflicting Daily Standups and Computer Science Riddles on Your Devs - David Guttman

[00:02:18] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to the Tech Lead Journal podcast show. Today, I have with me David Guttman. He’s one of the thought leaders in the JavaScript space, right? And also in the startup space. He has over 90 open source packages on npm. That’s kind of like a lot to me. And also he wrote two popular JavaScript books. But today, funnily enough, we are not going to talk about JavaScript and its ecosystem. We’re going to talk about his book, which is titled The Superstruct Manifesto. So when I read the book, I think it’s pretty intriguing and interesting. And hopefully we can cover some of the popular manifesto today, so that we all can learn how to build a great tech engineering team or tech company. So David, welcome to the show.

David Guttman: Thank you. Thanks for having me.

[00:03:06] Career Turning Points

Henry Suryawirawan: Right. David, I always love to first invite my guests to-share a-little-bit from your career. Any turning points that-you think we-can learn from you.

David Guttman: Yeah, I don’t know if you’ll be able to learn from me, but I think one of the early ones that was really big for me was when I was at Disney going into the more corporate world. One of the things that was most fun for me in larger companies was how many people there were around working at the company that you could talk to, you could take out to lunch, you could ask them what they were working on, and if they weren’t a software engineer, it would be totally different than what you dealt with day to day or you thought was important. And what’s really cool about that is, it’s almost like you’re in Harry Potter, and you get to meet muggles, and you have magic powers, and so they’ll tell you things that to you like are so simple like you don’t even think of them as problems. They’re just like complete non-problems.

So it’d be something like yeah, I keep trying to eat my food but it’s always so cold. And like, I hate eating raw meat, and you’re like oh, let me show you fire. And so at Disney, you know, there would be things like that. You know there was a one example was an editorial team would always put things on YouTube and they just didn’t, they weren’t able to track it. And so I just easily built them a scraper that went onto YouTube, looked at the number of views, and then they could see it over time. Now, look, that was a long time ago. There’s like a billion tools for that now, no longer impressive, much like if I were to pull out a lighter and show you fire, you wouldn’t find it impressive. But the important thing was just recognizing that there were opportunities like that all over the place to drive business goals. And I just think a lot of engineers don’t realize that they can do that, that they can be self-directed, go find people to help.

Going from Disney, that then I got my first, like, chief scientist position at an ad tech company. And so, that was really interesting, more from like a technical, like, scale, data, architecture position. You know, eventually at that company, we’re running a video ad server. And then during the peak ad buying season, more towards the holidays, we were getting over 10 billion requests a day and we were trying to do real time analytics. And how do you do that in a way that works at that scale? And so, you know, I found that a lot of fun, like those types of engineering problems are really fun. And you don’t ordinarily get to do those unless you’re in like specific industries or working at certain types of companies. And, you know, at that point in time I think what I fell in love with was just trying to do it as simply as possible. Like don’t over complicate it, have as few moving parts as possible and you can really get quite far with that.

And then probably the most recent was going out on my own as a consultant and so starting Superstruct, taking things that I learned from, you know, being a CTO and really systematizing that in a way that could be useful to more companies than just one.

When you’re a CTO, everything is in service of that one company. And then trying to take those lessons and package them in a way that can be used by other companies. And that’s where you get to, you know, we’ll talk about my book. That’s where a lot of the book came from is these principles that I try and use when creating engineering teams. And, yeah, we can, we can get more into that. We can get more into that later.

Henry Suryawirawan: Right. Thanks for sharing the story. So I laughed when you mentioned about your Disney learning experience, right? So sometimes engineers thought things are quite simple, normal, right? But for others, it could be really, really helpful. So I think that’s a very good call out. And I think 10 billion requests a day. So I think that’s not a joke, right? So something like not all engineers would have a chance to experience that. But thanks for reminding that building something simple, less moving parts will be something that is more scalable.

[00:07:10] The Meaning Behind Superstruct

Henry Suryawirawan: So before we go into your book, right, so I’m a bit intrigued by the name Superstruct. So why do you name your consulting company Superstruct and your book Superstruct? So maybe a little bit of background there.

David Guttman: Yeah, for sure. So Superstruct is, is actually a, like it’s a real word and it means to build on to an existing structure. So in this case, it’s quite literally that there is an existing company and then I’m building engineering teams on top of it. So coming in from the outside and being able to build something that fits with what’s existing, but then also adds on to it.

[00:07:44] The Superstruct Manifesto

Henry Suryawirawan: Nice. So your manifesto contains 10 different kind of like principles or lessons, right? So most of them are unique, right? Because this is something like an insight from your experience, right? But in the first place, tell me, like for example, why do you came up with all those 10, right? So from what learnings that you see and why do you make them as principles?

David Guttman: Yeah, for sure. So the principles actually got turned almost in reverse, and so the book is a survival guide. And so the reason why I made it as a survival guide for tech leaders is I just see so often that you have a founder or an engineering leader will copy, effectively blindly, processes and systems that they see being used at other successful companies. And this is dangerous because if you don’t have the problems that that company did, or that they are, they’re using that system to solve, you could wind up paying a pretty hefty tax, or a pretty hefty cost for something that you’re not getting very much benefit or ROI from. And so, there’s a couple of ones that I see all the time, like for example, stand ups.

Henry Suryawirawan: Standups I think is very interesting, right? So you mentioned that so many engineering leaders, you know, and founders, right? Almost all the time, right, look for best practices typically online, right? So there are many people blogging. These days, almost all big tech companies would have its own blogs, right? And they will just share whatever best practices. Few, I think that, I could think of. For example, Spotify model, you know, Agile practices, you know, Google, all these FAANG companies hiring strategies, right?

[00:09:30] “We Will Not Inflict Daily Standups on Our Devs”

Henry Suryawirawan: So I think you cover most of them in your book. So I think let’s probably start with the first one you mentioned about stand ups, right? So I think this is, I think, will be the habit or the practice for most of the engineering team, if not all, right? These days, they practice typically like some kind of Agile flavor. So stand up is definitely one of the practice that the many teams advocate. So tell us like why stand up is not great for us to do.

David Guttman: Yeah, for sure. So I think, broadly speaking, the use of time, of meetings, it’s a very dangerous game to play with. Like any meeting that you have, you are taking n number of people, so however many people are in the meeting. So whatever they could be, either opportunity cost, whatever they could be doing instead of that meeting, could be quite literal. Like you take their salary or their hourly rate and then you multiply it by the number of people. That’s the cost of the meeting. So whatever you are getting out of that particular meeting, you should get a return higher than that cost when you multiply it out by however many people you have.

So this is even more of a problem when you have a recurring meeting. And it’s more of a problem when you have a daily recurring meeting. So this means that you’re paying that cost every single day. Now, yes, I, I understand that stand ups are so short. But I mean, I, I, it’s, it’s funny cause it’s in the name. It’s almost like if you didn’t make people uncomfortable, they would want to be longer. And so I think people just have to be really careful about just those recurring meetings, in general. And the most common one by far is daily stand ups.

So the gain that I think a lot of people think that they’re getting from stand ups is this idea that the team really needs to uncover blockers, they need to coordinate, make sure they’re not duplicating work, things of that nature. What I would say is if those things are happening often enough for that meeting to be capturing that value, you probably have a deeper problem.

I feel like most people who have daily stand ups, most meetings are not, oh, wow, thank you for catching that. I was so blocked, I’m glad I mentioned it here, like that’s super insightful. I’m glad that we were able to do this. We just saved hours and hours and hours of time. I’m not going to doubt that that happens, I’m sure it does, I just don’t think it happens with the frequency for this to be an entire meeting around it. That’s where I think the ROI really goes out of whack.

What’s interesting is I’ll talk to founders and, you know, I’ll talk to them like, okay, so you’ve basically got over an hour a week minimum. I mean that’s assuming if they really are limited to 15 minutes. If you’re listening to this, maybe your standups are 15 minutes. I’ve known a ton of people where they’re not. So let’s just say that it’s a 15 minutes. We can even ignore the whole productivity angle of how it takes time to disengage from what you were working on, go to a meeting, leave your whole mental model behind, and then try and get back into the flow. We’ll come back to that.

So just imagine it really was only the time in the meeting. You know, I’ll talk to founders, like if they really think that they’re getting the value out of it and they will agree that they’re they’re not. But the reason why they don’t want to get rid of stand ups is because they feel like it’s the only time that the team gets to talk to each other and hear each other’s voices and sort of build this camaraderie. And for over an hour a week, that’s the best you can come up with? Like people are gonna read their to do list to each other each day? I think if that was your goal, like you could really come up with something better.

And then like I said before, I mean, It’s way more costly than just the time. Because if anybody knows about Cal Newport and Deep Work and how to have these uninterrupted blocks of time, like you don’t want a meeting just in the middle of this block of time. Like for a lot of developers, that morning, a lot of people have the, you know, daily stand ups in the morning. Like a lot of people just, that’s their most productive time. And so you would like really have to nail the timing of the daily standup for like everyone to be starting their day right at the exact time so that that block, that productive block all only starts after the daily standup and not in the middle for some people and others. And I think that that flow is just a really, really expensive thing to waste. And, yeah, I think you wind up upside down on that ROI quite frequently.

Henry Suryawirawan: There are so many things to uncover there. So I think you just mentioned like a number of anti-patterns, maybe, let’s mention it anti-patterns, right? So there are many things that could happen in the stand ups that probably is not that effective and efficient, right? So maybe let’s start with probably the time itself, right? So you mentioned stand ups are typically in the morning, but I feel sometimes to cater some night owlers, right, so they start a little bit, you know, later, not in the morning time.

So you mentioned about having to block the time in the middle of the day just to meet everybody and kind of like convene with everyone, right? So I think that sometimes, yeah, can be a productivity killer, because typically, let’s say if you schedule your stand up in, you know, in the morning, but one hour later, right. So, like, maybe if you start the day at nine, you start at ten. So typically people won’t start serious work in the first hour, right? So I think that’s kind of like one of the dangers.

And after the meeting as well, because there’s so many things that we need to, you know, I don’t know, context switch and do preparation or even to unload some of the conversations that just happened, right? We were also not productive. So that left us with, I don’t know, like maybe half a day kind of like productivity, right? So is this something that, uh, you also think that could be a productivity killer for many of the engineering teams happening out there?

David Guttman: Oh, yeah, absolutely. I mean, I just, yeah. I mean, like you said, like the hour after the start time is, it’s just so, it’s so common. Cause it’s really difficult to coordinate everybody. Like no, your day starts right now and we’re gonna start all of our days, like right at the same time with this daily standup. And then, yeah, I mean, I completely, completely agree that whatever that loss is to flow and productivity, like it’s hard to get that back from whatever happens within the standup.

[00:16:05] Alternatives to Daily Standups

Henry Suryawirawan: Right. And you mentioned in the book that we can live without standups. So what would be the alternatives that typically you suggest for all the startup founders or maybe the tech teams out there?

David Guttman: Yeah, so one of the funny things about doing a, a survival guide and having a book that’s, here’s what not to do, is it begs the question like, oh, what should we do? What I really want to reiterate though, is that for the same reason that I wrote the book of not copying the big companies, it’s very difficult for me to tell you like, oh no, here’s what to do. Here’s what we do. And as a perfect example of that, one of the best things that I think, you know, for the, let’s just say you wanted to do it for the camaraderie angle. Like that’s the most important thing to you.

You know, on one of the teams that I was on more recently, the thing that we did is we played Valorant, the first person shooter by Riot. So we all played, you know, basically a very high skill first person shooter computer game, like, that you would have to have a gaming PC for. You would have to have more or less played Counter Strike like games before. And so, it’s just so funny of me to say, like, no, like, the best thing you should do, if you’re listening to this, do not do anything else other than play Valorant with your team. Like I don’t care if nobody on your team likes first person shooters, I don’t care if they don’t have a gaming PC, they should go out and buy one. Like it’s just doesn’t even make sense for me to say what works for my particular team. I think what people should do instead is really think about what it is that they’re getting from the stand up or what problem they think the stand up is solving, and then think what works best for their team to do that.

So if it really is that you have juniors that are blocked and they’re too timid to speak up, and they get lost for a week, and then you talk to them, and you’re like, so, like, how’s that thing coming? And they go like, oh, well, you know, I wanted to do X, but then I realized I needed to install Y but then to have Y installed, I, I needed to go do Z, and so anyways, that’s what I’ve been up for the last three weeks. Like if that keeps happening, like, I don’t think daily stand up is like the best way to do it. Or, like I said, you know, if developers are working on the same thing, or they’re not talking, or whatever, you should really come up with a system that addresses that particular problem with a system that really fits your particular team.

[00:18:26] Status Report & Accountability

Henry Suryawirawan: Right. I think I love that reason, right? So I think, first of all, identify the problems in your team, right? And maybe try to come up a contextual or maybe situational kind of activities that maybe to solve those problems. But one particular thing, especially for leaders, that I heard a lot in the stand ups that typically happens is that first, it’s about status report. So the leaders want to know what is happening between the team members. And the second thing is about building so called pressure or accountability, so that everyone is kind of like on the toe every day. So maybe anything from you to maybe teach us here, what can leaders do in order to get those two from the team as well?

David Guttman: Yeah, I mean, I could certainly… Look, I can also give an example of what I do with Superstruct engineers. Superstruct has its own internal platform for management. I am working on the more public version available of that. So if you wanted to adopt some of the same systems and behaviors that we use, you would be able to do that. And so the first one is called Team Machine. And if anybody’s familiar with a tool like Standuply, this is a bot in Slack that’ll message your, I guess, everyone on the team, and it can ask whatever questions that you want. So if you really wanted to do just the basic, most default stand up, which is the what were you working on, what’s your plan, any blockers thing, you could 100 percent do that.

You mentioned accountability. The way that we do it, the questions that we have are a little bit different. Very similar, but different, which is, what is your plan for the day? And the key part of this is that that plan has to culminate in something that is independently verifiable. So it doesn’t work for an engineer to say, oh, I’m going to research X, Y, Z. Or I’m going to look into whatever bug. Or I’m going to work on issue number one, two, three, or whatever it is. That is off the table because no two people can agree on what work on means, or what research means, or anything of that. Also if that developer and their laptop get sucked up in the rapture, like it basically never happened. Like if the tree falls in this forest and no one was around to hear it like didn’t make a noise. Like the output, for any output to be valuable, it has to be able to exist independently of that person. So someone else on their computer with no help from the authoring engineer should be able to get value from it.

And so I mentioned the research example. That’s fine. You can still research. That just means publish some kind of document. You find an issue on GitHub that shows your findings. That anyone could read, even if you or your laptop are offline, that’s totally fair game. For an issue, you know, like work on issue 1, 2, 3, fine. Just say what you’re gonna have in the pull request that’s gonna go out before the end of the day. And it doesn’t even have to be the full issue closed. It could be part of it, but just say what it is. Fine. You want to just change the color of the button from red to blue, then just say that. Everyone can see, like, yes, they changed the button from red to blue. That’s fine. Like, there’s nothing about this that prescribes what your plan is. It really should be giving that autonomy to the engineer. Like, all the engineers should be adults enough to know what they should be getting done. It’s just calling the shot ahead of time.

And then this is the accountability, which is the next day, the other question that is part of this is, hey, here is what you said you were going to do yesterday. Did you do it? Yes or no? And because it’s very simple to know, like, well, did you push the PR that changed it from red to blue? It’s very simple, it’s a yes or a no. It’s not like, did you work on it? Where it’s like, well, you know, I opened the issue, I re-read it, I thought about it, and then I watched YouTube. And yeah, yeah, I worked on it. Like it’s very clear. And if the answer is no, the team machine, the thing that I have, it uses AI to both check that if they, the answer is independently verifiable, and it’ll re-ask it if it’s not. But also it’ll ask, you know, did you do it, yes or no, and then it’ll follow up with like, why not, if the answer’s no.

I think a lot of people at this point, I don’t know. I think there can be weird reactions to the idea of this accountability. Like I think, because you asked it, accountability is important. But I think we also don’t like to think that we’re being held accountable, I don’t know, just in case we had, I don’t know, a bad day or something got in our way. Like now we have to say no, and now it’s on our permanent record, and everything’s bad, or whatever. But like that’s really not the point. The point is that you have this record of not doing what you planned because this is what is going to surface real issues. Some of the time it’s going to be something like, no, I didn’t do it because the product manager swooped in and told me to stop doing what I was doing because this other super important thing came up. Well, lo and behold, if you keep saying no, and you keep saying something like that, that really reveals that a product manager needs a talking to or there’s something at a deeper foundational level that needs to be addressed because you can’t plan your day. You, you have a bigger problem.

Now sometimes it’s personal, like you will realize that you just keep coming up with excuses where like, yeah, I was gonna work on that, but then I had this like great idea, we could use this new database that just came out. And I started looking into the database, and then, well, I went down this rabbit hole because it didn’t really support the thing. You know, it’s like, you can surface those as well, and catch yourself, like, okay, well, it’s been three days in a row where I haven’t done the thing that I said I was going to do and it’s not the product manager’s fault, like maybe I should knock it off. Or your manager can talk to you about it or whatever.

So those are more of how I view it. Now, the other important part of that, which you might have picked up on, is that it’s asynchronous. Like it isn’t this like synchronous block of everybody at the same time. It is just that you more or less have to do this on your own time, once a day, thinking about, okay, this is what I’m gonna do. And it’s really easy to just do that before you do any kind of work, and it’s done. You don’t have to worry about it anymore.

Henry Suryawirawan: Thanks for such an elaborate answer, right? So I think there are a few things that I picked from the answer that you gave just now. So the first one, I think for me at least as well, the stand up kind of tradition helps everybody to actually plan, right? So kind of like plan the day ahead.

And second thing is about alignment, right? So if you plan something that is aligned with the goal of the team, or you know, the situation that is important for the team, I think that’s really great. Second thing, it doesn’t have to happen synchronously, right? So you can also use, I don’t know, documents, Slack bots, and whatever mechanism to just put down what is the plan and what is the outcome, kind of thing, right, into some, you know, like written kind of channel.

And then the last one is about treating everyone as adults, right? So, I think here we should respect each other. Like we want to have team members who are also kind of behaving like adults. Not like we have to keep on following up and asking them do things. So I think that’s really great, so hopefully people learn about the better stand ups or better not-to-do stand ups kind of thing, right?

[00:25:48] “We Will Not Recruit 10x Developers”

Henry Suryawirawan: So the second aspect of the typical pitfall that you cover in the book is about hiring engineers, right? So the first one is about trying to find the 10x engineers. And the second thing, maybe slightly related to that, is that we try to hire by using, you know, the big tech giants kind of interview styles. Typically like system design, you know, algorithms, those kind of things. So tell us these two things, right, two principles, why we should avoid them.

David Guttman: Yeah, for sure. So I guess I’ll first talk about the 10x engineers. A lot of founders get it in their head that there is these 10x engineers out there. And those are who they wanna find. So the general concept of a 10x engineer is that an engineer can have ten times the output, you know, they are ten times as valuable as other engineers. But, you know, they cost the same. So the same salary dev, same level, whatever, one of them has ten times the value output than the other one.

What’s interesting about this, and if you trace this one back, where this comes from is there was a study in the 1960s, it was by the U.S. Air Force back when, you know, everyone was working on a mainframe, I think with punch cards or whatever. And you know, this is a computer the size of like an entire floor of a big office building.

So I think first if that resembles your work environment and your team environment, and if you want to really take the conclusions from that. But if you do, there’s other things to remember from that study, which is that the 10x spread was not between the top developer and like the second best developer. It wasn’t like there was one that was 10x, and then number two, and then, I don’t know, like, on and on and on. It was a 10x spread between the top developer and the worst developer. And so, how these things were rated, there were two different tests given to all the developers. Now, this was in government, so government salaries are all super lockstep, and there isn’t a whole lot of wiggle room. It’s all seniority and stuff anyway.

So the two tests, one was I think mazes, like solving a maze, and the other one was solving like some algebra, math type thing. So, that 10x spread was, I think, found on both of them, and it was between the top dev and the worst dev. And I think this was based on how long it took them to come up with an answer that was, I don’t know, error free and correct or something like that. Most of the devs were near the top. So that top dev was actually closer to the median than the bottom dev was. So people have really taken to this, like, find the 10x developer, but like, no, no, no, no. It’s find the 0.1x developer and don’t, don’t leave them on your team. That’s where you’re getting the spread. So that’s one thing to remember.

And then the other thing to remember is it wasn’t the same dev who did good on both, right? Like, you can certainly have 10x devs for particular problems or tasks or things that you’re building. Like I mean, especially if someone has built that same thing before multiple times, like you compare them to somebody who’s never worked in that space before. Like yeah, of course, they’re going to do it ten times faster with ten, you know, less bugs or whatever. And yeah, I wouldn’t expect their salary to be totally different just because this person has worked in this problem domain and this person hasn’t. I think people just really need to remember that even though you can find these examples of sort of output differences in developers, it’s not consistent. It’s not like you have a 10x overall time.

And, you can also, it’s not weighted towards this one developer being so much more awesome. It could be weighted towards a developer just, who’s really not doing a great job, you know? And we can all just imagine how easy it is for that to happen. Instead, kind of how I think about it, and I think this is really what a lot of people are thinking about in terms of 10x developers is they have in their head the idea that there is this developer who given a hard problem, comes up with a solution that is so elegant that nobody else would have thought of it, and it almost like sidesteps the whole issue, right? Like everyone’s just thinking of like how do we efficiently compress this data so it fits on the drive and whatever, and then the 10x engineer is like, what if we don’t save the data? And everyone’s just like, you know, like mind blown. And I think that’s really important.

Like I’m not gonna say that that type of skillset isn’t hugely valuable, isn’t hugely important. I think in that particular instance, they could have saved tons and tons and tons of money. Like they could have paid for their entire salary just from that one thing alone. I don’t doubt it. What I’m more getting at is like that type of engineer who I call the commando, who really loves to like swoop in, solve a super hard problem that nobody else can do. And then like jump out. Those problems are kind of rare, those really aren’t. It’s not like every single day you have one of those issues.

I do think that there are some industries that are kind of like it, like that. I mean, I think I can imagine like think tank and agency work where it’s always some new, like someone’s coming to you to solve like some crazy problem that’s never been done before. Look, if that’s, the work that you’re in, fine. By all means, go for those commandos. I think a lot of companies, that’s not the day to day. I think a lot of companies, you have certain types of problems that have been solved before, you just need to do it. You need to put in the work. And I think there’s a different profile, the model that I’m referring to with commandos, it’s commandos, infantry, and police. And so I think that model of like the certain type of developer who can work well on a team, hears the plan, execute on the plan, divvy it up, and really not just get super bored and make it really complicated and just try and make it into something like crazier than it is. Like we talked about keeping things simple. I think there’s a lot of value to that type of engineer.

And so often what I recommend is, yeah, like you can imagine a situation in your head where this commando swoops in and saves you like oodles of money, or they invent this thing that now makes your startup worth like 30 times whatever. I guess I don’t want, I wouldn’t really just like bet your company on that. I would just, I would bet on you having more standard problems most of the time and find the engineers who can really cooperate, follow a plan, come up with those plans and execute.

And then, just for completeness, I’ll mention the last type of engineer is police. And they are not the one that is so much building. They’re the ones that if you have a system that you need cared for, you’re not adding on to it. You’re not changing it very much, but you do want to make sure that it is just very well cared for. It stays up. It’s working properly. If there’s an issue, it gets fixed. And that’s really, like that other type of engineer who’s really big on documentation, following procedures, like if this is what happens, here’s how you deal with it, checklists, and that type of thing. So depending on your situation, usually, I think people are looking for infantry. And that’s why I say stay away from, like, what I think most people are thinking of when they’re thinking of that, that 10x engineer.

[00:33:19] “We Will Not Test Devs with Computer Science Riddles”

David Guttman: Now if you want, I can get into the, you know, I think you were getting into like the FAANG style interviews with the what I call computer science riddles. And I mean, again, I think it’s, it’s so much like this theme of it’s the don’t solve the problems that you wish you had, like solve the problems that you actually have. And so if you’re looking for an engineer, the goal really shouldn’t be like, okay, who can solve the hardest problems? Like okay, and if they can solve that super hard problem, well then they can build out our whatever it is, because clearly if they can do the hard thing, they can do this one.

And man, hiring is hard. Like, you’re effectively doing a class of predicting the future, which generally humans are not good at, I think. Most people would agree with me there. And so like, don’t make the job harder, right? Like if you’re trying to predict whether someone is going to be good at this particular thing, you should really be testing them as close to that particular thing as possible. Like don’t play games with like bank shots or like, oh, if they’re that great, they could do this. Like no, just think really, really hard about what work you think they are most likely to be doing. And create some sort of test problem that really mimics the type of work that they would be doing. So you can easily do this just by asking your engineers or, you know, if you’re a tech lead, you know, like you’re gonna know what you’ve been working on. You can look back in time, you can look through all the tickets, like you can see what it’s been, and build something based on that. Like, you just, you’ll be able to see, like, oh, well, like to work on this system, which we’re working on constantly, well, you kind of have to be familiar with how we’re using Redis, or you constantly have to be familiar, you know, like, you have to know how we’re using like these queues. Or you have to know how, whatever.

You can look at a certain type of bug that was pretty difficult to figure out, and see, like, okay, how did we solve that? How did we, like, how did we have to change our thinking to be able to do that? And then you can create a test around that, and you can see like, oh, is this person able to get their head around that or not? That’s a great thing to know, because that’s what they’re probably going to be dealing with. I don’t think the Google style way of doing it. I mean, it works for them, right? They got a billion applicants, like, they can filter it any way they want. They make tons of money, far be it from me to tell them what’s right or not. But if you don’t have those style problems, I wouldn’t necessarily copy them.

Henry Suryawirawan: Right. So there’s so many things I would like to cover, right? So I think thanks for sharing. I think these are the typical practice in many tech startups, right? Like they copy from the bigger boys, right? The bigger startups, the practices. So the first one is about 10x developers, 10x engineers. So I think, thanks for sharing about the history, the 1960, where this concept may have come from, right? So I think that back then, maybe, like when you have these giant mainframes, right? Obviously the kind of output that someone produced can be much different. But today, we all use, you know, advanced computers, almost everything available online, right? Including the resources and, you know, the how to, the tutorials and all that. So I think many people would have the same opportunity to learn and be able to do the same thing, right? So I think maybe the concept of 10x output is probably something to debunk here.

And the second thing is about instead of finding 10x developers, try to find the 0.1x developers and kind of like oust them out, right? So I think that that’s definitely very, very important because you don’t want to have one of the team members who are not producing or delivering stuff. So instead of the 10x, maybe 0.1x is something that you should figure it out, how to solve.

And I think the other thing is about commando, infantry, and police. I think I find that concept really interesting, right? So obviously in the team, you need a balance. You can’t have all commandos or all the police,right? So having a balanced skill set and maybe responsibility in the team will be something that is great.

And I think about, you know, the commandos who will come up with some great solutions to, you know, some particular problem all the time. I think this is quite rare. I mean, I can see it also in my career, right? Mostly we all write CRUD applications, right? So, you know, like getting an input, saving to database and communicating it to other systems or other, you know, software.

So I think that’s the typical things, right? And in between you have so many different permutations like how things get done, right? So I guess like the kind of problems that algorithmic is something that is quite rare. And you mentioned in your book that we should optimize for more predictability. So people who can maybe plan and deliver, right? Rather than, you know, finding these commandos who-can suddenly deliver a great output.

[00:38:04] Interview Best Practices

Henry Suryawirawan: So the next I want to cover about interviewing style thing, right? So people actually kind of like find-it difficult to figure out the-questions that we should ask engineers. I mean, the Google, the Facebook, or the Amazon, maybe they have their own styles. But what would you think would be a great interview questions that should-ask engineers for a smaller type of-company or smaller like a-typical engineering team, right? So is-it something that you have, some kind of best-practices? Because you mentioned that it should be similar to problems that the team is having. But at the same time, you also can’t reveal too-much. That’s the first thing. Second thing is like, probably you don’t want to have too many setups, like, you know, setting up Redis, setting up particular database just for that particular interview. Or worse, some companies actually gave the candidates homework, asking them to do, you know, some questions outside of their working hours. So maybe from your view, what’s your take here?

David Guttman: Yeah, so, so, yeah, I guess it probably makes sense that it wasn’t clear from how I was talking about that. So the way that we do interviews is 100 percent that, that homework that you mentioned, but they’re paid challenges. So when Superstruct hires, we have like a very short filtering project. So like you do need to show us code. But that is, that’s much more of a, like did you get it or did you not get it? Like if you know the answer, like it’s like five minutes or something like that. It’s like incredibly, incredibly short. And so that’s like a filtering one. We don’t pay for that one. And so that’s one of the threshold ones. In terms of the paid challenges, yeah, those are much longer. Those are maximum, like I think, we do five hours. And we will pay for time on those.

Yeah. I mean, I think it is a challenge to figure out how do you distill a real business type challenge into something that you can share, right? Like, cause you’re not gonna say like, oh, well, well, here’s a feature that we want to add to our production system. But then, oh, yeah, but you gotta, you gotta know this and that. And like, oh, we’re giving you access to our GitHub. It’s like, no, no, no. It doesn’t, it’s like, it doesn’t even, doesn’t even make sense. In terms of the setup and the like, if you do want to test something with, let’s say, Redis or a queue or something like that. I do think we’re actually in a really good age for that with Docker. Like you can sort of create like, all of this, like one, one button spin up that works on everybody’s machine if you really wanted to do that.

In general, I think, the goal really is to reduce that anyway. Like there’s a reason not to introduce all of those dependencies, because it’s a pain, and it’s variation, and can create all kinds of issues that aren’t related to what you’re testing for. But also because I think you do want to distill it down into, like, what is that core pathway that you are testing for? And if you introduce too many dependencies, you’re kind of like introducing too many distractions from the thing that you’re testing. This is again one of those things that it would be really hard for me to say, like, here’s how you do it without knowing what the team is.

But I could say, like think really hard. Like, are you solving e-commerce type problems? Are you solving, like ad tech type problems? Like are you solving, like a consumer photo sharing app type problem? Like all of those are gonna be so different in what you’re looking for, because each one of those is gonna have its own either, like industry or code based type constraint that is, like, I don’t know, it’s almost like this like a no go, like, it’s like when you’re working at like the scale of like the ad tech and all those requests that you can get yourself like one of the things that you can test for is just whether or not they know that they just can’t put like the entire set in memory or something like that. Like that’s almost like what you’re looking for is like that they can have that awareness and there could be something. If you’re more consumer focused like their answer has to be something that isn’t going to drive a user insane, even though, you know, um.

And so it’s really hard for me to know up front what those types of things are that your team cares about. But you should be able to identify those. And once you can articulate those, you should be able to create a test around it. But that’s, I would say the first step is really thinking about what is important to your team. To the extent that anything, like, you think about an engineer who hasn’t done very well, like what were those things that they were missing? Or, oh, this engineer is really good, like what are the types of things that they did well and test for them? So unfortunately, I think that’s the best I can do.

Henry Suryawirawan: Right. I also agree that you can’t probably, you know, come up with just one style of interview questions that will work for almost all engineering teams, right? So definitely it depends on the stage, the problem that you’re solving, right? The formation within the team as well, right? Because, uh, you might have existing team members. You probably don’t need to find all similar engineers, right? First, I think identify the problems that you think is very crucial for the candidates. And-second thing is come up with kind of like a similar questions that would solve those problems. So definitely very, very important.

[00:43:12] “We Will Not Let Devs Start without an Estimate”

Henry Suryawirawan: So I think we still have one more manifesto that we can cover. So I think one particular thing that I would like to uncover is about dev giving estimates. So I think this is kind of like legendary problem in engineering teams, right? So how can we come up with accurate estimates. But you’re saying that we should ask dev to actually give estimates. So maybe tell us about why this principle exists.

David Guttman: Yeah. So one thing that I have found is that just by having a developer give an estimate, the project is much more on track. And the mechanism by which I think this happens, and one of the things I say in my book is like, you could even take that estimate in a sealed envelope and never look at it, and things are going to go better. Like it’s not even the estimate itself, it’s the fact that the developer gives one that things go more smoothly. And I think the mechanism by which this happens is that once that estimate is said, like that then becomes the budget that they’re working around.

Now, I don’t actually, you know, I think one of the things that people talk about is, like, accurate estimates. Like, I don’t… You know, I mentioned this before, predicting the future is hard. Like I don’t actually think that it matters if the estimate is accurate. I mean, I think all of us as engineers, we want to measure things. We want that like perfect precision on measurement. But it’s really not possible to measure anything perfectly. Like we know roughly how tall we are, but like not to the micrometer or something like that. So there’s value to having these estimates or these measurements, even if they are not precise.

And so, on the developer side, thinking about how long it’s going to take, saying a particular date that it’s going to be done by has a really good counterbalancing effect on a lot of what I would say is our tendencies, which is that once we get into the problem, there are lots of things that can blow us off course. And we might try to overreach sometimes or try and explore something that catches our interest when it is not wise to do so. And so if you say, yeah, this is going to be done in two weeks, and now you’re in it, you may not be so frivolous with trying to play with new technologies or toys or do things that introduce variability, right? Like you might, you are likely to just try and stick to the budget. Or you have a really good reason for it, and then that is something that you can communicate. You know, like, hey, I’ve been working into it.

And so this is one of the things that I think is really important to say, which is that the estimates are not something that the devs are really held accountable, like it’s not a deadline. It’s not something that that then becomes weaponized and like, oh, you said that the estimate was this and you didn’t hit it. Because it’s important that the estimates update as the developer has more information. So the problem is that if they don’t update you. Like they say it’s gonna be, you know, done on Tuesday. And then they don’t say anything and you’re like, hey, it’s Tuesday. And they’re like, oh no, no, it’s going to be another two weeks. Like, I, I’m not a fan of that. That’s, yeah.

In my book, I talk about this thing, because certain people don’t want to give an estimate because they don’t, they don’t want to get tied down. They think anything could happen. Like, how can I know it’s like predict the future? And look, I mean, that’s like as if someone’s, like you asked your friend to pick you up from the airport and your friend’s like, well, I don’t know. I could be sick that day. I could get a flat tire. Like, but why don’t you call me when you land, and then we’ll see. That’s not okay. Like, you can plan, but what you expect from your friend is not to leave you at the airport. Like, they can commit, and then you just expect that either, if they’re sick, or they have a flat tire, they call you, and they, or they leave a message, or something. So you’re not just, like, waiting for them at the airport without anything happening. And so that’s the important distinction is like these estimates can move as you get more information and they will become more accurate over time. Or they really give you a strong signal that the developer is really in over their head if like it keeps moving and keeps moving and keeps moving and it’s not getting more accurate. So that’s part of it.

Now, it’s so interesting because I get a lot of pushback, that this is like micromanagement. Like asking for the estimate and checking on the estimate. Like this is micromanagement. Like it’s treating a dev like a kid or something like that. And I think it’s quite the opposite. We were talking about before, like it’s treating devs like adults. Like I don’t know why people think asking for like an estimate is micromanagement. Like if you go to the mechanic and like you ask them like when they think the car is gonna be ready, like that’s micromanagement? No, like… Yeah, so I mean I just, I feel like it’s worth bringing that out, because that’s like a common reaction that I get that I think isn’t, doesn’t make a lot of sense to me.

But the final thing is that, and this is kind of related to the budget or the developer really thinking about it ahead of time, thinking what the scope is, and coming up with an estimate, is that when that estimate is said, like if that is much more than the business thinks is reasonable or is more than they think the feature is worth, that will trigger a conversation. And so that conversation itself is really useful. Like okay, you’re saying this is four weeks. That’s not really how much value we placed on it. Can you help explain, like why it’s four weeks? Like, what’s the most time consuming part of this?

And in my experience, like that often, not always, but that often will lead to a conversation that is something along the lines of, well, for this to be perfect, or this to support like every locality ever, or if this scales like to infinity, it’s gotta handle XYZ. And that’s a really good time to recognize, wait, is that, do we care about those things? And if you don’t, often what can happen is, like, no, we don’t need this to like go to infinity, we just have a demo with an investor, and it just has to work once, like for one user for five minutes. And then, you know, the response that you go like, oh, I can get that done in an hour. And you go from like four weeks to an hour, and I think everybody wins in those cases. So it’s really nice not to just have it be floating, because if those expectations are super out of line, that’s a really good opportunity to have that conversation, get some good value out of it.

Henry Suryawirawan: Right. So I think everyone listening to this, I’m sure you can relate, right? So what is the, you know, why you hate about estimates, why you like estimates, right? So I think one of the things which I learned from somewhere as well, right, I think estimate’s one of the best way to kind of like do a planning, so it’s like a planning tool, right, rather than making people accountable for delivering something on time, right? So I think, without doing some kind of estimates, probably just like what you mentioned, right? You’re giving someone like no kind of budget kind of thing, right? So you can spend all your time and just deliver it whenever you like.

So I think definitely in a team, especially if you work in company, you can’t just work like that. You need some kind of planning. And maybe the most important thing as well is to coordinate with other teams, right? Because when you deliver something, maybe someone else needs to do some coordination effort, be it marketing, be it sales, right? Or the support team in order to prepare what you’re delivering, right? So I think that’s almost very, very important in a company setup, because without giving the kind of estimate when things will be available is really hard for the other teams coordinate.

[00:51:11] Improving Our Estimates

Henry Suryawirawan: So I think the other aspect that you mentioned is about micromanagement, right? So I think many people hate giving estimates simply because they will be given a ransom, right? You said something about, you know, delivering it this day. I think this is still typical in many companies simply because, you know, we have many stakeholders, right? And people kind of like take it for granted that whatever that we mention is something that-is accurate. So how can we change this habit or maybe how can we educate other stakeholders such that, you know, we are okay to give an estimates, but don’t put us so hard if we cannot deliver it.

David Guttman: Yeah, so one of the things that my managers do with the estimates is that they’ll check back in at like the 50% mark, the 75% mark, just to see if everything is still going okay. You can flip that, right? If you are the one that’s giving estimates. Up front with the estimate, you can say like, yeah, I think this is going to be two weeks, but I’ll tell you what, I’m going to check back in a week and I’ll tell you if that’s still the case, like the 50% time. And I think that just makes it really clear that that two weeks is not final. And if it’s moving, you’re going to find out in a week, right? And so if you’re giving that in my head when you were talking, I’m just imagining this chain of stakeholders where maybe you do give that to your manager and they give that higher up and higher up and higher up. Like you’re giving a very clear signal to whoever you’re giving that manager to, like, look, you can communicate this up if you want, but just know that you might be giving an update in a week.

Like, so don’t, don’t say, like, don’t act like it’s final. And I think that’ll probably go a long way to helping anybody who’s giving an estimate feel more natural about giving it updates. Because they’re even, it’s almost like they’re making another commitment, which is like, hey, in a week, I’m gonna be giving you an update. Like, I’m gonna be telling you that my first estimate was wrong.

Henry Suryawirawan: Yeah. I like that tips, right? So definitely when you are given an estimate, right? So you can always check back in terms of milestones, right? Maybe it be what you said, 50%, 70%, or even maybe slightly more frequent, especially if it’s-a longer kind-of estimates, right? So the other things that I typically do is also asking people to actually think about, you know, the worst case, best case, and maybe like normal case. At least, you kind of like know some kind of variability could happen. If you think about the worst case, for example.

And the other aspect is actually to break down the tasks into a smaller chunks rather than, you know, like a big chunk. Because when you have a big chunk, if you want predict it, it’s kind of like difficult to-get like kind of like accuracy, right? So how can we deliver in chunks, in a smaller scope? I think that will be key as well.

[00:53:55] Estimate vs Fixed Deadline

Henry Suryawirawan: And you mentioned also something about estimate, right? If people don’t give estimate, they typically don’t own the problem. So why giving estimates actually kind of you can associate it with kind of like ownership. Maybe if you-can enlighten us here.

David Guttman: Yeah, so I would say this happens a little bit more when it’s not that like there’s no estimate. It’s more that the developer is given the deadline. Or they’re, you know, like, oh, we really need it, you know, X, like, oh, this will only take, you know, so much, don’t you think? So this is problematic because the developer, like, if they’re not the one that came up with the estimate, if it’s wrong, well, it’s not really their fault, right? Like, well, I didn’t say that, right? Like, I tried, didn’t work, whatever. And so it’s a very different stake or different amount of skin in the game. Like if they are the one thinking about when it’s going to be done.

Now I do want to say that some deadlines are real. Like you can have the date that something needs to be fixed. What I really want to make clear, though, is that you can either choose one. The date can be fixed and the scope is flexible. Or the scope is fixed and then the date is flexible. And that’s usually what I’m talking about with the estimates, which is that the scope is fixed and the date is flexible. So here’s this amount of scope, when’s it going to be done? But you can do it the other way, which is like, hey, this is what we want delivered. How much of this can you get done by this date? That is also fine. So the real problem that I have is if both are given to a dev, whereas this is the scope, and this is the date that we need it by. I don’t think that’s good for anyone.

Henry Suryawirawan: Yeah, I think that this is the triangle of, you know, I don’t know, project management, something like that. There’s the other one, which is the budget, right? But typically, it’s very hard to play the lever of the budget unless you are like, I don’t know, like a rich startup company, right, where you can just hire consultants out there as-well.

So David, thank you so much for all this. I think we reached the end of our time. So for people who are interested in what we just discussed, there are so many other things, so many other principles in the manifesto that David wrote in his book, Superstruct Manifesto. I’ve read the book. I find it really insightful and sometimes fun, because, uh, you of like reflect back to your experience and, hey, I had this problem before and-I think I can learn from what David is mentioning in the book.

[00:56:21] 3 Tech Lead Wisdom

Henry Suryawirawan: So I have one last question for you before I let you go. So typically I ask this question called the three technical leadership wisdom. So maybe if you can think of them just like an advice, is there something that you can share for us today?

David Guttman: Yeah, I mean, this kind of goes into the whole reason why I wrote the book, is that I really, really hope that people don’t just cargo cult, don’t just copy what they see other companies doing. Like wholesale copying of systems, wholesale copying of processes. Like, don’t. Just don’t do that. I think that’s, that’s what I would say. What you really should do is just think about the problems that you actually have and really come up with solutions that really fit your issue. Like solve the problems that you have, not the problems that you want.

Kind of, you know, related to that is, yeah, you know, I sort of brought this up in the beginning when I was talking about building, like the, you know, the high scale systems. And really there’s, like, a lot of value in reducing the moving parts that you have in any of these systems. And sometimes as engineers, like, we, you know, we’re guilty of overengineering, we like to make things, like more novel and try this and try that. And, you know, it all fits together in a cool way in building this big machine. You’re also, you’re often going to be much happier if you really try and minimize the number of parts. Minimize the number of moving parts, like simplify as much as possible, just as a general way to go. Like I kind of think of like Occam’s razor, like the simplest explanation’s generally the correct one. You can apply that as well.

And I think the third one, I guess I’m just, I’m going to go back to beginning when I was talking about the career pivot and, or like the parts of my career that I think, you know, were meaningful to me. And the never lose sight of those business goals, right? So when I was talking about, I’d go out to lunch with people and I’d figure out what they were actually, the problems that they had in their day to day. I think it can be possible, depending on your team, depending on your company, depending on what’s going on, it can be possible to lose sight of why we’re doing the engineering that we’re doing. We can lose sight of the company that we’re working in. It’s a machine that can only run if it’s getting fuel, and oftentimes that’s revenue. And really trying to think of what you are doing to get more revenue, more profit in, because that’s what sustains it. That’s, you know, what pays for your salary, your team’s salary for all the, you know, the systems that you use, everything like that.

And sometimes it can be really difficult, right? I mean sometimes there isn’t clear how you can do anything to drive revenue. Sometimes it can be that you lower costs. You know, you can increase profit by lowering costs, by saving time. And just don’t lose sight of that. And sometimes it means taking other people out to lunch or just having more conversations with people in other departments to know, to even be aware of where those opportunities are or where those problems are that you can sort of shift resources to solve. So I think those would be the three.

Henry Suryawirawan: Yeah, I like the last one, and especially in your book you also cover, don’t forget to actually give some meaning to the developers on the work that they do, right? So relate that with the business goals, relate that with impact that the product that you’re building given to other customers or people right out there. So find the meaning. And I think it’s also important for engineers not to lose sight, you know. Sometimes techies like to play, I don’t know, with technologies, try out new things, or build some complicated system that will probably not solve the problems that the company is facing at that point in time. So yeah, don’t lose sight of-the business. So I think thanks for tips.

So David, if people love this conversation or they want to check out the book, is-there-a place where you would recommend people to-go to?

David Guttman: Yeah, so it’s called the Superstruct Manifesto. That would be difficult for me to spell out. So if you want to get redirected to the book’s page just go to treatdevslikeadults.com and it’ll take you there. You can also find me on LinkedIn, David Guttman. And, uh, yeah, I think those, those are the two, two places to go.

Henry Suryawirawan: Wow, nice, catchy URL. So I’ll put it in the show notes if people want to check it out. So thank you so much again, David, for sharing your manifesto. I think it’s really insightful. Thanks again for that.

David Guttman: Yeah. Thanks so much for having me. It was great being here.

– End –