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

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, you could wind up paying a pretty hefty tax for something that you're not getting very much benefit or ROI

from. 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.

Like any meeting that you have, you are taking N number of people, 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. This is even more of a problem when you have a recurring meeting you're getting into like the Fang style interviews with the what I call computer science riddles. And it's so much like this

theme. It's 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, OK, who can solve the hardest problems? A lot of founders get it in their head that there is these 10X engineers out there and

those are who they want to find. They have in their head the idea that there was 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 everyone's just like, you know, like, mind blown. Hello everyone. Welcome back to the Technical Podcast Show. Today I have with me David Gutman. He's one of the thought leaders in the JavaScript space, right? And also in the startup space that he has over 90 open source

packages on MPM. That's kind of like a lot to me. And also he wrote 2 popular JavaScript books. But today, funnily enough, we are not going to talk about JavaScript and its ecosystem. We are going to talk about his book, which is titled The Superstar 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. Thank you. Thanks for having me. Right David, I always love to

1st invite my guest to share a little bit from your career. Any turning points that you think we can learn from you? Yeah, Don't know if you'll be able to learn from me, but I think one of the 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 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 him 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'll 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 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 overtime. 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 that they can do that, that they can be self-directed, go find people to help going from Disney that then then I got my first like chief scientist position and 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 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.

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 overcomplicate 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 superstructs, taking things that I learned from, you know, being ACTO and really systematizing that in a way that could be useful to more companies than just one. When you're ACTO, 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. Right, thanks for sharing the story. So I left 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 some moving parts is something that is more scalable.

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. 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. 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 insights from your experience, right? But in the 1st 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? 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. Stand ups, I think it's very

interesting, right? So you mentioned that so many engineering leaders and 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 it's own blocks, 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 Fang companies hiring strategies, right?

So I think you cover most of them in your book. So I think let's probably start with the first one we 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? 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

because 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 standups. So the gain that I think a lot of people think that they're getting from standups 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 standups, 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 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 is I'll talk to founders and, you know, I'll talk to them like, OK, so you 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 stand ups are 15 minutes. I've known a ton of people whether or not. So let's just say that it's the 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 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 going to 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 standups 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 stand up 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 stand up 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. 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 effective and efficient, right? So maybe let's start with probably the time itself, right?

So you mentioned stand ups typically in the morning, but I feel sometimes to cater some night hours, 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 productive particular 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 or at 9, you start at 10. So typically people won't start the serious worker in the first

hour, right? So I think that's kind of like one of the danger and after the meeting as well, because there's so many things that we need to, you know, I don't know, contact 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 productivity, right?

So is this something that you also think that could be a productivity killer for many of the engineering teams happening out there? 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 because it's really difficult to coordinate everybody.

Like, no, your day starts right now and we're going to start all of our days like right at the same time with this daily stand up. 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 with within the stand up.

Right. And you mentioned in the book that we can't live without stand up. So what would be the alternatives that typically you suggest for all the startup founders or maybe the tech teams out there? Yeah, so one of the funny things about doing a survival guide and having a book that's here's what not to do is it begs the question, like, 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 fun to 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 Valiant with your team. Like I don't care if nobody on your team likes first person shooters. I don't care if 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 need 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 out for the last three

weeks. Like if that keeps happening, like, I don't think daily standup 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.

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 like a contextual or maybe like 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 happen is that first is about status report. So I heard the leaders want to know what is happening between

the team members. And the second thing is about building so-called a pressure accountability so that everyone is kind of like on the toe every day. So maybe anything's from you to maybe teach us here. What can leaders do in order to get those two from the team as well? 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 stand up Lee, this is a bot and 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 the basic most default stand up, which is the what were you working on? What's your plan? Any blockers thing you get 100%

do that. You mentioned accountability, the, 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, 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 XYZ or I'm going to look into whatever bug, or I'm going to work on issue number 123 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 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 123, fine. Just say what you're going to have in the pull request that's going to 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. Like you want to just change the the color of the button from red to blue and 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 VR 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 reread it, I thought about it and then I watch YouTube and yeah, yeah, I worked on it. Like it's very clear. And if the answer is no, the T 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 is no, I think a lot of people at this point, I don't know, I think there could 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 going to 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 while 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, OK, well it's been 3 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, OK, this is what I'm going to 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. 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 the 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 a mechanism to just put down what is the plan and what is the outcome kind of thing right into some like written kind of a channel. And then the last one is about treating everyone as adults, right? So I think, yeah, we should respect each other. Like we want to have team members who are also kind of like behaving like adults, not like we have to keep on following up and asking them to

do things. So I think that's a really great. So hopefully people learn about this better stand ups or better not to do stand ups kind of

thing, right? 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? Yeah, for sure.

So, 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 want to find. So the general concept of a 10X engineer is that an engineer can have 10 times the output. You know they are 10 times as valuable as other engineers, but you know they cost the same. So the same salary dev, same level, whatever. One of them as 10 times the value output than the other one.

What's interesting about this, Amy, if you trace this one back, where this comes from is there was a study in the 1960s, it was by the US 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 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 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 #2 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 with 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 those 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.1 X 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 or 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 10 times faster with 10, you know, less bugs or whatever. And yeah, I wouldn't expect their salary 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 over all time. And you can also, it's not weighted towards this one developer being so much more awesome. It could be weighted towards the 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 that 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, 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 going to say that that type of skill set 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 of a company, 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, with commandos, infantry and police. And so I think that model of like a certain type of developer

