12 ms·

Keeping People

244 points by DanielRibeiro 14y ago

up_and_up 14y ago
Great set of slides.
qqqqqq 14y ago
Great slides Zach! Also, is there any audio of the presentation?
eksith 14y ago
"Generally itchy feet" Is why I'm moving away right now (slowly; I still have bills n' stuff). There are a lot of reasons for this for most people, but it's hard to pinpoint common aspects for all. For some it may be burnout as mentioned, but the solution there is fairly simple: fire the drama queens. There's a give and take tradeoff for hiring people with an ego as big as their skill-set (often, they're not proportional) and if you insist on keeping people who act like asses because they're skilled, you kill productivity regardless. And for avoiding tedium, let the devs choose their own tools if possible. Unless there's heavy collaborative editing or strongly connected analytics, there's no need to force people to use identical tools. That doesn't mean let them do whatever they please willy-nilly, just keep things consistent up to a sane degree. "Most users are idiots": A less mean way to say that would be, "most users don't perceive what you perceive" and that's for the very simple reason that you look at your product through the filter of a creator. Sometimes you really do need to step outside of yourself to get the perspective of someone who wasn't involved in its creation. Features should be only those that make sense, obviously, or you'll never bloody get done. Interesting reasons for sticking around should be the people, and by extension, the chat. The End. Everything else is fluff easily blown away at the first sign of friction. Don't hire A-Players... whatever that means. Hire people who know how to learn and don't have an ego that will make a newt look like Godzilla. Hire hackers; you can ask for samples of their work or just talk to them about how they see certain problems. There's an old trick carpenters/model-builders use to see if someone's a qualified candidate. They ask the person to drill a hole in a piece of wood. Most people fail it on the first try. +1 For "Hire Slowly". They don't fail as fast. (Correct answer is a question: "Where on the piece do you want me to drill?")
- reledi 14y ago
  I don't understand the carpenters' trick. Why is asking where to drill the correct answer?
  - notJim 14y ago
    I think the wrong answer would be to drill a hole in the piece of wood. Personally, I think trick questions like that are kind of a waste of everyone's time.
    - noonespecial 14y ago
      I'd hate the guy who spent 20 minutes asking about where, how deep, what bit size, how fast etc to drill his hole. Sometimes you just want to tell someone to go do something and trust them to muddle through the details without burdening you with all of them. The kind of worker that needs every detail specified is powered by servos and trained with a pendant.
      - wging 14y ago
        The point is, though, that you never just want a piece of wood with a hole in it. You want a piece of wood that has a hole in the middle so you can put a rope through the hole, tie a knot, and make a swing. Or you want a piece of wood that has a hole at the end so you can drive a post through it and have some sort of horizontal-piece-of-wood-sticking-out-from-a-post deal. I don't know. I'm not a wood expert. The point is that you have to think about what you're really doing, and that carpentry is about way more than the manual skill of working with wood. The parallel with software engineering is pretty clear when phrased this way, yes? Maybe it's part of a table. The piece of wood, not software engineering. The hole is where the table's leg will attach. If you just up and drill where you please, you'll probably not end up with a useful table.
        reledi 14y ago
        In that case, I think a better question to ask would be along the lines of "What function does this piece of wood serve?". Once you know what it'll be used for, you can demonstrate that you know where to drill the hole without having to ask where.
vonmoltke 14y ago
Point #1 really resonates with me, because my previous employer got it completely wrong. Sure, they paid lip service to the idea of internal movement and reducing unnecessary process. Their execution was terrible, though. The first point was highly dependent on management. Not just your direct manager, but also those around and above. There were many in management who saw people wanting to frequently change tasks, roles, or jobs as flaky, unreliable, and even disloyal. These managers wanted people who would knuckle down and perform their niche role on a program for years, or even decades in some cases. It was infuriating at times, and I think being in that environment for the first 9.5 years of my career hurt my current position and direction. Why I stayed there for so long is a long, off-topic story. The rest are good points as well, though a cringe a bit every time I see something to the effect of, "Only hire A players". From the reverse perspective, its pretty close to what I look for in a company when deciding who I would like to work for.
hkmurakami 14y ago
This slide set didn't touch on the most important factor for me: Your Manager. Having a micromanaging || incompetent || tyrannical || condescending || squeezing (as in trying to get the last drop out of you) manager is the quickest way to show me the door. (Now GitHub from what I understand is a flat structure with no "managers" so I see why this wouldn't be in their slide deck, but it's a huge part of the equation for most organizations) And now for some other points >"Not being forced to make poor product decisions" IMO, this happens often when you're placed under a manager who (a) is way too optimistic about development time/resources needed, or (b) knows that he's squeezing, but wants to get more done with little headcount in order to help his way up the foodchain (a friend was victim to this and it was terrible to see). Dear managers: please give us enough people and time to execute properly. We really don't want to ship a half baked product either.
- wisty 14y ago
  If your team is crap (disorganised and unfocused) you might need that kind of manager to ensure basic hygiene practices are followed. A nice guy who lets people run wild can be just as stressful. The problem is, most managers never change their style to fit the challenges they face. Headkickers try to whip good teams into shape (and just piss everyone off). Hands-off managers will let an unfocused team drive into an iceberg. If the manager is a bad fit for the team, or you are a bad fit for the team, then change teams.
  - integraton 14y ago
    If the team is disorganized and unfocused, then it's already a failure of leadership. Being a shitty, tyrannical manager as described by hkmurakami and using the "team is crap" as an excuse is unacceptable, and managers who do that are just deflecting the blame off themselves to avoid accountability.
- bickfordb 14y ago
  I think this is a really good point. Management is a skill just like software engineering, and from my experience there appears to be a wide spread of management ability among the ranks of those who call themselves managers. If managers create a toxic atmosphere workers are going to leave regardless of how many xboxes, espresso machines, travel opportunities or whatever.
mgse 14y ago
Related to "Hire open source hackers", I'd like to work for a company that respects, and dare I say encourages, open source contributions. I recently went through the approval process to contribute to a project on my own time. Due to its nature, the project obviously would not conflict with my business unit or any business unit within the company. Approval should have been a 5 minute conversation with my manager. Instead, I had to write up a proposal for the open source review board. After a week or so, they agreed it was acceptable. The next step was to fill out a form and get a VP to manually sign it. This took a bit of time since the VP is 4 levels up and was, unsurprisingly, out of the country. That experience will affect my next job search.
- mfenniak 14y ago
  Ouch. I think I would've quit that job when I found out there was an "open source review board". That reeks of bureaucracy.
  - rosser 14y ago
    Instead, you'd just let an engineer grab some AGPL code and use it in your web stack without considering the implications? I've seen it happen, and the engineer in question didn't understand why — or even that — it was a problem. Sure, it's a little process-y, but it's not there just to check boxes on forms.
    - georgemcbay 14y ago
      The grandparent post says: "I recently went through the approval process to contribute to a project on my own time." Which I took to mean he needed formal approval to contribute to some external open source project on his own time, completely outside of work and unrelated to his work project. Which is pretty bonkers. Of course if you're pulling open source in to your projects it is wise to have that reviewed first, though I have to admit that at my current job I'm slightly annoyed at the formality of things like having to apply to get Apache 2.0 licensed code brought into our Android project when the Android SDK itself is under exactly the same license as the OSS project. However, I also understand that I have a far better understanding of the implications of various open source licenses than Joe Average programmer guy, so I "get it".
chime 14y ago
I don't get how "the music" and "the chat" are good reasons to stick around while ping-pong table and xbox aren't.
- adw 14y ago
  The music and the chat are about the people in a way that ping-pong and Xbox really aren't...
  - notJim 14y ago
    I disagree. Where I work, the ping-pong table and (proverbial) xbox is where you find the people you're going to work on your next project or hack with.
- xnxn 14y ago
  It's really about the character of those things rather than the things themselves. Any company can just buy an Xbox or a ping-pong table, whereas the particular selection of music or friendly banter in the chat helps define the unique culture of GitHub.
  - chime 14y ago
    Sure. But you can call xbox or ping-pong "the game" if you want and it has as much impact on keeping people as "the music". I don't want to listen to any music when I'm coding or thinking and I despise being judged for my taste (or lack thereof) in music. I'd rather play a friendly game of ping-pong which does not bring my personal choices/tastes into question. Of course, neither has any effect on me long-term. It would have been interesting had the author elaborated on what "the chat" meant. Is it friendly banter between knowledgable folks about their personal takes on interesting problems? Or is it high-school drama or bro-code hijinks?
    - swombat 14y ago
      I think the point is you can buy a ping pong table and a pair of speakers, but you can't buy "the chat" or "the music" - you have to grow and evolve it organically, through active example. It's culture, not "stuff". It can't be bought.
logn 14y ago
How about: raises. When your engineers can realistically get a 20, 30 or 50% raise switching jobs, go ahead and match that. Does your entry level person now have two years of experience? Boost their pay. A lot. Give people raises based on market rates, not based on their current pay. Also, performance review processes at companies are generally horrid. I think it more often de-motivates people, lowers morale, and makes people want to go to other jobs if they feel under-appreciated or feel the process is bogus. Employees shouldn't have to write a 3 page essay justifying their growth and goals. It should be evident from their work. And peer reviews are all the worse. If a manager can't competently review performance of engineers, the manager isn't doing his/her job.
- hkmurakami 14y ago
  The Netflix culture slides immediately came to mind: "At many firms, when employees are hired, market compensation applies. (but at comp review time, it no longer applies!) At Netflix, market comp always applies: esentially, top of market comp is re-established each year for high performing employees. At annual comp review, manager has to answer the Three Test for the personal market for each of their employees: 1. What could person get elsewhere? 2. What would we pay for replacement? 3. What would we pay to keep that person? (if they had a bigger offer elsewhere?) http://www.slideshare.net/reed2001/culture-1798664 http://www.slideshare.net/reed2001/culture-1798664 edit: slides 96 and 100
  - msoad 14y ago
    I always hear two completely different things about Netflix culture. This slide represent the good side but there are Glassdoor reviews too. What really is going on at Netflix? Are people happy and those Glassdoor reviews are from fired people or what?
    - BrandonM 14y ago
      Did you see slides 22-25? It sounds like they have the potential to cut a lot of people regularly. That would easily lead to disgruntled ex-employees. Edit: See also slide 38.
riggins 14y ago
First Break all the Rules is relevant to this discussion. It also has the virtue of being very data focused (they did thousands of surveys to come to their conclusions). here's a summary of the key conclusions. http://www.refresher.com/!breakalltherules.html http://www.refresher.com/!breakalltherules.html
NDizzle 14y ago
Kind of disappointed there wasn't a 72 point FUCK within the first 5 slides. Slippin', dude.
jwilliams 14y ago
Pretty early on it calls code & design reviews "overhead", with "The Man" underneath. Maybe I'm missing some context/voiceover here, but every decent coder/designer I've worked with embraces feedback & reviews. Not sure how I'd survive without them.
- codewright 14y ago
  Design reviews were big at my last company partly because the designer was DYING for feedback.
- potatolicious 14y ago
  Ditto here, though I think there might be a subtext to it. A few weeks ago there was a discussion on HN about the idiocy (or not) of standups. It turns out that a lot of people who dislike standups have very regimental ones, where it's underlings reporting to the boss, and there's an uncomfortable hierarchy to it. I've been one company before where code reviews and design reviews felt very much like this - it was less about peer feedback and more about progress monitoring, and there's a tinge of "you're being assessed" at every turn. This may be what the deck is referring to as "The Man". Right now I have a pretty sweet gig - the best company I've ever worked for by a long shot, and code reviews, design reviews, etc, feel like a critical part of a collaborative process rather than an onerous and sometimes politics-filled chore.
- hkmurakami 14y ago
  The traditional "annual review" where it's more like a "what did you not do perfectly so that I can dock you on your bonus" is not a pleasant experience.
  - jwilliams 14y ago
    Don't disagree -- but in this context, the content (brief as it is) directly refers to code & design reviews.
- milkbikis 14y ago
  I think he's trying to depict the situation where one person becomes the go to guy for some component of the code, so everyone goes to him for code reviews etc. I vaguely remember Zach mentioning this in a talk he gave recently.
suyash 14y ago
@Zach "Hire People who Frustrate Easily?" That seems counter intuitive to me, what does it mean with example?
- potatolicious 14y ago
  I'm not Zach, but I think I know what he means. You want to hire someone who has a low tolerance for bullshit - because they're the ones who will automate a boring, error-prone task instead of just pounding the keyboard and doing it. They're the ones who will not stand for brokenness and will push hard to get it fixed - which in the long run will save your company a whole host of headaches. In other words, you want to hire people who will not let simple, small annoyances fester and accumulate into big, heavy problems.
- DanielRibeiro 14y ago
  I believe this is the point Zack made on this other presentation[1] Hire people bothered by suck [1] https://speakerdeck.com/holman/the-product-is-the-byproduct?slide=18 https://speakerdeck.com/holman/the-product-is-the-byproduct?...
- philsnow 14y ago
  http://c2.com/cgi/wiki?LazinessImpatienceHubris http://c2.com/cgi/wiki?LazinessImpatienceHubris
  - suyash 14y ago
    Well, I don't know if those 3 points made are to be taken seriously. I despise laziness and I don't think you can justify it in any form.
    - mryan 14y ago
      Yes, they are supposed to be taken seriously. Lazy sysadmins are the best sysadmins - I'm sure the same is true of programmers. Note that "lazy" does not mean "does not want to work". As per the linked article, in this context it means: "The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer."
benaiah 14y ago
"Dogfooding: Building stuff you use means recursive happiness" This is the best and most succinct explanation of why dogfooding is awesome that I have ever read.
davidroberts 14y ago
I quit my last job because: * I was hired as a commodity, not a person, and treated as one. * Management beyond my immediate supervisor had a fantasy about our working situation that colored their every decision, and no effort by front-line personnel could lead them to reality. * My company had a failing business model, and thought they could squeeze the difference between expectation and reality out of the people doing the actual work that supported that model. * Immediate supervisors thought loyalty meant not questioning. * Evaluations were based on arbitrary criteria that had little to do with actual job success. * My manager's response to pointing any of this out was "You should be grateful you have a job at all." In a week I will be starting a new job at a small, but successful startup that appears to be the exact opposite of my previous job. I feel really sorry for the (quite talented) people who are still there, and I am grateful to that company for teaching me what kind of job not to take.
krmmalik 14y ago
I love that presentation theme. Does anyone know where i can get a good template like that?
dscrd 14y ago
I left my earlier job mostly because I was bored. All the other reasons are just seasoning on that huge reason. I'm not sure if HR could've done anything, short of promoting me to upper management.
henrik_w 14y ago
Here is another recent article on building company culture: http://firstround.com/article/How-Dave-Goldberg-of-SurveyMonkey-Built-a-Billion-Dollar-Business-and-Still-Gets-Home-By-5-30 http://firstround.com/article/How-Dave-Goldberg-of-SurveyMon... A few things that stand out: "attitude matters", "meetings bad", and "leaving at 5:30".
crnixon 14y ago
Some of this just doesn't ring true. "Hire slowly": while Github was small for the first 2.5 years, the second 2.5 years have had insane growth. I don't think Github has been around long enough to see if they can really retain people. They've gotten a lot of people in the last year because of money and because the work is good, to be sure. Someone else great will come along eventually, and the real test of Github's retention will happen when those people have a new offer. As a purely technical company, Github has a lot of advantages to offer to technical people. I'm not slagging on them: personally, I'd love to work there. I just think they haven't been through a real test of retention yet.
ritchiea 14y ago
I'm glad "there are a lot of A players" was included in this slideshow given how often we hear that there are not nearly enough good people out there to hire.

Keeping People

244 points by DanielRibeiro 14y ago

up_and_up 14y ago

Great set of slides.

qqqqqq 14y ago

Great slides Zach! Also, is there any audio of the presentation?

eksith 14y ago

"Generally itchy feet" Is why I'm moving away right now (slowly; I still have bills n' stuff). There are a lot of reasons for this for most people, but it's hard to pinpoint common aspects for all. For some it may be burnout as mentioned, but the solution there is fairly simple: fire the drama queens. There's a give and take tradeoff for hiring people with an ego as big as their skill-set (often, they're not proportional) and if you insist on keeping people who act like asses because they're skilled, you kill productivity regardless. And for avoiding tedium, let the devs choose their own tools if possible. Unless there's heavy collaborative editing or strongly connected analytics, there's no need to force people to use identical tools. That doesn't mean let them do whatever they please willy-nilly, just keep things consistent up to a sane degree. "Most users are idiots": A less mean way to say that would be, "most users don't perceive what you perceive" and that's for the very simple reason that you look at your product through the filter of a creator. Sometimes you really do need to step outside of yourself to get the perspective of someone who wasn't involved in its creation. Features should be only those that make sense, obviously, or you'll never bloody get done. Interesting reasons for sticking around should be the people, and by extension, the chat. The End. Everything else is fluff easily blown away at the first sign of friction. Don't hire A-Players... whatever that means. Hire people who know how to learn and don't have an ego that will make a newt look like Godzilla. Hire hackers; you can ask for samples of their work or just talk to them about how they see certain problems. There's an old trick carpenters/model-builders use to see if someone's a qualified candidate. They ask the person to drill a hole in a piece of wood. Most people fail it on the first try. +1 For "Hire Slowly". They don't fail as fast. (Correct answer is a question: "Where on the piece do you want me to drill?")

reledi 14y ago
I don't understand the carpenters' trick. Why is asking where to drill the correct answer?
- notJim 14y ago
  I think the wrong answer would be to drill a hole in the piece of wood. Personally, I think trick questions like that are kind of a waste of everyone's time.
  - noonespecial 14y ago
    I'd hate the guy who spent 20 minutes asking about where, how deep, what bit size, how fast etc to drill his hole. Sometimes you just want to tell someone to go do something and trust them to muddle through the details without burdening you with all of them. The kind of worker that needs every detail specified is powered by servos and trained with a pendant.
    - wging 14y ago
      The point is, though, that you never just want a piece of wood with a hole in it. You want a piece of wood that has a hole in the middle so you can put a rope through the hole, tie a knot, and make a swing. Or you want a piece of wood that has a hole at the end so you can drive a post through it and have some sort of horizontal-piece-of-wood-sticking-out-from-a-post deal. I don't know. I'm not a wood expert. The point is that you have to think about what you're really doing, and that carpentry is about way more than the manual skill of working with wood. The parallel with software engineering is pretty clear when phrased this way, yes? Maybe it's part of a table. The piece of wood, not software engineering. The hole is where the table's leg will attach. If you just up and drill where you please, you'll probably not end up with a useful table.
      - reledi 14y ago
        In that case, I think a better question to ask would be along the lines of "What function does this piece of wood serve?". Once you know what it'll be used for, you can demonstrate that you know where to drill the hole without having to ask where.

vonmoltke 14y ago

Point #1 really resonates with me, because my previous employer got it completely wrong. Sure, they paid lip service to the idea of internal movement and reducing unnecessary process. Their execution was terrible, though. The first point was highly dependent on management. Not just your direct manager, but also those around and above. There were many in management who saw people wanting to frequently change tasks, roles, or jobs as flaky, unreliable, and even disloyal. These managers wanted people who would knuckle down and perform their niche role on a program for years, or even decades in some cases. It was infuriating at times, and I think being in that environment for the first 9.5 years of my career hurt my current position and direction. Why I stayed there for so long is a long, off-topic story. The rest are good points as well, though a cringe a bit every time I see something to the effect of, "Only hire A players". From the reverse perspective, its pretty close to what I look for in a company when deciding who I would like to work for.

hkmurakami 14y ago

This slide set didn't touch on the most important factor for me: Your Manager. Having a micromanaging || incompetent || tyrannical || condescending || squeezing (as in trying to get the last drop out of you) manager is the quickest way to show me the door. (Now GitHub from what I understand is a flat structure with no "managers" so I see why this wouldn't be in their slide deck, but it's a huge part of the equation for most organizations) And now for some other points >"Not being forced to make poor product decisions" IMO, this happens often when you're placed under a manager who (a) is way too optimistic about development time/resources needed, or (b) knows that he's squeezing, but wants to get more done with little headcount in order to help his way up the foodchain (a friend was victim to this and it was terrible to see). Dear managers: please give us enough people and time to execute properly. We really don't want to ship a half baked product either.

wisty 14y ago
If your team is crap (disorganised and unfocused) you might need that kind of manager to ensure basic hygiene practices are followed. A nice guy who lets people run wild can be just as stressful. The problem is, most managers never change their style to fit the challenges they face. Headkickers try to whip good teams into shape (and just piss everyone off). Hands-off managers will let an unfocused team drive into an iceberg. If the manager is a bad fit for the team, or you are a bad fit for the team, then change teams.
- integraton 14y ago
  If the team is disorganized and unfocused, then it's already a failure of leadership. Being a shitty, tyrannical manager as described by hkmurakami and using the "team is crap" as an excuse is unacceptable, and managers who do that are just deflecting the blame off themselves to avoid accountability.
bickfordb 14y ago
I think this is a really good point. Management is a skill just like software engineering, and from my experience there appears to be a wide spread of management ability among the ranks of those who call themselves managers. If managers create a toxic atmosphere workers are going to leave regardless of how many xboxes, espresso machines, travel opportunities or whatever.

mgse 14y ago

Related to "Hire open source hackers", I'd like to work for a company that respects, and dare I say encourages, open source contributions. I recently went through the approval process to contribute to a project on my own time. Due to its nature, the project obviously would not conflict with my business unit or any business unit within the company. Approval should have been a 5 minute conversation with my manager. Instead, I had to write up a proposal for the open source review board. After a week or so, they agreed it was acceptable. The next step was to fill out a form and get a VP to manually sign it. This took a bit of time since the VP is 4 levels up and was, unsurprisingly, out of the country. That experience will affect my next job search.

mfenniak 14y ago
Ouch. I think I would've quit that job when I found out there was an "open source review board". That reeks of bureaucracy.
- rosser 14y ago
  Instead, you'd just let an engineer grab some AGPL code and use it in your web stack without considering the implications? I've seen it happen, and the engineer in question didn't understand why — or even that — it was a problem. Sure, it's a little process-y, but it's not there just to check boxes on forms.
  - georgemcbay 14y ago
    The grandparent post says: "I recently went through the approval process to contribute to a project on my own time." Which I took to mean he needed formal approval to contribute to some external open source project on his own time, completely outside of work and unrelated to his work project. Which is pretty bonkers. Of course if you're pulling open source in to your projects it is wise to have that reviewed first, though I have to admit that at my current job I'm slightly annoyed at the formality of things like having to apply to get Apache 2.0 licensed code brought into our Android project when the Android SDK itself is under exactly the same license as the OSS project. However, I also understand that I have a far better understanding of the implications of various open source licenses than Joe Average programmer guy, so I "get it".

chime 14y ago

I don't get how "the music" and "the chat" are good reasons to stick around while ping-pong table and xbox aren't.

adw 14y ago
The music and the chat are about the people in a way that ping-pong and Xbox really aren't...
- notJim 14y ago
  I disagree. Where I work, the ping-pong table and (proverbial) xbox is where you find the people you're going to work on your next project or hack with.
xnxn 14y ago
It's really about the character of those things rather than the things themselves. Any company can just buy an Xbox or a ping-pong table, whereas the particular selection of music or friendly banter in the chat helps define the unique culture of GitHub.
- chime 14y ago
  Sure. But you can call xbox or ping-pong "the game" if you want and it has as much impact on keeping people as "the music". I don't want to listen to any music when I'm coding or thinking and I despise being judged for my taste (or lack thereof) in music. I'd rather play a friendly game of ping-pong which does not bring my personal choices/tastes into question. Of course, neither has any effect on me long-term. It would have been interesting had the author elaborated on what "the chat" meant. Is it friendly banter between knowledgable folks about their personal takes on interesting problems? Or is it high-school drama or bro-code hijinks?
  - swombat 14y ago
    I think the point is you can buy a ping pong table and a pair of speakers, but you can't buy "the chat" or "the music" - you have to grow and evolve it organically, through active example. It's culture, not "stuff". It can't be bought.

logn 14y ago

How about: raises. When your engineers can realistically get a 20, 30 or 50% raise switching jobs, go ahead and match that. Does your entry level person now have two years of experience? Boost their pay. A lot. Give people raises based on market rates, not based on their current pay. Also, performance review processes at companies are generally horrid. I think it more often de-motivates people, lowers morale, and makes people want to go to other jobs if they feel under-appreciated or feel the process is bogus. Employees shouldn't have to write a 3 page essay justifying their growth and goals. It should be evident from their work. And peer reviews are all the worse. If a manager can't competently review performance of engineers, the manager isn't doing his/her job.

hkmurakami 14y ago
The Netflix culture slides immediately came to mind: "At many firms, when employees are hired, market compensation applies. (but at comp review time, it no longer applies!) At Netflix, market comp always applies: esentially, top of market comp is re-established each year for high performing employees. At annual comp review, manager has to answer the Three Test for the personal market for each of their employees: 1. What could person get elsewhere? 2. What would we pay for replacement? 3. What would we pay to keep that person? (if they had a bigger offer elsewhere?) http://www.slideshare.net/reed2001/culture-1798664 http://www.slideshare.net/reed2001/culture-1798664 edit: slides 96 and 100
- msoad 14y ago
  I always hear two completely different things about Netflix culture. This slide represent the good side but there are Glassdoor reviews too. What really is going on at Netflix? Are people happy and those Glassdoor reviews are from fired people or what?
  - BrandonM 14y ago
    Did you see slides 22-25? It sounds like they have the potential to cut a lot of people regularly. That would easily lead to disgruntled ex-employees. Edit: See also slide 38.

riggins 14y ago

First Break all the Rules is relevant to this discussion. It also has the virtue of being very data focused (they did thousands of surveys to come to their conclusions). here's a summary of the key conclusions. http://www.refresher.com/!breakalltherules.html http://www.refresher.com/!breakalltherules.html

NDizzle 14y ago

Kind of disappointed there wasn't a 72 point FUCK within the first 5 slides. Slippin', dude.

jwilliams 14y ago

Pretty early on it calls code & design reviews "overhead", with "The Man" underneath. Maybe I'm missing some context/voiceover here, but every decent coder/designer I've worked with embraces feedback & reviews. Not sure how I'd survive without them.

codewright 14y ago
Design reviews were big at my last company partly because the designer was DYING for feedback.
potatolicious 14y ago
Ditto here, though I think there might be a subtext to it. A few weeks ago there was a discussion on HN about the idiocy (or not) of standups. It turns out that a lot of people who dislike standups have very regimental ones, where it's underlings reporting to the boss, and there's an uncomfortable hierarchy to it. I've been one company before where code reviews and design reviews felt very much like this - it was less about peer feedback and more about progress monitoring, and there's a tinge of "you're being assessed" at every turn. This may be what the deck is referring to as "The Man". Right now I have a pretty sweet gig - the best company I've ever worked for by a long shot, and code reviews, design reviews, etc, feel like a critical part of a collaborative process rather than an onerous and sometimes politics-filled chore.
hkmurakami 14y ago
The traditional "annual review" where it's more like a "what did you not do perfectly so that I can dock you on your bonus" is not a pleasant experience.
- jwilliams 14y ago
  Don't disagree -- but in this context, the content (brief as it is) directly refers to code & design reviews.
milkbikis 14y ago
I think he's trying to depict the situation where one person becomes the go to guy for some component of the code, so everyone goes to him for code reviews etc. I vaguely remember Zach mentioning this in a talk he gave recently.

suyash 14y ago

@Zach "Hire People who Frustrate Easily?" That seems counter intuitive to me, what does it mean with example?

potatolicious 14y ago
I'm not Zach, but I think I know what he means. You want to hire someone who has a low tolerance for bullshit - because they're the ones who will automate a boring, error-prone task instead of just pounding the keyboard and doing it. They're the ones who will not stand for brokenness and will push hard to get it fixed - which in the long run will save your company a whole host of headaches. In other words, you want to hire people who will not let simple, small annoyances fester and accumulate into big, heavy problems.
DanielRibeiro 14y ago
I believe this is the point Zack made on this other presentation[1] Hire people bothered by suck [1] https://speakerdeck.com/holman/the-product-is-the-byproduct?slide=18 https://speakerdeck.com/holman/the-product-is-the-byproduct?...
philsnow 14y ago
http://c2.com/cgi/wiki?LazinessImpatienceHubris http://c2.com/cgi/wiki?LazinessImpatienceHubris
- suyash 14y ago
  Well, I don't know if those 3 points made are to be taken seriously. I despise laziness and I don't think you can justify it in any form.
  - mryan 14y ago
    Yes, they are supposed to be taken seriously. Lazy sysadmins are the best sysadmins - I'm sure the same is true of programmers. Note that "lazy" does not mean "does not want to work". As per the linked article, in this context it means: "The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer."

benaiah 14y ago

"Dogfooding: Building stuff you use means recursive happiness" This is the best and most succinct explanation of why dogfooding is awesome that I have ever read.

davidroberts 14y ago

I quit my last job because: * I was hired as a commodity, not a person, and treated as one. * Management beyond my immediate supervisor had a fantasy about our working situation that colored their every decision, and no effort by front-line personnel could lead them to reality. * My company had a failing business model, and thought they could squeeze the difference between expectation and reality out of the people doing the actual work that supported that model. * Immediate supervisors thought loyalty meant not questioning. * Evaluations were based on arbitrary criteria that had little to do with actual job success. * My manager's response to pointing any of this out was "You should be grateful you have a job at all." In a week I will be starting a new job at a small, but successful startup that appears to be the exact opposite of my previous job. I feel really sorry for the (quite talented) people who are still there, and I am grateful to that company for teaching me what kind of job not to take.

krmmalik 14y ago

I love that presentation theme. Does anyone know where i can get a good template like that?

dscrd 14y ago

I left my earlier job mostly because I was bored. All the other reasons are just seasoning on that huge reason. I'm not sure if HR could've done anything, short of promoting me to upper management.

henrik_w 14y ago

Here is another recent article on building company culture: http://firstround.com/article/How-Dave-Goldberg-of-SurveyMonkey-Built-a-Billion-Dollar-Business-and-Still-Gets-Home-By-5-30 http://firstround.com/article/How-Dave-Goldberg-of-SurveyMon... A few things that stand out: "attitude matters", "meetings bad", and "leaving at 5:30".

crnixon 14y ago

Some of this just doesn't ring true. "Hire slowly": while Github was small for the first 2.5 years, the second 2.5 years have had insane growth. I don't think Github has been around long enough to see if they can really retain people. They've gotten a lot of people in the last year because of money and because the work is good, to be sure. Someone else great will come along eventually, and the real test of Github's retention will happen when those people have a new offer. As a purely technical company, Github has a lot of advantages to offer to technical people. I'm not slagging on them: personally, I'd love to work there. I just think they haven't been through a real test of retention yet.

ritchiea 14y ago

I'm glad "there are a lot of A players" was included in this slideshow given how often we hear that there are not nearly enough good people out there to hire.