You cant come to the company with a radical new plan and have no idea what the answers to basic questions like "How am I going to be compensated?" before switching over to that strategy, that's highly questionable.
The Zappos Holacracy documents I read were nuts. Bad, batshit crazy. "Tensions" and "next-actions" and "accountabilities" and Policies and Domains and . . . the Holacracy Constitution reads like they were going for flat, but freaked out and decided to obfuscate a power structure after all. The Glassfrog documents are the hesitation marks of ditching a hierarchy. It's like they want people to execute a script rather than actually do work. At its core, Glassfrog is afraid of itself.
The documentation reminds me of one of my favorite quotes:
"Consultants invent these kinds of phrases to label things we’ve all known all along—it’s a perversion of business life that fancy words always cost more than plain ones, even though the plain ones are more valuable."
The Agile in question refers to the made up customer (in the book) who asks for changes and features on the go by walking by your desk. It's a good book.
I interviewed there in 2008, well before the Holacracy movement. Tony, while clearly brilliant, seemed to have some sort of "reality distortion field" surrounding him.
The interview process is pretty intense, so I talked to a lot of people there. They mostly seemed aligned on their opinions of what was working well, what wasn't, etc. None of their opinions matched what I heard from Tony.
I have to imagine then, that this Holacracy experiment, as implemented at Zappos, must have been even more bizarre than it seems generically.
I found the Super Cloud bit interesting. 350 employees haven't been able to move an e-commerce store onto Amazon's infrastructure in 27+ months. "For well over a year, Van Beek wasn't even sure the migration was technically possible ... the difficulty of this effort is almost unfathomable". Are the services Amazon makes available to its own teams substantially different from AWS? If so, why not just use AWS, and figure out the internal billing?
It's probably rewriting Zoppos retail app in Amazon's retail platform. That's like a redesign, re-architect, and rewrite of the whole app, plus the whole backend pipeline. That's a huge task. Also retail is driven by huge amount of data: product category, inventory, pricing, customer info, experiment data, marketing, ad, clicks, billing, etc. Migrating those data without interruption with live operation is like changing engine in mid flight.
You're right it's pretty challenging but 27+ months and 300+ engineers challenging? I would have suspected to take half the time which makes me wonder what their architecture originally looked like and what they've been doing for so long.
What I think you're hinting at is that a development organization with nobody driving direction devolves into a pile of people working on pet projects rather than doing the terrible boring work of shipping product.
I don't see how Conway's law relates to what you said. Can you please elaborate? Do you think if no hirearchy is driving direction then there is a lack of communication between groups that work on projects?
Holacracy implies no organization. It is a freeform, organic, shapeless philosophy with possibly no direction.
The migration project has taken 27 months with 300 staff, about 8100 man-months, with apparently little to show for progress. Lots of people in a project with no tangible features, like a blob.
That's a bit of a false comparison though. Amazon developed and used AWS as it was becoming a thing and transitioned parts when certain pieces of AWS was ready for them. This Super Cloud move seems really different though if we had more details of both company's transitions this would be a little easier to talk about.
A huge task? Sure. But product catalogs and shopping carts and payment processing are 90s tech. They could have re-implemented from scratch on AWS with the same graphics assets on the front end and cut over in a fraction of the time. Instead they are trying to force a square peg into a round hole and wondering why no matter hard they push it won't go.
While there are differences in what people use internally vs externally for some operations (see Apollo vs CodeDeploy in a few blog posts and talks), what they're talking about here is migrating Zappos onto/into the retail infrastructure and applications.
I work with a guy who worked on the Digital products side of the Amazon store and he said it was all done in Perl + Mason which sort of sounds like a nightmare, though he says he enjoyed it.
consider that running a complex piece of software on o&o hardware is very different than amazon. You have to re-architect your app to tolerate (1) hardware just disappearing (yes that happens in a data center but much less often than in amazon), (2) generally lower-powered hardware (no giant db servers running on TB+ ram / fusion-io drives / bonded 1g ethernet hardware), (3) often shitty network and ebs performance, (4) generally a very different HA architecture. Not to mention ops relearning everything they know about how to keep your site up.
As a DevOps guy with a great deal of startup experience I briefly worked at a hierarchy-less organisation and found it soul destroying. In the absence of any hierarchy decisions tend to be made by whomever can shout the loudest; projects go unmanaged; the needs of minorities (in my case long-term operational requirements for hosting the damn product) get ignored and appeals to reason with the company's owners were politely ignored.
My inner cynic wonders if founders love this fad because it saves the payroll they'd need to spend on experienced managers and absolves them of any responsibility to run the internals of their organisation, freeing them up to focus on overall strategy.
The result (admittedly based on a limited sample size - I'm not trying that again) was chaos. Real lord-of-the-flies stuff. One of the first questions I now ask when startups approach me is "what's your org structure like" - and if they haven't got one I run like hell.
"In the absence of any hierarchy decisions tend to be made by whomever can shout the loudest."
This. Classic problem with volunteer organizations. If you have the time, you can have formal meetings using Robert's Rules of Order, which are designed to force decisions by voting after discussion. But that's unwieldy within an operating organization.
The military is formally very hierarchical but, when planning operations, is much less so. There's a military custom that, when discussing a proposed plan, the most junior people speak first. (The elder Moltke is credited with this custom.)
This, of course, is to reduce the tendency of people to agree with their superiors.
More than that, it's to find holes in a plan before the enemy does. Once the decision is made, everyone is expected to carry it out fully, and not drag their feet, whether they agreed or not.
I suspect this works in the military because the military doesn't tolerate rebellion - even minor rebellion - much at all. But it has unique, specific privileges that enable this - it's definitely not a model you can apply elsewhere with ease.
> My inner cynic wonders if founders love this fad because it saves the payroll they'd need to spend on experienced managers and absolves them of any responsibility to run the internals of their organisation, freeing them up to focus on overall strategy.
I totally buy this at the macro level. Just like open office concept saves buying a bunch of walls and more office space.
But Zappos? I think they have a history of making the "poor financial" decision to make employees and customers very happy. Seems very out of character to come form them.
If you read the book reinventing organizations that describes holacracy you notice that the examples of successful flat orgs all had policy enforcers, people who forced sane conflict resolution and decision mechanisms and had the authority to do so, whether by dictatorship or by democratic vote. Truly flat doesn't work, you need to have people who enforce the equality.
Hierarchy is part of human social interactions, switching to a completely flat organizational structure is just sweeping it under the rug.
Better to re-organize to try and match the organizational structure to the actual communication and power structure. If your organization has too many groups and tiers of communication, that is either a staffing problem, or you haven't properly separated business concerns.
Holocratic organizations are not flat. It's a common misconception.
Holacracy is just agile redirected towards defining roles in an organization rather than building a product. You take on roles when you can help the organization by doing it instead of having a manager tell you what to do. Those roles are constantly iterated on to make them better.
I understand every word you wrote, but I honestly think if I took that paragraph and surround it with some anti-Holocracy quotes and put some sort of sarcasm mark around it it would read perfectly.
It all makes perfect sense and a small organization, but how could it ever work at the scale of something like Zappos? At that size how can any employee have enough information to make a good decision as to what role in the organization needs filling right now? For that a role that is filled needs to be filled by someone else as the person currently doing it is suboptimal and doesn't realize it.
It seems like one of those things where the communication demands necessary to keep it running smoothly between all the individuals would quickly overwhelm what any normal person could actually do. The obvious solution is to have people in charge of relaying messages to other sets of people. Whoops. I added hierarchy.
> At that size how can any employee have enough information to make a good decision as to what role in the organization needs filling right now?
It's not necessarily about finding what roles need to be filled in the whole organization. It's more about doing what needs to be done in your department. If something needs to be done in another department, you point out the problem and they decide how to fix it.
> or that a role that is filled needs to be filled by someone else as the person currently doing it is suboptimal and doesn't realize it
I think Holacracy is actually better at solving this problem than traditional management. If a role isn't being fulfilled well, it's everyone's job to bring that up at a department meeting so the group can decide how to fix the problem.
> It all makes perfect sense and a small organization, but how could it ever work at the scale of something like Zappos?
I have no idea. I hope they make it work. It sounds better than the status quo.
"I understand every word you wrote, but I honestly think if I took that paragraph and surround it with some anti-Holocracy quotes and put some sort of sarcasm mark around it it would read perfectly."
Isn't that true of any idea? That's just describing how someone would belittle an idea while not focusing on the content.
Personally I have found that a great manager is worth their weight in gold. Breaking down barriers, navigating red tape and bureaucracy so the team doesn't have to, helping keep the team happy. And most importantly being and advocate for the team to the larger organization. I feel that advocacy role is often overlooked. A great manager will make sure the powers that be know who is doing great work, what the team is up to and ensure they get the credit they deserve.
And at places like Google, this is how it does work (on paper. In practice there are always exceptions, either due to actual hierarchy or individual charisma). If you look at Google's org, you essentially have 4 ladders: 1) Engineering, 2) product management, 3) business, 4) G&A superstructure. You can bet that if you're a PM trying to decide roadmap priorities, you're going to be driven by input from engineers primarily, not customers, sales reps or professional managers.
Certainly, and in some of the places I have worked with a good manager, they were not necessarily considered "higher up". These companies had separate technical vs manager tracks in some form or another. So the notion of "higher up" depended on the track you are on.
Make the tech people the managers. Hire BAs for the soft skills and project management, attach a BA to each tech lead, and they work together to provide direction for their group. BA owns all communication and requirements, Tech lead owns the technical decisions, code reviews, work assignments, and they collaborate on managing the team.
That sounds mostly great. Separate technical leadership from organizational management.
Not sure "requirements" necessarily belong to the BA. They probably belong to whomever can identify best with the customer. That's certainly a BA in many circumstances, but hardly all of them.
> What if I say X is we must all stop working and you say Y, we should carry on as we are?
> Do we fire half the company?
If we can fire half the people currently working in the economy, stop the pretense that "job" is something meaningful on its own and start dealing with the actual issue, things might actually get so much better!
I mean, I'm not sure if the GP committed a fallacy or not (he probably did with that blanket statement), but you picked a bad example.
For two real-world examples: compare "We must ban slavery" to "We must allow slavery", and compare "Equal voting rights for women and men" vs. "No voting rights for women".
What's the sweet spot between those two pairs which isn't one of the endpoints?
This is funny. You're picking examples where this no middle ground to counter an example where there is: you can have organizations that are somewhat flat with a bit of hierarchy.
Yes, that was deliberate. You objected to ethanbond's comment because you regarded it as straw man example.
I restated ethanbond's objection to show real-world examples where your statement "When people say it must all be X and not Y, you can bet that there's a sweet spot between X and Y" does not apply. Therefore, it is not a strong rule for inductive logic, which is our point.
The midpoint fallacy is that the truth lies directly in the midpoint.
Typically it lies SOMEWHERE in the middle, but the fallacy is meant to point out that it's just as likely to lie very close to one end or the other, as directly in the middle.
Of course, if you construct a total straw man argument where we already know the god-given truth, you can show that a second argument will take you further from the truth.
"Somewhere in the middle" is one of three possibilities if you reduce everything to a one-dimensional line and pick two points. Even in the rare cases where an oversimplified single continuum expresses the best solutions to address a problem, there is little reason to assume that two point alternatives aren't together in being the wrong direction away from the optimum.
However, I really think golemotron was just referring to when a trend becomes a default that no longer needs to have its case made in new situations. Like assuming middlegrounds are implicitly correct, or cargo culting, it's just a form of assuming there are shortcuts that make understanding the mechanisms of success or doing actual analysis are unnecessary.
I don't know how a flat organization works in practice but to me it sounds like you end up with top management secure in their jobs and having their equity and everybody else has to constantly struggle to stay relevant. This may work for some people but most people prefer having some security in their position.
Because humans, flat organizations always end up with an informal hierarchical structure, and that structure very rarely optimizes for organization success and almost always optimizes for success of the people who've clawed their way to the top of that hierarchy.
That's actually how it works in regular corporate hierarchies too. Those who are good at politicking, making friends with higher-ups and know how to cover their asses usually outperform (success-wise) those who just do a good job. A good well-cited read on this is Power: Why Some People Have It and Others Don't.
True, all groups of humans form informal hierarchies, even in the presence of formal power structures.
What formal hierarchies have that flat organizations don't is the ability of the formal hierarchy to use normative actions to drive the optimization function to favor the organization and not the people at the top of the informal hierarchy.
e.g. a loud mouthed developer can't force the CEO to do something they don't want, while a CEO can fire a disruptive employee
An informal hierarchy is where one gain power through influence and manipulation (e.g. creating a fight between two other people so you're the only one who still have good relations with both of them and you're the only one getting the benefits of these relations). The problem with this is that you end up with invisible hierarchies with a lack of accountability. At some point few people understand why a project is stuck and it takes a while to unearth. God forbid that a small clique forms and finds a way to exploit failures in the oversight to drain the company for their own interest, blocking real progress within the company but with the inability to either point fingers or fire people.
Now with formal hierarchies everyone generally knows who's responsible for what, but in larger companies you can still end up with inter-divisional fights, rivalries, etc. e.g. Microsoft under Ballmer. But at least a higher up can roll their sleeves and clean up house because they have that power, e.g. Satya Nadella.
Basically, in both informal and formal hierarchies the same sorts of problems can occur, but in an informal hierarchy the phrase "you can't tell me what to do" is often times a valid response.
Humans are interesting animals in that one of our instincts is to self organize as we form groups and work together. As social animals we just do this, and it's been quite well studied over the last few decades -- it's instinctual to us the same way birds might flock. References to this are found in economics, sociology, finance, and a dozen other fields.
It begins forming in surprisingly small groups, some research says as small as 2 people, other says around 5, but nevertheless, humans tend to self-sort into various levels of "leader" and "subordinate". When this structure accidentally emerges its considered "informal".
A "formal" hierarchy simply means a hierarchical organizational structure that's been imposed on a group from up on high. Leaders are selected from the herd and put into a rigid position, and attempts to usurp that structure can be enforced with various measures (in modern society banishment from the group is the typical response).
In an informal hierarchy, because there is no imposed structure, the leaders tend to fluid and there's no built in corrective function to reimpose an order to the herd. As a result, the "leaders" in an informal hierarchy tend to be those who have cultivated the most social power, usually through personality, but also through favor trading and promise making and other mechanisms.
Ideally formal hierarchies are supposed to be structured by the formal leaders (who also, as a formal corrective function, have a mechanism for removal and smooth transition of power) and those structures are supposed to be optimized for the good of the organization (not the group, the organization...e.g. an Army organizes to win wars not to provide safety for the members of the Army). Informal power structures always optimizes to try to secure power in the leaders e.g. a mob boss kills off his rivals
In terms of opportunity, informal hierarchies need to spend a huge amount of their time determining structure, this often means that nothing much else gets done except for activities that will help secure and define that structure and maintain it. Formal system spend far less of their time with this kind of introspection and thus frees the members up to pursue work meaningful to the organization.
It's not perfect, even in the presence of a formal power structure, humans will still form informal structures within it. However, the formal power structure can be used to break it up if it's becoming problematic (a CEO can fire a problem employee, while no single employee can remove a CEO). Good managers understand how to use the informal structure to help the goals of the formal structure.
it doesn't work with me (or in my presence) - i don't even need a Scotsman, i grew up in the USSR and it is like telling me that USSR (or China or Cambodia or Cuba ...) were doing socialism/communism wrong.
Recently many orgs inside our BigCo have been through couple years of the best Agile/Lean/Scrum/<whatever crap> the money can buy. It was a zombie-like horror show and a spectacular failure across the orgs. And one wonderful day the management and PMs just seem to have waken up and just magically forgot all these words. We're back to normal planning and developing features like nothing happened in those 2 years. Magic.
like it has been for the last 25 years starting at the University and through the places i worked in Russia and here - natural cycle of plan, design, implement of the stuff slated into the next release (ie. the dirty word of "waterfall"). It has mostly been pretty large projects with multiple teams involved (though even in 1988 in high school with a friend developing a small game we followed the same "process").
As someone said "you can't successfully run marathon by running a series of sprints". One can try him/herself to run even a couple of miles by running it as a series of sprints to understand the foundational principle from systems analysis about the cost of low latency and synchronicity (normally one would expect that software engineers are aware about it without self-mutilating experiments, yet here we're ... to really feel the pain make somebody tell you, strictly each 20 seconds, where to run the next sprint) - those being the 2 main paramount features of Scrum ( note : Agile,insisting on low latency while relaxing somewhat the requirement of synchronicity, is a little bit less disastrous on its own, ie. when isn't attached to Scrum).
For me it's more like this: prototype, design, implement. I do some lightweight planning while I prototype. All of this is anathema to Agile. Prototyping alone could mean going dark for a week or two. Design, likewise, has no useful status to communicate. Implementation fits pretty well, but it's maybe 1/3rd of the work. I don't think I'd be able to deliver quality software any other way.
Sure it does, about like the USSR supported freedom of speech. What do you report in your daily standup? What if your prototyping takes four weeks instead of two? How about if your problem is particularly gnarly and it takes six weeks? What if it's only reasonable to devote, say, two people out of the team of six to prototyping? Do they report status (which they already know) to each other? "Syncing up" with them is useless for the rest of the team. What if I'm already an adult and therefore don't need adult supervision? Why would you want to interrupt my "make time" with your bullshit, useless standup, thus knocking me out of my zone for an hour or more?
On the teams that I ran, we relied on a weekly meeting, lasting about 30-45 minutes to go over what we did last week and what the plans are for this week. The rest is handled perfectly well with ad-hoc communication. Those teams were far more "agile" than any of the Agile teams I've seen, since people expended all their effort on achieving the goals as opposed to figuring out what they're going to say in the next standup.
That's basically how I run my teams also. Weekly tempo-setting meetings to go over status and adjust planning as needed.
Plans are made with broad brush strokes and are expected to be fluid and details are figured out during development. Planning sets goals, and are used to time box the work (even if the boxes are different sizes, so no adherence to stupid 2-week one size fits all sprints). Pre-planning makes it easy to get stakeholder buy-in without having to go into deep philosophical development notions. Ad-hoc communications and gasp my involvement with the teams covers 90% of the rest and if major problems occur, the appropriate parties are pulled into a meeting to discuss and resolve.
My teams are pretty consistently the most productive performers in my organization, use the fewest people and resources, and produce the highest quality product at the end of the day. As a result, my teams are consistently in demand to work on things, and once they're out of my hands and back into some scrummaster's their performance goes back to normal.
I've noticed an inverse correlation on all of these metrics the more "Agile/Scrum" the teams seem to be. Between standups, retrospectives, scrums, and whatever activities the other groups get mired down in, the consistent complaint is that nobody seems to have time to actually get anything done.
The problem is that Agile is supposed to be about liberating teams from process and tools and documentation and so on and focus on people and product. However, the Industry that's exploded around "Agile" has simply created another pile of rigid processes that bring everybody back to square one again. Even worse, most people in the industry are so young they think this is better than what the old fuddy-duddies greybeards used to do and don't have the perspective to realize they've just become trapped in another set of process ceremonies that get applied to everything without regard to the nature of the task at hand.
I just got out of sitting in another team's sprint planning meeting and they spent 2 hours trying to figure out how to fit O&M and R&D into their next sprints...30 minutes of which was spent figuring out how to model the Epics.
Agile is a great idea in theory. Agile in practice is a terrible one.
Agree I worked on a project (to manage the UK's core SMDS network) where we had a long planing process (over 6 months) but built the product in a 12 week sprint at the end.
I'm not completely certain you know what you're talking about, especially about Agile. Tell me which part of the agile manifesto you disagree with, or why you think waterfall increases the likelihood of success of your projects. That's an honest question, I'm truly interested in your reply.
i don't agree or disagree. I just apply basic system analysis principles which explain the observed behaviour. It is pretty valid choice to choose low latency and synchronicity as the top priorities over everything else. I just find it very funny that making such choice people frequently declare productivity increase as the goal. And even more funny when they find that productivity really went down at the end (in the case of one project - after very major feature priorities change - low latency and synchronicity make this much easier, i'd even say tempting - each sprint for several last sprints before the release, and as result there was nothing to release at all).
I don't think he is referring to the manifesto, but to the concept of agile, and all it`s related buzzwords being promoted to sell you 5000$ 4 day courses or conference tickets.
you don't do frequent start/stops, route change midway, conferences with judges/observers/coach/journalists/etc.
What you describe is pure waterfall - you have the preset target/route, you work out the plan and you execute it.
Yeah. There are no panaceas. And change for the sake of change isn't useful.
This certainly mirrors some of the horror stories of "agile" adoption I've read online. With most of those, either an executive read a book and forced change on everybody, an over-priced consultant tried to force change on everybody, or some combination of the two.
Counter those exmaples with my own experience in an organization adopting scrum. My current employer started that process 3 years ago and it has been reasonably positive. There were growing pains, but the company invested in training to alleviate FUD, there way buy-in across the board, etc.
Based on this one article, it really sounds like the executive team failed to get buy-in from the broader management team and then doubled-down on the failure by not providing the employees with enough training to overcome FUD-induced panic.
And then tells the employees to implement the consultants model. While the management continues in old ways and refuses to totally let go. Now the team is supposed to be "self organizing" but actually the management uses the tools intended for teams self-organization, learning and communications as precision vehicles in employee evaluation. Which completely erodes the 1. requirement for succesfull 'agile' - trust. Also, goodbye honest communication.
IMHO, agile is a bad fit for a lot of legacy, heavily-employeed companies.
Would it be incorrect in saying that agile has an implicit position of "if you don't trust this developer, fire them"? Which I think is much more of an option in a startup than some politicized offices.
FWIW, my employer is a legacy, heavily-employed company (3000 employees, 20 physical offices worldwide). We use scrum or scrum-hybrid for most projects/teams.
I do think it's incorrect to state "if you don't trust this developer, fire them." At least, it's no more true in an agile environment than any other.
A couple of questions then: what's the long term result of a perpetual "I haven't done {thing X} because of {justification Y or Z}"?
And related to that, do you encounter the "no one on the agile team is empowered to remove this blocker" (because it's too many departments away and that team has no stakeholder/ownership close enough to the agile team)? If so, how does that play?
1. Most of those can be avoided with enough coordination and planning. If you know thing X has a dependency, you need to plan for it (and make sure any other team knows about it). Weekly scrum-of-scrums, leadership meetings, etc.
2. No, we don't usually encounter that.
That said, when we do run into long-running problems, we do need to escalate. One of our systems had some serious performance problems and it did take VP involvement (daily 15 minute standup with the players involved) to keep things moving towards a resolution. It's annoying when it happens, but I'm not sure it's completely avoidable in a large org. Perhaps I've been lucky, but management has always had my back - we def have a culture of servant-leadership, at least in my division.
This might be a case of how not to flatten an organization's structure, but there is always heavy turnover during any restructuring.
There is a key paradox of implementing a "holacracy" in an existing organization. An organizational hierarchy is trying to force non-hierarchy on itself.
A prerequisite for such rapid change seems to require an organization that can rapidly adapt to change. But part of the argument for flat organizations is creating adaptable businesses.
I haven't read what problems prompted Zappos to push for these changes. Was an overly bureaucratic hierarchical culture holding a Zappos back from continued success? Is this admitting that something was wrong with their supposedly strong culture, but missing the actual problem?
This seems part of a larger trend on insisting hires and workers should have an almost cult-like desire to be with their current employer. And leaders who obsessively manage their company's culture and its perception. People who don't buy into the whole result are treated as non-believers unfit to be part of their "mission".
> I haven't read what problems prompted Zappos to push for these changes. Was an overly bureaucratic hierarchical culture holding a Zappos back from continued success?
The concept of paying for people to leave does not make sense to me. I see companies doing it, and seems to me that they're doing it so they can reduce headcount without having to actually fire people.
Thing is, the people who will take the buyout will be the ones who are confident that they can find another job. The company is left with the people who don't really care about their job, are afraid they may not be able to get hired anywhere else, or both.
No I recall when British telecom had generous voluntary redundancy several years pay plus 6 years pension payments. One guy I know got over £200k mostly tax free
They lost a lot of key technical people who took a huge pay off and joined a competitor.
And I know that for some specialties (radio planners) who where not allowed to go - the competition brought them out by paying $100,000k starting bonuses.
It works for the HR executives in charge. They can reduce headcount without bad PR, with the ostensible rationale that they are cutting the ones who don't have the passion and loyalty for the company.
I'm concerned Hsieh decisions show a blatant lack of concern for maintaining a meritocracy. Also it doesn't really seem like Zappos cares about attracting talent. I might even venture to say the decision is driven by the chance to maximize profits. Imagine how much money you save by firing all your manager.
I've worked at companies that stress how important their bullshit "culture" is. It's usually to distract from shitty compensation and rare promotions.
Another nice opinion article which cites the tendencies of "flat" organizations to create opaque hidden hierarchical political structures, with some references to Github, Valve, and 60's commune and feminist groups.
Critics say flat organizations can conceal power
structures and shield individuals from accountability.
This idea dates to the 1972 essay The Tyranny of
Structurelessness by Jo Freeman, who describes her
experiences in “leaderless” feminist organizations in the
1960s. “There is no such thing as a structureless group,”
Freeman wrote. “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.”
The problem with supposedly non-hierarchical groups, she
wrote, is that power structures are invisible–and
therefore unaccountable. That inevitably leads to
disfunction and abuse. Charismatic leaders could use their
position to advance their own agenda, award desirable
tasks and projects to an “in group,” and shift blame for
mistakes.
Charismatic leaders could use their
position to advance their own agenda, award desirable
tasks and projects to an “in group,” and shift blame for
mistakes.
And how exactly does that differ from formal hierarchies?
Regardless of your prejudices and perhaps negative experiences with holacracy, I would highly recommend the book, 'Reinventing Organisations', that Zappos' employees were encouraged to read. You can download it here: http://www.reinventingorganizations.com/pay-what-feels-right...
It is a fascinating read and will help you think about how to structure your organisation regardless of what structure you deem fit. The most interesting insight, which I can see most of the commenters here are probably not aware of (as I wasn't), is that in Teal organisations (such as ones who implement holacracy), it is recognised that different structures and behaviours are applicable depending on the situation. For example in a war an army better have some hierarchy or they will get wiped out but in a modern company the hierarchy is not as necessary if at all. Anyways, even if you never touch a holacratic model, go read the book. Guaranteed to be at least a rewarding thought experiment.
I like the idea of parallel/independent organizations but I think the problem I see with their use in businesses is the fact that it can impede the very purpose of a business: to make a profit from a good or service. To achieve part of that mission is to specialize where you have someone directing production (managers) and someone who knows how to produce a part of the good/service (labor). Now, I do believe managers and labor can be the same thing at least in terms of dual roles. But to get there you can't bomb out an existing firm's structure which is what I see Zappo's CEO doing. The turn around is either going to take a VERY LONG TIME or it may never happen at all with high churn of employees.
What a surprise: Zappos, as a division of Amazon and not a profit-seeking free-standing company, has plenty of capital to waste on humoring their sales-hustling CEO's lunatic ideas about human potential.
Valve, a company that also practices a system similar to holacracy, mentions that it's not the right fit for some (most?) people. But that style, is the right fit for Valve.
Well there in lies the beauty of Valve. From my outside observation, no one is making a HL3 / HL2 Ep3, because that project can't get critical mass to build (although there is a part of me that wonders if they'll pull it out for the SteamVR launch).
It's an interesting method to build entertainment software--build something you're passionate about and can get others passionate about it, rather than taking money from a publisher to build something that has someone made a business case for.
That philosophy doesn't work unless you have deep pockets, which Valve does.
My guess is that it's a collective name for all the retail systems Amazon are running to manage logistics, inventory, and everything else that makes an e-commerce business tick. A lot of that may well be running on AWS, although whenever that comes up you always hear people mentioning quite a few of their core systems have yet to be migrated.
1. Zappos offered a very attractive payout and most people at an average company would take it.
2. 14% in first few weeks and 18% thus far, so after first few weeks the "exodus" nearly halted to the low 4%, that is low.
3. Radical ideas, take some time to adaption.