Keeping People
zachholman.com
zachholman.com
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.
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?
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)
Within a company there are two options:
1) This is considered unacceptable behaviour but it has gone undetected so far.
2) This is considered acceptable or even desirable behaviour.
In the first case, standing up for yourself and exposing the behaviour will be the right thing to do and you'll find that your company will back you up.
In the second case, standing up for yourself will get you (and possibly anyone who supports you) fired.
Either way standing up for yourself will be an educational experience, but statistically speaking if this is happening to you it's most likely because it's normal within the company.
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.
If you choose aggressiveness then at least make it active (advice to be taken with a grain of salt :-) )
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. :)
People like that rarely change. By confronting them, you'll only force them to worsen their behaviour in defence at which point they might condemn or criticise you unfairly, leaving you with a lower opinion of yourself undeservedly. You also run the risk of having your reputation harmed.
So for your own happiness, no matter how tempting, generally it's better to avoid confrontation with the ones that don't have the willingness or capacity to change.
I had to deal with a situation like this at one point in time, where my manager was dictatorial, unreasonable and extremely defensive and saw every suggestion as an attack on his authority and would immediately run upstairs to the upper management and write people up. When I saw that normal dialogue was not possible with this kind of person, I decided to start agreeing with him on everything and made sure he wouldn't perceive me as a threat anymore. It completely killed any chance for positive feedback on my part but it also protected me from his outbursts because I wasn't giving him a reason to see me as a threat to his authority anymore.
Going to their bosses does nothing and more likely than not, you will be perceived as a moaner and troublemaker and may get yourself into even more trouble. They are holding those positions because the management TRUSTS THEM. They are also in charge of keeping their people in check. Also, if the organization was any good, they wouldn't be putting people into these kinds of situations in the first place.
Bide your time, look for work elsewhere (or wait until your project is over and get reassigned to a different team) and absolutely do not confront anybody unless you're prepared to walk right then and there if things go south (and they probably will).
Shitty people/organizations don't change. Moving on is usually the correct course of action.
It did cost several people I cared about their jobs, it didn't cause the company to change much and the personal cost was very high, but in the end I'm still glad we stood up for our principles.
I guess I wanted to say that if you feel the behaviour is too far out of line, say systemic overt discrimination or such, to also not be afraid to make a stand, speak up and accept that it might cost you your job.
If anybody ever wants to go that route I'd suggest getting a lawyer / interest group on your side from the get-go though.
I don't believe any manager behaving like that is doing it without his/her full consent and awareness of the situation, and its effect on the lives of his team. Do you really want to make such person successful by sacrificing your health and happiness?
If the manager's even a little bit politically-minded, you're gonna have a bad time if you try to fix the situation while he's still your boss.
(Sorry, the cynical codger in me is talking.)
PS: Don't threaten in any way though, that will make you sound like a loser.
A manager should be able to provide the team with a unified vision, but allow the team members to be creative and flexible. A manager should be (or try their best to be) unbiased, respectful, and acknowledge the accomplishments of his or her team. A manager should be able to give the team valid and solid reasons for goals and vision.
I recently had the opportunity to work with a good team, but a weak (see: crappy) manager. I wrote a blog post about it: http://www.jayhuang.org/blog/how-a-b-environment-is-created/
My former manager was extremely gifted at salesmanship (selling our "product" to the C level) and was deft at dealing with interdepartmental politics (including posturing to make our product/team more important in the company) for us. But he was a squeezer, and honestly just didn't care about the well being or mental sanity of each of his team members. This made him (in my view) a good or even very-good manager, but far from a great one.
The way most of corporate America is structured today, most managers are incentivized to manage up. That's why great managers are so rare.
In my experience a lot of these managers were essentially failed engineers, they never demonstrated they were at all good at engineering, so no loss like the one above you've seen, and of course they make terrible managers due to poor technical judgement and envy of those who can do it.
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.
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.
I've suffered under this. At some point I'm either starting my own product or join a company who's decisions I can get behind. Software engineer run. Even designers should be developers.
(Or everyone's a manager, depending on how you look at it.)
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.
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.
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.
So, replace the whole slide deck with just one slide:
$$$$
"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
edit: slides 96 and 100
What really is going on at Netflix? Are people happy and those Glassdoor reviews are from fired people or what?
I think the culture (both socially and technically) where I work is great, and I couldn't imagine much better, but all of the Glassdoor reviews are quite negative.
I can only assume it is because happy employees don't bother posting to Glassdoor.
The glassdoor stats are useful, but as you said seem to reflect disgruntled or people on the way out. For example, the pay ranges were at the bottom of the level band (which was tied to the job titles) corresponding to my previous employer. There are only two reasons to be at the bottom: just promoted, or...
Edit: See also slide 38.
* 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.
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.
So far, nothing has been vetoed. We use tons of NodeJS and PHP frameworks/libraries, so contributing and open-sourcing is part of why we enjoy our job so much :)
Sure, it's a little process-y, but it's not there just to check boxes on forms.
"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".
I have a gut feeling I know which company he's talking about, because I used to work for them too. All contributions to open source, even off company time, must pass through the approval bureaucracy.
The worst part about it is that said bureaucracy is staffed with people permanently afraid that they will sign off on something that might at some unforeseeable point in the future come back to compete with the company, and their neck would be on the line for it.
The result being that they're incredibly risk-averse and not inclined to approve anything, even if it has zero relationship with what the company does. In other words, open source contributions are de facto banned throughout the company, but the company gets to make a lot of noise about how they're open to the idea.
I have one colleague who quit his job because of it, one of the best coders I've ever met. No surprise that the company overall has an attrition rate easily in the 20-25% per annum range.
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.
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.
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.
Good quality staff, pairing and making sure test automating is in place are way better practices than code reviews.
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" ;)
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?)
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?
Yes, but you also have to have a culture that lets you use them. My office has both and yet, they never get used. If you try to use them during the day, you're told it's too much of a distraction and you should get back to work. You pretty much have to wait until the boss goes home for the day.
Also, playing is usually a matter off stress relieve, and if there is no stress and deadlines, there isn't much need for toys.
I remember reading that Githubbers are into Techno (trance?), so that speaks to the kind of people you're likely to work with.
Chat is passive communication, which is something many developers look for. (God, if I could get a dime every time a sales/marketing guy went to talk to devs directly despite me getting all over their case so many times...)
Travel I'm going to give the benefit of the doubt and think it's travel for OSS conferences and the like, which again not all companies provide or look favorably upon.
People with bad taste in music?
Music, chat, xbox and ping-pong can all be either a means to that end, or a soul-sucking lie.
Given that these things are common in even many of the worst startups in the bay area, they can't reasonably be used as indicators of whether a company is toxic or not, much less whether it has a good culture.
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?")
That's really not what that part of the slides was about. It's more about the common adage, "users don't really [consciously] know what they want." A customer might not be happy even when you give them exactly what they asked for; and a customer might be ecstatic when you give them something they didn't mention wanting at all. Don't listen to requests; just iterate and observe the real reaction of the market.
Personally, I think trick questions like that are kind of a waste of everyone's time.
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.
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.
This is the best and most succinct explanation of why dogfooding is awesome that I have ever read.
A few things that stand out: "attitude matters", "meetings bad", and "leaving at 5:30".
Slippin', dude.
That seems counter intuitive to me, what does it mean with example?
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.
Hire people bothered by suck
[1] https://speakerdeck.com/holman/the-product-is-the-byproduct?...
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."
here's a summary of the key conclusions.
Also, is there any audio of the presentation?