
Hire For The Ability To Get Shit Done - eladgil
http://blog.eladgil.com/2011/09/hire-for-ability-to-get-shit-done.html
======
ChuckMcM
I can relate to this, but I can also relate to the other side of the question.
Sometimes it isn't me, its you. Take someone who gets things done and suddenly
in your organization they aren't delivering. Could be them, but it could also
be you.

I had this experience working at Google. I had a horrible time getting
anything done there. Now I spent a bit of time evaluating that since it had
never been the case in my career, up to that point, where I was unable to move
the ball forward and I really wanted to understand that. The short answer was
that Google had developed a number of people who spent much, if not all, of
their time _preventing change_. It took me a while to figure out what
motivated someone to be anti-change.

The fear was risk and safety. Folks moved around a lot and so you had people
in charge of systems they didn't build, didn't understand all the moving parts
of, and were apt to get a poor rating if they broke. When dealing with people
in that situation one could either educate them and bring them along, or steam
roll over them. Education takes time, and during that time the 'teacher'
doesn't get anything done. This favors steamrolling evolutionarily :-)

So you can hire someone who gets stuff done, but if getting stuff done in your
organization requires them to be an asshole, and they aren't up for that, well
they aren't going to be nearly as successful as you would like them to be.

The other risk is of course the people who 'get a lot done' but don't need to.
Which is to say they can rewrite your CRM system and push it out to the world
in a week but only by writing it from scratch.

~~~
rhizome
Word f'ing up. I was recently fired from a remarkably relatable situation
where a _hot ninja_ startup had no effective intake process, so for
orientation I had one pair-programming episode regarding an intensely
technical internal aspect of the application before being sent off to fend for
myself in their repository. Couple this with an office and project management
style predicated on "who can interrupt the loudest?", having multiples of
these conversations occur simultaneously, and an absolutely open office plan.

But hey, the CEO had sold a previous company for good money so this means he
knows what he's doing. I'm sure they'll be a huge success.

I'm not saying that I'm God's gift to college-dropout programmers, but I'd
never had a problem succeeding in a job until this one. In reaction to this
state of affairs I had considered that maybe I need to be at a huge company
that has better processes, but your Google tale says maybe otherwise.

</vent>

~~~
ShawnJG
since there seem to already be quite a few employees when you started I think
most of the problems there was a culture clash. coupled with the fact that
they did not properly educate you on how they operated. I'm not judging
different cultures but there are plenty of steps a company can take to make
sure new hires fit.

~~~
rhizome
If by "quite a few" you mean "less than 10," several of which had previous
worked together, I'm not sure that it qualifies as anything more than process
ignorance.

------
silverbax88
"As part of our hiring process at Mixer Labs, we would often give people a
half day coding exercise. "

I (and many people who I've hired) don't have time to waste on your startup. I
can tell within two minutes if someone can code or not. I've never understood
the need to have someone write code (and then nitpickingly critique the code
because it doesn't look like _my_ code) when I can just ask them and know if
they are lying or not.

And I've hired a LOT of super fantastic programmers.

~~~
aboodman
If you can do this reliably, you should start a business.

Common knowledge is that hiring programmers is insanely difficult. If you have
a gift for it, you could make craptonnes of money!

~~~
silverbax88
I did start a business. But I should state that I learned how to interview and
hire for years working for other people.

~~~
sliverstorm
Your parent probably means you should start a business of helping other people
hire good programmers.

~~~
silverbax88
I did. It does quite well. But I am no longer involved in it day-to-day.

------
aridiculous
Two things: a) I once heard a good quote and I think it's often true and
helpful to think about if hiring: "Talent doesn't come in convenient
packages".

b) The best traits of someone are very often some of their worst as well. Be
mindful of that when trying to find the "perfect" candidate. Example: Someone
who communicates well might also communicate (i.e. talk) a lot instead of
working at their workstation for extended periods. The point is to not expect
perfection from people. And by perfection, I mean excellence in several types
of disparate skills.

~~~
TheBurningOr
This is one of the best comments on here. 'Talent' is not a one dimensional
scalar.

------
chollida1
With the exception of Lazy, I've seen almost all of these at our fund:

I find most of these are pretty easy to fix:

    
    
        Lack of urgency.  

This one is simple, give a deadline for every task assigned.

