The Buzzword Is Dead, Long Live The Buzzword
Last month, I was joking with another Panda that as soon as Scrum and Agile die out, another generation of equally flawed cookie-cutter management processes will take their place.
The very next morning, I found out about Holacracy™. Now everybody’s talking about it.
14% of Zappos employees say "Holocracy? More like Lolocracy, amirite?" http://t.co/nzwYbxN0Nr
— 1.0! 1.0! 1.0! 1.0! (@steveklabnik) May 8, 2015
Holacracy is just one of several new managerial terms being used for self-organizing organizations. GitHub favors the term open allocation, even though the circles in their Team UI are very reminiscent of a core holacracy concept. Valve refers to itself as having a “flat structure.” There’s also an Async Manifesto and a Remote Manifesto.
Zappos CEO Tony Hsieh embraced holacracy so enthusiastically that even holacracy consultants thought he might be overdoing it. Hsieh offered severance and a boot out the door to any Zappos employee who didn’t want to read his favorite book on holacracy. The top comment in the Hacker News discussion actually came from a former roommate of mine, Justin George:
Especially for software companies, I’ve always found the idea of using external workflow and management software to be a little bit abhorrent, like wearing someone else’s underwear.
It should be your way of doing things, and software… is just a way of codifying and automating that. In the same way we customize our editors, we should customize our workplaces so that they reflect the unique sets of people and activities they contain.
And of course, other people have pointed out the irony of a hierarchical mandate for [changing] to a non-hierarchical system.
Fourteen percent of Hsieh’s employees took him up on his offer. The only surprise there is that the number was so low. I don’t have any inside information about Zappos, but I only see two really plausible explanations.
- Tony Hsieh is saving a company in trouble.
- Tony Hsieh is the type of person who is great at starting things and terrible at doing the same things over and over again. Rather than having the good sense to move on and start something new, he’s restarting something that he himself only started recently in the first place; or, in other words, fixing something which isn’t broken, and asking his employees to risk their careers on his whims, after first having sold them on the idea of joining a completely different organization.
Most people seem to assume it’s the latter. I’m leaning towards that too, but I don’t know. And one blog post goes against this trend, listing a bunch of companies that fired many more people than Zappos lost.
how is possible that 15,000 people have lost their jobs due to bad management and we don’t hear a peep about it, but people have gone nuts over Zappos having 210 people volunteer to leave?
It’s as though we’re acting out this quote from John Maynard Keynes:
Worldly wisdom teaches that it is better for reputation to fail conventionally then to succeed unconventionally.
The post has a good core argument: anyone who wants to change an organization will face internal resistance, and buying out your dissenters might be cheaper, faster, and easier than arguing with them.
Unfortunately, the post first states that this interpretation is possible, then leaps to the conclusion that it is certainly true, while providing literally no justification at all for upgrading the idea from a possibility to a certainty, unless you count the author’s opinion that it would be cool.
Personally, I’m willing to wait for the Glass Door reviews, and to see what results Zappos actually gets from all this.
Also, for the sake of correctness, holacracy should actually be referred to as Holacracy™. There’s a good reason for this, if you’re familiar with the trainwrecks that divided the Scrum community into Scrum Inc., Scrum.org, and the Scrum Alliance. Scrum pioneers disagreed on what Scrum was and where it should go, and this, combined with Scrum’s inherent (alleged) malleability, created a situation where you can say “that’s not really Scrum” about almost any aspect of Scrum. Trademarking Holacracy™ allows its advocates to enforce a clear and consistent meaning for the term.
A similar motivation, no doubt, drove the trademarking of GROWS™, a new software development methodology which was recently announced in the most vapid, condescending, and absurd blog post I’ve had the misfortune to read since I stopped arguing with Ron JeffriesMy personal opinions do not necessarily reflect the opinions of Panda Strike in every last detail..
Not coincidentally, its author was another Agile Manifesto signatory, namely Andy Hunt. Something weird about these folks is that whenever they encounter criticism of the Agile Manifesto, they refer to it as “objection” or “complaint,” as if their dominance and correctness were unquestionable, and only mewling children would fail to honor it.
there have been many folks complaining about the agile movement, some quietly, some loudly, and none of these complaints are novel. But here‘s a new twist: let‘s fix it.
Fix it! Wow, nobody ever thought of that. Twenty years later, the Agile crew is still cooking up innovations that nobody else could ever dream of. (Never mind that many people are “fixing” Agile the way they would “fix” a broken VHS player they found at the back of their garage.)
Here are Agile’s problems, according to Mr. Hunt:
- Agile terminology suffered semantic drift.
- Agile zealots insist on their own interpretations.
- Many people use degraded, half-agile versions of Agile.
- “Agile methods themselves have not been agile.”
- Agile methodologies lead to people following rules instead of thinking.
His solution’s another brand name methodology.
I’m not kidding you, that actually happened.
I won’t waste your time taking this thing seriously, but I will point out that its fundamental premise is flawed: it claims that Agile has failed, and the solution is more of the same. The obvious problem is that you don’t add failure to failure to create success. But the more subtle problem is that Agile hasn’t failed. It’s just outlived its usefulness.
The most absurd assumption a lot of Agile advocates seem to make is that software development methodologies are immortal and absolute. How could this possibly be the case? You’re going to ride up an exponential curve in computing power without changing your fundamental philosophy? We’re going to go from horse-drawn carriages to self-driving cars in only a little more than a century, but this isn’t going to require a whole ongoing series of perpetual reformulations of our basic philosophy around work? When NASA put a man on a moon, writing huge stacks of bug-free software without the benefit of anything as powerful as the computers in a modern toaster, should they have been using the same development methodology as a 1980s Smalltalk project, or a 2010s Node.js one, or a 2050s quantum robotics one?
Moore’s Law created Agile. But Moore’s Law giveth, and Moore’s Law taketh away. Rails revolutionized web development in 2005 with the simple act of writing code which could write toy web apps for you. Odds are pretty good that the tech industry might change again once robots become capable of handling more complex software development tasks for us. We already have AI sports journalists.
These things aren’t supposed to live forever. If you had that insane goal for Agile, then yes, it failed. But a much more reasonable interpretation is that Agile existed to shepherd us through a technological change; that it did so successfully; and that it has not failed, but simply completed its task.
Holacracy™ isn’t going to live forever either. But it, and other ideas in the same category, exist because a new techonological change is underway. Agile isn’t any better equipped to handle that change than waterfall was ready to deal with the power of Lotus Notes, so we need a new thing.
But let me remind you of what Justin George said:
Especially for software companies, I’ve always found the idea of using external workflow and management software to be a little bit abhorrent, like wearing someone else’s underwear.
On Reddit, Hacker News, and Twitter, there’s an overwhelming theme which overlaps with this: most people say that software development methodologies don’t matter if you have good programmers. But there’s a few problems with that:
- You could conceivably translate that as “don’t bother solving this problem, just hire people who can solve it themselves,” which, although good practical advice, is just passing the buck.
- Either way, the world needs much more software than it has great devs to create software with.
- If you’ve never had the experience of seeing great programmers fail together at anything, then you’ve probably never spent any significant amount of time around great programmers.
Which brings me back again to Mr. George, because although I’m not going to name names, he and I saw some absolutely fantastic programmers fail completely, back in the day.
I think Mr. George’s argument is right: selling a process to manage a company is kind of like telling everybody how they ought to run their families, or making proclamations about how a coach should run a team in pro sports. So much depends on the chemistry of individuals in particular, and the group as a whole, that the only hope you have of giving out useful advice in that situation is to speak in generalities. Or tell your own personal stories, with the upfront acknowledgement that they’re stories first and lessons second.
But as long as Moore’s Law keeps periodically redefining everything our industry is, we will need words with which to discuss these changes and reason about them. Just as there’s about 10,000 Scrum Certified Whatsits™ for every individual who’s actually taken the time to read the Agile Manifesto and think about it, there’s going to be about 10,000 dissatisfied, suboptimally-productive Holacrats™ or GROWS™ Certified Fertilizer Producers™ for every one person who figures out their own solution and gets it to work really well.
Whenever you learn a programming language, you should learn its idioms. Whenever you learn a new platform, you should learn its conventions. But that’s not a mark of expertise. That just means you’re qualified.
You see expertise when a programmer knows the idioms of a language, and knows when to disregard them. You see expertise when somebody understands how a platform works, and knows when to circumvent its norms. And you see overconfidence interpreting itself as expertise far more often than you see expertise itself.
The same is true for Holacracy™, Scrum, and whatever else the future holds. This was indeed one of the few genuinely timeless points made in the Agile Manifesto (or at least implied by it), and even if it’s time to throw a lot of that thing away, we should keep the best parts intact.
If you think Holacracy™ is the The Answer™, you’re probably wrong. If you think Holacracy™ can’t be The Answer™ because Your System™ is The Answer™, you’re definitely wrong.
These systems make good places for conversations to start. They’re just terrible places for conversations to end.