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

31–40 of 47 posts

Re: Inside GitHub's Super-Lean Management Strategy

#31

Post by sologoub »

lifeisstillgood wrote: post #16
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

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.

Re: Inside GitHub's Super-Lean Management Strategy

#33

Post by yeukhon »

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

Re: Inside GitHub's Super-Lean Management Strategy

#34

Post by ma2rten »

siliconc0w wrote: post #19

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…

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.

Re: Inside GitHub's Super-Lean Management Strategy

#36

Post by markdotto »

nolite wrote: post #30
briandoll wrote: post #26

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.

Re: Inside GitHub's Super-Lean Management Strategy

#37

Post by barry-cotter »

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.

Re: Inside GitHub's Super-Lean Management Strategy

#38

Post by lifeisstillgood »

sologoub wrote: post #31
lifeisstillgood wrote: post #16

Earlier quoted context omitted.

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

Re: Inside GitHub's Super-Lean Management Strategy

#39

Post by vonpidda »

siliconc0w wrote: post #19

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…

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

Re: Inside GitHub's Super-Lean Management Strategy

#40

Post by specialist »

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…

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

Post reply on HN