Good people will hit their targets or let you know well in advance if they
won't.

    
    
        Easily distracted.

Hmmm, I'd say something here but there's that old expression about the kettle
calling the pot black:)

    
    
        Starts but never finishes things.

I'm not sure how this is allowed anywhere, but for us we follow the Peter
Thiel principle,

that you have one major task to do and that's what you'll be judged on. This
seems more of a management fail.

    
    
        Argumentative. 

This is where we fail the most.

We try to hire smart people and fortunately/unfortunately smart people have
strong opinions on how things should be done.

We've settled on a hybrid of the Microsoft, you own your area for smaller
decisions, and the "disagree and commit" style of decision making for larger
decisions.

    
    
        Slow.  

Unfortunately this is a deal breaker for us.

If you can't keep up then you don't make partner at your 3 month review.

    
    
       Perfectionist.  

This just follows from the "Lack of urgency" and the "slow" categories.

You can code your algos and systems as well as you want as long as they work
and come in on time:)

------
danenania
Something about this mindset is depressing to me. Obviously we all want to get
shit done, and every company wants to hire people that get shit done, but this
definition of 'get shit done' seems very narrow and robotic. The author seems
to want to evaluate a programmer's efficiency the same way we evaluate the
efficiency of an assembly line or a sorting algorithm.

The problem is that the smartest, most creative, and overall most productive
people often don't think this way at all. Instead of slogging away obediently
at a problem for six hours, they might dilly-dally on twitter for two hours
before having a lateral insight that lets them solve the problem in 15
minutes. They might go to Thailand for the first 3 weeks of a 4 week project
then, in a semi-sleepless 100 hour binge, produce a technical masterpiece with
a beautiful UI and additional business-savvy features no one else could have
thought of thrown in on the fly. Would it be better for your company if this
person just sat at his or her desk and focused perfectly and coded 10 hours a
day like a good little robot? Does it matter? The same qualities that make
some people brilliant will tend to make them unable or unwilling to work like
this. You can gripe about irresponsibility or lack of discipline, but they are
indeed getting shit done, just not the same way you do. You can pass on them
because they don't fit your mold if you like--a more open-minded company will
quickly be there to capitalize on the value they offer.

------
mannicken
""As part of our hiring process at Mixer Labs, we would often give people a
half day coding exercise. "

I'm just letting you know, I'm not working with you. Luckily, after years of
experience I have been able to arrange lines of clients wanting me to get
stuff done for them so I'm capable of screening companies like you on simple
cues like this.

Have fun finding a slave who'll just do what you ask, no questions asked, no
creativity involved.

Of course, I'm lazy but only about things that don't really matter. Only
stupid people laboriously move huge tons of mass by dragging them; smart
people invent a wheel and an internal combustion engine.

------
dusklight
I don't fully agree with this, it depends on what type of project you are
working on.

There is a certain type of cowboy programmer that depends on thinking quickly
and having a good memory. This type of programmer can write code that works,
really quickly -- provided the size of the project can fit entirely in their
head. Because of this, they can do really well on small size projects but they
never learnt proper code design and architecture skills, because they never
needed them. This type of programmer ends up not being able to scale as the
size of the project gets larger, because eventually they reach the limit on
how much code they can remember at one time, and the lack of code design that
lets you reduce the number of things you need to be aware about in order to
write new code without breaking anything really starts to bite you.

~~~
eladgil
Maybe I did not state things very well. This isn't just about short term
projects. Some things will take many months of work to complete (e.g. v1 of
some key scalable infrastructure).

It is not about doing short fast sprints - it is about being long term
productive as a member of a team. Productivity includes good design and
thinking through what is needed up front. But it is also about marrying
thoughtfulness to efficiency.

~~~
cppsnob
_e.g. v1 of some key scalable infrastructure_

Just so I understand: You're always willing to trade intelligence and
experience for someone who produces more, for essential key components of your
startup. So you would hire a less experienced person who writes more code over
a very experienced slow developer, do I have that right?

All that does is trade the short term risk of not having as much developed
with the long term risk of having a broken system. It means you're potentially
betting your business on someone who isn't the best, just because they seem
more productive.

In summary, you risk making a Friendster instead of a Facebook.

Let me know if I misunderstood your point.

