Hire for the Ability to Get Shit Done (2011)

http://blog.eladgil.com/2011/09/hire-for-ability-to-get-shit-done.html

by rememberlenny • 5 years ago

78 106 5 years ago

blog.eladgil.com

I am not able to figure out if this article is parody or in a serious tone.

I feel like HN has become a mecca of FAANG workers, laissez-faire engineering that complain about this and that, look down on startups as slavery, hardwork is considered right-wing ideology and perspiration is toxic.

I wonder if HN has become a parody, have you considered that?

lr4444lr• 5 years ago

There are just so many more Big Tech workers than us scrappy startup people reading and writing here than in the early HN days, and frankly, we have much more to do that keeps us too busy to post on HN as much as they probably have. Yeah, I said it.

aerosmile4• 5 years ago

Thank you.

shusson• 5 years ago

Any suggestions for alternatives?

gnatxc• 5 years ago

HN isn't nearly as bad as some "open" source projects, whose code and infrastructure has been completely taken over by seriously under-performing but power-hungry Microsoft, Google and Facebook employees (Amazon and Apple are less prominent here).

You can still say many things here that can't be said practically anywhere else on the Internet.

Sadly, like "open" source developers, startups are quite afraid of MAGAF as well, so they no longer talk as freely as they did 5 years ago.

MattGaiser9• 5 years ago

Maybe the startup ecosystem has just burned a lot of people? Startups seem great for the owners. But for the employees, they can easily be a terrible deal.

lemmsjid• 5 years ago

I've been doing startups since 2001, with brief stints at larger places due to acquisitions, and then a sojourn at a FAANG. Something that irritated me well before Hacker News existed, and manifested as Hacker News came into being, was the performative nature of startups. By that I mean all the boxes that startup founders would tick in order to be seen as a 'real' startup. This would create an excessive focus on superficial aspects of a company's culture: things like open plan offices, underpaying employees to keep them 'hungry', employees work 24/7 churning out code... In my own experience I never saw these things actually improving a startup's output. And along side that were many experiences of actual employee exploitation: promising employees the moon on equity by obfuscating their actual stake, shaming employees who did not conform to the founder's superficial sense of a productive programmer, etc.

