How does a manager abolish managers?

I’m deeply excited about the future of self-managed organizations, but I’m uneasy about the way some of these organizations are undergoing the transition. Perhaps this is captured in the opening paragraph of an article from The Atlantic: “This spring, by order of the CEO, Tony Hsieh, the company abolished managers, eliminated job titles, denounced its own organizational hierarchy, and vested all authority in a 10,000-word constitution….”

There’s clearly something ironic about abolishing managers “by order of the CEO.” In the old system, of course, the CEO did have the power to declare such a change. But to begin a glorious new era of empowered employees by commanding it? That feels to me like a dangerous precedent, and a recipe for all the sorts of problems that self-management is intended to solve.

I realize that this sort of transition is going to be difficult no matter what, and I don’t claim to have any magic solutions. But I do wonder what alternatives might be explored that are more in the spirit of empowerment, wholeness, and purpose. Could the CEO invite teams to experiment with self-management, and support their efforts if and when they proceed? Could the CEO begin to practice self-management, at least within her own team of executives? Could the CEO share with the rest of the company his own authentic hopes and fears about a potential transition?

And what is a CEO to do if the company as a whole does not want the freedom, responsibility, uncertainty, and pain that comes with such a transition? Wouldn’t it be against the spirit of a compassionate community to force such a change? And anyway, wouldn’t such force merely arouse suspicion, resentment, and resistance from those who it is forced upon?

In Zappos’ case, anyone who did not want to transition were invited to leave the company with generous severance pay. I like the individual freedom in this, but again I worry about the precedent: not everyone is welcome in this community.

I suspect there is still a lot of opportunity for creativity and experimentation in helping organizations transition to self-management more gradually, organically, and compassionately.

 

Change

“To be alive is by definition messy, always leaning towards disorder and surprise. How we open or close to the reality that we never arrive at safe enduring stasis is the matter, the raw material, of wisdom.”

-Krista Tippett, Becoming Wise (p. 67)

End-user programming is still an experiment

John Gruber, on the departure of Sal Soghoian from Apple and the apparent dissolution of the macOS automation team:

Part of my argument for why I feel so much more productive on a Mac than an iPad revolves around the automation technologies that Soghoian’s group developed. […] I find this to be a profoundly worrisome turn of events for the future of the Mac. […] On a personal note, I’ve known Sal for a long time. I first met him at a WWDC in the early years of Daring Fireball.

I too met Sal at WWDC years ago. (I knew one of the engineers on his team from grad school.) Even in 2008 I wondered about the future of the automation team, for the simple reason that the WWDC session on automation technologies was always scheduled in the smallest room, in the last time slot, on the last day (when many attendees had already left town).

I see these automation tools as experiments of sorts, exploring which programming-like tasks users can accomplish without needing to actually learn to program. AppleScript, for example, adopted an experimental English-language like syntax that aimed to be more approachable than other programming languages. Apple’s more recent Automator app used more of a graphical, lego-block approach. Both of these rely on other apps to surface third-party functionality in a way that is accessible to the automation tool. It’s not clear how many people ever really used these tools.

Meanwhile, the Mac moved over to Unix and gained 30 years worth of command-line automation tools. Now it’s often easier to copy and paste a Terminal command from a web search than it is to set up an Automator workflow. And the developer community continued to grow and ship new automation-related apps and scripting languages, for everything from text editing to web design to server maintenance. So the Mac is not losing its ability to be automated — on the contrary, there are more ways to do it than ever before.

Now Apple has thrown its weight behind different, related efforts: it’s not hard to imagine Siri becoming capable of many of the things Automator could do (even Automator’s robot icon foreshadowed this). And perhaps Apple’s Swift Playgrounds app, designed to help anyone learn how to program, can be seen as an assertion that previous automation technologies were too limiting — you may as well dive in and learn to code.

I think it’s a testament to Soghoian’s commitment that the automation tools team lasted as long as it did — and that the Mac has such an abundance of automation tools today. I’m not really sure what the team’s dissolution means for the future, but I think the space is still ripe for exploration. I hope Apple, Soghoian, and the developer community will continue to experiment.

5-hour workday

“When I tell people my team only works five hours a day, their response is always, ‘That’s nice, but it won’t work for me.’ The 9-to-5 is so ingrained in their minds that they can’t imagine anything else. But you can reduce your hours by 30% and maintain the same level of productivity.”

-Stephan Aarstol, The Five Hour Workday