I hire on both: smart people who get it done. And getting it done is relative.
Unless you're in consulting, velocity is almost never the issue compared to
correctness, so a smarter, slower person is sometimes the right choice. A
member of my team took a long time to come up to speed, and is now kicking ass
and making the right decisions to keep things on track.

~~~
eladgil
No. What I am saying is intelligence and experience are crucial (intelligence
more then experience in my book). Also crucial is the ability to get shit done
and culture fit.

I want candidates with all these things.

If someone is very very bright but not very effective, or terrible for the
culture of my startup, I would not hire them.

If someone was an amazing culture fit, but not very bright, I would not hire
them.

"Coming up to speed" makes sense. It is all about the context in which the
person is working, what they did before etc. Productivity takes time to scale,
as does trust in one another, working as a team etc.

But there are some people that you give a lot of time and attention to that
just don't get a lot done.

~~~
cppsnob
_crucial is the ability to get shit done_

Ok, so what exactly does that mean? Are you concerned with velocity or
correctness?

~~~
rgraham
Do you want me to meet you at the right place or on time?

You want both. It's a false dichotomy.

------
famousactress
I call bullshit. In my experience it's very rare for people to fall into
almost any of those adjectives naturally... _especially_ developers. These are
people who almost universally _love_ to write code.

Most of the observations listed here I'd be more likely to line up with a lack
of investment and clear alignment of goals and priorities. The tone of the
article seems to further support to me the lack of an environment that's
nurturing to the team members' motivation.

~~~
sdh
In my experience, the difference between a GSD engineer and an average
engineer is the understanding that it is up to you to be motivated, focused,
and effective.

And, I've worked with many GSD engineers, so they definitely exist.

~~~
famousactress
I'd agree that it's up to them to identify and communicate things that are
challenging their effectiveness, but not always to fix them... and early in
someone's career even identifying them can be tough.

I'm just arguing that it's contextual way more often than it's fundamental,
and the tone of the article left me with the impression that the author isn't
interested in playing much of a role in people's motivations.

~~~
eladgil
Apologies if my tone set up the wrong impression - I think the environment,
manager, motivations etc. are all crucial, and some people are very productive
in some settings but not others.

That said, I also think there are many people who just aren't that productive,
and screening for people who are great at GSD is crucial for a startup.

~~~
famousactress
Likewise, I apologize if I took too much from tone.. I think the bottom line
is that we disagree here:

 _"... there are many people who just aren't that productive..."_

I don't think that's the case. I think the steady-state for most people is
working (hard). People who aren't productive are generally _frustrated_ that
they're not productive. I get it though, there are people who require very
little from the outside world to move forward. They'll "GSD" as you put it
without much outside influence. I've worked with people who score high on that
metric, and I'm genuinely humbled by their ability to make forward progress
even in less than optimal conditions.

That said, I think it's tempting to value them above resources that are more
sensitive to their context but I'd warn against missing an opportunity. In my
experience the developers your talking about will absolutely 'GSD'.. Even when
all you ask them to do is 'S'.

I frankly like surrounding myself with people whose motivation falters when
they don't feel connected to the problem we're solving for our users, or when
we're calling too many bullshit meetings, or when they don't believe in what
we're doing. Keeps us honest. Those employees are your canary in the
mineshaft. I think where their interest goes, our market is likely to follow.

After all, if my team isn't excited to build it who the fuck do I expect to
pay me for it?

------
wccrawford
"I don't care how smart someone is - if they are unable to work hard and crank
out a large amount of high quality work, they will weigh down your startup."

Don't forget that you need to pay them like-wise.

It's acceptable to accept slower (but still high-quality) work in exchange for
less pay, etc. And sometimes it's even acceptable to let the quality slack for
the same reason.

~~~
epo
Oh yes, if you want people this perfect (and it is a good list) then pay them
accordingly.

Unless of course he missed off his other criterion "will work for peanuts".

~~~
eladgil
I agree you should compensate people for being really good. Is there someplace
I stated otherwise?

~~~
kamaal
Although you agree on this, a lot of people including ones from start up's
aren't comfortable with paying people proportional to their productivity.

There are many reasons for that, most are happy with flat salary models where
can they pay a donkey and a horse the same salary under the premise that they
assume both a donkey and a horse can carry weight and run. Unfortunately
that's how badly people think of when they pay. Or they are just afraid they
may end up setting a trend productive people end up earning big all the time.

