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.
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?
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)
These managers are essentially adult versions of bullies and you should deal with them accordingly.
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.
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. :)
In general that'll just make you miserable. If it's that bad, either start actively looking (eg. interviews at lunch time), or quit and fall back on your 3-6 months of savings runway while you look.
Be a "yes man" while you bide your time and look for something else.
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.
I guess it also depends on what kind of person you are. I experienced something like this recently and I did stand up for myself.
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 don't intend to sound facetious or condescending, but walking away would have been as good a way of standing up for your principles. At least in my opinion. Don't get me wrong. I've had more than my fair share of confrontations too, but you start to realise that that there are better ways to maintain your principles.
Your comment isn't condescending at all; re-reading mine it might actually have across as such. I think we're actually talking about different degrees of transgressions.
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?
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 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.
There's a whole range of "management skills" that are pertinent to being a manager. This is what really complicates things.
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.
Keep in mind too that many managers of technical teams are upjumped engineers; this is one of the worst antipatterns I've encountered. Not only does the organization pay the opportunity cost of losing engineering talent to the duties of management; the skills of management are orthogonal to those of engineering.
"Not only does the organization pay the opportunity cost of losing engineering talent to the duties of management"
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.
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.
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.
Poor product decisions, unsustainable work pace, decisions/sales made by people incompetent in the field
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.
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.
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.
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.
> 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.
So, replace the whole slide deck with just one slide:
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?)
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...
I agree, you barely see salaies close to $200K for software engineers in Bay Area but it's a norm for good engineers here. They can get paid up to $250K for their job in Bay Area.
A local startup here is tackling that second paragraph of yours and they just got an opportunity for office space in the valley. Basically using a simple goal-oriented checklist for managers to evaluate performance, trying to make the process less formal, more focussed, and more enjoyable. More about that here: http://www.techvibes.com/blog/startup-weekend-canadian-cloud...
I just generally see that as useless hoops to jump through. As a manager I'm always evaluating my people. I don't need a big event made out of it or need to solicit feedback from all sorts of people. It's a basic function of a manager and they seem to have delegated that function to the employees themselves and other teammates.
Capture by parts of the company whose goals can be negative for the long term good of all the stakeholders and as a way to manage the pay levels down using the cloak of performance reviews.
* 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.
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.
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.
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.
I'm the VP of Software Development at my company, and as long as what we open source isn't advantageous specifically to competitors or required significant resources to produce, it's all gravy.
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 :)
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.
"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".
He's not talking about using open source code, he's talking about contributing to open source in his own time.
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 work for that company as well, and had I known their open source contribution policy was so draconian (and their general attitude toward open source so utterly mercenary), I would have thought twice before accepting the offer.
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.
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.
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.
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.
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.
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" ;)
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?)
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.
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.
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?
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.
>Any company can just buy an Xbox or a ping-pong table
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.
Having experienced this at a previous job I can only agree (and sympathize). I hope your future employer respects you and trusts you to use your own time effectively.
In my experience, the toys barely get used in a healthy environment. When you have a team of dedicated professionals that feel ownership over the product they build, they prefer to build stuff over playing games in the office, and spend their downtime with friends and family.
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 thought about this, and I think music/chat/travel are more directly tied to culture and inter-personal interaction than ping-pong/xbox/free-cola.
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.
Not having seen the actual talk, I can only assume that "the chat" means being able to chat with lots of very smart people. (A huge benefit to any job like this)
I would have loved to hear more about that. Couple of smart people discussing the merits of git-fs would be interesting. Ceaseless arguments about vi vs. emacs would get boring.
Ping-pong tables, xbox, foosball, etc are trivial to buy, superficial, and mainstream enough that horrible founders/managers have long used them as a way to pretend they have "fun" "startup" "culture." These are all components of the "startup culture" stereotype, so providing at least one is part of the todo list of every funded "startup founder" in the bay area.
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.
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.
"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?")
> 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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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).
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.
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.