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

41–47 of 47 posts

Re: Inside GitHub's Super-Lean Management Strategy

#41

Post by mojuba »

specialist wrote: post #40
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…

+1 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 cl…

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!

Re: Inside GitHub's Super-Lean Management Strategy

#42

Post by eliot_sykes »

swampthing wrote: post #10
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…

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

Re: Inside GitHub's Super-Lean Management Strategy

#43

Post by sologoub »

lifeisstillgood wrote: post #38
sologoub wrote: post #31

Earlier quoted context omitted.

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/facilitato…

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.

Re: Inside GitHub's Super-Lean Management Strategy

#44

Post by sanderjd »

chii wrote: post #29
sanderjd wrote: post #17

Earlier quoted context omitted.

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

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.

Re: Inside GitHub's Super-Lean Management Strategy

#45

Post by lifeisstillgood »

sologoub wrote: post #43
lifeisstillgood wrote: post #38

Earlier quoted context omitted.

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…

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.

Re: Inside GitHub's Super-Lean Management Strategy

#46

Post by Already__Taken »

sanderjd wrote: post #44
chii wrote: post #29

Earlier quoted context omitted.

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.

Re: Inside GitHub's Super-Lean Management Strategy

#47

Post by arkem »

barry-cotter wrote: post #37
arkem wrote: post #35

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

Post reply on HN