Inside GitHub's Super-Lean Management Strategy | Hacker News Reader

Inside GitHub's Super-Lean Management Strategy

fastcolabs.com

126 pointsollydbg44 comments

This is great for creating new products, for innovation.

But I've never understood, who then does the grunt work? Who slogs through producing the documentation, and keeping it up-to-date? Once a new product/feature is launched, who sticks around for the bugfixes, support, etc., since presumably everyone will be more excited to allocate themselves to the next new big thing?

In every company, there's a lot of totally boring, unattractive stuff that needs to get done nevertheless. With open allocation, who does that?

Zach Holman has an answer on Quora on this:

http://www.quora.com/GitHub/How-does-GitHub-handle-tasks-tha...

A link to the same page on Quora, but with ?share=1 appended to the URL so login isn't required: http://www.quora.com/GitHub/How-does-GitHub-handle-tasks-tha...

More often than not, boring work that nobody wants to do at your company is an indication that something went wrong in the process of design & development of your product.

For example, from my experience as an end user, if a product or service relies heavily on documentation, "knowledge bases", forums etc. then it's pretty much fucked up already. Work of any kind at a company behind such a product would be boring: from management and engineering to QA and technical writing.

Github is obviously not among this kind of companies. And I wonder what would be considered "boring job" at GitHub then.

The idea that the existence of "boring" work at a company is an indication that the company did or is doing something wrong is specious, and as a user of lots of software, I really hope this mindset doesn't become common. I want the people making the software I use to be ready and willing to do tough and unglamorous work that makes my experience better. Github's solution seems to be for everyone to really own and care about the product, such that working on "boring" things is a matter of pride. That's a really good solution, but creating and sustaining that culture is really difficult. The lesson others should learn from them is not "don't ever have boring work to do", but rather "create a culture where employees hold themselves and each other responsible for getting the boring work done".

management could incentivize "boring" work by allotting bonus equity/share/money to those who do it instead of the "glamorous" work. Then the individuals gets to decide for themselves what to work on. If not enough people are doing the boring work, it just means that the work isn't being compensated for enough.

Except we're talking about structures where there is no management to speak of. If there is strong management, they can just tell people to work on those things as part of their job. I suppose you could extend your idea to a loosely structured company where incentives would be created through consensus.

You could offer straight bounties for the work. Those are great for motivating simple low cognitive tasks and getting good results.

You're conflating good product design with good company processes, but those are completely separate concerns. Of course a good product shouldn't require documentation because the whole point as a consumer product company is you are bending time and space to make something that people want to pay for. However in order to accomplish that there will most likely be some shit that needs shoveling along the way. Who does the bookkeeping at Github for instance?

My hypothesis is speculative. I think what we call "shit work" is in fact something that is less creative and as such is likely to be subject to automation/algorithmization.

In other words, with the right tools, platforms and algorithms you have less shit work to do.

A few things that can be considered "external bureaucracy", such as accounting, patents, legal stuff etc, that are kind of beyond your control, so they should simply be outsourced. For bookkeeping, hire a company. There will be some amount of interaction with them of course, but that itself shouldn't require full time involvement. I did that for one of my companies, worked OK for us.

Word of support: Some people call this "technical debt".

At my current day gig, developing new "products", I spend a lot of time trying to understand what's what. Oversimplifying: dealing with terrible legacy code, overwraught design, poor implementations of poorly defined interfaces, supporting byzantine processes.

We have acres of documentation. Mostly out of date, useless, or both. We make up for the lack of clarity by having lots and lots of meetings, where we get to swap misunderstandings.

