11 ms·
How GitHub No Longer Works
- canistr 13y agoI'm always skeptical when companies say they have "no managers" and are a completely flat organization with 100+ employees. I don't pretend to fully understand organizational theory, but I take it that at some point, there will be someone doing the "management" work. Whether that's someone with the title of ninja/hacker/product guy/project manager/director/CEO/BDFL
- mpyne 13y agoIf nothing else Dunbar's number will creep in somewhere. And of course the whole reason we don't use flat hierarchies unless the company is really small is because of the explosive growth in the company communications graph. People could form ad hoc teams to reduce the exponential growth (instead of having such teams pushed on them by management), but then it's not a flat hierarchy anymore. Instead it's a self-organizing construct which may or may not be better than actually designing a proper org. structure.
- bct 13y agoSomebody needs to do the management work, but they don't need to be "higher" in the org chart than the people they're working with. The best managers I've had are more like facilitators than bosses.
- ben_straub 13y ago(Disclaimer: Hubber.) Here's the thing about "management work": it turns out you don't necessarily need management to do it. Setting priorities? This can be done through consensus. Making sure schedules are met? Don't have schedules. (1) Hiring? Have everybody do it. Giving out raises? Set up a deterministic system and forget about it. Giving feedback? Everybody can do this. Running meetings? Don't have meetings. Communicating with the other parts of the company? We have technology for this. 1) EDIT: forgot my footnote. Of course, we're in sort of a fortunate situation here, and not every company can just not have a schedule.
- cpeterso 13y ago> Making sure schedules are met? Don't have schedules. (1) Did you forgot a footnote (1)? I'm curious to read more.
- ben_straub 13y agoHeh. Whoops. Thanks. :*)
- techscruggs 13y agoWhat is your deterministic system for determining salary?
- ben_straub 13y agoNote that I didn't say salary, I said raises. ;) Every other job I've had uses some sort of stressful review as part of the salary process. You get a good review, your raise is bigger; bad review, smaller raise. This seems like it works, but it actually doesn't. What's the goal of a review? To provide feedback. Shouldn't you be interested in feedback so you can get better, not just so you can get paid more? If so, shouldn't you be getting it all the time, instead of twice a year? What's the goal of a raise? To keep you from being effectively paid less (because the cost of living keeps going up), and to make sure you feel satisfied with how much money you're making. There's nothing in there about making sure some people feel less appreciated than others. So pick a percentage number, preferably one that's above COLA, and just give everybody that. If that's not enough, your base salary isn't enough. Note that none of these goals overlap. Feedback and salary don't really have common goals. If you're trying to get people to do better work by dangling the salary carrot, you're taking away intrinsic motivation – see DHH on mixing open-source and money, he did a good job with this topic – and you'll end up with less performance and motivation, not more.
- PeterisP 13y agoThe main goal of raises isn't cost of living adjustments, but as a part of career progression. If you're staying in a stable role and productivity, then you need COLA. If you're improving, in time you become significantly more valuable both to the company and to outside market, so you deserve much larger compensation than back in the years when you were a fresh-out-of college newbie.
- brown9-2 13y agoI'm skeptical when people claim that their lack of managers mean they don't have a hierarchy. If there isn't an official hierarchy there will still be an unofficial one in some way - founders and early employees with more esteem/authority, etc.
- ben_straub 13y agoSpot on. What you're describing is leadership, which is pretty deeply wired into human nature. We don't try to avoid this; rather, we want to recognize it as a discipline, and help people become better at it. Authority, however, is totally different. It's the power to make someone do something they don't want to, and we try our darnedest to avoid that kind of situation. (Also note that "having authority" is different from "being authoritative".)
- hobonumber1 13y agoI'm a big fan of Zach Holman's talks and slides. He's a great speaker on these topics. Looking forward to seeing the video up soon.
- bronson 13y agoSeems like 20% of that slide deck is about chat rooms... GitHub still uses Campfire for chat? I tried Campfire and Hipchat a couple years ago, neither stuck. Not sure why, maybe poor offline notifications and logging? Or maybe our team didn't have enough timezone overlap or things to chat about? Hard to say. Is strong chat as important to Github as Zach implies?
- holman 13y agoAbsolutely. As I mentioned, we have 150+ rooms that we chill in, and most of our day-to-day work practices are tied into chat. Mention someone's name in a room they're not present in and we send push notifications to their phone and desktop- works great to pull people in as needed, without needing to distract them with the noise of being in the room 24/7. Our ops team is particularly in deep with chat. Instead of siloing everyone's process off individually in SSH sessions, many operations happen in chat, so everyone can learn and help out when diagnosing problems. They've built some really fascinating tooling around the problems they face- if you're interested, check out @jnewland's talk on ChatOps: http://www.youtube.com/watch?v=NST3u-GjjFw http://www.youtube.com/watch?v=NST3u-GjjFw
- DanielRibeiro 13y agoGreat post Zach! Tom Preson Warner, GitHubs founder and CEO (and creator of TOML[1]), also gave a very good overview of how GitHub works: http://www.youtube.com/watch?feature=player_detailpage&v=Ms-8GcZXiDA#t=6881 http://www.youtube.com/watch?feature=player_detailpage&v=Ms-... Tim Berglund recently talked in details about the PRPs and the product development process: http://www.infoq.com/interviews/berglund-product-owners http://www.infoq.com/interviews/berglund-product-owners [1] https://github.com/mojombo/toml https://github.com/mojombo/toml
- trumbitta2 13y agoI still don't get how do you manage to do security-sensitive things in Campfire via Hubot :-/
- 13y ago
- speg 13y agoHow GitHub works is one of my favourite slides, looking forward see how things have changed.
- carbon8 13y agoI've found it interesting how many people in the Bay Area, particularly veterans of the 90s boom, discount a lot of the ideas pushed by GitHub and 37signals. Anedotally, one of the common responses whenever I reference either company is, "Yeah, but how big is [GitHub|37signals], really?" It's actually somewhat surprising to me how consistently I've encountered this response (so consistent, it feels as if it was distributed like a political talking point). As mentioned in the slides, publicly announced funding definitely serves as a signal, and I haven't heard anyone say that about GitHub since then, though someone said it to me regarding 37signals within the past few months. What I think it really has to do with is that GitHub seems to make an effort to hire doers, whereas many companies develop processes to deal with non-doers, eg, having staging servers so non-technical staff can check the work of "their" developers. Remote work also doesn't serve the interests of non-doers, since they want to Have Meetings and Make Decisions.
- runako 13y ago>> staging servers so non-technical staff can check the work of "their" developers Surely staging servers have some other benefits? Maybe some teams consider running code on the production setup for the first time to be risky to their customers? Perhaps some teams have encountered differences between dev laptops and production servers, which run on different OS/memory/etc. combinations?
- carbon8 13y agoShort-lived staging environments (eg, a temporary clone of a production environment) certainly have a place, such as when making architectural changes, but these kinds of changes are generally not happening on a regular basis if you are making incremental changes and doing continuous deployment. I'm sure that there are companies that have a valid engineering need for perpetual staging environments rather than feature flags, but I've seen absolutely no evidence that staging servers are commonly engineering driven. Certainly in every part of the web startup world I've had contact with or heard about, staging environments have consistently been for product QA in organizations with heavy-handed processes and/or product management by non-technical stakeholders. Edit for the people responding: This is not about haphazardly pushing to production. You should familiarize yourselves with continuous integration (http://en.wikipedia.org/wiki/Continuous_integration http://en.wikipedia.org/wiki/Continuous_integration) and the various deployment strategies of major web companies.
- jcutrell 13y agoLove these talks from Zach Holman. Brilliant work happening at GitHub, of course. Seeing the rise of the "primarily responsible person" is huge for us in our small company - we've found it's natural to work this way, without a label. Keep on putting out these fantastic slides, Zach.
- ddoolin 13y agoSeriously. I almost never just flip through slides without a video but these were engaging and to the point, as a slide show should be. ...and now I wanna work at GitHub. :) Keep it up!
- skrebbel 13y agoAdmittedly I'm cynical, but how is a "primarily responsible person" different from a lead developer? It feels a bit like you're just calling things different to avoid manager-like names.
- jbarnette 13y agoWe use PRP in any situation where someone explicitly takes responsibility for an outcome, no matter whether the outcome is some software or a clean office or an accurate tax return.
- dingaling 13y agoI'm intrigued as to what happens when no-one 'takes responsibility' for a non-optional task. Like a compliance issue, or that tax return. Who assigns the shit task to whom?
- jbarnette 13y agoThere is no such thing as a shit task. Added: That's a little too glib, sorry. Let me try again: From my perspective, if there's something that needs to be done at GitHub there are a few possibilities: 1. It needs to be done and it's getting done, 2. It needs to be done and it's not getting done, or 3. It's bullshit. Cases of #3 become obvious pretty quickly. The best evidence: Searching for ways to make someone do it because nobody stepped up. Cases of #2 can happen for a bunch of different reasons, but malice, apathy, laziness, or incompetence are the least likely ones. The most likely: Not enough hours in the day or not enough people with the knowledge necessary to be worried. No matter the reason for #2, someone at GitHub who is worried will generally try to get others to share their priorities, by persuasion, by hiring, or by prototyping. Or occasionally by just jumping up and down and wailing.
- eknkc 13y agoI love almost eveything GitHub does, and the way they do them. I'm a GitHub fanboy. There it is. I had a similar crush on Google, maybe 6-7 years ago, they lost me somewhere on the road.
- reustle 13y agoI think they lost a lot of us as soon as the G+ train started rolling.
- kmfrk 13y agoSpeaking of the Google analogy, I hope they do more with their acquisitions of Speaker Deck and gaug.es, as I can't recall a single feature being added or improved since their acquisitions.
- jbrooksuk 13y agoI believe gaug.es has been sold, or moved home. It's now being run by FastestForward.com
- sillysaurus2 13y agoThe question is, do we matter anymore?
- pron 13y agoOf course we matter. After all, Google profits from trafficking our private lives. It's a company that manufactures sugar coated surveillance devices that seem so useful that we submit to them willingly. If we didn't matter, Google will have had nothing. After all, its power stems from our voluntary submission to its merciless watching eye. In fact, the question is frightening. Are we, prisoners, afraid that our benevolent jailers no longer pay us enough attention? That they've lost their touch to slyly subdue us by painting the convincing illusion that they have our best interests in mind? Have the abusive guardians' charms lost their potency on their admiring wards?
- 13y ago
- willejs 13y agoDear github, please sort out your: - Intermittent angry unicorns - Slow data transfer (150kb/sec?!) - Poor support - Expensive enterprise licence, why don't you host a better service and i will pay for it?
- absconditus 13y agoTheir enterprise license is pretty comparable in price to something like Perforce, which does not include hosting. Do you also find Atlassian's Stash pricing to be high?
- WestCoastJustin 13y agoIf you are so fed up with them, why not host an internal Git service with gitolite for user access rules [1]. You could even add something like gitweb as a web interface for git/gitolite [2]. Or, better yet, use something like GitLab [3]. [1] http://sysadmincasts.com/episodes/11-internal-git-server-with-gitolite http://sysadmincasts.com/episodes/11-internal-git-server-wit... [2] https://git.wiki.kernel.org/index.php/Gitweb https://git.wiki.kernel.org/index.php/Gitweb [3] http://gitlab.org/ http://gitlab.org/
- RyJones 13y agoWe used gerrit at amazon and my current employer and it seems to have plenty of enterprise features out-of-the-box. https://code.google.com/p/gerrit/ https://code.google.com/p/gerrit/
- __chrismc 13y agoWhy do you rate GitHub's support as "poor"?
- voltagex_ 13y agoFew things to help diagnose the slow transfer: * What protocol are you cloning over? * What connection are you cloning over? * Where is the connection that you are cloning over?
- grandalf 13y agoI can't wait to try Github/REDACTED
- Raphael 13y agoWhich one? It's confusing to have 2 teams with the same name, github:[redacted].
- adamb_ 13y agoPlease remove "[video]" from the title. As of right now there's no video (there's a placeholder saying it's coming soon.)
- fn 13y agoThat's funny. I didn't click on the link cause I thought it was a video, until I saw this.
- nocman 13y agoActually, I'm kind of glad that the link said "video". Because I might not have clicked it if it didn't, and I almost just closed the tab when I saw the video wasn't available. Amusingly, I'm also glad that the video wasn't available yet, because I clicked through the slides, and I suspect I got the gist of the talk at just about the right density for my interest (and it took very little time). Funny how things work out like that sometimes.
- bado 13y agoWhen I submitted the link, the "[video]" wasn't in there; it was added by someone else later (when it hit the main HN page I presume).
- serf 13y ago[Video] coming soon. So.. the topic is wrong?
- Maro 13y agoI was at the talk. It was great. Good job!
- eliben 13y agoNice presentation, thanks for sharing! Favorite quote: "your product should be cutting edge, not your tech"
- lucasnemeth 13y agoThat guy knows how to make good looking slides.
- rurounijones 13y agoThe one thing that would make it better would be to black-line border the text I think so that it stands out on the black AND white parts of the slide.
- cenhyperion 13y agoWow, I'm taking notes on the slide design. Looking forward to the video.
- z999 13y agoHe has an earlier blog post on how he designs his slides. Not extremely informative but csn give you couple of tips on how to get that zach holman look. Iirc it was in response to the how github uses github to build github talk.
- cenhyperion 13y agoHere's the blog post I think you're referring to. http://zachholman.com/posts/slide-design-for-developers/ http://zachholman.com/posts/slide-design-for-developers/
- deleted 13y ago[deleted]
- wffurr 13y agoAnybody else made sad by Open positions: Technical Account Manager or just me? Or it's like my company, and they don't bother to list positions for software engineers because they're hiring those all the time.
- timc3 13y agoWhat I get from these really great presentations presentations/posts/slidehows that Zach creates is that obviously GitHub is an interesting place right now, and Zach has got some really good insight but I can't help feeling that Zach really needs to get some experience with working at few more companies for some of the points he makes. Companies that succeed in different ways, companies that get bought out, companies that fail. From the outside GitHub is in a really interesting space in that they can dog-food their own product very successfully, they have a huge market and intellectual share, and he writes as if this is the way that all companies could operate - but they simply can't. For instances some companies have to play safe with what they say and do because they are in regulated industries, some just operate by people that have other values or outlets for their own time. I personally think it's fine if a company that I use has given up blogging or whatever to spend more time on creating a great product, or doing that while enjoying friends and family. I will leave/stop buying when the company no longer creates value for me, not when they stop talking at events or the original founders cash out because some people are born to create new interesting companies but are not suited to the 100+ person growth. Zach if you are reading this, keep up the good work, but damn your writing is going to be interesting in 10 years time with a few more companies under your belt.
- d0m 13y agoFunny, couple days ago I was wondering why zach stopped talking about the github internal.. which I found illuminating and highly entertaining, and then, a couple days later, boom an amazing presentation. If I may add a question: How do you manage to keep a consistent design across all teams considering that there's no manager and that most teams have different designers?
- holman 13y agoWe keep a styleguide (which is actually public: https://github.com/styleguide https://github.com/styleguide) that we loosely use across many products and apps. Beyond that, we have two libraries (one CSS, one JavaScript) that we pull into projects that help us maintain a general feeling of consistency. Beyond that, designers get passed around the company a lot. Typically they can implement the frontend quicker than the backend can be finished. This has an interesting and unintended side effect of getting designers working all across the company. I think this plays a large role in getting a lot of the consistent feel across different projects: there's a lot of transfer of taste across the company.
- rschmitty 13y ago"Our tech stack shrinks as we age, fewer trendy languages and databases, your product should be cutting edge, not your tech" I'm glad this was said. I find it hard to quell the excitement about new FOTM language/framework/database in our internal team and always wanting to use the hot new stuff that HN is raving about.
- northisup 13y agoNot actually a video.
- fragmede 13y agoSo... you guys are relying on a bot on a 3rd party chat system to do live-deploys? Does that scare the crap out of anyone else?