Planning for a post-work future

It’s that time of year where many bloggers make their predictions for next year. Rather than do that, I wanted to look a generation out, when those who entering college today send their children to college, and think about the events of automation on our future. This is not a prediction per se. Instead it is more of a RFI (a request for ideas).

As a caveat, I work in automation (machine intelligence and machine learning, sensor and computer vision, automated controls and planning systems). I also have a prior background in policy—one that is driving me to think about the bigger picture of automation. However, this post is not about the work I am doing now. It is about the near-term “practical realities” I can imagine.

We are at the onset of an “Automaton Renaissance.” Five years ago, most people outside of tech thought about self-driving cars as something from the Jetsons. Last week, the governor of Michigan signed a bill allowing live testing of self-driving cars without human testers. Chatbots are not just the stuff of start-ups. Last month, I attended a conference where Fortune-500, large-cap companies were sharing results of pilots to replace back office help desks and call centers with chatbots. Two weeks ago, I was at a supply chain conference where we discussed initial pilots that a replacing planning and decision-making with machine learning (pilots involving billions of dollars of shipments). Automation is not coming—it is here already, and accelerating. Last week, I was at a conference for advanced manufacturing, we the speakers discussed the current and future impacts (good and bad) on jobs in the US.

So what will life (and work) be like in 20 years? Here are just a few things that we already have the technology to do today (what is left is the less-futuristic problems of mass production, rollout, support and adoption):

  • If you live in the city and suburbs, you will not need to own a car. Instead you can call an on-demand autonomous car to pick you up. No direct insurance costs, no auto loans, less traffic and pollution. In fact the cars will tell Public Works about detected potholes (street light and infrastructure sensors will tell Public Works when maintenance is needed).
  • If you work in a manufacturing plant, you will have fewer workers who are monitoring and coordinated advanced manufacturing (automation + additives). The parts will have higher durability and fewer component suppliers—also a reduction in delays, cost and pollution.
  • If you work on a farm you will demonstrate (supervised learning) to drones how you want plants pruned and picked, holes dug, etc. These drones will reduce back-breaking labor, reduce accidents and automatically provide complete traceability of the food supply chain (likely via Block Chain)
  • If you do data entry or transcription, your work will be replaced with everything from voice recognition-based entry, to Block Chain-secured data exchange, to automated data translation (like the team is doing at Tamr)
  • 95% of call centers will be chatbots. Waiting for an agent will be eliminated (as well as large, power-hungry call centers). The remaining 5% of jobs will be human handling escalation of things the machines cannot.

These are just five examples. They are all “good outcomes” in terms of saving work, increasing quantity and quality of output, reducing cost (and price), and even improving the environment. (If you are worried about the impact of computing on energy, look at what Google is doing with making computing greener.)

However, they will all radically change the jobs picture worldwide. Yes, they will create new, more knowledge-oriented jobs. Nevertheless, they will greatly reduce the number of other jobs. Ultimately, I believe we will have fewer net jobs overall. This is the “post-work future” — actually a “post-labor future”, a term that sounds a bit too political. What do we do about that?

We could ban automation. However any company or country that embraces it will gain such economic advantage that it will force others to eventually adopt automation. The smarter answer is to begin planning for an automation-enhanced future. The way I see it, our potential outcomes fall between the following two extremes:

  1. The “Gene Roddenberry” Outcome: After eliminating the Three D’s (dirt, danger, and drudgery) and using automation to reduce cost and increase quantity, we free up much capacity for people to explore more creative outcomes. We still have knowledge-based jobs (medicine, engineering, planning). However, more people can spend time on art, literature, etc. This is the ideal future.
  2. The “Haves vs. Have Nots” Outcome: Knowledge workers and the affluent do incredibly well. Others are left out. We have the resources (thanks to higher productivity) but we wind up directing this to programs that essentially consign many people to living “on the dole” as it was called when I lived in the UK. While this is humane, it omits the creative ideas and contributions of whole blocks of our population. This is a bad future.

Crafting where we will be in 20 years is not just an exercise in public policy. It will require changes in how we think and talk about education, technology, jobs, entitlement programs, etc. Thinking about this often keeps me up at night. To be successful, we will need to do this across all of society (urban and rural, pre-school through retirement age, across all incomes and education levels, across all countries and political parties).

Regardless of what we do, we need to get started now. Automation is accelerating. Guess how many autonomous vehicles will be on the roads in the US alone by 2020 (virtually three years from now):

10 million

Note: The above image is labeled for re-use by Racontour. Read more on the post-work word at The Atlantic magazine and Aeon magazine.

After Moving to Slack: Inbox Zero (at least twice per week)