I experience recurring eurekas, each time I finally understand the actual end goal (business need, user's use case). Quickly followed by a face palm slap, wondering why anyone would make such a simple problem so frikkin hard.

Often it's not just algorithms and approaches, but also the choice of tools. I once had a rare opportunity to rewrite a legacy application from scratch, and by simply switching from COM/DCOM to REST I got code base 20 times smaller than the original. 20 friggin' times!

There are plenty of industries where customers want to see documentation upfront before purchase and if you can't provide it you'll lose the sale, it's a clear indication of an immature product. Maybe not in your industry, maybe you don't care about lost sales, but to say any work in companies with such customers is boring is utterly naive.

Honest question, have you worked a real job before?

Documentation, by virtue of existence, does not negate product integrity. There is so much extremely complex software with very specific applications out there with documentation that would take you very long to comprehend.

It's the behavioural nature of the system being documented that determines complexity.

Have I worked before? Been in the industry for almost 25 years now.

The benefits from complex software should be so disproportionately massive that the users would be willing to adopt it. The C++ language and the compilers come to mind: they do come with documentation, are complex, but that's nothing compared to the entire worlds that you can create with C++.

On the other side of the spectrum you have things like Parallels Plesk: an awful piece of software that always creates more problems for you than it's trying to solve, even if you read their tomes of documentation, knowledge bases, searched their forums etc. The existence of Plesk and software alike can't be justified really.

I think that is where "cultural fit" comes in, where everyone has a sense of ownership of everything for which they possess the required skill-set.

If that is so then the real magic happens at the hiring stage.

> Who slogs through producing the documentation, and keeping it up-to-date? Once a new product/feature is launched, who sticks around for the bugfixes, support, etc., since presumably everyone will be more excited to allocate themselves to the next new big thing?

Doing this work is part, and perhaps the most important part, of shipping a feature. It's not just boring work. If someone isn't prepared to support something, they shouldn't ship it.

I don't know how common this is, but I personally love working on documentation and fixing bugs. I can't imagine I'm the only one out there. Perhaps they just make sure they have enough people that are interested in that type of thing?

I think there are different kind of developers. Some like to build new and shiny stuff, where others like to maintain and keep stuff running.

I like to do both things, and can't say that I like building new stuff more than maintaining.

I doubt they don't have assigned roles. It would be a chaos when everyone just write 100 lines for every project. Nothing will get done.

I am sure people work on specific tasks every day but they are free and welcome to contribute.

At a certain point a myth got started that management was a valid profession in itself and it was perfectly fine for a non-technical person to make technical decisions. And for most businesses today, growth and innovation is going to come from better use of technology.

"Non-technical" (I love that word) professional managers are thus incapable of either coming up with innovative ideas or recognizing the opportunities when they do come up because they simply don't understand them well enough. For the same reason, they're unlikely to make well informed choices between priorities. Even ex-technical people that moved into management still make bad decisions because they often don't really keep up with new technology and the changing technology landscape. They might go to conferences and surf slashdot but they aren't in a position to actually apply that knowledge so it ends up being practically useless. If they're asked how to approach a problem they often just use the approach they would have went with 10 years ago before they became managers because that is what they truly know and understand (because, unsurprisingly, you have to do something to understand it).

You seem to be making the wrong assumption that innovation is technology..? On the other hand you talk about growth and innovation coming from better use of technology. Innovation is a behavioral outcome, it's about behavior and its implications. The problem so far is that decisions of behavioral nature is taken by managers for one reason or the other not qualified to do so...

I don't think so. Counter-Example: Steve Jobs.

The problem is that most technical people are also bad prioritizing things: making wrong assumptions about how the product is going to used, assuming that if it is technically difficult it must be valuable, wanting to rewrite things when that is too expensive, wanting to use the latest shinny technologies.

Github is fortunate in being one of the few companies that their customers are the same type of people as their employees. This allows them to get a lot of what traditional management is needed for "for free" and allows radical freedom in their management structure.

I'd hesitate to try to apply their example to other companies unless you're in a similar situation.

Another example which backs up your hypothesis is Valve; a gaming company filled with people who love games, and thus they are their own customers. They too have a "no management" management approach.

The current resource allocation models mostly stem from non-software industries, especially in financial planning and budgeting. As the result, the fit is not always perfect.

Working in software for a little over 10 years, I'd say of projects that should not have been undertaking by companies I worked for or should not have been undertaking by core developers, 90% would have had a lot of trouble attracting people within such model. Generally speaking, software engineers within companies know their own capabilities better than management, especially non-tech management, and can differentiate between a good and a bad fit for a given approach.

On the other hand, I have yet to run into a group of engineers that would not want to attack a valid customer problem, whether it's "sexy" or not. The "shit" work some people mentioned, really isn't if it is what is needed to make a difference for a customer. Engineers generally take a lot of pride in their work, so if there is a defect, they want to fix it.

Seems like such a model could be a much more efficient allocation of resources in the long run, but would hurt some egos in the process.

Agreed - but I have thought for a few years that management as a career and a well remunerated one is coming to a close - one of the main drivers for me to get "back" to coding

Well, facilitators and enablers will be in demand regardless of what methodology you subscribe to. For the last 8 years I've been a product manager (& director). This is one of those jobs that if you do a mediocre job, at best you'll be a nuisance, at worst an impedance. If you do a stellar job, your team's productivity will skyrocket and so will the returns on the investment.

PMs, like many other enablers/facilitators, are there to weed-out noise and make sure the team is always in the know on the relevant context and insights. When things go badly, strong PMs provide cover for the engineers to work through the storm and continuously synthesize all forms of feedback to ensure engineers have proper situational awareness and facts to make sound decisions, but not thrash in response to whatever strife might be out there.

There are other "managerial" type professions that have a place and make things better. All good managers know how to resolve conflict and make sure the team knows about any land mines, but also knows when to get out of the way and let people work. Individual development is also the job of the manager.

I'm not disagreeing - except that manager-as-facilitator is an appropriate role only for skilled and usually gelled teams. Manager-as-coach are also often needed, but weirdly most of it seems to be manager-as-supervisor-meddler - it's something to do with a short term view - put people together, do no training, hope they work together.

"put people together, do no training, hope they work together" that's usually a sign of an inexperienced manager.

That said, I do agree that much of what I said assumes you are dealing with adults that actually want to be there. If you have a demoralized team that doesn't want to work together, there is a whole other managerial skill set that is needed trying and bring them together. Unfortunately, often times things are too far gone to salvage all team members, especially in such market as we have today in tech - just raise a hand and recruiters beat down your door.

BTW have you heard of / had experience with programmer anarchy approaches championed by Fred George?

And I suspect we are in violent agreement. which leads me to wonder what is going wrong

There are a lot of people getting paid in the IT industry, about half of whom write code. They range in skills across the double hump of software ability. And they are apparently all over stretched or on silly short timescales brought on by a poor initial estimate.

To go from just surviving to a team that guides itself takes a lot of training, social norming and individual coaching. None of which will happen with these foolish estimates driven projects.

So I am not sure I see a way forward.

I think the key quote for me is about how effective Githubbers are as communicators. Which isn't at all common in our industry.

I think about it is as being highly networked. [...] you look at the strength of connections between people, the communication channels, and how information travels amongst them, and then you can draw a diagram.

What seems like a higher-than-average percentage of Githubbers are particularly effective communicators publicly, even outside the management team. (Zach Holman in particular comes to mind.)

Github is a very special case because they have a relatively simple product and very tech savy audience. I currently work on a very large b2b web platform/application where customers are typically 40+ and still using Internet Explorer. Its also so massively complex that you just cant do it without extensive planning and talking about every last detail of the implementation with all people involved. I wanted to avoid it, but not talking things through in detail usually results in misunderstandings and more work down the line.

Its great that github can do it like this and i envy them for it, but its not a one-size-fits-all solution to project management

GitHubber here. There's some great questions in this thread already. I'm AFK this weekend, but if you've got more questions about our structure, or how we use GitHub.com to work like this, ask away and I'll try to answer them in a blog post next week.

Does github use Jekyll for it's blog? And what chat/video conference software is used, Skype?

Fellow GitHubber here :).