I believe there is a lot more cynicism around now, because we're several decades into the whole startup thing, and such cynicism is often a good thing. Employees are way more savvy about looking into a startup's finances, business practices ( so many startups were built around the idea that regulations didn't actually exist...), and work culture before listening to the company's hype.

Not to mention that in my large company stints I encountered many people whose work ethic I found admirable. Really the difference between a startup and a large company in my experience, and the reason I prefer startups, is quite simply that startups are not large enough to experience the inevitable communication/hierarchy issues that come up when any group of homo sapiens becomes sufficiently large. I tend to get lost in my work and will work most of my waking hours, and that often isn't even possible at a large company because of the cross team orchestrations, while a typical startup has a big pile of things you can simply dive into individually and solve. You certainly can do that at a large company if you look for things to do, but I like my work to have measurable impact as well.

perl4ever• 5 years ago

"It was surprising how honest some (very smart) people would be on this. E.g. "I am average compared to other engineers". For an early stage startup, average is not enough."

Well, they want better than average liars. Could go either way.

aerosmile4• 5 years ago

People have definitely found ways to turn PG into a monster, so I am prepared for anything... but Elad Gil? That would be a first, so super excited to hear which parts rubbed you the wrong way. If possible, try to keep the context in mind (early stage startup: 5 people with less than 12 months worth of runway).

probably_wrong• 5 years ago

I didn't think it was satire, but I'm at the point of my career where I wouldn't want to work for a company like this.

If I'm expected to make a 3-days homework exercise plus a half day live coding session, and then I'm expected to jump at their every whim too (respond email when it's convenient for them, honesty seen as a weakness, expected to be proactive but not too much or you become argumentative), I'd rather look somewhere else.

This reads more like "how to screen for people who will blindly follow your orders". And sure, if you have a small startup maybe you do want people like that. But as a developer I don't think this guide has my best interests in mind.

zebraflask2• 5 years ago

Me, neither, although I have run across people who think this way.

What this is, in my view, if it is taken too seriously, is the perfect recipe for instigating employee burnout in short order.

jpm_sd• 5 years ago

I think it's semi-serious trolling.

Decker873• 5 years ago

It's in a serious tone but focused on early startup hiring. I've experienced early-stage startup life, and the article makes sense to me.

lax0• 5 years ago

Does anything capture the zeitgeist of the early 2010s as well as replacing “stuff” with “shit” whenever possible.

Then putting it on a shirt for the ad agency people to wear.

zelias• 5 years ago

this is nonsense when it comes to ICs, but the ability to solve large org-level problems is a key part of any leadership position

mdoms• 5 years ago

Half a day coding exercise? Mate you're not hiring the best, you're getting for people who will tolerate a lot of crap. Which it sounds like you'll need.

MattGaiser9• 5 years ago

I would actually prefer this to studying for Leetcode. If I am going to dump two months into it anyway, I would rather not forget my actual job.

ffhhj• 5 years ago

I've been in one of those interviews with a person with really bad English. It's a preview of how painful working there is. I just quit the interview after hearing the first question, and a few days later got a nice well-paid job at a larger company with a 30min interview about my previous experience.

taurath2• 5 years ago

It’s striking how little the author thought to include even the concept of empathy, either in their employees or their disposition towards them.

Code machine go brrrrrr.

MattGaiser9• 5 years ago

Employees are considered commodities. Never forget that.

leetrout2• 5 years ago

Human _resources_

altgeek• 5 years ago

As far as GAAP goes, employees are expenses, not assets. -> https://hbr.org/2019/10/the-problem-with-accounting-for-empl...

darkerside• 5 years ago

People seem to be missing that this is targeted at an early stage startup. Honestly, an early stage startup will likely fail without people who are focused on GSD to an unreasonable and unhealthy degree.

iamdbtoo5• 5 years ago

Everything in the list of "Inability to get things done" is something someone with ADHD struggles with and can be successfully managed in the right environment, but it sounds like this person would fire that person without reflecting on the environment they've created and how that person experiences it.

Decker873• 5 years ago

I'd rather hire someone who doesn't struggle with those things.

iamdbtoo5• 5 years ago

I'd rather work for someone who understands their employees are human.

winter_blue• 5 years ago

Thank you, I've felt the list was heavily something a person with ADHD struggles with as well. In the right environment, ADHD people can shine brilliantly and beyond any expectations.

PragmaticPulp• 5 years ago

Environment can absolutely influence people’s ability to get things done. That effect may be amplified by ADHD, but it’s not unique to ADHD.

Every manager should be sympathetic to their team and try to make a reasonably accommodating environment. However, it’s still up to the employee to take ownership and be accountable for getting things done. You can’t reasonably expect managers to constantly micromanage employees to extract work from them, nor can we expect companies to create perfectly distraction-free environments. At some point, it’s the employee’s responsibility to manage their own output.

It’s not just the employer who suffers when a team member is unable to complete tasks. The rest of the team has to step up and fill in the missing pieces or constantly watch over the person who can’t get things done. Eventually you start losing talent because your good employees are tired of doing a job and a half while some other employees are only delivering half of their work, and everyone suffers.

iamdbtoo5• 5 years ago

I didn’t say the employee has no responsibility. This article makes it sound like the person is completely unwilling to work with anyone who isn’t perfect.

floe• 5 years ago

Ask the candidate. I would often straight out ask people how effective they were at GSD, and how did they compare to their peers? It was surprising how honest some (very smart) people would be on this. E.g. "I am average compared to other engineers". For an early stage startup, average is not enough.

lol, wait, if this line of thought works, why don't you also just ask them how good they are at coding, instead of wasting all that time doing interviews?

TameAntelope• 5 years ago

You probably could, and people would volunteer that they aren't that good at coding and therefore screen themselves out (assuming you need people who are good at coding).

You definitely run the risk of not hiring people who are victims of impostor syndrome, but it's the same logic, and it would for sure apply to coding.

gHosts• 5 years ago

Trouble is I've burnt a lot of man hours fixing shit that was done truly shitly by people who had a reputation for getting shit done... and then they move onwards and upwards to another role to create more shit that needs cleaning up before it can be really called a product and actually sold.

dragonwriter2• 5 years ago

I've burnt a lot of man hours fixing shit that was done truly shitly by people who had a reputation for getting shit done...

IME, people who have a reputation of getting shit done tend to:

(1) Have little ethics around quality of work, and

(2) Have their greatest skill in self-promotion which is used to sell their lack of attention quality as a pragamtism.

People who have a reputation for getting shit done well, OTOH...

MattGaiser9• 5 years ago

I don't see this as an ethics issue, but just a trade off and given how long employees stay in a role, there is no long term. I can do both. "Do you want carefully tested code in 3 days or do you want it tomorrow?" And whenever I have put it to any non-technical product manager or business analyst, 90% of the time the answer is "tomorrow."

Product Managers get a reputation for getting shit done too by encouraging this.

zsmi• 5 years ago

I always thought is was more of a semantics things. For example the article, and all the comments in this thread at this time, don't define the word "done". I am pretty sure we're not all using the same criteria for "done".

0xy• 5 years ago

One thing I've noticed about "get shit done" people is that they quickly become the poster child to management for "Dirty Deeds Done Dirt Cheap".

Managers go directly to these people for sketchy, half-baked ideas done in 3 seconds that can boost whatever metric makes them look good to their bosses.

Of course, it's always an unmaintainable spaghetti mess. Over my years in the industry I've come to realize these types of people are really damaging to engineering culture within an organization. They represent a quick buck over quality.

leetrout2• 5 years ago

And hero worship when they circle back and clean up their own messes.

grecy• 5 years ago

I worked at a very large telco for 4 years, and you just described a few of the people I worked with better than I ever could.

I once got a call from a Project Manager on conference with a bunch of VPs, letting me know I was now the sole support person for a new customer-facing product that went live that day.

On the call I confirmed with everyone listening there was no documentation for the entire system, no support procedures, nobody could tell me the name of the server or any credentials to even access anything, or what to do if anything went wrong. But there it was, dumped in my lap.

That PM always got a green tick for delivering projects on time, and got many promotions and bonuses.

marktolson• 5 years ago

There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do both.

t0mbstone2• 5 years ago

I can do both (and have), but it really is a case of time constraints.

So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows?

There are trade-offs. The quick prototype allows you to get something in front of your stakeholders that resembles the desired end product. This allows them to easily identify things that they missed, and allows them to quickly change direction if need be.

This can backfire really easily though, because if your prototype is too good, they will think it's a polished product that can be sold even though it's completely lacking tests and is duct taped together behind the scenes.

You have to CONSTANTLY remind them that THIS IS NOT A STABLE PRODUCT and that it still needs tests and refactoring and clean-up. A lot of the time, you will have to create the JIRA stories and advocate for this extra work to be done yourself, or else management simply won't prioritize it.

I've been a part of multiple startups with successful exits now, and they were all based on code that was rapidly prototyped and duct taped together behind the scenes.

Being able to pivot and adapt is more important than stability, when you are a startup.

But once the startup has been bought by a larger company, it's probably time to rewrite and refactor and stabilize things. Now that you have big clients and people depending on the systems, it's time to batten down the hatches and prioritize stability and longevity.

Verdex2• 5 years ago

Yeah, a large problem in software engineering is that we have zero metrics for how terrible anything is. So, you have some engineers complaining about code written by another one of your vendors. Are they just unfamiliar with the technique/programming language being used? Or maybe the other vender is just too sophisticated and their engineers can just do better? Or maybe they were a bunch of hacks that threw together code until it worked well enough to pass the acceptance criteria needed to get the final milestone payment released.

One way to pass the buck is to just "hire on the ability to get shit done" and justify it with "well, the shit needed to be done and now it is."

I can see it working okayish in the short term. However, eventually you want something (or need something a competitor has) and the answer is "cannot be done because the codebase is infested with demon spiders." Meanwhile the "got shit done" people are either gone (if you're lucky) or insist that the only way to do it is to continue the nightmare development philosophy they created on their own that mixes ideas from shintoism and kabbalah into C++ templates. Every week they're "making good progress" but the features are going to show up exactly never.

zebraflask2• 5 years ago

You know, I recognize that this is a somewhat serious discussion? But I can think of a few scenarios from experience where saying "the codebase is infested with demon spiders, can't do it" would be a satisfying thing to say in reply to unrealistic development requirements.

taylodl• 5 years ago

"we have zero metrics for how terrible anything is"

There's Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity) but I think that's too low-level for what we really need. Cyclomatic Complexity allows us to evaluate one function implementation versus another, when what we really want is the ability to evaluate different architectures and designs.

29athrowaway2• 5 years ago

The reason startups get large amounts of funding is because they are expected to grow exponentially.

Tech debt mills cannot grow exponentially. They grow quickly for a couple of years, then stop growing once the accrued tech debt slows down growth.

Once the 10xers/rockstar/ninjas that "got shit done" for years are asked to make things work for that missing "5% of the time", they will look for another job and disappear.

Tech debt mills should not be treated as startups. They are small or medium businesses that are not prepared for exponential growth, and as such, do not deserve startup-level funding. The obsession over "getting shit done" and "shipping" are traits of tech debt mills.

Sustainable growth and a long-term vision beats tech debt mill mentality.

gumby• 5 years ago

A positive use case that still matches your criteria:

Used to work with a really nice guy (everyone loved him). Wrote code really fast. It worked. It was scary code though.

When a customer had a crisis we’d send him in. He’d find the 10 holes in the dike and stick his fingers in. As soon as he went to work on something else the water would come rushing back in.

But that was ok. He’d stabilize things while somebody wrote a saner patch. What he did was usually a clue about the underlying problem.

Actually this wasn’t his only mode. You probably are running some of his decades old code right now.

I could use someone like him again.

robotresearcher• 5 years ago

"Come back in 3 days with a 1-page marketing plan for our product."

Do people really do this as part of interviews?

dantillberg• 5 years ago

I've heard of (clever? sociopath?) executives that would do this periodically to get fresh perspectives at a cost of zero dollars. They had no intention of hiring any of the candidates.

TigeriusKirk2• 5 years ago

I've definitely had similar experiences with companies still at the "handful of employees" stage. If I'm actually interested in what they're doing, I enjoy the exercise. If I'm not actually interested, well it was an easy way to learn that before wasting their time or mine.

MattGaiser9• 5 years ago

I have had take home assignments like this. Amortized I still have spent far less time on them than Leetcode.

klyrs• 5 years ago

There's a sucker born every minute...

MattGaiser9• 5 years ago

I would often straight out ask people how effective they were at GSD, and how did they compare to their peers? It was surprising how honest some (very smart) people would be on this. E.g. "I am average compared to other engineers". For an early stage startup, average is not enough.

Why do you assume that people answered accurately, rather than depending on their confidence level/interview knowledge?

codingdave• 5 years ago

This is my favorite one: "Did the candidate respond to every email from me quickly?"

If they did, then they are living in their email, not getting shit done for their current job. Is that really the good signal that the author thinks it is?

dragonwriter2• 5 years ago

No, but its a very common thing for people who have a reputation for getting shit done to do. Such reputations aren't built on actually getting shit done (and especially not on getting it done well), but on knowing how to present the image of someone who gets shit done. Responsiveness, both because of the impression it creates on its own and because it provides the opportunity to instantly begin image management when a concern arises and before other input has been received, is central to that.

Olumde• 5 years ago

This is why some people think software engineers are not real engineers. No one will ever ask a structural engineer to build "it" quickly and cover 95% of the failure cases.

Okay, apples and oranges. It's actually okay for a team to crank out a prototype held together by duct tape, but you should move away from this mentality as soon as you prove the business idea otherwise the technical debt will sink you quick.

iamjustoldnow• 5 years ago

At a big company, or in a complex market, project or ecosystem - People who “get things done” have to:

1. Eliminate all discussion, information sharing or teamwork to avoid complex conversations or communication slowdowns or pushback (Try to form silos)

2. Attempt to dramatically simplify their work so it can be streamlined and done faster, perhaps by doing a very bad job or doing everything the way they want to do it

3. Continually step on political landmines or get into a lot of fights by accidentally wandering into someone else’s area through blind execution

4. Be incredibly sneaky and underhanded and opaque and do everything in a way that seems slimy

5. Have some unusually strong managerial backing to go plow ahead and run over any obstacles or objections

Startups are wonderful because there aren’t 9,000 people in the way claiming every square inch of space. At a big company, everything you do is a potential territory violation.

I used to be much, much, much more aggressive when I was younger. I just ran over everyone in my way and destroyed or avoided obstacles.

Turned my career into a giant heaping pile of wreckage. Get shit done at a large company turns out badly for your career I learned.

This is very temporary career advice. You’ll be fine if you do this at a small startup. Medium size and up, you will get zapped like cancer for doing too much of the above.

MattGaiser9• 5 years ago

Even at a "startup" those turf battles emerge. At one company I once had nothing to do so started to help someone on another team automate work.

Set off a turf battle of resource allocation, billing, hours, and a couple cents in cloud systems. I had nothing to do, but a battle started over what I did. They fought over how to allocate time they had no use for.

matthewfelgate4• 5 years ago

God I hate hearing this. I once worked at a company where it wasn't allowed for 2 programmers to be at 1 computer ever. Programmers were never allowed to go to another programmers desk to work on something together or discuss something. Because it was "wasted time".

It was also one of those companies that pulled the entire programming team into hour long meetings they didn't need to be in...

Maybe its just me, but a 5-10 minute conversation with another programmer can save hours of wasted time trying to figure out how something already works or how to implement something.

mrblampo• 5 years ago

This article describes the kind of person who launches things, meets deadlines, and is comfortable creating lots of tech debt in the process. Perhaps it _is_ a good idea to hire lots of these people at a startup, but I definitely prefer working on a team with more of a balance.

29athrowaway2• 5 years ago

tl;dr: It doesn't work.

If companies were empires, "get shit done" translates into exploitation colonialism:

1) "Recruit" large amounts of people.

2) Assign them to bruteforce tasks. Set production quotas.

3) Punish individual agency, self improvement and free thinking.

