
Keeping People - DanielRibeiro
http://zachholman.com/talk/keeping-people
======
hkmurakami
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.

~~~
victorhn
I am facing this situation right now. How do you deal with a manager like
that?

Do you confront them directly and tell them how you feel? Do you "report"
them? Do you realize life is too short and likely they won't change and just
quit?

Any other suggestion?

~~~
hkmurakami
I have done all of the following at various points in the past:

1\. Report to HR.

2\. Switch teams (new manager).

3\. Quit.

IMHO (1) doesn't accomplish anything. Human nature is such that even the most
empathetic, self-aware, fair people have a tough time changing their day to
day habits and standards. The likelihood of a tyrannical manager somehow
finding the light because some underling told them how they felt is
infinitesimally unlikely.

Switch teams or quit, imo. (switching teams is kind of like quitting anyways)
And start looking asap, since job searches tend to take a while.

Also,

4\. Tell them how you feel.

My former coworker did this. Did not accomplish anything. However, when
another team member left for a very prominent company which at this point had
developed a track record of recruiting from our company, he did get a decent
raise. (this doesn't help the root cause of the frustration at all, but
letting your boss know that you're unhappy does make him realize that you
might quit at any moment)

edit: I'm happy to be a sounding board in private if you think that'd help.
Ping me on twitter and we can exchange contact details. (same ID as my HN ID)

~~~
reinhardt
How about:

5\. Do nothing and adopt a "it will be done when it's done" attitude bordering
on passive aggressiveness, leave work at 5:01pm every day, etc. while
preparing (mentally and/or practically) for switching team or company. At
least that's my natural tendency.

~~~
praptak
This would make me unhappy and I believe it is also true for most people. This
positions oneself as helpless and feeling helpless is feeling unhappy.

If you choose aggressiveness then at least make it active (advice to be taken
with a grain of salt :-) )

~~~
quanticle
Not necessarily. I did that for a while at a job I hated. It was the only
thing that kept me sane. Lots of hackers (like me) _hate_ confrontation. Even
small amounts of interpersonal conflict cause intense discomfort. So, when
under a toxic boss, I think adopting a clockwatcher attitude is an entirely
valid strategy.

I analogize it to the strict shift rotations employed by nuclear reactor
workers, chemical plant workers, and others who have to deal with dangerous
and toxic materials in their day-to-day jobs. You set hard limits on exposure
and stick to them. The act of setting and sticking to those boundaries can
give you a modicum of control over a situation where you feel like you have no
control at all. It can make a huge difference.

And, of course, as a side benefit, setting hard limits on the hours you work
also allows you to have time to conduct a search for a less terrible job. :)

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

~~~
potatolicious
So very, very true. Hell, half the time your employees don't actually know how
much their job sucks until they start looking because they feel underpaid.

I felt into that category - spent two years right out of college at a company
where my technical skills were atrophying and middle management reigned
supreme. Younger me didn't know any better - but knew that I was being grossly
underpaid.

I'm still a little bit thankful that they shafted me two compensation reviews
in a row, otherwise I may still be working that job.

> _"Also, performance review processes at companies are generally horrid."_

I have never, ever met a review process that wasn't a complete waste of time.

There was always a huge disconnect between compensation and reviews. I'd get
reviews where my coworkers vouch for my abilities and sometimes sing my
praises, and then my total compensation adjustment would come in sub-1%.

We just spent the last week and half wasting everyone's time writing up these
review forms so that the conclusion is "is very good at his job, well liked by
everyone, demonstrates initiative and judgment, is worth a 0.8% raise".

Compensation is a big deal, and should have been mentioned in the slide deck
IMO. I don't care _how_ perfect my job is, if I feel like there's a 30-40% gap
between my comp and market comp, I'm going to up and leave.

~~~
Joeri
I agree about the uselessness of performance reviews. I've seen several
attempts at introducing a performance review process, and the results are
always the same: everybody finds out what they already knew intuitively,
nobody gets a meaningful raise that they wouldn't have gotten without the
review anyway, and bottom performers who haven't already been weeded out will
not be weeded out as a result of the review.

