Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside GitHub's Super-Lean Management Strategy

fastcolabs.com

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Inside GitHub's Super-Lean Management Strategy

#11

Post by bshacklett »

crazygringo wrote: post #3

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 b…

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?

Re: Inside GitHub's Super-Lean Management Strategy

#12

Post by dasil003 »

mojuba wrote: post #8
crazygringo wrote: post #3

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 b…

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: fr…

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?

Re: Inside GitHub's Super-Lean Management Strategy

#13

Post by swanson »

petercooper wrote: post #2

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

Re: Inside GitHub's Super-Lean Management Strategy

#14

Post by sologoub »

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.

Re: Inside GitHub's Super-Lean Management Strategy

#15

Post by kawsper »

crazygringo wrote: post #3

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 b…

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.

Re: Inside GitHub's Super-Lean Management Strategy

#16

Post by lifeisstillgood »

sologoub wrote: post #14

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 wit…

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

Re: Inside GitHub's Super-Lean Management Strategy

#17

Post by sanderjd »

mojuba wrote: post #8
crazygringo wrote: post #3

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 b…

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: fr…

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

Re: Inside GitHub's Super-Lean Management Strategy

#18

Post by mojuba »

dasil003 wrote: post #12
mojuba wrote: post #8

Earlier quoted context omitted.

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: fr…

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…

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.

Re: Inside GitHub's Super-Lean Management Strategy

#19

Post by siliconc0w »

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

Re: Inside GitHub's Super-Lean Management Strategy

#20

Post by shalmanese »

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.

Post reply on HN