We know now that exploitation colonialism is an inefficient and primitive approach to governance that fails at achieving what it was designed to do: maximize value. Instead, it just maximizes poverty and misery. The empires that used it lost and capitulated to the empires that didn't. And this happened for a reason: it's a greedy heuristic, not a real strategy, it lacks a long-term vision.

The poorest countries in the world are governed either in this way or a similar one (extractivism), and are often so weakened by this form of governance that are forced to become vassal states that exist only to be bullied.

It doesn't matter if you throw all your entire country's population to "get shit done" (e.g.: agriculture, mining). Maximizing value means you also have to invest in education, infrastructure, science, culture, etc.

Instead of telling your employees to work mindlessly towards a goal, tell everyone to believe in themselves, and pursue their ideas if they think they have value.

"It doesn't make sense to hire smart people and then tell them what to do, we hire smart people so they can tell us what to do" - Steve Jobs

nathanvanfleet• 5 years ago

"here's how I make sure to only hire people with a similar background and personality to myself..."

Rd6n6• 5 years ago

I was told in a screening interview once that they don’t really need people who can solve problems or write maintainable code, or who understand software design. They said the tech lead will do all that. They said they just really needed people with framework experience. I was at a loss for words

ndnxmsm• 5 years ago

I am also at a loss of words, but I would really like to know what they were picturing.

