13 ms·

Hire For The Ability To Get Shit Done

145 points by eladgil 15y ago

wccrawford 15y ago
"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 15y ago
  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 15y ago
    I agree you should compensate people for being really good. Is there someplace I stated otherwise?
    - kamaal 15y ago
      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 15y ago
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.
silverbax88 15y ago
"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.
- eladgil 15y ago
  What are the key things in your experience that let you know if someone is good or not as a long term fit with your company? Our test was not primarily just code quality. When we brought people in we would look at: 1. Approach. Did they use e.g. an open source pre-existing module or write something themselves? Did they come up with a creative solution? 2. Culture fit. While they were in working with us, how did they interact with the team? Did they enjoy working with us and vice versa? 3. Productivity. How much did they actually get done?
  - rubashov 15y ago
    This stuff just seems easy to figure out from a resume and asking questions. If they can talk competently in detail about cool stuff on their resume, and you yourself are smart enough to spot BS, then you know they get stuff done. As for culture fit, again, a socially competent interviewer can size these things up reasonably quickly.
  - owenmarshall 15y ago
    There's no way to figure this out from a one on one interview with that person? I mean, a half-day programming test feels excessive. Are you worried about loosing good candidates that just don't want to deal with the headaches? I've heard people try to justify insane hiring processes by saying "we want to filter out the people that don't want to work here. We only want people that really want it." But the best programmers -- the ones you want to hire -- are going to be in high demand by companies that look at their github, have a three minute interview, and pull the trigger.
chollida1 15y ago
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:)
dusklight 15y ago
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 15y ago
  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 15y ago
    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.
jroseattle 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.
jcromartie 15y ago
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 15y ago
  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 15y ago
    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.
ChuckMcM 15y ago
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.
- eladgil 15y ago
  I 100% agree with this. Sometimes it is the wrong manager or the wrong environment which makes a productive person less so. In this case the person and their manager either need to work it out, or the person may need to leave the team, group, or company and find a home where their talents can really shine (or, if the manager does this to everyone who works for them, hopefully their manager realizes this and fixes it).
- ohyes 15y ago
  "Google had developed a number of people who spent much, if not all, of their time preventing change...The fear was risk and safety." I think you nailed it here. But something to realize is that this is not unique to Google, this is true in any large corporation. The issue is that as people develop careers within the corporation, they become interested in what is most politically expedient for said career. This means they become very averse to any situation where the individual might personally look bad. This means that aggressive projects which could have a high level of reward and equivalent risk for the company get waylaid disproportionate to their overall risk/reward ratio. I think your point about people not understanding the systems that they are working on compounds this idea, as it makes the risks of changing a system appear higher (because they do not know the system).
medinism 15y ago
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
famousactress 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        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?
samd 15y ago
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 15y ago
  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.
johngalt 15y ago
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.
HannibalLecter 15y ago
This is good but it's lacking something. I've done the Clifton Strengthsfinder (by the Gallop people) and there are many many strengths people have that are not related to getting things done. SO instead of hiring someone with one specific strength, whether it's getting stuff done or being responsible -- I recommend hiring people who have strengths you desperately need and also by that same caveat, make sure you push them in areas where they are strong, not in areas where they are weak.
ShawnJG 15y ago
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.
mannicken 15y ago
""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.
Tichy 15y ago
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 15y ago
So... how do I convince an interviewer that I am someone who can Get Shit Done?
- Tangaroa 15y ago
  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 15y ago
> 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 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 15y ago
  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.
billforsternz 15y ago
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 15y ago
  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 15y ago
    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.
muyuu 15y ago
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.
danenania 15y ago
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.
aridiculous 15y ago
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 15y ago
  This is one of the best comments on here. 'Talent' is not a one dimensional scalar.
skcin7 15y ago
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 15y ago
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?

145 points by eladgil 15y ago

"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 15y ago
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 15y ago
  I agree you should compensate people for being really good. Is there someplace I stated otherwise?
  - kamaal 15y ago
    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 15y ago

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.

silverbax88 15y ago

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

eladgil 15y ago
What are the key things in your experience that let you know if someone is good or not as a long term fit with your company? Our test was not primarily just code quality. When we brought people in we would look at: 1. Approach. Did they use e.g. an open source pre-existing module or write something themselves? Did they come up with a creative solution? 2. Culture fit. While they were in working with us, how did they interact with the team? Did they enjoy working with us and vice versa? 3. Productivity. How much did they actually get done?
- rubashov 15y ago
  This stuff just seems easy to figure out from a resume and asking questions. If they can talk competently in detail about cool stuff on their resume, and you yourself are smart enough to spot BS, then you know they get stuff done. As for culture fit, again, a socially competent interviewer can size these things up reasonably quickly.
- owenmarshall 15y ago
  There's no way to figure this out from a one on one interview with that person? I mean, a half-day programming test feels excessive. Are you worried about loosing good candidates that just don't want to deal with the headaches? I've heard people try to justify insane hiring processes by saying "we want to filter out the people that don't want to work here. We only want people that really want it." But the best programmers -- the ones you want to hire -- are going to be in high demand by companies that look at their github, have a three minute interview, and pull the trigger.

chollida1 15y ago

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:)

dusklight 15y ago

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 15y ago
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 15y ago
  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.

jroseattle 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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.

jcromartie 15y ago

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 15y ago
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 15y ago
  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.

ChuckMcM 15y ago

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.

eladgil 15y ago
I 100% agree with this. Sometimes it is the wrong manager or the wrong environment which makes a productive person less so. In this case the person and their manager either need to work it out, or the person may need to leave the team, group, or company and find a home where their talents can really shine (or, if the manager does this to everyone who works for them, hopefully their manager realizes this and fixes it).
ohyes 15y ago
"Google had developed a number of people who spent much, if not all, of their time preventing change...The fear was risk and safety." I think you nailed it here. But something to realize is that this is not unique to Google, this is true in any large corporation. The issue is that as people develop careers within the corporation, they become interested in what is most politically expedient for said career. This means they become very averse to any situation where the individual might personally look bad. This means that aggressive projects which could have a high level of reward and equivalent risk for the company get waylaid disproportionate to their overall risk/reward ratio. I think your point about people not understanding the systems that they are working on compounds this idea, as it makes the risks of changing a system appear higher (because they do not know the system).

medinism 15y ago

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

famousactress 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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?

samd 15y ago

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 15y ago
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.

johngalt 15y ago

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.

HannibalLecter 15y ago

This is good but it's lacking something. I've done the Clifton Strengthsfinder (by the Gallop people) and there are many many strengths people have that are not related to getting things done. SO instead of hiring someone with one specific strength, whether it's getting stuff done or being responsible -- I recommend hiring people who have strengths you desperately need and also by that same caveat, make sure you push them in areas where they are strong, not in areas where they are weak.

ShawnJG 15y ago

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.

mannicken 15y ago

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

Tichy 15y ago

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 15y ago

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

Tangaroa 15y ago
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 15y ago

> 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 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 15y ago
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.

billforsternz 15y ago

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 15y ago
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 15y ago
  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.

muyuu 15y ago

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.

danenania 15y ago

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.

aridiculous 15y ago

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 15y ago
This is one of the best comments on here. 'Talent' is not a one dimensional scalar.

skcin7 15y ago

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 15y ago

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?