------
chrisabruce
I think this is some of the best advice on hiring for a startup I have seen in
a while. I just don't think the typical "reverse all the words of a sentence
in place" is as helpful. With stuff like StackOverflow, it seems much more
valuable that someone can figure something out and "get shit done", especially
in a startup where there is so much to do.

Going forward, I will probably only hire someone after seeing them work on a
small project, maybe even pairing with them in the process.

------
johngalt
For every one true GSD person you'll find, there are ten who'd rather spend
all day arguing about how their tools aren't perfect or they are waiting on X
person/thing. In larger teams it becomes easier and easier to blame the 'X'.

A good rule of thumb to spot these people is how much yak shaving they require
before they will start adding value. If they walk in and say "well I need new
new system A from IT, and hours B approved by HR, and version control system
C, and software stack D, and my last company had E, and, and, and etc..." The
big red flag is when they ask for all of this serially and not in parallel.
Then you know you've got somone looking to setup excuses for why they haven't
delivered. A true GSD will carve through obstacles as much as possible.

A good analogy is the out of shape person who wants the platinum gym
membership, new workout clothes/shoes, the trainer, and the diet plan, but
always needs something else before they can start working out. Meanwhile the
GSD person is going for a jog and doing pushups.

------
muyuu
Expecting 1/2 day free labour will filter out experienced, non-desperate
engineers. I've put up with that kind of stuff in my early 20s but certainly
wouldn't any more, unless my personal situation was desperate.

------
jcromartie
I have to say that some combination of these negative traits can describe me
_at certain points in time_. I'll set out to try to build the "perfect" thing,
and then snap to reality and use the quick-and-dirty solution.

Procrastination, distraction, laziness, lack of follow-through, slowness,
those all manifest themselves when I have no reason to be engaged in the work.
The work might just be a really bad match (example: endless maintenance and
toiling through bad legacy code, putting out fires, when I could be designing
and building something half decent).

~~~
eladgil
Good points. We all have moments where we exhibit some or all of these traits.
This is not about an individual moment (or e.g. working for a terrible,
demotivating manager, or on a crappy project).

But I do think there are some people who may be very smart or experienced, but
who just are not very effective. Some of this could be contextual (in which
case it is valuable for both you and them to find them a new home), but
sometimes it is just a person's personality or approach to work.

~~~
prawn
Elad, really enjoyed your post. I am a notorious procrastinator, I start
things I don't finish, I am very easily distracted, but I also run a small
business. I didn't hire GSD types intentionally, but it happened through sheer
luck and I would definitely favour those attributes in the future. My two
current employees, usually without deadlines or any real structure, crank out
work at a great pace.

------
medinism
I can relate to this post. Specially around Slow and Argumentative. These are
cloaks in which faux-smart people hide under. I had experience with a
developer who would not want to lift a finger until he absolutely knew that
the feature he was about to build was assured unquestionable success. So we
would gather some data to figure out users predisposition to use the feature,
and still nothing. in the end he would not experiment and we fired him

------
samd
Just about all of these problems can be solved with good agile practices like
pairing and scrum.

People are way more productive, focused, and determined when pairing. It's
simply much harder to waste time and produce low quality work when you're
directly accountable to the person next to you.

Scrum solves the urgency, commitment, follow-through, and slow problems. Each
iteration the team has to commit to a set of tasks to get done. If they don't
make it they have to figure out why they didn't, and how to improve. This
continuous reflection and optimization is how team's get good and fast.

Of course there will be people who can't be brought into the team, but they
are few and far between. And you can't tell until you've created a team for
them to be brought in to. So instead of focusing so much on the fantasy of
hiring a great team, learn how to build a great team.

~~~
unshift
i've found scrum to be the worst possible "methodology" on the planet and
can't stand pair programming. i've also been known to get things done on
occasion.

nothing about making software is one size fits all. forcing scrum and pair
programming sounds like a really good way to get an enthusiastic team, but
guarantees little else.

------
jroseattle
This is a bit too one-sided. Hiring those who GSD is obvious, but it's not the
only thing. Context is important -- what are you building? Do you need
algorithmic expertise? What about scale? Platform experience?

Applying one aspect to hiring, especially at an early-stage startup, is a poor
approach.

