holman
commented
7 years ago Hi there,
Hi there!
We all know that before 2014 Github was a "flat" organisation, and that after 2014 managers were introduced. However, what's not clear is this: how were they introduced? And did the company culture really change after that?
Yeah, so things changed dramatically. But it was really a confluence of many things happening, and a lot of what happened really depends on what facet of the company you’re looking at, at what level of the organization you were at, and a random mishmash of other factors. What’s worse, you really can’t carve this stuff up into convenient little pieces; we only did the GitHub experience once, and what it is today is necessarily a culmination of many, many things going wrong, right, and just plain going.
It’s kind of like taking a completed 1,000-piece jigsaw puzzle, tossing it up in the air, and then going back and trying to figure out which piece was the 137th piece you placed into the solution. You might have a good idea, in hindsight, but it’s kind of just a guess based on faded memories and different outlooks and priorities.
Introducing managers
2014 was certainly a tumultuous year at the company, for a lot of reasons. One of those reasons from a practical aspect was something that was simply building up over the previous two-ish years: growth.
A lot of what has been lost in some of these articles about GitHub moving away from managerless companies was that being managerless wasn’t really our intention at any point. We were just interested in building a company that was enjoyable to work for and was very productive when it came to building product. Early on, managers weren’t needed for the team that we had, so we didn’t have managers. I think the general consensus was sure, we’d move to a different system once the cracks started showing.
And the cracks started showing. I think it just started with people getting frustrated by not being able to move as fast as they used to. More checks and balances were being placed in the process, and for good reason: GitHub was mission critical software for more and more millions of people, and we couldn’t necessarily go willy-nilly anymore.
A lot of it dovetailed with the structure of our product not lining up with the structure of our organization. We’d have one or two people working on Issues, for example, and then they’d run off to do something else for a few years and sure enough, Issues would go stagnant. That happened quite a bit, which is natural as you grow: earlier developers have their fingers in all the pies, but no longer can work on baking all the pies in the same oven (okay maybe the allusion fell down there, but you get the drift).
So we started moving towards managers. Cautiously, at first: we explored hiring a type of “therapist” manager, who would mostly have been a type of employee advocate in different leadership meetings. That became clear it wouldn’t scale, though, so we started looking for less innovative solutions.
I’ll sidebar and say I think it was important to sort this all out, particularly knowing now that GitHub would more than quadruple to 600+ employees over the next few years. I think everyone knew things needed to change, but people had different thoughts on how to do it.
At a certain point, we started really moving to management instead of dipping our toes in it. It wasn’t great at first — my first manager was the CTO, who had something like 70 reports for the first six months or something. It didn’t bother me much since I was working well without management (as someone who had simply been there long enough to understand latent communication webs at the time), but in hindsight it was pretty ludicrous.
Around 2015 I got my first actual manager, where we ostensibly would have 1:1s every week and stuff (though she decided against doing those after a few weeks in). This was on a more manageable team of ~12, although no one on the team actually worked with anyone else on the team, so it kind of made for really strange dynamics.
I think that’s part of the problems with how they initially implemented managers. There was such a schizophrenic approach to building teams and managers out. Sometimes teams would be organized around a very specific problem, or project. Sometimes teams — like mine — would be just thrown together as kind of an arbitrary unit of workers. It made for interesting power struggles between the two types of teams, on occasion, as more functional teams would be able to get more things done, and more dysfunctional teams would become more dysfunctional, leading to more frustration. Kind of normal human dynamics in organizations.
The other problem was who was leading the team. I don’t particularly have a strong opinion on where they should come from: you can just as easily bring in an outsider that’s fantastic as you can promoting someone who’s been inside the org for a long time, provided that both are great managers.
And that’s really the thing: if someone is a great manager, then that’s like 90% of the chance of success here. And do you know who tended to be good managers? People who had done that shit before. There were a number of managers inside GitHub early on who had their direct reports of 8 or 10 or whatever, but then also informally managed another couple dozen, because everyone would DM or text them or take them out for lunch to deal with fallout arising from their team because they were good people who were able to provide great human feedback on how to approach the problem. That’s great for those individuals, but terrible for the system in general.
I was asked to be a manager two or three times, and each time I asked, okay, but is this a promotion, or is this just a branch in career, so to speak? Each time they said noooo, we just need people who can manage projects and things, it’s totally fine if you want to just work. This ended up definitely not being the case, but at the time I took them at their (possibly naive, but probably truthful) word. Many of the old-timers had moved to management positions and off the codebase, so I decided to stick with development since I was having a pretty great impact there.
Unraveling this situation a bit more: I think they could have benefitted quite a bit more from rethinking what a “team” was supposed to be. We had such a confusing approach of thinking that a “manager” was supposed to be managing both humans and projects. It’s easy to conflate the two, really, if you have teams that are split out by project area. It’s tempting to think that the person in charge of the team is also in charge of the project. I think there’s a lot of value to splitting the two apart, at least conceptually.
This was also apparent when we had external hires coming in to manage both teams and projects, especially when those managers hadn’t done any programming for awhile, in some cases for over a decade. Just ended up with a worse result for both the human side of things and for the product side of things.
Another thing that became frustrating for many people was that there was an awful bunch of shifting around, seemingly every 3-6 months. You kinda would start feeling comfortable in the situation and boom, another reorganization. Repeat with another reorg every few months. It’s not necessarily bad per se — the idea of trying to reorganize and continually improve and streamline is a great one, of course — but having a feeling of constant upheaval can be a bit unsettling at times, depending on how the reorg is done.
Takeaways
So there’s a lot to unpack here, and sorry for writing a novel. I think it’s interesting to think about, and it’s definitely become more interesting for me to think about now that I’m pretty distant from the organization and I’ve had some time to think and to compare and contrast with other similar companies.
I can organizationally backseat gripe about how things went or didn’t go — starting with their choices of employee terminations, perhaps! 😏 — but I was also a rank-and-file employee rather than management and leadership. I have a perspective. I’m sure management and leadership would probably spin a story of the rank-and-file being uppity and hard to work with, which is probably just as equally true.
The company hasn’t collapsed, and things seem to have gotten markedly better there over the last six months, so there’s not a whole bunch I feel you can say of things being wrong from the changes they’ve made the last two years.
And it’s critically important again to note that there is only one GitHub. We can’t fork GitHub at 2012 and try a whole bunch of other ways of doing things. We can’t run isolation tests on how the company might’ve worked if we literally didn’t hire a single person past 2013.
I’ve talked with a lot of people over the past few years, and shit, there are some really unfortunate stories from other startups, too. When you’re growing as much as they did, things happen, things fall through. This shit is just hard to do. And that’s why the goal for those of us at the company then and for those at the company now is to do our best to incrementally improve it as you go, bit by bit. Hopefully as a whole it’s better off than if you sat and did nothing. And if you make a mistake, well, correct it.
I’ve certainly changed a lot over my last year and a half on a personal level, and it’s really changed a lot of my thinking when it comes to this stuff. I’m certainly not the end-all-be-all with regard to management and organizational tactics (and I encourage any GitHubbers or Xubbers reading this to chime in with their thoughts), but there are a few things that seem valuable to me now, from this position, where I totally get how the decision was reached, where I can see the whole place.
- Have good managers. People who are good managers have probably done it before. I was speaking with a young startup recently and they were like, “yeah, we’re promoting
as our first manager soon”. Their main justification was that the engineer was going to take some management courses over the coming months. I mean, yeah, that’s great, but if you want a mature organization you need to find people who are really great at this stuff. And that’s a talent that’s really fucking hard to master. I almost want to say that it can’t be learned, at least not without spending years on it. Some people are more empathetic, some people are just better at dealing with situations. So focus on those people rather than using this as a promotion to award your 10x programmers (because, if they’re bad at management, not only do you lose your 10x programmer (whether you believe in that shit or not), but you multiply their -5x management skills across all of their reports and the company really loses out). - Have human/product splits. This is a little harder for smaller companies where it might be harder to justify possible employee overhead, but at, say, 75 people, it should be fairly easy to say “okay you are focused entirely on your reports and their feelings and how they interact with the organization, and Naina will lead her team purely on the technical aspects behind this project”. If you have the right person that’s good at both, sure, make it the same person. But I just think that it’s helpful to think specifically about that kind of breakout, since the boundaries are more clearly defined.
- Start thinking about this early. Look: I don’t really care about whether you are no-managers or pro-managers or whatever anymore. I guess I used to, and I did fan the flames a lot, but, well, times change and I regret a lot of the things I’ve said publicly in talks and blog posts these days. 😋 But if you do decide to do the no-manager thing, at least early on, you should be thinking of moving to managers (or at least some meaningful changes) if you plan on growing over the coming years. Even having a clear direct report of who each person can talk to, even at ten people, would have been better in hindsight to help us transition into aa different set of management. Because these things, no matter what change you do, need to be gradual and forgiving. Drastic changes make people nervous. If you can ease them into a new system before they really know they need it, it can be really helpful.
- Empathy. “Empathy” is one of those strange words that’s completely overused these days when it comes to startup culture, though interestingly enough it’s not actually used in practice very much. Lotta talk, not as much walk. I was certainly bad at this too. I’ve been going over a lot of this stuff on a personal level as I’ve been kickin’ the shit out of depression the past few months — more on that in a future blog post, I’m thinking — but I definitely became aggravated at times. Part of it was the culture of GitHub, which was good, in certain contexts: I was really wary of making a lot of changes which might impact the overall health of the organization. I wanted changes to happen just like everyone else, but, like many others, it was easy to get caught up and get really passionate about these things. Or maybe it was an indictment of the system we were currently in that prevented everyone from jumping into things differently. In either case, when dealing with all of this, it’s important to remember that you’re dealing with people’s lives and happiness and careers here, and you have to be really careful with who you put in charge and what processes you’re advocating.
When in doubt, just put kind, diverse, thoughtful people up top. I promise you won’t miss the .005% of margin you’ll miss out on by not hiring a REALLY CUTTHROAT MANAGER. (Or, more likely, you’ll make more dough as people are more productive.) In either case, life’s too short. And if someone isn’t working out as a manager, take steps to protect the larger group of people underneath them. They’re more disadvantaged when it comes to power in the organization, and should be sheltered when possible.
Anyway I’ve gone way too long on all this. I still occasionally think on these things, even though I’m not currently in the thick of it. Makes it easier to make more honest judgements, I think, but it also makes it easier to be wrong, so take it all with a grain of salt. Everyone has different perspectives on everything. What you’ve gotta do is determine what you really value and make sure that doesn’t change. If you focus on happy employees, for example, who really cares how you work anyway as long as it ticks your happy employees value checkbox.
Also I think it would have helped if we had Nerf wars in the office. And ping pong tables. Those were probably our major problems.
raganwald
iamnader
tzhenghao
rossfeller
MattyAyOh
lsinger
jeremyricketts
Hi there,
Well, you did say "ask anything" (how weird, opening an issue that is not about software development BTW).
We all know that before 2014 Github was a "flat" organisation, and that after 2014 managers were introduced. However, what's not clear is this: how were they introduced? And did the company culture really change after that?
Thank you as ever!
Merc.