No, we don't use Jekyll for our blog. It's part of the GitHub.com codebase I believe.

For chat, all standard stuff really :). We use Campfire for group chat (dozens of rooms), Gtalk/AIM/etc for individual chats, and Skype or FaceTime for video chats.

I'd be more supportive of GitHub if they open sourced some of their infrastructure code.

This approach seems almost magical. There are a couple areas that I'd like to hear more about.

- How detailed is the strategy coming down from the top? "... [W]hat you work on is up to you, within the bounds of what’s important to the company." What is the process of oversight to determine if each project is "important to the company"? Are there often conflicts in this area?

- How does employee evaluation work? Does each member of a project submit evaluations for the others?

"There’s Google’s now-defunct concept of 20% time"

I wish people would stop saying this, 20% time is not defunct at Google.

Be more specific. One presumes you are a Googler. If so, when was the last time you did a 20% project, how much dedicated, blocked off time did it have, and how did it effect your relationship with your manager?

Stuff like 20% time being defunct becomes common knowledge through multiple independent repetitions, like Amazon being a shit place to work, Google not doing customer service or Zynga, well, Zynga.

I recently left Google (about a month ago) but in my roughly 18 months at Google I was always working on 3 or 4 projects of my own choosing outside of my 'day job'. They each took up between 5-15% of my time so I'm happy lumping them all together and saying that they were my 20% time.

One of my non-day job focus areas was security education, I ran several classes/events to try and teach people about writing secure software. A public example I can give is the Hardcode Secure Coding competition which I was one of the organizers and judges. See http://googleonlinesecurity.blogspot.com.au/2013/05/the-resu... (I'm one of the guys in the desk photo).

Another example of my 20% projects was a dashboard that compared the number of security reports that had been reported against various parts of Google. It compared them with a lighthearted metaphor and was displayed in a relatively high traffic area in the hopes that it would draw the interest of people who did not track security issues day to day.

A final example is that I worked a little bit on Glass, but only as an interested outsider. I helped out with some security reviews of internally developed Glassware on a volunteer basis as well as wrote my own Glassware to help test the platform.

Blocked off time varied, Hardcode required a lot of blocked off time (including a trip to Singapore). My other projects generally needed a couple of hours at a time. In an average week I'd work two half days on my side projects (not every project every week).

My managers were both very supportive (and all round great guys), it helped that I could explain the potential benefits of all my projects and that they were not completely unrelated to my day job (performing security assessments and code reviews of non-Google code/systems). There are probably limits to what my managers would endorse, but I never got anywhere near those limits.

Where did you pick up the link with .html appended on the end? It resolves back to without it and all the internal links lack it.

This post was on the front page last night/this morning and dropped off, this was to avoid the duplicate check methinks

ot: i really love all these tech sites that just don't stop loading crap while you're already reading the article. then it just scrolls to the top, bothers you with popups and shit.

extremely off-putting. many times i just quit. really great for retaining readers.

Reply on news.ycombinator.com