mcavoybn• 5 years ago

Many of the replies in this thread talk about empathy, and I get where they are coming from. The problem is, if your priority when hiring was empathy you would just offer the job to everyone you interview. It's true, everyone has the ability to grow and learn on the job, and once you hire someone you should be empathetic and help them grow as best you can. But it's asinine to suggest that watching for the signs and markers described in this article during the hiring process wouldn't be helpful.

gexla• 5 years ago

Might you also argue that empathy is putting people into roles they would flourish in? That hiring just anyone might be placing people into situations they would ultimately be unhappy with? That you may need to remove or even fire people when that role changes and this person isn't able to change with it? That putting the wrong person in the role is an opportunity cost for a better fit being happier with that position?

seattle_spring• 5 years ago

If you only hire to get shit done, then everything you get done will be shit.

matthewfelgate4• 5 years ago

This is the best reply.

morelandjs• 5 years ago

I’m always amused that people think they can just “hire great talent” by instinct and sheer force of will.

Sure there is skill to hiring, but a lot of what you can hire is determined by how desirable you are as an employer. If you’re a hot company, hot employees want to talk to you. Sound familiar?

IMO focus on a great employee pitch and make yourself known/visible to social circles populated by quality engineers. The match making process doesn’t need to be a coked out box checking session…

