The Zappos Exodus Continues After a Radical Management Experiment
bits.blogs.nytimes.com
bits.blogs.nytimes.com
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.
1. Take the payout
2. Take a few weeks vacation
3. Get a new job (when you switch jobs you usually get a raise).
Try some of the documentation here: http://www.holacracy.org/constitution#art1
(Oh, and it looks like there are companies that will consult with you and help you move to a Holocracy. Big surprise).
I work in an org that is flat. There's none of that nonsense. You don't need it. You really don't.
"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."
From Agile Development with Rails, 4th edition.
I assume the irony is intentional?
While Valve isn't perfect either, their system appears positively utopian when contrast with Holacracy.
[0] http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...
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.
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.
I would say Conway's law fits perfectly.
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?
> 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.
What's the sweet spot between those two pairs which isn't one of the endpoints?
Do you realize you're doing this?
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.
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.
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.
The middle ground fallacy is the idea that given two ideas, the truth lies somewhere in between them.
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.
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.
Did you mean people? I really hate this kind of dehumanising management speak.
Who is responsible for removing engineers that aren't pulling their weight?
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.
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.
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.
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.
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.
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.
Isn't that true of any idea? That's just describing how someone would belittle an idea while not focusing on the content.
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
What are the differences between an informal hirearchy, and a formal hirearchy that makes them unique?
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.
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.
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.
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).
I think that's a lazy argument.
If you don't like the word 'sprint' use another term to denote a period of time.
> natural cycle of plan, design, implement of the stuff slated into the next release (ie. the dirty word of "waterfall").
Actually, if it's in small units of time/work, then it's pretty close to agile.
The problem with waterfall is the big upfront planning where you try to estimate how long it'll take to implement things months ahead of time.
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.
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.
E.g I can run a mile in x minuets flat out but to last for 26 I need to target x+y minutes per mile.
I've done 5 and I've never had a plan hold after the 20th mile.
1. Agile: when stuff works ,it's agile. When stuff fails, its not agike.
2. Not-Agike: when stuff works, its not agile. When stuff fails, it's agile.
The agile debates are just shows of tribal colors, not substantive analyses.
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.
The executive reads the book and then hires the overpriced consultant(s).
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.
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.
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?
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.
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".
Religion is my bet.
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.
Does this actually ever work?
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.
http://www.wired.com/2014/03/tyranny-flatness/
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.
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.
...and a list of organizations currently using it here: http://structureprocess.com/holacracy-cases/
but, yes. valve does make some pretty cool stuff.
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.