There seems to be an assumption in this article that you need to adopt a typical command-and-control structure to run a successful company. There are several examples of very flat organisations showing this is not the case. Valve and Github are well known examples in the tech. industry. Ricardo Semler / Semco (http://en.wikipedia.org/wiki/Ricardo_Semler) is an example from outside tech.
It's probably more work to run an organisation with a flat structure, but it seems to be more successful if you get it right.
It's probably more work to run an organisation with a flat structure, but it seems to be more successful if you get it right.
Define "more successful"? Valve has 250 employees, github 140. Are you saying that these are "more successful" than more traditionally managed/structured companies like Wal-Mart -- the world's largest retail company with $450 billion in revenue/year?
Unfortunately you are using a definition that is not shared by most people when judging business success in the long haul. It is okay to have your own metrics but it is disingenuous to suggest that your metrics are also the metrics generally considered by the majority of industry experts.
Why do you feel that profits, market cap etc. are poorer metrics to judge a business success than your metrics? You should write about that.
Google is not flat, and was the best company to work for in 2012 [0] because of how happy their employees are. In addition to meeting your made up measurements, significantly more people associated with Google have become richer than at GitHub; Google has made billions more money than GitHub; Employs more people; has more products; etc; etc; etc.
Flat works in small companies. It is impossible once they get above a certain size. They cannot be "more successful".. because they will eventually need to restructure as they grow larger.
You don't need to be "flat" for people to be happy, but you do need a decent amount of employee autonomy. You probably need some big-picture direction at 1000+ employees, but you don't need the closed-allocation "you work on this project, or you pack your bags" extortion of most companies.
Some Googlers have autonomy, some don't. I don't care to get into this discussion because for all my criticism of it, I really admire Google (the engineers and the vision, if not the middle management and HR) but I'll just say that the Googlers who've established a basic autonomy are very happy. They pick their projects and have little interest in leaving, unless to do their own startup. However, there's an underclass who face manager-as-SPOF and live or die by their "calibration scores". For them, Google is a closed-allocation company and these people are not happy.
You don't need "flat" structure outright, but open allocation is non-negotiable in technology in 2013.
It depends on whether the work is concave or convex. Concave means that the difference between excellence and mediocrity is smaller than that between mediocrity and failure. It applies to commodity work where the best performers might be 1.2-1.4 times as effective as average ones. There's no such thing as a "10x factory worker". Convex work is where the difference between excellence and mediocrity is huge, but mediocrity and failure aren't far apart.
If you're doing concave work, command-and-control works. Reduce defects in your factory process, fire the slackers, reduce risk. If you're doing convex work, then you need the Valve/Github approach because traditional management will drive excellence away.
Wal-Mart excels in a commodity domain. Valve and Github are in software, and software is convex.
Nice try at explaining it. But Apple, Microsoft, Samsung, IBM, HP, Intel, AMD, Nvidia -- not a single one of these is flat. Valve and GitHub are TINY companies in comparison.
Flat works at the small size of GitHub and Valve. But I can't think of a single large company that is flat. Where is the evidence that a flat structure even works at the size of these companies?
Just so the comparison is clear:
Microsoft: 94000 employees [0]
GitHub: 140 [1]
In other words, Microsoft is 670x larger. Or GitHub is 0.15% of MS's size.
You need coordination and guidance at 94,000 people. You can't have it be totally "flat"; I agree. You need some administration and some conceptual structure and hierarchy is the way humans think.
You don't, however, need managerial extortionists who won't let people seek independent credibility, choose their own projects and teams, or collaborate extra-hierarchically.
Google's the one I have the most experience with, and there's some excellent work going on there, but there's no longer a company-wide culture of excellence, and the reason is the injection of traditional HR and managerial behaviors: "calibration score" witch hunts, manager-as-SPOF, stack ranking.
If you're a Real Googler, you're above the fray with regard to a lot of that shit, and you can move to projects as you wish. Hell, Steve Yegge quit his project at Oscon and wasn't fired. He moved to a different project. The culture of excellence that exists at Google is for Real Googlers. If you're a Real Googler, it's an awesome place and you can get some really great work done there. If you're not, you're wasting your time and career. I'm sure it's wonderful if you're already great. It's not the best place for people like me who are good and trying to become great.
Valve is now the cultural leader, and it will be able to scale with open allocation. Why? Because open allocation is a natural fit for technology. I don't think you can grow at 300% per year and retain OA, but I see absolutely no upper limit on the number of people who can coexist in such a regime. What makes scaling hard is the deadline factor: having to grow quickly. It's easy if you can control the pace, which Valve (being privately funded, not a get-big-or-die VC gambit) can.
OA seems the anomaly because we're used to these military-inspired corporate megaliths, but the reality is that closed-allocation is the oddity. A caste of people whose only job is to delegate work? Top-down internal headcount limitations set according to political fights, arbitrated by people who barely understand the day-to-day of the company? Does this sound like an intrinsic necessity, or self-serving parasitism centered around control of the division of labor? I know where I'd put my money on that one.
Open allocation essentially mirrors open source software projects we see in public. I totally agree that open allocation is the way to go. Even software on a company's critical path will attract new people to work on it, mostly to learn and develop new skills. That frees the original super star devs to move on to new projects.
"There is no question the once-open Googleplex has become more compartmentalized. Areas where the Google+ and Android teams work suddenly began to require special badges. Page's own suite is on the top floor of the Google+ building."
BTW, if you're interested in these types of orgs... the linked article is interesting because it actually goes into some of the Pros/Cons of running your company this way. It's not written by an ideologue.
Managers and "hierarchy" aren't toxic if it's conceptual hierarchy and if management is more of a sponsorship/mentoring role, but when you have a stable hierarchy of people and begin restricting internal mobility, you're fucked. You can't be completely "flat" at 10,000 employees, but I refuse to believe that a company can't get to that point and retain a decent culture. However, you probably can't grow to that number in 4 years.
Companies lose their culture when they hire before they trust. That makes an underclass that's used for grunt work but gets no respect. Soon they hire an "HR expert" who sets up a stack-ranking system and an annual "low-performer" witch hunt and the company's culture is garbage.
I can't put a number on what is growing too fast, but you can't hire before you trust. By "trust", I mean that people should be trusted with their own working time to do good for the company. I'm not saying they should have million-dollar expense accounts.
This is interesting—as someone who is part of a "management team" at a company that has grown rapidly from startup to perhaps a post-startup stage, there is some truth to this.
There's a giant void of advice out there for folks who are making this transition. It's awkward and really challenging; like hitting puberty for your company (I like to say we've got braces right now). HN and publications focus a lot on startups. Business education and literature is heavily focused on "management" in the sense of Fortune 500 like worlds (I've been in that world as well). My sense is those two appeal to much wider, paying audiences where much smaller sets of people actually make these jumps. There's very little advice/tips/thoughts about how you steer your company as you get more customers (e.g. how to manage early customers who got more attention as you were proving your product vs. later on when the cost of that attention might be a challenge), hire a lot of employees (training, compensation models, etc.), build out teams (trade-offs of various structures, ability to repeat and scale), etc. This stuff is hard and unless you're growing at such a rate you can ignore it until much later on, you have to deal with it.
Does anyone out there have a collection of posts/tidbits/advice for others who have actually managed through these transitions? The linked post talks about trial-and-error. I'd love to read about what worked and what didn't for others.
Many of the comments here hating on the idea of management teams highlight how blinded we can be as a community. While it may be cool for startups to hate on BigCos, almost all start-up founders aspire at varying degrees to become the very BigCos they bitch and moan about here.
Management teams may have their own issues but to blanket discount them shows utter misunderstanding or ignorance. I challenge folks to find me a single billion dollar revenue company that doesn't have some structure that looks much like a management team.
You're missing the point. At some time, a company has figured out at least one way to succeed. At that time, you're going to grow extremely rapidly and take all sorts of ways the company does things, break them down into elements, and optimize to accelerate that growth. The "management team" are often the ones who drive that optimization. Someone who understands engineering is going to lead building software at scale. Someone who understands sales is going to scale out your sales. And so forth. Founders often lead this and see across all spectrums.
FWIW, I worked at MSFT and had opportunities with both Gates and Ballmer. I can absolutely ensure you management teams existed at the company. Hell, Microsoft is made of layers upon layers of management teams. A young, bright-eyed version of myself thought this was inefficient (and it was to some extent). But I got a chance once to ask Ballmer what a typical week was like for him--holy hell, managing an organization of 90k+ employees is not a challenge that many of us are made out for.
And... what was the Ballmer answer (if you can comment about it)?
I see it different, for many founders, companies are a way for a personal grow. In that case founders grow with the company and change their management styles. Ballmer was a very early Microsoft employee, he was even in the IBM/DOS license negotiation.
Probably not something I can share (sorry); just, really, good management isn't often as much about "command as control" as it is steering a lot of smart, opinionated people who often disagree.
You're completely right on the growth aspect. If you're working somewhere with a founder and their not growing in that way while the company is, I can see nothing but headaches. The original link essentially calls this out... what you did at 5 people doesn't work at 50, which doesn't work at 150, and on. You gotta learn and adjust; as it scales up, the folks who help move beyond the Founder and into a trusted group.
I agree. It's a silly idea to believe that people like Gates and Jobs roles stayed the same after their companies grew beyond a certain point. When a company gets large enough, it's simply impossible for a single person to know or even understand everything that is going on. There are too many moving pieces and too many areas of expertise to cover.
"Management team" is a horrible pair of words. I suspect this was submitted as a protest of the inability to downvote submissions.
Once you start talking about "the management team", you've created a company run with an "us vs. them" mentality and that ruins the culture over time, because the people actually doing the work are a "them". It's not something that happens only at scale. I was recently at a startup infested with this mentality at under 100 people.
Management is a function. It's work that needs to be done, like administration. Drawing lines within the company is one way to end up with a horrible culture as people try to cross or control the line. Ultimately, as soon as you have a company where people succeed or fail based on their ability to control the division of labor, your culture will tend inexorably toward corporate grey goo, no matter how good your company's original intentions were.
You'll have noticed in life that every point has a counter point. In this case it's Microsoft. Specifically Steve Sinofsky's approach to managing delivery of Windows 7 and 8. For some insight, read his book (One Strategy).
Microsoft talk about a leadership team, rather than a management team.
The problem isn't in defining what management is. The problem is in founders not understanding or knowing how to manage. This is a result of inexperience and the youthful tendency to ignore others' (especially experienced others') advice.
It's probably more work to run an organisation with a flat structure, but it seems to be more successful if you get it right.