mbank• 5 years ago

I think this is an even bigger issue: A cultural one. We live in a (western) society where NOT getting shit done has become the norm. Often things don't get finished at all and if they do they take forever. There seem to be only few companies/founders (have to mention Elon here!) that are able to break this habit.

xupybd• 5 years ago

Reading the authors section on culture fit I found this:

"Bonus points: financial stability. This could be a low personal burn rate, or ability to take a low salary either through a past financial success, being straight out of school so living costs low, or other means. This means the person may be more willing to take a low salary in exchange for more equity, which helps the company survive longer on less."

This makes me worry they have no respect for their workers and want cheap people the can bully into long hours, high workloads and low pay.

I don't know if you can read that much into the comment but it would scare me away.

taurath2• 5 years ago

If I were working at a startup and this was the content coming out of it, I'd assume they'd be hiring competitive sociopaths and the risk of politicking and aggressive diluting of shares would go way up even if it did succeed.

IvanaSays• 5 years ago

Sure. But every startup, no matter what stage, can benefit from mature, thoughtful people, who may take a little longer to get things done, but they will be done better. They are also the people who will ask the right questions, introduce positive paranoia, etc. There is tension with the GSDs, but it's for mutual benefit.

Those very candid people who say they are average on GSD? Those would be my executives.