TL,DR Version: Moving my entire Engineering organization to Slack and adopting a ChatOps collaboration mindset has reduced email volume over 95% and now enables us to resolve issues in 1/4th of the time.

I have always been a fan of using automation, web hooks, and chat-assisted operations to streamline work and enable collaboration across different locations. However, this traditionally required some Engineering and Operations (i.e., DevOps) investment in setting up collaboration servers, programming bots, etc. Slack has changed this, virtually eliminating all technical friction of moving to a ChatOps model. Here is our of how Slack enabled us to move to a ChatOps environment with far less email, faster response times, and greater overall productivity.

In late 2013, I joined a new company that—at the time—had no one on staff at the time with a DevOps-style background. After coming from several years of Chat-integrated operations, it felt like hitting the brakes. One night a few weeks later, I saw a Tweet by @mparca on February 9 about this new great service called Slack. I took a quick look and realized I could achieve everything that HipChat and Hubot did—with a simple push-button SaaS service. My initial set up (our organization, some channels, and hooks to Github) took less than 10 minutes. As it was free (for many features), I did not even need to process a Purchase Order (even better). I was off to setting ChatOps at a new place.

Initially, things went pretty slow. At the time, most of our tech stack and tools were hosted on-premise. Our chat tool of choice as a Skype (not a hook-friendly app). I got a few people to move to Slack, but not many.

Over time, as we implemented a full continuous integration and deployment chain, we added more and more hooks into Slack. First came a move to Atlassian (Cloud). Next Jenkins. Next Sentry. Then Ansible. Then Icinga. Then came custom RTM scripts for more complex things, such as letting our Data Scientists know they have left an idle PySpark context running for more than eight hours. What made this so easy was that everything but the custom RTM scripts could be done in less than five mouse-clicks (it is very helpful that so many collaboration and monitoring tools have enabled web hooks).

As we added more hooks, and started to bring more people onboard, I noticed an interesting shift. People joining our team began to just use Slack to communicate. One developer would come across an interesting new open source repo or article and share it with the rest in #general. Developers with DevOps privileges would jump on issues as soon as they saw a Sentry alert in #prod (saving the need to even text or phone the on-call engineer). Some people even answering questions in code review while they were doing things like waiting at the airport to depart on vacation.

Today our Engineering Teams (Product, Hardware, Software, Data, and Ops) all now primarily use Slack for communications. Most even use it in favor of texting. We Slack each other tickets that are ready for work, UAT, or release). We use group chats to have conversations to answer questions about stories, designs, bugs, and more. We use Slack channels integrated with Github for better code reviews. We use Slack to facilitate pair programming (and pair testing). Slack is now our default tool  for issue diagnosis, as sharing log messages, code snippets, and JSON is much clearer thanks to native markdown.

We achieve this with the following channel model:

  • One channel for each environment (so we can let people know if we are about to add nodes, run a load test, etc.). We have our respective Jenkins, Ansible, Icinga and Sentry hooks tied into each environment channel as well.
  • One channel for each code repository (to see PRs and conduct code reviews). We have aligned our JIRA projects with these to integrate tickets as well.
  • We have some basic team channels for more focused group conversations
  • We also have a #rm channel for simple-to-read log of what was released, when

As our organization moved to this model, life and work got easier in some rather visceral ways:

First, I have been able to dial down my notifications to only ping me when four things happen: I get a call, I get a text, I get a direct Slack message, or there is public Slack in a mission-critical channel. I no longer get endless interruptions, making me more productive at work (and more attentive in meetings and at home). If my phone does ping, it means there is something very important—which actually lets me react to these issues faster.

Second, my email volume is down over 95%. The bulk of the emails I now get are related to true business questions (vs. endless status messages and FYIs). As a result, I can answer email faster and now regularly hit “Inbox Zero” at least twice a week—while managing a 24x7xForever SaaS Engineering organization with follow-the-sun development and operations spanning California, Washington, Europe, and Asia.

Our full embrace of Slack did not happen overnight. It organically evolved over a period of about 18 months–a natural rate of adoption for organizational change. Because it was organic, we did have to institute policies  that forced usage. Instead we allowed our teams to naturally adopt Slack in ways that made work easier. I hope more organizations can make this transition as everyone could benefit from less email and fewer interruptions.

Natural adoption of Slack over other forms of communication would have happened if the usability was not as good as it is. One of my favorite features is how well Slack detects when I am no longer at my desk: if I walk down the hall, my phone chirps on key Slack messages; when I sit back down my phone stops and my laptop takes over.  This happens within seconds.

Oh BTW, we do all of this with the baseline free Slack account. That’s one less excuse to not give it a try.

PS – Want to work in an environment like this? Check us out.

5 points where tech balances between life and work