Why GitHub Finally Abandoned Its Bossless Workplace
bloomberg.com
bloomberg.com
One of the biggest challenges for flatland-style organizations is getting technical people to focus on business objectives which tend to be non-fun. For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades.
(Disclaimer: I have been a manager about 2/3 of the time in my last few jobs. I'm an engineer currently.)
And to your first question I have been through a few interviews with those 22-year-olds who asked about irrelevant CS questions. That's a good sign to avoid the company.
Even the best ones probably wouldn't flourish in a flat org though- that's not a knock against the developers, more the unsuitability of most software tasks to such a structure (or lack of it).
On the other hand, I think there's a very strong correlation between people who think they would flourish in a flat org and people who wouldn't do well in one. The only people who might do all right are those who would join a flat org with great skepticism and trepidation, because they would be paranoid enough about things going off the rails that they would obsess over making sure that their own goals are set appropriately as well as the people around them.
If you get rid of managers, essentially everyone becomes a manager of sorts and they need to really embrace the role to make it work.
This. In my years of working in Software, I've dealt with managers, both good and bad. The best ones have without a doubt been those who took care that I had to attend as few meetings as possible, that my requirements for work were met, who were open to genuine conversation about my performance.
Although I don't have much evidence (yet, but I'm doing some research), I suspect that the qualities that make up good managers (and bad ones) is fairly similar from one field to the next.
We're all (technical folk) steeped since we were 12 years old in a culture that says that solving tricky problems in the most elegant way is what gets you love. This way of thinking predates computers by thousands of years. I think this is the root of why you see everything slant towards cool trickery rather than solid engineering and working stuff. There is something of an age factor but only insofar as the more experienced people end up having this way of thinking partially beaten out of them by real life experiences and the benefit of a long time observing the "nons" in the world.
Staying at 0.9 can just mean having very high standards for 1.0.
That's exactly the kinds of things I wish that I could do. In my experience it's mostly managers that want you to push features without any documentation and filled with bugs.
Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly.
Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied.
EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.
I usually like researching and fixing bugs, especially when they are mine. But compare business value between bugs versus new features and guess which one wins the most.
One thing that can really help in organizations that lack discipline is to define a detailed, rigorous definition of done and institute strict work-in-progress limits for each agile team. That way the team will be less likely to underestimate in the first place and everyone understands that time must be allowed for testing and documentation.
I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s).
And this is not a job for your engineers.
No matter where I've worked, most product is basically no one knows what they want until its built and sitting in front of them.
It's silly and counterproductive for engineers to expect managers to be all-knowing seers, and then act disappointed and put upon when those managers inevitably make mistakes. They're human too. Find a way to work with them productively.
Obviously an engineer is involved in the shaping of the requirements by interacting with the product manager or whoever(never the client). By asking questions, making inquiries and sometimes even poke holes into user stories that ultimately don't make much sense.
No one is all-knowing, no requirements are perfect, etc etc.
What I'm saying is that it's the job of the (Product) manager to understand what the client wants and to relay this into more tangible terms to the engineers.
As for knowing the business domain. Meh, sometimes maybe, but I can think of myriad of situations that it doesn't matter and it may not even make sense.
If you have dozens of engineers and you expect all(or most) of them to be familiar with the business domain, I'd suspect there would be some serious management/organizational problems in that company.
Often however, the manager takes a bit too much "artistic liberty" in relying what I said to the client, usually announcing features as done when that's not remotely the case or worse still, selling features as done which I don't even know about yet.
I've also learnt that when a client asks "How long?", the manager seems eager to give an eagerly short date, usually around two weeks, for even complex feature, before consulting the engineers and has the whole "I know what I am talking about here.", attitude.
Probably slightly too B&W for the shades of grey of HN.
Practically speaking, engineers wearing both product & engineering hats are effective and sometimes crucial part of the process. Obviously more so in LEANer teams. And less so long-running enterprise projects.
Right now we have a designer making mock up pages for me and we have a deadline. He is adding a fair bit of stuff that will need to be done with a mix of back end code and JavaScript. If we do things slightly differently I can code most of it in Django. If we do it exactly as he has done, i will need slightly less Django code, but the same amount of code again in JavaScript. Plus I find it better to have as much logic in the back end, rather than jumping between JavaScript and Python to work out where bugs are.
The designers must always collaborate with the engineers, if that's not happening it's bad project management :(
I also approve your tech/engineering choices :D
My first real junior dev job [1] gave me an ulcer. I only relaxed when I realised what you allude to: people yelled at me and complained about my working pace (and the fact I didn't... smile) but there wasn't anyone else willing to do the job I was paid a pittance to do, especially not with that money. I could just take my time and do my best in the time I thought was appropriate and let middle management go screw themselves. Poor bastards anyway- they were the de facto product testers so they probably had it worse than me in the end.
[1] In other words, working for a company that didn't give a shit about me and just used me in a "human-wave" sort of approach to development. This also came after a stint at a company that treated me fairly and gave me a full "software engineer" title, no "junior"s, so I had the chance to observe the difference between the two models very closely.
I get tasked with delivering arbitrary deadlines for impossible features and timelines to my team and managing the outcomes.
There really are no other reasons for some of these deadlines other than higher mgmt. competing against each other. There are no business reasons.
Long ago I just started ignoring them and giving my team deadlines that were both reasonable and obtainable. I don't want anybody stressed on a daily basis.
If mgmt thinks they can do better, go for it.
When the whole dev team is in on it it's actually not too hard to bake in extra time for the unseen things by just everyone taking longer than they would if they were doing purely what the managers wanted. (Though ideally by doing some of the unseen things the total time for future work will become less than it would have because you don't drown yourself in tech debt by trying to do the PM's MVP only every time... It's nice to have a PM who understands that tradeoff.)
I've become especially cynical of highly marketed "shiny" third-party things that are actually completely broken when it comes to technical innards:
MongoDB, Segment analytics, Unity3D game engine, to name a few...
Ahhh yes. Fancy website? Grandiose claims? Piece of crap.
Essentially plain text site? "just a tool"? Couldn't live without it
Aye, and that person would be called a "junior developer".
It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.
I worked outside of the Bay Area before coming here. I can tell you that the Bay Area tech has the worse managers. They drink the Kool-Aid way to hard out here.
There are reasons for coordination and trust, otherwise 100% of the workforce would be independent contractors.
All of the above is non-fun. I'll do all the boring documentation, monitoring and change control and say thank you. I'm not trying to be harsh on managers (I am one), but I can't blame people for overreacting.
> Wanstrath told staff of the switch to bosses the month after his co-founder’s departure, and the software engineering department began assigning managers in the spring.
It doesn't explain how their new management structure works, or how they picked the managers, or what. Half the article is about the Github gender bias controversy, and the other half is about other companies with flat organizations.
Does anyone have any real insight about how Github's new management structure works?
> While the old times created a strong sense of camaraderie, employees didn’t know who to direct questions to, either about uncomfortable confrontations with colleagues or about their own performance. “Without even a minimal layer of management, it was difficult to have some of those conversations and to get people feeling like they understood what was expected of them, and that they were getting the support that they needed in order to do the best work,”
No information about what the current structure is, how it's working out compared to the last one nor really any satisfying answers for why the initial bossless failed (I mean I can certainly guess but they went through it, it would be nice to have more data).
The company's at an inflection point and management has to choose between a) raising capital or b) exiting. Either way, investors had expressed concern about GitHub's (lack of) hierarchy, and the constraints it imposed on opportunities.
Don't read this as a management howto but a "hey look, we're legitimate now!" PR-focused post. They're trying to acknowledge the previous risks and describe how they are now addressed.
We're not the audience for this one, folks. Institutional investors are.
blorp blorp!
money money!
blorp blorp!
feed me, seymour!
One could quickly argue that PR articles that skip the details, and make designs to produce the sensation of graphs that "go up and to the right," are a clear indicator that pleasing investors produces a bland gruel of profiteering corporations as ineffective at doing anything useful besides "making money," as is flatlander management, at providing direction to employees (read: millennials) who can't adjust to the sensation of not being subordinate to micro-managing overlords.
1. You want someone to evaluate your and your team's performance. Not getting feedback on this is demotivating.
2. You want someone to help you get better and plan your career (all of our managers are skilled in the area of work of their reports).
3. You want someone to go to with problems: individual execution, team execution, collaboration with another team, and (inter)personal ones).
For more information about our reporting structure see https://about.gitlab.com/team/structure/ and our leadership principles see https://about.gitlab.com/handbook/leadership/
There can be many factors to play around with. After everyone on a team has had the chance to be manager couple times, the team could vote for who should be the manager for the next month. Etc, etc. The idea is to still give a team the sense of control, rather than feeling that you're imposing a boss on them.
However, I think a boss is more like a person you go teach a dance workshop with that a person that participates in it. Maybe the intern can have a new mentor every week. But I see some obstacles doing this do experienced team members.
It is already hard to find people that are both an expert at the work and a great boss. Finding multiple bosses in a team seems hard.
Frequently your boss needs a long term view on your activities. Career planning, performance reviews, and performance improvement plans are multi-month affairs.
Coordinating with other bosses and team also happens via social capital. Having to deal with a new persons for all other teams every month might be hard.
A hierarchy works fine if it really is a hierarchy. It won’t work if the hierarchy has been poisoned with “dotted lines” or lots of unnecessarily-senior-sounding job titles that let senior people share control over project direction. I’ve worked in groups in the past where there were like 5 senior people trying to pull things in completely different directions, no one would tell us whose opinion really mattered, and we kept having to decide for ourselves.
The end result was unhappiness, and contention between coworkers. The senior engineers felt unappreciated and unrecognized, and the junior engineers felt the brunt of that resentment.
Based on that experience, I tend to believe that organizations should have clear power lines (titles), and respect those titles. Doesn't mean you need to have a dictatorship, but someone needs to be able to make a strong decision that sticks, when the time calls for it.
[1] https://en.wikipedia.org/wiki/United_Airlines_Flight_173
While I believe clear power lines, and titles, are important for business function, they should not come at the cost of respect, or a democratic environment which promotes conversation and compromise. You can definitely have both; Not all rigid org structures are authoritarian.
"Yes, some wrong decisions would be made but that's what learning is all about."
The problem I've seen is that unless an engineer sees his peer as having more experience (visa vi the title), then they often won't even give them the time of day. Even if their peer is 100% right, the junior engineer often believes themself right and is unwilling to budge. While the reverse can definitely happen, its generally less common.
I respect explanations, not assertions, nor titles. Maybe that's why I have trouble with large companies.
I think randomness is often underappreciated in business decisions. It helps create a baseline for performance measurement.
This is actually a pretty good example of the phenomenon - if you and I were on a team and trying to figure out how to make decisions for our team, we would have this strong disagreement about whether it's better to break ties through intuition of randomness. My intuition is that intuition is better, and your intuition is that randomness is better. It's unlikely I can convince you that I'm right, or vice versa, so how should we break that tie?
If you focus on a hierarchy of 'ownership' instead, it's much better for everyone.
There's a fantastic book (Extreme Ownership) that talks about how this is used within the US Navy Seals, and how it empowers the people doing the job, rather than dictating what they should do.
Decisions do need to be taken with regards to direction - they shouldn't necessarily enforce 'how' that direction should be achieved.
https://books.google.ca/books?id=JEuYpTC-mQYC&pg=PA242&lpg=P...
In short, students walked over the grass, despite the "keep off the grass" signs. The solution proposed by university president Dwight D Eisenhower was "Why not let the students take whichever route works, and then build the walkways over the bare patches?"
The same could apply here. If the rank & file see person X as being necessary / useful, then give that person an official title and responsibilities.
I've also heard a version (or two) in which the campus was specifically one of the top tier US schools for CS (MIT/Stanford/CMU/etc.). The common thread was always that it was supposed to illustrate the visionary status of whoever was in charge, and/or the enlightened status of the company or university. The Eisenhower version would be the oldest one though, perhaps it was the original.
While I appreciate the philosophical sentiment, I think it's both a little naive and a little jaded.
Naive because in practice, there are real disputes, and someone needs to be in a position to resolve those disputes and keep things organized. When the structure is informal, even with great technical people (and often this occurs more often with great technical people), effort will often be spent on duplicate tasks, and the differing implementations will compete for mindshare internally. While that's not always a problem, there are times when the structure needs to be directed so that more important corporate goals can be achieved. If the employees can't operate with unity, they may find the whole company unified with them on the unemployment line in the not-too-distant future.
It's naive because good ideas are not always received well by self-interested actors, especially when you're dealing with people of mixed experienced levels and backgrounds, as any company with more than a few employees is. The manager's role is to make a critical analysis of the proposal and make what is frequently a difficult choice about what will be in the organization's long-term interest.
It's also naive because there needs to be a designated official who represents both you to the company and the company to you. That representation ensures you always have someone to voice your concerns and needs to. It ensures that you understand what the company wants you to be doing instead of having to try to pull it out of the ether, come out with the wrong thing, and find yourself in sudden political turmoil. It ensures that you have an appointee who can advise and represent your cause in sensitive personnel matters, and argue for the value you bring to the company. A good manager serves many very important organizational functions besides just determining technical direction.
Jaded because such a massive majority of managerial structures are so comically broken and useless, that traumatized workers don't understand how they could ever be useful for anything and just want to chuck the whole thing out. Believe me, I beyond sympathize with this, but I don't think it always has to be that way. This is part of why finding a good corporate fit is very important for the job seeker.
Any time you get more than 3-5 people in a room, a political pecking order will naturally arise. That force needs checks and controls to keep everyone safe. Benevolent, mindful leadership from good, fair judges is critical to the success of any group of humans, whether organized into a corporation, nation, tribe, family, or other. We can't discard that principle just because it's hard to find qualified leaders.
"We began to realize that by building a company with a flat org structure, we had done the exact opposite of what we had intended. We had centralized all the decision-making, and we were relying on a secret implicit structure to make progress.
Every company has a structure. If you don't explicitly define your structure, then you are left with an implicit one, and that can stifle productivity. We had hoped that being flat would let us move faster and be more creative, but as we grew, we ended up with an unspoken hierarchy that actually slowed down our ability to execute."
There is no such thing as a structureless group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. --Jo Freeman, "The Tyranny of Structurelessness"
Are they that effective at Valve though? Seems it's not bad enough to cause the company serious damage but are they doing much nowadays? Yes there's the Vive but that's in partnership with HTC who may be providing a lot of the top-level direction.
I get the feeling Valve is coasting along on the Steam cash cow and could be doing a lot more with the people and resources they have available.
I don't buy your reasoning either. Right business move because DotA 2 and their Hats! are a cash cow business, sure.
They don't want to make Half-Life 3, the expansion to Half-Life 2. They want to make something new. They created something new with Portal, which required them to hone their ability to introduce players to an entirely new game mechanic, but now they have to wait for VR to put it all together.
And they're not really coasting. They're at the forefront of broadcast gaming, competitive gaming, whatever you want to call it. I've watched Riot grow, and Blizzard falter in that industry, but I'm damn near positive that Valve has the better framework for the long-term.
Edit: I also think that Valve's primary product is "not having to deal with industry standard financing and deadline problems so we can make games that are actually good without burning out like everyone else does."
Valve seems like the poster child for upsides and downsides of this system.
They release cool games, make lot of money, Hats!
On the other hand, steam is still really clunky and their customer service has historically been horrible.
I've never tried so hard to give a company my money and have them so actively refuse it.
I've had a customer service request in for about 4 days now. I know that if/when it gets replied to, the person who replies won't read what I typed and I'll have to explain it again and wait another 5-6 days to get any action. (Before you ask, it's about a DLC that isn't part of their refund policy, so I can't simply refund it.)
Based on Steam's example, I'm not a fan of this concept. They're popular because they have a lot of network effect, not because Steam's any good.
Every single other marketplace even slightly similar to Valve has support that outshines Valve in every single way possible.
EA with their Origin client launch did a fantastic job with customer service and making sure they are keeping as many people that actually use Origin, happy. (yeah we all love to hate them, but they got this one right.) I thought it would go to crap quickly but from my (admittedly limited) experience and what I have heard it is still great.
I am actually scared that should my steam account get hacked I will lose everything. I've used steam for many many years. I've put more money than I should have into it (400+ games) and now I have to be extremely careful that nothing I do screws my account because there is a very good chance that it will go unresolved and I will be out all of that time/money.
Whenever I look to get a game, I buy them any way I possibly can outside of steam before I turn to their platform.
I believe there is time for Valve to turn it around. There are many things they have certainly done right. They've done a great job pushing for Linux, especially since I moved to linux only gaming over a year and a half ago. They've helped Indie developers and modders bring their creations to a unified platform.
And why do they continue to do well with their game offerings?
Steam won because it had first mover advantage. Valve was historically a developer, and it launched Steam with a highly-anticipated game, so I suppose it didn't have pre-existing relationships with its retailers to negotiate. Other traditionally to-retail large publishers didn't get into the online distribution and online DRM game till quite a bit later. Meanwhile, the indie gaming scene exploded, and many of them chose to distribute via Steam.
As for why it continues to be the most popular platform, I presume that they are mostly due to it's reach as a channel as well as its gamification of its platform to encourage loyalty and spending. I think I should let someone who's seen things from the developer side answer this though.
That said, the democratic approach has a lot of other issues in the form of cohorts and cliques. A manager might secure just enough votes to stay in power by having quiet conversations with some employees, using power to give them breaks, etc. I'd love to see a frank discussion or proposal about how to dissuade that.
In the work setting I've never seen management determined by vote, but you see the phenomenon just the same. Most people who want to climb the management ladder are normal, sane people, but the power-hungry are the ones who try the hardest to get to the top. In an organization that doesn't properly evaluate people you end up with the brutes in charge, which makes life miserable for everyone else.
The funny thing is that the first democracy which called itself a democracy was perfectly aware of this problem - and the tyranny of informal leaders - and had a simple and effective solution to both problems: filling chairs by lottery.
Clear lines of ownership and responsibility do wonders for just letting coders code, and let everyone else decide what they code.
I was treasurer of my housing co-op and we had one full-time employee who reported to me and the board. That employee (the coordinator) hired contractors for maintenance, bookkeeping, as well as things like the laundry machines.
Even large co-ops (like clothing stores) have the members vote a board in that sets up the structure.
Every single member of the team having to keep up with every single other person is unnecessary and impossible past a certain number of people. Certain things don't scale well.
The full article. Her point seems to really boil down to this:
We cannot decide whether to have a structured or
structureless group, only whether or not to have a
formally structured one. Therefore the word will not be
used any longer except to refer to the idea it
represents. Unstructured will refer to those groups
which have not been deliberately structured in a
particular manner. Structured will refer to those which
have. A Structured group always has formal structure,
and may also have an informal, or covert, structure. It
is this informal structure, particularly in
Unstructured groups, which forms the basis for elites.
I really recommend reading the whole thing. It's a pretty interesting article and, I think, gets at the problems (solvable in some or many cases) in any large organization, structureless or not.
EDIT: And do read the article. It's much more than just the snippet I included. That's just her thesis, the rest explains it better and the consequences of insisting on informal organization.
An example from history. Elections are actually how volunteer units in the early days of the American Civil War selected their officers. Every soldier got one vote, the whole regiment got together and cast their ballots, and the guy who got the most votes got to be the commanding officer. Very democratic!
With just one problem: in almost all cases, soldiers voted overwhelmingly for officers who promised not to make them do all the tedious army stuff they hated, like drilling in formation and practicing their marksmanship... which it turns out are actually very important things for a unit to do, if it wants to actually perform in combat. So these units had a bad habit of dissolving into mobs of terrified amateurs (and therefore getting slaughtered) the moment they entered battle.
Eventually it was decided that it was more important that army units be able to function in combat than that they be democratic organizations, and the elected "soldier's friend" officers were kicked out and replaced with hardasses. The soldiers hated them, and swore under their breath every time they were called out to drill yet again. But they learned how to fight.
A manager who is getting lousy reviews from engineers is going to face difficulties with the higher ups.
I have been in those same activist groups. Right now I work for an "engineering run" organization. Maybe my emphasis should have been on _a little_.
Every organization collapses towards high-school. Those that don't are the most successful. Just as the majority of Olympic athletes are freak'n amazing, the contest is rarely not who excels but who doesn't falter.
When looking for a job, be careful when leadership says their organization is flat. You will probably find people at the top (C level) who hate being told what to do and hate management. That will poison the structure and coordination of the company. People need some sort of structure so they know where to turn to for help, responsibilities are assigned and there is accountability.
I'm not advocating having rigid, strong management and structure at a company, just that if you don't have an official structure, an unofficial and hidden power structure will emerge. And that is far, far worse.
OTOH, every place I've seen, corporate and government, with a visible and formal hierarchy has also been a mess featuring hidden power structures, informal and outside of office meetings where decisions were made, and arbitrary decisions made at a whim.
(One big feature of California's "public meeting" laws is to try to limit and expose this in the highest levels of certain representative government decision-making bodies, but its pretty much a universal feature of human societies.)
> if you don't have an official structure, an unofficial and hidden power structure will emerge.
That will also happen, pretty invariably, if you have an official structure.
In my (somewhat limited) experience, you need a balance to get good work done: too much official structure slows things down and limits good people, but too much informal structure leads to the kind of place described in "The Tyranny of Structurelessness."
Leadership by example, training, adhering to values all matter. It just so happens that use a tried and true system of actual structure gives you a wealth of knowledge and experience to pull from.
Could a flat org work? Maybe? So far, it seems like every company that tries and gets to scale has serious problems. Maybe it makes sense stick to innovating on your core business, and sticking to business best practices in your processes. (A recent post by the former Cofounder/CEO of Brightroll digs into this: https://medium.com/@todsacerdoti/0-to-640m-non-obvious-lesso...)
Michael Schulson, "How to Choose" https://aeon.co/essays/if-you-can-t-choose-wisely-choose-ran...
Instead they periodically elect a body of 20 (or so) partner to deal with compensation, bad partners, sets policies, etc, etc.
My buddy says that all the partner are fairly self-driven grown ups, and usually do the right thing. Rarely is there any action needs to be taken by that elected body.
They do have a "CEO" in name to represent the firm to the outside, but with no other powers otherwise. And obviously you need some HR department.
Immediately I wondered whether one could run a software company like that.
Seems that GitHub drove it a little too far on the no-structure route. I wonder if they could have done what this firm does.
I previously worked for a company that does purely outsourcing work; they nowadays have a bossless hierarchy (apart from project leads, who are named anew for every project, and basically anyone willing can volunteer). It seems to work well for them, and I don't see why not.
Now I'm in a "product company", and the needs are completely different. Like has been stated elsewhere in this thread, when making products, there just has to be someone making the final decisions, i.e. being the product owner.
By the way, I am not asking from cynical perspective. I run a project team, and I am working through on how much autonomy to give the team members.
Technical decisions are made by majority vote.
The team handles uninteresting work like documentation, bug fixing, broken builds, and training with full-time promiscuous pair-programming.
This means that attitude and maturity are our most important attributes, as technical skill quickly will be taught while doing regular work. Several times in my career we've had to say to someone, "perhaps this isn't a good fit for you, why don't you start looking..." because they hate the exposure and boring work required to build a massive Enterprise system.
We almost always fix bugs and broken builds immediately, followed by product work. We spend 25% of our time fixing technical debt (this is typically the least fun work!).
Through all this we are able to ship release after release on time, adding in new features and regulatory standards with ease. It's given me hope it _can_ be done, but also that the circumstances to maintain it are almost impossible to force. It requires all the right people in all the right places to change a typical hierarchy into something like this.
Some workers require oversight to be productive, and for some it just helps. This means you get the most out of your work force, and can also hire workers who can't manage themselves. But managers also abstract trust and responsibility from multiple staff to one staff, help organize workflow, and ensure proper communication across teams. It's a simple matter of fact that some work is more fun, some people communicate better, and people don't organize themselves. Add to this the coaching and mentoring factor of a good manager, and it's a no-brainer.
Granted, what most employees fail to understand is if you have a manager, the company has already deemed you need one, and you're practically paying for your own overhead. Good managers are hard to come by, and are expensive. But businesses desperately need good managers because they solve most staffing issues. In other words, if you stop being complacent and just behave like a manager, chances are you will become one.
Here is how it's done: You start by managing yourself and removing your own overhead. Then you start taking care of other responsibilities because you can't help it. Know what needs to get done, understand the big picture, and just help accomplish it from the side. And when you provide relevant insight about how to improve something, put out a fire, or organize a project, you're already manager material. Your goal is to replace your manager without actually replacing him, without being the boss, without pissing anyone off, and without higher pay. You just made your bosses job easier, increased the value of everyone else, and ensured work got done. If your company doesn't give you a raise, you're at the wrong company.
Here is how it isn't done: You keep relying on your manager to keep you in check. You only accomplish your minimum requirements. You blame training for not being able to do anything else. You feel entitled for a raise just by being there for a long time.
Both of the above are exaggerated to emphasize two opposites, but most people are somewhere in between. Of course, if you're not manager material and you suck at your job, the likelihood is you will get fired, so it's perfectly okay to be complacent and just do good work. But the point is, you have your manager to thank for your straight forward and fairly comfortable job, and at the end of the day, his/her salary is practically coming out of yours.
If you have a group of people that can manage themselves, you have a group of potential managers. In other words, they're worth more than people who can't manage themselves, and the likelihood of them doing simpler tasks that can be done with someone more cost effective is greater. Meaning, unless you're allergic to non-autonomous people, it becomes a good business decision to just start managing some helpers instead of forcing everyone to help themselves. The quintessential helper is "the intern" (and they may be grooming you for a managerial role if they put you in charge of one).
Also, if you're an entrepreneur you're a manager. If you can't manage people, you have no business trying to build a business.
It's also worth noting public education systems do not produce managers. The teacher-student dynamic is similar to the manager-worker dynamic. They don't teach you in school that you could learn whatever you want on your own and that the teacher is mostly there just to make sure you get your work done. It's pretty much the same with managers.
But any thoughts on what to do in the "allergic to non-autonomous people" situation?
Sounds like you have the wrong job then.
Managers are in the meetings where they talk about other managers that suck or other departments that need more help. The whole point is to look out of place. And if they don't appreciate you, you need to take your value proposition elsewhere. And if you look out of place by sucking, you'll get fired.
Sounds like if you'd managed to keep reading, you'd agree with the poster.
But I think it's safe to say, if you're good enough to manage people, you have a job in America. Businesses lust for good managers. It's the only way to ensure work gets done with affordable labor, and many businesses can only afford affordable labor.
Seems like without management, an employee with an agenda--especially on that's not related to technology--could go off unchecked for a long time.
It made them understand the importance (and risk for the business) of such issues, so added HR and middle-management with a focus on them. As a side effect we ended up with things like this happening.
The people with an agenda are not random employees in a flat company here, it's the management.
Every day I had 10 people coming to me with issues they all thought were critically important. I was being pulled in every direction and I couldn't focus on anything. It was a complete mess.
Now I work at a company where I have one boss, and he acts as a funnel for all the work that comes into our department.
I'm never going back to a flat company again, if I can help it.
Many orgs tend to conflate technical leadership with people management and with project management, and they are different things.
The problem is that if you get a professional PM, they typically have seniority on the org chart and call the shots, even when they don't have the technical capacity to do so.
I'd like to experience an in team flat structure, one where management/PM is working for the team, not in charge of them.
The poorer PMs were the ones stuck in hierarchy, who managed schedules, tracked bug counts and (aside from bug triage maybe) did work that could have been largely automated. These folks tended to circulate through and were generally fungible, even at the nosebleed levels of their management tree.
I would happily have traded 20 or 30 of the "bug counter" PMs for a couple of technical PMs who could write specs that meant something. (I saw many "bug counter" PMs quit, or get fired).
Uh? I thought that for most people, bad memories fade away and only good ones remain. And that's what I observed around me as well (I noted it because I seemed to be the only one in the group to remember bad memories linked to a certain period, while other guys only remembered the good ones and looked at this time through rose-tainted glasses and had totally forgotten about the whole lot of hardships we went through).
In one of my college business classes we tried to define a startup, and we ended up with something like: > A startup is a company that is new company, less than 5 years old, that is also looking for a big payout by trying a risky and novel product or business strategy. A startup is also looking for extremely high growth, which is usually funded by outside investment.
So, github? No longer a startup. A year after you've become successful and paid off the VCs? No longer a startup. If you're a design/development agency? Not ever a startup, because the product/services you're providing are not novel or new territory. If someone made a competitor to Jira, I might also hesitate to call it a startup. At some point these kind of services get commoditized.
Of course, colloquially this definition fails and I don't ever try to push this definition on people. But it helps to conceptually divide the "high-growth new product startups" from the "lifestyle startup" and "traditional business startups".
If the business model is not new then the business can be categorized as X (grocery chain, real estate dealer, machine shop, etc).
Holy smokes. I didn't know it was already that large. What are they doing with 600 people that they were unable to do with 30? I haven't seen anything novel come out of there for a long time. Maybe Atom?
;o)
As far as I could tell nobody used these perks that day. A guy even made his own coffee at his desk.
Obviously, the analysis shouldn't be limited to the mere quantity of commits. I'm more interested in if the activity becomes more "regular" than sporadic. Or if long-neglected (i.e. boring) issues get more attention than they did before.
What I would find interesting is a what is the slope of the line in terms of worker productivity as it varies with org size as the number of workers are added.
Having a bossless architecture is fine when there is lots of interesting engineering work to do. Coordination and direction is just overhead when the organism should just spread in every direction. But after some point it needs to move and find food.
This is the best brief simplification of organizational dynamics on scaling I've had the pleasure to read.
This can't be serious...
It's surprising that it works for Zappos, which is just an online shoe store. Yes, there are people who are fanatical about shoes, but the business of selling and shipping them is not that exciting.
Is Valve's latest "new" IP DOTA2 successful when compared to the other set of MOBAs that have come out over the past few years?
Have Valve's forays into VR and hardware been successful compared to other companies in the space? e.g. the Vive, Oculus?
Looking at Steam itself, has the service dramatically improved since launch? Certainly there have been a lot of good incremental updates, e.g. two-factor auth. But the Apple App Store has seen a lot more updates in terms of search, discoverability, etc.
I am not an expert, and may have my details wrong about Valve. But I don't think the company has been especially successful outside of being the only game in town for buying AAA video games online.
It's probably best for Valve that Steam did happen, but if it's due to Valve's flatness, I would attribute that to the org's inability to resist Gabe rather than any sort of bonus wisdom that arose from that flatness.
Dota 2 I would estimate is #2 behind League of Legends, and it's too early to tell whether VR is working out, but guess which platform VR games are going to be delivered through?
(Besides Steam, their games are pretty successful: Half Life, Team Fortress, Portal, Counter Strike, Left 4 Dead)
This may not be your main point, but have you ever used the Steam store? It's the only app store that I've ever encountered that actually gives me valuable suggestions, and thus the only one into which I've sunk a considerable amount of money. (At least 200€, probably more. In second place is Google Play, where I spent some 7 € or so on apps.)
Just look at the huge percentage of games that are only purchased and never played (or even downloaded) to see that Valve has absolutely nailed the Steam store.
Regarding the actual argument: I agree that for a company this large, the turnout in form of actual products (esp. games) from Valve is surprisingly low. But I'm not sure if that's even a bad thing: For some studios, it works well to release 10 mediocre games within a certain amount of time. For other studios, it works better to release only one extraordinary game in the same timespan.
...but there's no one to do good customer service and other boring but necessary things.
Honestly, I don't know what Valve does any more, or if they have to do anything. They can just all take a year-long vacation, schedule some sales, and let people make them money by buying hats, games, or gun skins.
As engineers, we can sometimes become obsessed with updates/refactors/optimizations that have zero meaningful impact on the user experience. A user doesn't care about your cobwebs and dirty laundry, but as an engineer it's so hard not to obsess over these optimizations. It's so easy to forget that users don't care about the same things as you.
At the same time it's maddening when you feel like you're working with a house of cards and your manager asks for a third story.
I see a lot of conflict here, and this imho is what separates good technical managers from bad ones. They understand the competing interests and are able to prioritize work in a way that works best for everyone.
The reason I want to refactor is to make the code easier to read and maintain and more likely to be bug free. It doesn't have any meaningful impact on the user experience, but it is making the software a lot better and keeps running costs lower and allows new features to be added more easily.
However the transition is hard. Democracy is nice but companies are too close to the daily life of people to allow a vote every four years and let others decide policy
GitHub could have experimented with new ways of deciding policy (voting) - and I would argue that it's likely they would have got things like "write good docs" voted in anyway.
And it would be interesting to see how one handles voting on issues like "gender bias"
But we will all have to have companies like this one day - otherwise where do the big value wins come from. We can't keep inventing technology of the 21 C and hope they overcome the management hierarchies of the Stone Age
I think you are confusing structure and culture. I've always worked for the past decade under a boss and retained autonomy and spiritual ownership of my work. Yes, a boss can be a micromanaging asshole but going full anarcho-syndicalism usually just means that politics will happen, structures of influence and fealty will form and the end result is still a tree of authority.
I had to look up anarcho-syndicalism and no I don't think that's what I mean. I mean democratic participation of the whole company in the decisions affecting the whole company.
Edit: unfair to say no influence. Fair to say no "right" to an influence.
W.L.Gore and Associates of Gore-Tex fame are renowned for their organizational culture, for example (based on what I've read):
https://en.m.wikipedia.org/wiki/W._L._Gore_and_Associates
There are lots of different types of decisions made at companies. For example, Germany mandates a high level of employee influence at companies https://en.m.wikipedia.org/wiki/Codetermination_in_Germany
while remaining typically authoritarian in day to day activities (I've heard).
Non-democratic governance does not mean people could not be encouraged to participate and be creative. The book "Creativity Inc" by Ed Catmull ponders the problems of leadership and management at Pixar (namely, how they attempt to avoid all the stupid mistakes that are obvious in hindsight).
You might be interested int the "seven day weekend" by Ricardo Semler as well.
Human organizations are complex and difficult. I don't think you can legislate the pathologies away unless they are really obvious. But there are several companies already that include workers way better than not.
We have the same general primary social structure - certain people have control of a lot more of the resources than others and don't want to cede that control.
Is there any wonder that we have those structures in organisations whose focus is "making a profit", ie ensuring unequal distribution of resources by increasing the control of resources for those who already have the most.
So I have very few issues with "making a profit", it's just that "fire is needed in the engine room, to drive the steam engines and turn the wheels. But one does not invite fire up to the cockpit and let it steer". Democracy should choose where to steer. Capitalism can provide the engine room.
The problem arises that the successful capitalist farmer is rich and well fed; those living around the farm might be starving though.
Under other structures to be successful the farm would need to have everyone reasonably well fed.
In the capitalist regime the farmer is rewarded by keeping successful method to himself. Then he gets more farms to control and more wealth.
Under other ideologies the successful farmer shares his ideas and method so that the society can prosper, in turn the well fed populous can work well and improve the farmers life too.
The capitalist farmer wants other to fail, then he gets more. The other farmer needs others to succeed, then he gets more.
[Yes that's simplified and idealised.]
One interesting one proposed by cyberneticist Stafford Beer was dubbed Syntegrity [1].
It involved relationships between workers structured like a bucky ball, where each person had direct influence over a number of topics, and oversight of a number of others.
The result was (in theory) an arrangement where everyone had some responsiblity, but there was no overall "leadership". In theory
Modern western democracies aren't democracies, they're republics. Part of the reason they aren't direct democracies is actually a thing you mention: in a direct democracy the 51% effectively rule over the 49% and there is no recourse for the minority to have their needs met.
Also, no need to re-invent the wheel. If you want a model where an organisation isn't led by a "self-appointed dictator", just look at cooperatives, or foundations like Mozilla.
Most of the people I've talked to who make the argument that a republic is not a democracy base point to Federalist #10. But Madison was comparing a "pure democracy" - "by which I mean a society consisting of a small number of citizens, who assemble and administer the government in person" - and a "republic" - "by which I mean a government in which the scheme of representation takes place".
The section at https://en.wikipedia.org/wiki/Republicanism#Democracy_and_re... highlights how "democracy" now is something a bit more broad than was used 225+ years ago:
> In contemporary usage, the term democracy refers to a government chosen by the people, whether it is direct or representative.[32] Today the term republic usually refers to a representative democracy with an elected head of state, such as a president, who serves for a limited term; in contrast to states with a hereditary monarch as a head of state, even if these states also are representative democracies, with an elected or appointed head of government such as a prime minister.[33]
> The Founding Fathers of the United States rarely praised and often criticized democracy, which in their time tended to specifically mean direct democracy;
What should really be flat is the pay scheme: pay every worker 1/n of the company's assets at the end of each financial period.
That means anyone who wants more money must work to make the company prosper as a whole. Employees should also have the chance to decide who gets hired (because they have a motivation to hire only the people they think can increase their own pay).
Btw, I'm totally willing to try this in my own company one day. And if it doesn't work- who the hell cares. Most companies fail for much more common reasons than their management or pay structure anyway.
If companies want to avoid tyranny in the workplace then perhaps it would be better to have bosses but allow a majority vote of direct reports to fire them. Give 360 reviews some actual teeth.
https://blog.medium.com/management-and-organization-at-mediu...
I've heard people describe GitHub as the "Facebook of Open Source" and that's not as absurd a statement as it may seem at face value.
GitHub is basically the SourceForge of Web 2.0. It's where you go for open source projects and it makes it easy to participate.
I would hope to see GitLab succeed GitHub by virtue of being open source at heart (rather than just at the surface level) but as much as I love GitLab I'm not holding my breath.
Either way, git is ultimately an implementation detail to GitHub's success. Git's success may have given GitHub the edge over BitBucket (back when BitBucket was hg-only and GitHub was git-only) but it feels like the inverse is also true.
"the Preston-Warner episode helped demonstrate that some problems couldn’t be solved by the masses. While the old times created a strong sense of camaraderie, employees didn’t know who to direct questions to, either about uncomfortable confrontations with colleagues or about their own performance"