Simon321• 5 years ago

reeks of short-termism

tpoacher• 5 years ago

Without wanting to take an overly generalist post and overgeneralise back:

- Lack of urgency <-- wait, isn't that the manager's fault? (for failing to clearly communicate the timelines)

- Easily distracted. Heavy procrastinator <-- wait, isn't that the manager's fault? (for failing to provide goal clarity)

- Lazy / doesn't work hard. <-- wait, isn't that the manager's fault? (for failing to provide the right conditions and motivation)

- Starts but never finishes things. <-- wait, isn't that the manager's fault? (for failing to provide task boundaries)

- Lack of follow through <-- wait, isn't that the manager's fault? (for failing to clearly allocate task ownership and accountability)

- Argumentative. <-- wait, isn't that the manager's fault? (for not ensuring buy-in in decisions)

- Slow. (overcomplicating simple stuff) <-- wait, isn't that the manager's fault? (for failing to communicate requirements clearly)

- Perfectionist. <-- wait isn't that the manager's fault? (for not communicating priorities clearly)

matthewfelgate4• 5 years ago

Yup.

I've seen a lot of shitty companies like this where the programmers are expected to do the management as well as the programming.

matthewfelgate4• 5 years ago

This sounds a lot like lazy manager.

flome• 5 years ago

Wow, I really appreciate all the comments here. My takeaway here is that there is no formula or framework for hiring, you just have to spend the time it takes to hire the right people for your company. Period. Some of the insights in this blog post is useful to me, some aren't. The comments here help balance me out.

Hire for the Ability to Get Shit Done (2011)

Related Stories