I'm usually wary of Holman's presentations and writing. GitHub is such a unique, special place — an engineering company with a product engineers use and are devoted to.
This presentation is pretty good and has some good tenets. However, I have trouble believing that all of these ideals will work when you have a PM screaming at your engineers to finish the internal CRM system, or something else that engineers must work on but don't necessarily care about.
> However, I have trouble believing that all of these
> ideals will work when you have a PM screaming at your
> engineers to finish the internal CRM system [...]
That's the point. The point of these things is that instead of having a screaming PM demanding that deadlines be met, you hire self-starting employees who have fun with their job. It's an internal CRM system, so why not shove it full of in-jokes and vi-keybindings for navigation? Why not give it a REST API and a CLI app to consume it?
It may not be possible to get an existing company to this state, but perhaps it's possible to start a fresh engineering department that's run on these principles?
There's also the issue of exposure industry cred. I mean, we're talking about GitHub here, one of the hottest websites amongst developers. Working on it comes with a certain amount of prestige and every feature they add results in a massive amount of industry press on sites like HN. Of course engineers working there are going to be extremely driven and motivated, it's a very rewarding product to work on.
Now imagine you took the engineering team of GitHub (or one like it) and transplanted them to work on Widget Inc.'s CRM system that's primarily used by their sales, marketing and HR people. Instead of your end users being similarly savvy and motivated developers they're now your typical corporate office staff. They're not using your product by choice but only because it's what the corporate higher-ups handed to them. They couldn't care less about new whiz-bang features you add to the product, they're mostly concerned about getting their TPS report out on time. Interface changes only confuse them and slow them down. They're never going to tweet or post a blog post about how awesome the new thing you just rolled out is.
Do you think the engineers would be similarly motivated to work on such a product? I doubt it.
I agree with what you're saying, but the solution is not to make the situation worse by having a PM screaming at them about TPS reports. That will only drive away what talent is in the pull of Widget Inc; a net negative for the company.
Widget Inc does not need to have the best devs, so this is largely moot. Widget Inc does not compete on IT, does not need their apps to be good, does not care if the best devs work there, no matter what they say.
perhaps it's possible to start a fresh engineering department that's run on these principles?
The key word there is department. GitHub is an engineering company, with engineers from top to bottom. It's extremely unlikely that an engineering department could live in isolation of it's company as a whole. So there would indeed be a PM screaming at someone to finish the internal CRM system and move onto something that the (non-engineer) customers really want.
"It's an internal CRM system, so why not shove it full of in-jokes and vi-keybindings for navigation? Why not give it a REST API and a CLI app to consume it?"
Because the users of the system don't care about any of that crap, so it's a waste of time and money, which most companies don't have extra of to spare.
I work on several projects that I have never used. However, my employer doesn't completely shield me from people who do use it. At least for me, the satisfaction comes from interacting with people who the project helps and seeing how it helps them.
I think part of why (some)? engineers may not give a shit about the project they're working on isn't necessarily because they have no interest in it, but because they haven't met anyone with an interest in it. In github's case, it just happens to be themselves.
I like to know what I'm doing actually matters. Meeting people my stuff impacts helps with that.
My best experiences in corporate IT were when I escaped the department for short times - a flight to an office whose processes were on fire, a deployment of a new warehouse management system where all the workers were counting on me, a 3-month 5-person project sprint to deliver a late, overbudget project without adult supervision.
Whatever the purpose of IT middle management, it does not appear to accomplish much.
I wish I could give you ten upvotes. I get a lot out of interacting with the people that actually use my software. It makes things more personal and that makes me more motivated to work on a project. And the feedback helps to make what they actually want instead of having to second-guess, or build to some abstract specs.
That the project is technically interesting/challenging also goes a long way, of course, but that's not everything.
Worst would be a project that is boring and you don't know whether anyone, including yourself, is ever going to use it.
Cause and effect? I mean, yes, they're darlings of the tech community and throw a ton of events, but that is explicitly mentioned as part of their strategy for keeping their employees happy, which is the underlying principle for their “scaling”. So perhaps it's a self-reinforcing cycle: they were originally darlings because of their service, and as they've grown, their attempts to keep their employees happy result in more goodwill, which further makes them darlings.
In essence, I think if they were crappy to work for, they wouldn't have an easy time hiring, because a lot of the cool stuff they do just wouldn't happen.
I'm not a fan of loudmouth hipster programmers either.
But it's easy to see how a programmer was hired and came to work on a project he didn't like. He was hired to work on a project he was interested in, and was moved over to a project he dreads. They won't stay long though.
Which is the difference GH has from many other places: The work is interesting (to many). Therefor they have an easy time hiring and retaining good employees.
>I'm not a fan of loudmouth hipster programmers either.
I throwing hipster around is a waste of time, especially considering these are extremely successful hipster programmers.
Create product everyone loves, create environment everyone loves to work in, live in San Francisco: fucking hipsters.
>He was hired to work on a project he was interested in, and was moved over to a project he dreads. They won't stay long though.
There is always shit work to do. It's a constant of the universe - there will always be work you're not super interested in. The difference is, is the rest of your job good enough to suck it up and take one for the team?
(Do you even think of it in terms of taking one for the team, or do you think you are just being shat upon?)
You're right, they wouldn't. GitHub would never hire the PM you're referring to, because that's the type of PM that makes engineers hate their jobs and become demotivated.
"you have a PM screaming at your engineers" - and there lies your problem.
I'm the sole engineer for a distinctly non-engineering company (we deliver food, and I'm the only person with any sort of engineering background).
However, we work in a very similar way to GitHub. We have a motivated team who love our product - and that rubs off on our working practices. No one is ever told they have to work late, or they have to hit a deadline, but things get done at an amazing pace. At some point soon I'll be working on an internal CRM system, but because I care about the company, and the impact it will have on everyone else's ability to do good things I'm excited about that.
This presentation is pretty good and has some good tenets. However, I have trouble believing that all of these ideals will work when you have a PM screaming at your engineers to finish the internal CRM system, or something else that engineers must work on but don't necessarily care about.