I would say that there's no reason for a business to have performance reviews,
but i've seen them used as an instrument to postpone raises with the argument
"we're setting a baseline now to adjust compensation next year". So, they are
useful as a cost reduction instrument, provided your people don't walk out in
disgust.

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

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

~~~
derefr
I would take that further: I want to work for a company where you need a form
from the VP to allow any work in the company to go _un-open-sourced_.
Everything is MIT-licensed and posted to Github by default. Only the secret-
est of secret sauce gets redacted.

~~~
law
Why not GPLv3?

~~~
sokoloff
If I had to guess, it might be because, while philosophically more "pure", I
believe GPL is a less pragmatic license if the goal is getting your software
more widely used.

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

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

~~~
nahname
I've never worked anywhere that code reviews were more effective than
communication (ideally pairing). The process feels like a kludge to try and
solve code quality. Rather than fix the problem (code quality going in and
communication about changes) you place a barrier to entry for submitting code.
Anything that prevents me from doing my job (shipping code) is going to cost
the company money.

Good quality staff, pairing and making sure test automating is in place are
way better practices than code reviews.

~~~
anthonyb
Well, in the places where I've seen it done right, the code reviews happen
_before_ the code is committed.

Fixing existing code after it's already in the code base is a losing battle
(particularly since it usually has to be re-tested), and you'll get pulled off
onto "more important work".

And it's not a kludge, it's a very good way of improving code quality
(possibly up to the union of your better programmers' skills) and preventing
dodgy crap from seeing the light of day.

 _> Anything that prevents me from doing my job (shipping code) is going to
cost the company money._

I think you meant "working code" there - where "working" means "solves
business problems" as wells as "not buggy" ;)

~~~
damncabbage
_Well, in the places where I've seen it done right, the code reviews happen
before the code is committed._

Do you mean before the code is _merged_? Either programmers at these places
worked directly together (eg. pairing), or they weren't using a DVCS like Git
or HG.

We use GitHub at work, with code-reviewed Pull Requests. You do you work
(pairing as you want), then ask for it to be merged. It gets reviewed by at
least one peer, and you get feedback, discuss and make changes, and then merge
those into trunk.

You get the benefit of code review, while also being allowed to carry on with
something else in the same codebase without sitting on your butt waiting for a
code review.

(Has anyone else tried this and had good or bad results?)

~~~
anthonyb
Committed into master / dev branches, was what I meant to type. And yes,
essentially pull requests, but in person rather than over the internet :)

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

~~~
xnxn
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
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
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.

------
eksith
"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
I don't understand the carpenters' trick. Why is asking where to drill the
correct answer?

~~~
notJim
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
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
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
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
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.

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

------
henrik_w
Here is another recent article on building company culture:
[http://firstround.com/article/How-Dave-Goldberg-of-
SurveyMon...](http://firstround.com/article/How-Dave-Goldberg-of-SurveyMonkey-
Built-a-Billion-Dollar-Business-and-Still-Gets-Home-By-5-30)

A few things that stand out: "attitude matters", "meetings bad", and "leaving
at 5:30".

------
NDizzle
Kind of disappointed there wasn't a 72 point FUCK within the first 5 slides.

Slippin', dude.

------
suyash
@Zach "Hire People who Frustrate Easily?"

That seems counter intuitive to me, what does it mean with example?

~~~
philsnow
<http://c2.com/cgi/wiki?LazinessImpatienceHubris>

~~~
suyash
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.

~~~
InclinedPlane
There are two kinds of laziness. Rank laziness (aka "goldbricking", to use an
outdated term) doesn't really have much use. But there's also virtuous
laziness, which is the desire to do work in the most efficient way possible.
People who work like that often tend to be assets because they invent all of
the stuff that leads to everything running smoothly and with a minimal amount
of effort.

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

------
riggins
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>

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

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

------
qqqqqq
Great slides Zach!

Also, is there any audio of the presentation?

------
up_and_up
Great set of slides.

