Tag: workers

  • What Do We Do When Everything is Automated?

    What Do We Do When Everything is Automated?

    Recently, I came across a study the caused me to think beyond the day-to-day world of code-slinging in which I live. According to the study conducted by Center for Business and Economic Research at Ball State University in Indiana:

    “Almost 88 percent of job losses in manufacturing in recent years can be attributable to productivity growth, and the long-term changes to manufacturing employment are mostly linked to the productivity of American factories.”

    Just translate the term “productivity of American factories” into the word “automation” and you get the picture. Other workers are not taking jobs away from the gainfully employed, machines are.

    This is not a new trend. It’s been going on since before Eli Whitney invented the cotton gin. Industry creates machines that do the work of humans faster, cheaper, with more accuracy and with less failure. That’s the nature of industry; nothing new here. However, what is new is rate by which the displacement of human beings from the workforce in happening.

    The Bureau of Labor statistics projects that by 2024 the U.S. economy will need 50 percent less car mechanics, 42 percent less telephone operators, 26 percent less postal clerks and 20 percent less parking enforcement officers. Or, to put it another way, cars will be better at self-repair, call routing technology will get better at conducting verbal conversations with humans, self-service postal machines will get better at taking care of human transactions in the post office and parking meters will know how to write tickets.

    Here’s another another point to ponder. As the quality and reliability of self-driving vehicles improve, it’s not far-fetched to imagine self-driving trucks becoming the norm on the nation’s highways. How many truck drivers will be displaced once self-driving trucks are everywhere?

    Also, think about this: As Uber and Lyft mature in the business landscape and self-driving cars become commonplace, the ride-share companies will replace human driven vehicles with self-driving vehicles. Then, Uber or Lyft will start to offer a pricing model that is flat fee for 24/7 service with unlimited mileage. So, to keep it personal, imagine Uber/Lyft offering me a deal in which I pay $150 a month to have all my driving needs taken care of. Or, I can continue to pay the $400 it costs me for my car lease and insurance coverage (yes, I lease a modest vehicle). Which way do you think I will go? Spend $400 for the pain of driving in a car in LA traffic or spend $150 to get where I need to go while I read a book in the back seat? Me? I’d fork the car over in a New York minute.

    As if this isn’t startling enough, try this one out: Walk down your street. See all those cars parked on the side of the road. In the near future, using the Uber/Lyft automation scenario, they won’t be there any longer. Any car made will be used 24/7. All this translates into less cars doing more work. And less demand for cars means less cars being made. Less cars being made means less people working making cars. You get the picture.

    What about software? Let’s take a scenario that is part of my day-to-day coding world, logging. In the old days, you’d log to a file on disk. Over time, that log file got so large that a human would need to move the file manually onto an archive disk so as to not eat production space. Somebody comes along and says, “Hey, I can write a piece of code that watches the size of the log file and moves it automatically when the file gets too big.” So much for the person doing the manual file move. But, still, you had to keep adding capacity to the archive machine, which typically meant a human walking down to the server room and twiddling with some hardware. Then a someone has a great idea, “Let’s use this thing called cloud storage as a back-end for a log collection service. We’ll leverage the elastic capacity features of cloud storage and write out logs to that service. Hell, why make a service? We’ll subscribe to an existing one and save the development costs.” Thus, no more humans needed to monitor capacity, move files, write incidental scripts—any of it. In terms of logging, a bunch of automation is doing the work a lot of humans used to do. Is this progress? Might be. But the trend is unmistakable, so much so that I have no problem imagining a future in which 90 percent of work that used to be done by humans is done by low-cost, automated, robotic, labor.

    We’ve always been on our way to automating everything. The only difference between then and now is that now we are really, really close to full automation. Asking the question, “What will we do when everything is automated?” is no longer fantastic, it’s essential.

    So what will we do?

    “Simple,” you say. “We’ll retrain the displaced workers.” Really? Many of us in the software game know that notion of retraining is a joke. If you are not constantly learning the new stuff, you are out of work. For a knowledge worker, continuous learning is an ongoing requirement for commercial viability. And, the baseline from which you are learning is very high. In other words, you need to know a lot to get the basics of how to write a deployment script in Ansible that runs against AWS. And, even as you are learning that basic technique, somebody is already creating a technology that will make the technique you are learning obsolete.

    So back to the question, what do we do?

    First, let’s do the obvious. When near total automation has the result that there is no longer any work for most humans to do, we need to come up with other means of survival. Survival in the modern world means having money to live on. Charles Murray suggests in the Wall Street Journal that we plan to implement Universal Basic Income. Finland is starting a pilot project based on the idea. Other countries are experimenting too. Universal Basic Income is a program in which citizens of a state are provided with a base income on which to live. Some programs vary basic income according to income produced otherwise. The common thread is an understanding that jobs are not plentiful and that depending on one for survival is not realistic.

    The notion of Universal Basic Income is not that new. It’s been around since the 1960’s, proposed by folks such as Milton Friedman as the negative income tax.

    Second, we need to address the elephant in the living room: the birth rate. In the old days when agriculture and small, private farming was a major industry in the United States, having a large family made sense. You needed your family members to work the land. As the Industrial Revolution created demand for factory workers regardless of age, large families still made economic sense. But now the trend is that we need less people to do more. Thus, having large families becomes counterproductive to the economy overall. Yes, there are certain sensibilities out there that encourage large families and adherents to such thinking have large families as a matter of choice. Still, many families end up with large families for reasons other than intention. It just sorta happens.

    Thus, to ensure that humans have a chance at a viable existence in a fully automated world, implementing effective family planning policy and practice becomes as useful to the society of the near future as the anti-smoking efforts that started in the 1960s does today. I am not advocating draconian, government mandated family planning. We cannot legislate family size anymore than we could smoking behavior. Rather, we need to create a social condition in which the wisdom of the idea prevails.

    Finally, we need to address the need for human dignity in a fully automated world. For better or worse, we need to accept that in the near future the traditional relationships between demand, productivity and income no longer may be applicable. The old days of human workers making stuff and getting paid for their product or labor are coming to an end. Yet, one of the intangible benefits of the old days was the dignity and satisfaction that went with pulling your weight and earning your keep. Being able to provide for yourself and your family defined your worth in your own eyes as well as those around you. This need for dignity will remain no matter how the technical and economic landscapes evolve.

    When I started to doing the research for this piece, I asked others in the know to respond to the prospect of a world that is fully automated. One the people I talked to was Phillipe Kahn, founder of Borland, Starfish Software, LightSurf Technologies and most recently, Fullpower Technologies. Here is his response:

    “I remember being in India and watching a construction site: Lots of people, elephants, activity. I asked, ‘Why don’t you all use bulldozers and tractors and prefabricated concrete parts?’ The answer was enlightening: ‘How would this community make a living with dignity?’ That’s the whole paradox that we are dealing with: Productivity versus dignity for communities that could be unemployed for generations.”

    There is a difference between work and labor. Work is an activity a human does to give one’s life meaning. Labor is what a human does to survive. In the old days work was your avocation, labor was your vocation. Some humans were fortunate enough to have their activities be both avocation and vocation. Others went to work in factories, farms and offices to earn a buck. They pursued other interests at other times. But whether you sang in the New York City Opera full time or in the choir on Sunday morning, the dignity of your work, bringing music to the ears of other humans, was in full force.

    So, the final part of answering the question, “What do we do when we’ve automated everything?” is this: Preserve the dignity of the person and the community. A fully automated world will be a wealthy world unless we blow it up. Productivity produces wealth. That’s the way it is. Regardless of who is or what is the owner of the wealth—government, corporation or private citizen—sharing will become more important than ever. Concretely, this means allocating a significant amount of money to people and organizations that do work that has little or no commercial value, but extraordinary amounts of human value. When it comes to commercial value, the machines will have that end of the economy covered and then some. However, stuff that has little commercial value—curing low occurrence diseases, space exploration, academic research, expanding the arts—this is where human activity can excel.

    In the old days we had a notion called the commonwealth, that shared space where our individual assets grew. We shared some to get some. In the automated future it might have another name. But no matter the name, it will be a place where humans work with dignity in communities and most labor is the left to automated robotics. If not, the common thread of our individual survival might indeed be nothing more than alms for the poor while automation creates wealth for a few.

    — Bob Reselman

  • Four Inspiration-Killing Concepts That Need Redefining

    Four Inspiration-Killing Concepts That Need Redefining

    Software engineering is a creative process, and creativity cannot be measured by the hour. It can be measured only by the value of the contribution. Yet, a majority of companies still measure productivity by hourly contributions. Companies treat the development process as if it still existed in the days of the assembly line, and all we needed to do was to affix 100 widgets a day. This mindset pisses off developers, kills inspiration and causes developers to quit.

    So, how do we measure progress in our companies? How do we ensure that we can increase our probability of success? These are necessary questions for businesses, and it’s easy to see why companies cling to the rules of the past. It’s all we know. And it is a big gamble to change. After all, shareholders and such.

    It will take true visionaries to rewrite the rules. And although many new companies are doing wonders for changing the way we define work, we still have a long way to go. So the question now stands: What does the ideal dev process look like in the future? It might be helpful to attribute new words to the dev process to help us gain better understanding.

    New definitions for the Internet Era

    Task → Contribution

    Approval → Collaboration

    Workplace → Remote

    Workers → Culture

    Task → Contribution

    Remove the worker from the assembly line, and give them a seat at the decision makers’ table.

    This trend has already started in the open-source community. What used to be a to-do or a task is now an “issue” on GitHub or GitLab. If you think about it, task implies, “You got to do this whether you like it or not!” It’s involuntary but necessary involvement; you being creatively engaged with the task is optional. We embraced this unnecessary definition and are justifying it for no reason.

    We have established that creative workers don’t like to be told what to do and how. We should have contribution meetings where creative workers decide what they would like to work on. Unfortunately, many decisions are made in meetings where business owners pre-decide needs and delegate to managers to distribute tasks among engineers. If you want to lose creativity in your team and make everyone feel bad, this top-down approach works exceptionally well. We see the Band-Aid solutions to this top-down approach all over the place now. The manager needed to find ways to motivate workers. How? Ping pong tables! Free laundry! Ice cream! You get the idea. Most creative people see right through that garbage. It’s only novel to inexperienced recent grads who have yet to understand how the real world works.

    You will not have an engaged workforce unless you empower them and let them decide how to give value to the company. The easiest way to achieve this is to communicate transparently to the company what the business requires and give a detailed description as to the reasoning. From there sit back and watch the engineers chime in and say, “Hey, can I do that?” or, “What about this other problem we have?” I believe we could then change the perception from, “This is what I’m expected to do,” to “This is what I’m contributing to the company and I’m passionate about it.”

    Approval → Review

    This change is also apparent in the open-source world, when you submit your changes to a source code repository, your peers can take a look at it and see if they can contribute to its quality. In the past, this process was called “approval” and now is called “review,” where in fact your peer is approving the piece of code you’ve written. Approval implies. “I have authority over you,” whereas review says, “I’m going to help you get this done.”

    Workplace → Remote

    Dave Gray makes some really interesting points about how we make decisions in his book, “Liminal Thinking: Create the Change You Want by Changing the Way You Think.” He suggests that we only have the ability to make theories, judgments and beliefs based on our personal experiences. And even in our experiences we are only able to process a minuscule sliver of the information available.

    picture1David Gray’s diagram of how we come to our understanding of what the obvious choices is in a situation.

    If we apply this idea to the way we feel about our workplace, then we can quickly see the we are reducing the number of creative solutions available to our workforce. If everyone one of your creative workers gets to work from 9 to 5 at the same desk doing relatively the same thing daily,  they will start narrowing their understanding of what is possible. Just imagine what different solutions might arise if your employee is sitting outside at a lake or in a crowded bar. Their experience would change, thus their well of experience deepens, and their concepts of what is possible, multiplies. Make sure your developers experience new things, both as individuals and as teams. This doesn’t just mean offsites for team-building. It means, let them follow their gut, and work from wherever they need from time to time. This doesn’t mean let them go solo and unplug for days at a time. They need to stay plugged into the team and be a contributing part to the culture, but they need to balance that with building fresh perspectives so they can contribute to the collective experience of the whole.

    Workforce → Culture

    Yes, I know. “Culture” is one of those buzzwords that now cause people to roll their eyes so far back in their head that they fall out. But it’s important to know why the concept is important in relation to the old idea of “the workforce.” When management thinks of its developers as “workers,” the developers are immediately dehumanized and turned into pawns. They are expendable and indistinguishable as creative minds. They act out of fear from punishment and rarely take chances.

    We are no longer cogs in the corporate machine. Our ability to take risks can make the difference between being one of the 99 startups that fail, or the one tech company that succeeds. Managing culture as opposed to a workforce means that we can focus on enabling workers to be as creative as possible. We can focus on nurturing collaboration and honest feedback. A healthy culture is one that is transparent and communicative. A workforce could give a rat’s ass about making positive change. A culture is a living breathing thing that everyone contributes to and improves. A culture is owned by the collective. A workforce is owned by a man in a suit at the top of the tower. Screw the man. Power to the people.

    Conclusion

    Now that we have an understanding of why we must redefine our terminology, it’s time to start defining practical ways to make the switch for each term. In my upcoming writings I will start to lay out practical ways to make the switch in your company.

    About the Author / Devrim Yasar

    devrim_yasarDevrim is the CEO of Koding, a San Francisco-based software development automation platform vendor. Connect with him on LinkedIn and Twitter.