~~~
eladgil
This is a fair point - you should definitely tailor your hiring approach to
your needs. But for all the types of people you mention, I think you would
want people who are very productive and able to GSD for their areas.

Do you think this is not the case? Or are these specific types of roles where
you think having effective people are secondary?

~~~
jroseattle
Absolutely, productive people are very important. Especially in early-stage
startups, where nearly every day feels like all-hands-on-deck.

However, productivity comes in multiple forms -- just depends on how you
measure it. Because of the limited resources in early startups, people need to
fire on all cylinders -- productivity and smarts.

~~~
eladgil
I 100% agree with you :) I think the way I wrote the post may have stated the
GSD side too strongly. I totally agree you need really sharp people who are a
good culture fit who also GSD. Thanks for reading the post.

------
billforsternz
I can't tell you how much _more_ I would value someone who takes 4 weeks to
build something that works 100% of the time over someone who takes 1 week to
build something that works 95% of the time. Something that works 95% of the
time is worse than useless IMHO.

~~~
jodrellblank
The replies to this topic are the most ridiculous programmer-equivalent of
Internet-toughguy posturing.

Have you seen the people, money and time resources NASA put into the code
which runs on space flight hardware? The reviews on reviews on reviews, the
exactly specified every code path, the complete tracking and investigating of
every bug in their codebase ever and checking all of them for wider
applicability... and _they_ don't get 100% success in _years_ of applying
their processes to a comparatively small and limited codebase.

Wasn't Zed telling us about how 37 signals restarts their Ruby in Rails
processes every day due to instability and memory leaks? Guess that makes
their lower-than-100% success rate multi-million dollar generating software
"worse than useless", eh?

~~~
billforsternz
Sorry didn't see this at the time. Just for the record, I wasn't saying lower
than 100% success rate is worse than useless. I was saying 95% success rate is
worse than useless. I didn't set up this false equivalence, the OP did. I know
that 100% is a tough or impossible goal, but you really do need to _approach_
100%. 95% is nowhere near close enough.

------
skcin7
So what should I do if I am reading that article and thinking to myself the
whole time "yup, I do that. yup i do that too"

------
cbs
How do you "Hire For The Ability To Get Shit Done" when your interview process
is going to drive all of the non-masochistic talent away?

------
Tichy
I hope you would pay me if you expect a half day assignment. Or at least make
it fun, like the Google Code Challenge.

------
radarsat1
So... how do I convince an interviewer that I am someone who can Get Shit
Done?

~~~
Tangaroa
Show that you have a past record of Getting Shit Done. List things you have
accomplished on your resume. Be able to say "I led the doing of X, and it
improved the company". If you are fresh out of college, describe your ability
to finish your schoolwork early and completely and have recommendations from
the professors backing you up on that. If none of this applies to you, start a
small open-source project _and complete it_. Also RTFA and see that you meet
the author/interviewer's definition of a person who can Get Shit Done since he
describes what he's looking for in a fair amount of detail. Having a college
degree used to be evidence you could GSD but it's not good enough anymore.

------
dramaticus3
> E.g. "I am average compared to other engineers". For an early stage startup,
> average is not enough.

If you bailed them on this, you're process is seriously flawed.
<http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect> As Kruger and
Dunning conclude, "the miscalibration of the incompetent stems from an error
about the self, whereas the miscalibration of the highly competent stems from
an error about others" Historical references Although the Dunning–Kruger
effect was put forward in 1999, David Dunning and Justin Kruger have quoted
Charles Darwin ("Ignorance more frequently begets confidence than does
knowledge") and Bertrand Russell ("One of the painful things about our time is
that those who feel certainty are stupid, and those with any imagination and
understanding are filled with doubt and indecision") as authors who have
recognised the phenomenon.

~~~
eladgil
Asking people what they think of themselves is just 1 input. It is not a
binary decision. Rather, you need to get as many data points as possible on
whether the person is very productive or not and then make a call on whether
to hire them.

------
ShawnJG
while there are definitely bad employees, the major problem is the fact that
the US school system no longer trains people to be leaders. That's where
friction comes in between hiring someone in the early days of the start up.
You have a culture clash between a person who's trying to blaze trails and a
person who just wants to be along for the ride. I think there's definitely a
place for both, but in the beginning you definitely have to take extra time to
look for like-minded individuals.

