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.