who can work well on a team. Here's 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. Like is it 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, 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 is 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.

Now, if you want, I can get into the, you know, I think you were getting into like the Fang style interviews with the what I call computer science riddles. And I mean, again, I think it's so much like this theme. It's 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, OK, who can solve the hardest problems? Like, OK.

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, 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, you know, like you have to know how we're using like these cues where 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, OK, 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, 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 for me to tell them

what's right or not. But if you don't have those style problems, I wouldn't necessarily copy them. 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, other 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 like these giant mainframes, right? Obviously the kind of output that someone produce 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.1 X developers and kind of like oust them out, right? So I think 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.1 X is something that you should figure it out how to solve. And I think the other thing is about commando inventory 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 the commandos or all the police, right? So having a balanced skill set and maybe responsibility in the team will be something that is

great, right? 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, like I can see it also in my career, right? Mostly we all write crap 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 a problems that algorithms arithmic 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 great output. So the next I want to cover

about interviewing style thing, right? So many people actually kind of like find it difficult to figure out the questions that we should ask engineers. I mean, the the Google, the Facebook or the Amazon, maybe you have their own styles, but what would you think will be a great interview questions that we should ask engineers for a smaller type of company or smaller like a typical engineering team, right? And so is it something that you have some kind of best practices?

Because you mentioned that we should be similar to the 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 a particular database just for that particular interview. Or worse, some companies actually actually give the candidates homework, asking them to do some questions outside of their working hours.

So maybe from your view, what's your take here? Yeah. 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% that homework that you mentioned, but there are paid challenges. So when superstar hires, we have like a very short filtering project. So like we do need you 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 that's like 5 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, because you're not going to say like, Oh well, well, here's a feature that we want to add to our production system. But then, Oh yeah, but you got to, you got to know this and that and like, oh, we're giving you access to our GitHub. Like, 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 AQ 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 11 button spin up that works on everybody's machine if you really wanted to do that. In general, I think the 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 distal 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 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 industry or code base type constraint that is like, I don't know, it's almost like this no go. It's like when you're working at the scale of the ad tech and all those requests, like 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, And so it's really hard for me to know upfront 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. Right.

I also agree that the, 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 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. 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 deaf 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 deaf to actually give estimates. So maybe tell us about why this

principle exists. Yeah. So one thing that I have found is that just by having a developer give an estimate, the projects is much more on track. And the 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 1 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. Like 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 counter balancing 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 going to 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'm, I'm not a fan of that.

That's yeah. But 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 that 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, like, why don't you call

me when you land? And then we'll see. That's not OK. 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 the 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, OK, you're saying this is 4 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 got a 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 5 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 4 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. Right, So I think everyone listening to this, I'm sure you can relate, right? So what is the, you know what 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 estimates 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 budget kind of a 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 a company, you can't just work like that. You need some kind of a planning and maybe the most important thing as well as to coordinate with other teams, right? Because when you deliver something, maybe someone else need 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 that kind of estimate when things will be available, it's really hard for the other teams to coordinate.

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 and 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 we are OK to give an estimate, but don't put us so hard if we cannot deliver it. 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. OK.

You can flip that, right. If you are the one that's giving estimates upfront with the estimate, you can say like, yeah, I, 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, 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 an updates because they're even, it's almost like they're making another commitment, which is like, hey, in a week I'm going to be giving you an update. Like I'm going to be telling you that my first estimate was wrong. 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 could be like when you said 50 percent, 70% or even maybe slightly more frequent, especially if it's a longer kind

of estimates, right? So the other things that are typically do is also asking people to actually think about the worst case, best case and maybe like a 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 to predict it, it's kind of like difficult to get like kind of like a accuracy, right? So how can we deliver in chunks in a smaller scope? I think that will be a key as well. 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. 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 of 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 the estimates, which is that the scope is fixed and the date is flexible. So here is this amount of scope,

when's it going to be done? But you can do it the other way, which is like a, this is what we want delivered. How much of this can you get done by this date that is also 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. Yeah, I think that this. Is the triangle of, you know, I don't know, project management, something like that. That'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 or 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. Because I've read the book, I find it really insightful and sometimes fun because you kind of like reflect back to your experience. And hey, yeah, I had this problem before. And I think I can learn from what David is mentioning in the book. So I have one last question for

you before I let you go. So typically I ask this question, the tree technical leadership is them. So maybe if you can think of them just like an advice, is there something that you can share for us today?

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 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, you know, I sort of brought this up in the in the beginning when I was talking about building like the, you know, the high skill systems in 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 over engineering. We like to make things like more novel and try this, then try

that. And you know, it all fits together and in a cool way and 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. I kind of think of Occam's razor, the simplest explanations, generally the correct 1. You can apply that as well.

And I think the third one, I guess I'm just, I'm going to go back to the 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 of 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, you can increase profit by lowering cost, by saving time. And I, I just don't lose sight

of that. And, and sometimes that 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. 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 the impact that the product that you're building given to other customers or people right out there. So find the meaning. And I think that 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. And so, yeah, don't lose like the business. So I think thanks for the 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? Yeah, So it's called the Super Struck. Manifesto. That would be difficult for me to spell out, so if you want to get redirected to the books page, just go to treatdevslikeadults.com and it'll take you there.

You can also find me on LinkedIn, David Gutman and yeah, I think those are the two two places to go. 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. Yeah, thanks so much for having me. It was great. Being here.