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?
http://www.quora.com/GitHub/How-does-GitHub-handle-tasks-tha...
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.
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.
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.
If that is so then the real magic happens at the hiring stage.
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 like to do both things, and can't say that I like building new stuff more than maintaining.
I am sure people work on specific tasks every day but they are free and welcome to contribute.
"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).
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.
I'd hesitate to try to apply their example to other companies unless you're in a similar situation.
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.
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 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.)
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
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.
- 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?
I wish people would stop saying this, 20% time is not defunct at Google.
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.
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.
extremely off-putting. many times i just quit. really great for retaining readers.
