devopsy.kinsta.cloud

Category: Features

The New AI Overseer Role in DevOps

Robot overlords are the stuff of science fiction fantasy. Today, with more teams implementing artificial intelligence (AI), DevOps teams need a hard, continuous look at reality. An AI overseer watching apps at work could make the difference between sadness and euphoria in your efforts.

We’re seeing AI misses more and more often. Facebook recently admitted its algorithms failed to stop uploads of a particularly heinous live-streamed video. Autonomous vehicles have struck cars and people. Jaywalkers in China have been misidentified and publicly shamed in error. It’s not for lack of effort in development. The adage “If it were easy, anyone could do it” applies.

A few weeks back, I was in a Twitter chat session on AI led by Kirk Borne, data scientist at Booz Allen Hamilton. The question came up of what organizations should consider when creating guidelines for use of data and bias-free AI. Here’s my response:

A4: DevOps teams should have someone whose role is AI oversight—actually watching what it’s doing and constantly testing/validating its findings #MITSMRChat

— Don Dingee (@StratisetDon) February 14, 2019

Common Problems

Most fails are due to fire-and-forget, wherein AI systems are trained, tested against training and turned loose. Even a well-designed AI system is subject to several problems:

Errors: This is where AI makes a factually incorrect decision. False positives and false negatives are in this category, along with miscategorization problems.

Gaps: There are situations in which AI understands conflicting options and is unable to choose. Then, there are situations in which the AI doesn’t recognize what it sees.

Bias: Maybe the system prefers green M&Ms or German shepherds because there was some subtle trend in the training data for “candy” or “dog.”

Ethics: This can be a higher level of bias, where preference is given based on age, gender or race. Sometimes it’s the classic no-win scenario in which both options are harmful.

An AI overseer guards against these types of problems in near real-time, every day, for as long as it takes to weed them out. Some problems are easier than others. An example of a more difficult problem came when autonomous vehicle researchers realized that not all traffic signs are brand new and well-lit. Shade, branches, wind, scratches, dings, bullet holes, stickers, graffiti and many more types of defects exist in the real world.

Increased Complexity

Inevitably, part of the solution the AI overseer leads is better scenario-planning and more training data. Retraining becomes a way of life and at some point, bigger data sets also lead to more complex implementations and another challenge: speed—after retraining to correct issues, the reloaded real-time classification engine runs like it’s stuck in molasses, producing correct results too late to be useful.

While the A system is running, a B version should be in development with new training and classifier boxes. For very large data sets, teams should consider designing a workload-optimized training server complex instead of relying on elastic cloud resources. This was behind NVIDIA’s recent acquisition of Mellanox—using InfiniBand for more bandwidth between GPU clusters in AI server complexes.

Where training systems often scale, real-time systems usually don’t. They are optimized for size and power consumption and can only accept so many additions. When a bottleneck emerges, it can kill the entire application. New generations of CPUs, GPUs and FPGAs keep pushing the envelope for designers tackling AI challenges.

Human-in-the-Loop

In many use cases, the job of the AI system is not to make every single decision autonomously. Instead, the system should make routine decisions and lead the AI overseer to look at exception cases. Directing humans quickly to areas needing attention is often more valuable than risking bad decisions. Human-in-the-loop is something DevOps teams should architect into systems more often.

This may all sound obvious, but it points out a big difference in developing AI versus developing code-based algorithms. If there’s a bug in code, you can debug it and find the offending lines of code to fix. But debugging AI is a lot more difficult. Digital twin implementations come into play using playback of real-work inputs to look at what happens inside the classifier black box. There are usually hints of problems developing before catastrophe strikes. Running data both good and bad can help spot issues.

Ideally, the AI overseer is a hybrid of a data scientist plus a systems architect. Look for someone who understands both data sets and hardware implementations, at least at a high level. They may have to call in other resources on the team for detailed investigations.

The last thing you want after all the hard work in developing a system is to have it run amok months or years later. It’s just Murphy’s Law. AI systems will do something entirely unexpected at the worst possible time. An AI overseer can help a DevOps team get ahead of AI problems.

March 27, 2019
DevOps: Assessing Behavior Flows Through an Organization
I’ll admit it, this article is a little strange. It is an experiment. But DevOps is all about experimentation, right? This article explores how information and behaviors in fact “flow” through an organization. It is based upon my observations with literally hundreds of DevOps teams. I have used the Three Ways of DevOps to show how and why many organizations struggle with this flow of information and behaviors, and what you can do to identify and prevent behavioral “defects” in your organization.

Simple, Really: Mindsets and Behaviors

IT organizations embarking upon Agile or DevOps ways of working are basically attempting to realize behavior change—simple. Consistent, new “desirable behaviors” that deliver value and reduce risks, wasted effort and costs—simple. This sustainable behavior change demands a change in mindsets and beliefs; it also means unlearning old ways of behaving—not so simple. This requires feedback and correction.

Start with the ‘Why’

Changing mindsets relies on the right messaging. Understanding the “why” and the “purpose” is seen as a critical factor in changing mindsets and ultimately behaviors. The right messaging is not just in terms of words, but also in terms of behaviors, such as people “walking the talk” and “leading by example.”

Desirable behaviors are about people doing the right things. Doing the right thing implies making the right decisions; for example, prioritization of work. To be able to make the right decisions requires having the right information, such as mentioned above—the why. Knowing and understanding the why helps underpin decision-making and prioritization. However, we see many teams that do not fully understand the why behind new ways of working. Somehow the message did not arrive. Somewhere in the flow of information the “why as a justification” ended up as the “why as a question.”

This made me realize that information and behavior flows through an organization. I decided to look at many of the challenges organizations face when adopting new ways of working, by using the Three Ways of DevOps.

The First Way: Flow

The First Way of DevOps is all about the flow from left to right, understanding the flow of work, seeking to increase the flow and never passing a defect downstream.

Understanding the Flow

The messaging I mentioned above flows through the organization traditionally top-down and bottom-up; with the shift to Agile ways of working, this flow is through the end-to-end value stream. This flow is upstream and downstream: Downstream is the flow and hand-offs; upstream is feedback.

I mentioned above that desirable behavior is related to making decisions. If we consider the traditional decision-making authorities in an organization, we have from left to right: strategic, tactical and operational decision-making. This can be seen, for example, as the CIO and business management team (strategic decisions), e.g., product portfolio and key goals; product owners and IT delivery managers (tactical decisions), e.g., product backlog, IT changes; teams and employees (operational decisions), e.g., sprint planning, incident prioritization.

The importance of decision-making was also confirmed in a recent Forbes article, “The Netflix Decision Making Model Is Why They Are So Successful.” Netflix’s desirable behaviors are driven by a set of corporate values. The first value is judgment, which “outlines the company’s decision-making ways and accompanying expected behaviors. Notably, Netflix encourages its employees to ‘make wise decisions despite ambiguity’.”

Every so often, it is decided to embark upon an Agile transformation at a strategic level. This decision is communicated throughout the decision-making levels as an intent—usually the why is vague and left open to interpretation. A set of values or principles are also communicated, such as customer-centric, end-to-end responsibilities and continuous improvement. However, these usually are not translated into desired behaviors. An implied set of behaviors are linked to these values and principles, and can end up being inconsistent with the original intention. This miscommunication of the why and the desired behaviors downstream is a form of a defect—often causing assumptions, driving poor decisions and resulting in undesired behaviors.

For example, as a frustrated senior level manager complains that teams won’t take ownership and frustrated teams protest about lack of empowerment, desired behaviors were not defined and agreed. As a result, they were not displayed, waste occurred, frustration, delays, lack of return-on-value from the effort and behaviors spent.

Another concept of flow is constraints—constraints stopping or slowing down the flow. In terms of behaviors, a constraint could be attitudes and beliefs (not understanding or believing in the new behavior), lack of skills or ability to perform the behavior and allocation of time to learn and experiment or improve behaviors. So, not only must we ensure that we do not pass defects downstream, we also must ensure feedback can identify constraints, impediments and barriers that are stopping the right behaviors from flowing smoothly through the end-to-end stream.

Other types of constraints could be ignorance, indifference, confusion, fear, uncertainty, doubt—or, as Mike Orzen said in a discussion, focus, attention and trust.

So, on one side we have:
- Intent, implied, assumptions and inconsistent behaviors flowing from left to right (cause), meeting….
- Indifference, confusion, fear, uncertainty, doubt, lack of trust etc. (effect)—you get the picture.
- A management solution to this is then to tell people to collaborate, or to tell people they are now empowered—again, without defining the associated behaviors.
“… Application delivery is a set of very human-oriented tasks, a key factor that determines the speed to value is trust,” wrote Carmen DeArdo in his latest book, “A Leader’s guide to Digital Transformation,” co-authored by Jack Maher. “As teams lose trust in the validity of the work as it flows through the lifecycle, a large amount of rework and waste is introduced.” he wrote. Trust is probably one of the biggest enablers or barriers to the smooth flow of behaviors through the system.

The Second Way: Feedback

The Second Way of DevOps talks about shortening and amplifying feedback right to left so that corrections can be made. One form of this is giving feedback when poor information is passed downstream or undesirable behaviors are displayed, enabling us to correct the messaging and the behaviors. Inconsistent messaging, in the form of managers giving conflicting signals or failing to “walk the talk,” are forms of defects. A commonly chosen ABC card (Attitude, Behavior, Culture) in global workshops is, “Don’t do as I do … do as I say.” However, if there is a culture of blame or a lack of safety associated with giving feedback to correct defects in behavior, then feedback isn’t given. Undesirable behaviors and inconsistent messaging goes unchecked.

Failing to stimulate and act on feedback is another form of defect. This means undesirable behaviors continue to occur. All these behavioral defects create cultural and behavioral debt. As this debt accumulates, the ability to deliver value diminishes. In response to this, managers often revert to old management and control styles of behavior (cause), creating more resistance and reducing the willingness to give feedback or experiment (effect). Again, examples of passing defects downstream and creating more barriers and impediments to the flow of desired behaviors.

As suggested in DeArdo’s book, “Feedback should be treated as though it were the most precious of our resources, because it is.”

The Third Way: Experimentation and Learning

The Third Way of DevOps is about continuous experimentation and learning—recognizing that repetition and practice are the prerequisites to mastery.

Agile ways of working are still relatively new. DevOps is still evolving. Old management styles and models are no longer fit for purpose in this new world. Leadership in this new world is also characterized by experimentation. As one CIO stated, “Leaders are expected to walk the talk, but we don’t know what that looks like in this new model.” Leaders often fall back to an S1 leadership style—which is in conflict with the culture associated with Agile ways of working. Poor leadership styles and behaviors, as mentioned above, are also a form of defect—more behavioral debt.

Feedback becomes even more important to validate experimental approaches and to learn and improve. However, the Third Way also stresses the need to allocate time for the improvement of daily work. We sometimes see impediments on team backlogs, but we don’t see behavioral or cultural debt as a backlog item. We don’t see this on the backlog of management teams’ behavioral debt, either. Teams often are frustrated with a lack of time reserved for technical debt, impediments or improvement work—let alone behavioral debt. As Orzen stated, “Even more important than daily work is the improvement of daily work.” Continual learning and improvement should be core skills and behaviors.

As stated in the Third Way, repetition and practice are prerequisites to mastery. There is nothing new about this. It isn’t that the DevOps movement came up with this “new” philosophy: Aristotle, around 300 B.C., stated, “We are what we repeatedly do. Excellence, then, is not an act but a habit.”

We need to practice and repeat behaviors until they become habits, or culture—like “the way we do things here.” Practice also requires feedback to validate improvement gains as a result of practice.

Top athletes practice with the guidance and feedback from coaches. Scrum and Agile coaches are often assigned to Agile and DevOps teams as they practice and grow. These coaches are skilled in training on Agile and DevOps tools, such as standups, retrospectives, value stream mapping, Kanban and Kaizan. But what we see globally is that not all coaches have behavioral management skills.

Another form of feedback from practice is measurement. In terms of DevOps, teams measure metrics such as number of releases—successful releases. We don’t often measure the behavioral change. We can measure the frequency and decisions from standups, but can we measure giving feedback, confronting undesirable behavior? One small example I use is measuring the amount of “yehbuts”—yes, but!—in a dialogue, or worse still, “yehbuts” before somebody has even finished talking. This is an example of a communication defect. Another example is assuming that we understand what somebody has told us without confirming if what we believe we heard was the actual intention.

Communication defects are a major barrier to successful flow of information. Another measurement needs to be related to the impact of behavior change, such as improved customer and employee satisfaction and less rework because of assumptions. Although measuring the actual impact is difficult, having the dialogue itself is valuable: How is what we are doing adding or reducing value to the team and to the organization?

Conclusion

If we want desirable, consistent behaviors focused on creating high-performing teams, we need to look at how messaging and behaviors flow through the system and recognize defects we are passing downstream. Our vague intentions need to be quantified in terms of desirable behaviors. We need to build in feedback mechanisms to signal defects and undesirable behaviors. We need to identify the constraints and impediments that may be causing undesirable behaviors such as fear, uncertainty, doubt—behaviors that may be slowing down or stopping our transformation to new ways of working. We need to recognize that experimentation and practice is needed—knowing that we will struggle and fail, but ensuring we learn and improve as an end-to-end capability. Leadership skills, styles and behaviors need to be aligned to facilitating the three ways of behavior flow. Finally, remember there is really nothing new about this.

Case

In a Phoenix Project simulation, after recognizing the above defects, a team posted the strategic portfolio and goals on the visual management board. The CFO explained these goals and why each backlog item was prioritized against value creation (benefits and value to be realized)—an example of clarity of the why. At the same time, the CFO displayed the right behaviors—being at the standup to explain to the team and ask for direct feedback and understanding.

At the same standup, the CISO and IT team explained the potential “value leakage” backlog items in terms of debts, risks and defects, so that together—business and IT—could make the right decisions on prioritization.

“This made me realize,” said the product owner, “I was now able to make a better-informed decision, because of the team’s input on value leakage—giving feedback from the usage of the applications and the negative impact. It also gave me more trust in the team as they demonstrated an understanding of the ‘why’ and had a clear understanding of value. If, as a team, we did not fully know or understand the value, this created a great dialogue to explore it and ensure we didn’t pass a ‘defect’ (wrong decision on prioritization downstream).”

The team in the simulation learned that as well as visualization of impediments on their backlog, they also needed to visualize the behavioral defects that needed work on and allocated time.

— Paul Wilkinson
March 22, 2019
SRE: How Do You Get to Blameless?

Site reliability engineering (SRE) is the companion to DevOps. If we take my normal divisions of DEVops versus devOPS, traditional DevOps is mostly the developer side, and SRE is mostly the Ops side. This isn’t a perfect comparison, but it is a good starting point, and for this blog, I’ll run with it.

While DevOps focuses on getting releases out consistently, quickly and with minimum disruption, SRE focuses on putting those releases into a robust infrastructure. Tracking application issues, regardless of whether you’re using DevOps, always requires information about the software and hardware infrastructure. SRE takes the proactive steps to try and make sure the environment is stable and designed to host the applications being thrown onto it. When that process fails, SRE attempts to identify the code/architectural problem and resolve it without blaming staff members—hence, the idea of “blameless.” It’s about the environment and improving it, not about the individual and punishing them.

There are a lot of interesting parts of SRE that most IT groups could look at and see as a good place to start taking advantage of. Closely tracking errors in a cross-section of IT interest areas—by application, by infrastructure, by toolset—means problem areas can be definitively identified and fixed. But there is more behind SRE. In this example, once tracking of where errors occur more frequently is in place, a selective reduction in deployments using that piece of the IT puzzle can go into effect until the issues are resolved. This is not unlike what we are doing today, but it is formalized and has measurements around it that generally are not in place.

Which brings us to Blameless, a company that just came out of stealth to champion SRE. While some large organizations with large application footprints are using SRE already, Blameless is offering a platform to make SRE more accessible to companies without large staff and application footprint.

We took a bit of time to talk with Blameless last week, and their vision is a strong one: Address directly what DevOps addresses more indirectly. Build and environment that can measure and improve the entire application ecosystem.

If nothing else, the idea of error budgets is intriguing. Counterintuitive at first glance, the idea of saying, “Piece X gets Y amount of issues before we start backing off of it or raise the priority to fix the underlying issues,” is a solid one.

If your organization is looking for a mechanism to improve reliability and stability while reducing time to resolve issues, SRE in general and Blameless specifically are worth a closer look.

— Don Macvittie

March 21, 2019
5 Practices That Will Help Drive Successful Robotic Process Automation Deployments

Enterprises have begun to invest considerably in robotic process automation (RPA) in recent years. RPA is one of the critical technologies that enterprises now are leveraging to automate their business processes to make their businesses more agile and efficient. When properly deployed and managed, RPAs can automate everything from mundane tasks (such as organizing files) to more significant functions, such as user provisioning to resources and more.

While RPAs do promise to help businesses move more quickly and with more agility, a company’s RPA strategy needs to be executed effectively across the organization. In my recent discussions with CIOs and others implementing RPA, the following practices repeatedly were mentioned as essential to RPA success.

Understand the Process Being Automated and How RPA Impacts Other Operations

One of the most common mistakes made is not thoroughly understanding the process being automated and the potential implications of automating the process. An example would include a business process that is time-sensitive and automated, which throws off the workflow timing. It’s possible the automation moves things along too quickly.

Another example would be not taking into consideration the nature of the data being accessed. If it’s regulated or sensitive data, there are security implications that must be managed. If the bot potentially will process sensitive or regulated information, the bot should be controlled appropriately. RPA technology is an IT function, and at the very least IT and security should be made aware of and potentially involved in the oversight of the bot. It’s much better to inform them and bring them in early than them finding out later about an army of bots managing and manipulating information.

Consider Refining the Process Before Automating

After the process being automated is understood, evaluate the process for potential optimization. Sometimes processes that have been underway in organizations for years are more than just inefficient; they’re actually antiquated. Look for ways the process can be made more effective; consult all stakeholders when necessary or warranted; and consider refining the process if possible. There’s no sense in automating an inefficient process.

Document, Test and Catalog Your RPAs

After the RPA is built, make sure to document its functionality and how its code works and examine its functionality. The RPA is now ready to be used. It’s important to continually monitor the RPA for potential abuse or something gone wonky. Send all the documentation relating to the bot to the IT department.

As the Bot Owner, Know You’re Responsible for Your Bot

Should the bot do something unexpected or unwanted, prepare to answer for it as the bot, or business process, owner. Make sure the bot is managing risk within its acceptable scope and that it’s not given too high a level of access. While you as process owner may have administrative rights to an application, does it make sense for those rights to be transferred to the bot? Perhaps it does, and perhaps it doesn’t. It’s a risk management call and will vary from situation to situation. Just be aware that, as the owner, you also own the risk.

Remember Your Bot May Live Beyond Your Tenure

In one, two or five years from now you may not be in your current job position. It’s essential that the bot is constructed for this eventuality. Beyond the proper documentation and cataloging of the bot mentioned previously, put into place the appropriate identity and entitlement management of the bot. Down the road, someone may want to enhance the bot with machine learning or AI capabilities. For when this happens, it’ll be essential to have the bot well-documented as well as its entitlements well-defined.

Consider Centralizing the RPA Deployment Process

While some enterprises have chosen to undergo organizationwide automation efforts, others are dipping their toes in tepidly with small RPA pilots. Others still haven’t decided on how to incorporate bots within their organization, so it’s happening organically and haphazardly as individuals and departments decide to make a go of it on their own.

If an organization is large enough, it may make good sense to put into place an RPA center of excellence. It will provide a repository of policies and strategies for RPA deployment, help catalog bot capabilities and dependencies and help drive overall RPA efficiency as the organization becomes more and more automated.

These bots are here to stay—in fact, they are going to grow in numbers. Technology research and advisory firm Gartner expects global spending for RPA to reach $2.4 billion in 2022, up from $680 million last year. That’s an increase of 57 percent annually. RPAs help drive efficiencies and remove mundane, low-risk tasks and workflows so that humans can focus on higher value and higher cognitive tasks.

— George V. Hulme

March 18, 2019
Deeper Technical Information with SweetCode and Fixate

I know many of you go right to the article you want to read on DevOps.com without ever visiting the front page. But if you go to the home page and look down in the bottom right corner of the page, you will see a link to Sweetcode.io. Sweetcode is a site run by Chris Riley and the folks over at Fixate.io, offering great deep, technical articles on all things DevOps and more. Check it out.

More importantly, it is the visual evidence of a deeper strategic partnership that we here at MediaOps have formed with Fixate. I have known Chris Riley, the founder of Fixate, for about five years now. Chris has done a great job of developing a deep bench of technical writers who can really deliver the technical viewpoint without the marketing fluff. I know this is exactly the kind of content our audience loves. Not just our reading audience, either—our sponsors are also challenged to create good technical articles for their audiences. Now, we can deliver this either to our sponsors or on behalf of sponsors.

On top of this, we are also going to add Chris’s technical chops and talent to our roster. You will see him hosting webinars, doing interviews at conferences for Digital Anarchist and otherwise engaged with our audience. Chris brings a practitioner/analyst viewpoint to his work that I think our audience will appreciate.

I should emphasize this is not an announcement of an acquisition or merger with Fixate. Fixate will continue to operate as an independent company (which it is). We will just be working really closely with Chris and team there to help bring you deep technical articles and other forms of content that we believe you will find interesting. It is all part of our plan to keep creating and distributing the kind of material that our audience is looking for.

So, go check out Sweetcode. We also will be promoting Sweetcode through our social media and newsletter channels. Stay tuned as we turn up the gas, and we hope you enjoy.

— Alan Shimel

March 13, 2019
Announcing DevOps Connect: DevSecOps Days Virtual Summit

We just wrapped up our fifth annual DevSecOps Days @ RSA Conference 2019, featuring an exceptional lineup of speakers and a variety of informative sessions, providing an unparalleled experience for all. If you couldn’t make it to San Francisco for RSAC or missed any sessions, we’ll be hosting a virtual version of DevSecOps Days @ RSAC Tuesday, April 2.

You’ll hear stories from DevSecOps practitioners discussing how they made the cultural transformation from legacy development and deployment processes to integrated systems that include security as a part of the process—not as an overseer or bottleneck to secure application development.

Similar to the environment we created for the DevOps Experience and Predict 2019 virtual events, DevOps Connect: DevSecOps Days Virtual Summit will feature a virtual environment with a conference lobby, presentation theater, expo hall and more. DevOps Connect: DevSecOps Days Virtual Summit is more than a series of YouTube live presentations; it is a true conference experience, from the comfort of your desk.

Join John Willis, Chenxi Wang, Shannon Lietz, James Wickett and other industry luminaries for a deep dive into the world of DevSecOps. Register now to attend live Tuesday, April 2. Registration is FREE, but space is limited. Reserve your spot now!

[su_button url=”https://devopsconnectdevsecops.com/#join-us” target=”blank” background=”#DC2E2A” size=”5″ center=”yes”]SAVE YOUR VIRTUAL SPOT[/su_button]

[su_divider]

[su_button url=”https://devopsconnectdevsecops.com/#join-us” target=”blank” background=”#DC2E2A” size=”5″ center=”yes”]SAVE YOUR VIRTUAL SPOT[/su_button]
[su_divider]

MediaOps is the company behind technical communities DevOps.com, Container Journal, Security Boulevard and DevOps TV, and events including DevOps Experience, Predict 2019 and, now, DevOps Connect: DevSecOps Days. Our virtual events take place in the industry’s first truly immersive, virtual reality conference environment. More than a series of Google Hangouts, DevOps Connect: DevSecOps Days is a true virtual conference, replete with theaters for each of the keynotes and presentations, a conference lobby to chat and socialize, and a real virtual expo floor with virtual exhibitor stands equipped with video, downloads and even swag for attendees.

Follow us on Twitter at @devopsdotcom and @securityblvd for event updates. Use the hashtag #devsecopsdays and let us know if you are going!

— saleem

March 12, 2019
Got DevOps Skills? A Look at the Upskilling: Enterprise DevOps Skills Report
IT recruiting is at an all-time high and organizations want T-shaped professionals with cross-functional skill sets to join their teams. While “T” represents an individual’s core competency, and the top of the T represents a broad range of related knowledge, there has been little clarity on which skills are the most important across a wide spectrum of possibilities—until now.

DevOps Institute launched the Upskilling: Enterprise DevOps Skills survey in 2018 to focus on the human element of skilling. The feedback from more than 1,600 individual responses echoed the notion that regardless of vertical, organizational size, geography or role, DevOps practitioners need data-backed skilling statistics. As the focus within the enterprise, DevOps community shifts from “What is DevOps?” to “How do we do DevOps,” this demand is more crucial than ever. After all, “how to” requires “know-how” and “know how” requires a new set of skills. But which skills?

According to DevOps Institute’s Upskilling: Enterprise DevOps Skills Report:
- Soft skills and technical skills are equally important
- IT operations knowledge received the most “must-have” votes as a functional skill in DevOps
- Cloud and analytical knowledge are the top technical skills
- DevOps Engineer emerged as the most popular job title (see below for figure N=812)
N=812

The report was developed in partnership with veteran research analyst Eveline Oehrlich, formerly of Forrester Research. This comprehensive data provides indications of which functional, process, technical and automation skills are “must-have,” “nice to have” and “not important.”

This is particularly significant for IT professionals who are confused about where to focus their personal skills transformations in their journey toward the “T.”

Should developers work on upskilling their testing, automation, process and/or security skills? Should operations professionals learn to code, test or explore more about machine learning and AI? What about project management and systems administration? The Upskilling: Enterprise DevOps Skills Report can be used as a snapshot of critical enterprise skills that are important to successful digital transformation.

The Upskilling: Enterprise DevOps Skills Report was released March 4 and is now available for download. On behalf of Platinum Sponsor Electric Cloud, Gold Sponsor CloudBees and Silver Sponsor Lenovo, industry influencers and international DevOps community, we hope this data will help shrink the skills gap and support the transformational goals of both individuals and organizations. We’re already looking forward to the launch of DevOps Institute’s Upskilling: Enterprise DevOps Skills Survey 2020 to continue meeting the demand for ever-evolving skilling trends in the DevOps community—stay tuned!

— Jayne Groll
March 11, 2019
ITIL V4 Foundation Embraces the Agile Manifesto with Teamwork as a Core Value

The Feb. 28 release of the ITIL Foundation ITIL 4 Edition book is proof positive that other service management frameworks have impressed the folks who brought the latest iteration of ITIL to fruition.

ITIL V4 proves to be significantly different than previous generations of ITIL and embraces many of the core values found in frameworks including Lean, Agile and DevOps. Ideologies such as embracing value, fostering collaboration and adopting what ITIL V4 specifies as a four-dimension model bring a holistic approach to service management. The four dimensions are classified as people, products, partners and processes.

Perhaps the biggest challenge in creating ITIL V4 was moving from traditional process-led delivery advocated in ITIL V3, to a best practices approach of focusing on co-creating value collaboratively between the organization and stakeholders. A change that potentially impacts ITSM, development, operations, business relationships and governance.

“We worked with 12 lead architects, 61 authors and reviewers and hundreds of practitioners from the wider IT industry,” said Mark Basham, CEO at AXELOS, the organization responsible for ITIL. “In addition, our ITIL Development Group has more than 2,000 members from all over the world. This huge collaboration has now produced a framework that will support practitioners and organizations, to meet the challenges that come with the Fourth Industrial Revolution.”

At first blush, ITIL V4 seems to reiterate what many other frameworks already espouse. However, ITIL V4 does bring some other ideologies into play.

“One big change with ITIL V4 is the focus on value, where value is more than just a desired outcome but also something that is co-created by all involved. That ideology fuels collaboration and breaks down silos. The shift to focus more on the customer experience demonstrates achieving value, establishing the value chain as a foundation,” said Nancy Van Elsacker Louisnord, President of TOPdesk USA, an Orlando, Florida-based developer of service management software. “ITIL V4 actively embraces some great concepts out of Agile and DevOps, exemplified by the guiding principle of progress iteratively with feedback. The ITIL4 service value chain looks very similar to what we see in DevOps and actively encourages an iterative approach.”

However, with ITIL V4 seeming to borrow from other ideologies, one may wonder how much value remains in the ITIL framework.

“Partners and suppliers have been added as a fourth dimension, next to organizations and people, processes and value streams, and information and technology. It is an addition that accounts for the reality of increased outsourcing, and the challenges that come with that,” said Van Elsacker Louisnord. “The dimensions play an important role in the 34 ITIL practices that have replaced ITIL V3’s 26 processes. While in essence they haven’t changed much, ITIL V4 takes those four dimensions into account in every practice, making practices much more practical than the processes of the past,”

While many questions still remain around ITIL V4, the writing is on the wall that Agile ideologies are becoming the norm, and DevOps-orientated development brings forth certain advantages. ITIL V4 must co-exist with other frameworks to bring value into best practices and adaptable frameworks. More importantly, ITIL V4 is being set up as a framework that can enhance other ideologies, while helping to preserve the investment that hundreds of thousands of IT professionals have made in ITIL.

— Frank Ohlhorst

March 8, 2019
DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

In this DevOps Chat we speak with Cyara CEO and co-founder, Alok Kulkarni, about how DevOps is helping in the customer experience arena. Cyara has carved out a leadership role in bringing DevOps to CX. Alok is a delight to speak with and very wired into this space.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Alok Kulkarni, CEO and Co-founder of Cyara. Alok, welcome to DevOps Chat.

Alok Kulkarni: Hey, Alan. Great to be here.

Shimel: It’s our pleasure to have you here. So, Alok, let’s—before we jump right into what I wanted to talk about today, I think the first thing we should do is a little level set. Maybe we have some folks who are familiar with Cyara, maybe we have some folks who are not. Why don’t you give us kind of a quick background on Cyara?

Kulkarni: Sure, Alan. So, Cyara is a customer experience assurance platform, which allows customers to accelerate their CX development right from the design through to testing and all the way through to customer experience monitoring for customers’ journeys end to end.

And so, what’s different about us is, we support the entire software development life cycle from the design through the functional integration testing right through to user acceptance testing, including load testing and production monitoring. And, in the CX world, we’re able to do this from an end customer perspective across all the different channels that the customer might be interacting with the organization. So, that’s just a brief summary of what we do.

Shimel: Sure. And you are the Co-founder and CEO.

Kulkarni: Mm-hmm.

Shimel: And just, while we’re here—

Kulkarni: Yes, and—

Shimel: —give us a little bit of your own personal journey. How did you come to be the co-founder and CEO at Cyara?

Kulkarni: Sorry, go ahead.

Shimel: Oh, I’m sorry. I was going to say, if you can give us a little bit of your own personal journey, how did you come to be the CEO and Co-founder of Cyara?

Kulkarni: Oh, great question, Alan. Sorry, I lost you there for a bit. I was working at another software company, which is currently the leader in customer experience management technology, and one of the things I found in those days—this was in the late 2000s—was, every time we put the technology in production, the customers, the end customers used to deal with this new technology and the enterprises would be sitting there with white knuckles hoping and praying that it would all work—because there was no platform in those days which would enable them to test and monitor the technology that they were putting in for the customers from the outside in. So, essentially, it was like playing Russian roulette.

So, I felt, being an architect at this company and managing the solutions engineering group at this technology company called Genesys that, there had to be a better way. And one of the—the idea came to me when we were rolling out a large implementation for an Australian government organization when it failed. I thought that there must be a better way of doing this.

So, hence, I felt—imagine if there was a cloud-based platform that was technology agnostic which enabled enterprises to just use and simulate customers from the outside in to be able to test and monitor, not only the infrastructure, but the applications from an end to end customer journey perspective. It would really take the risk out of deploying new and innovative solutions in the market. And so, that’s how it all happened. So, I got together with my buddies and we built Cyara.

Shimel: Excellent. So, you know, in so many ways, there’s so much DevOps there, if you will, Alok. And first of all, the idea of—and we see this in security, we’ve seen it with other forms of QA—the idea of waiting ‘til after something is deployed to see if it works or not, you know, that white knuckle moment? Why?

Kulkarni: Mm-hmm.

Shimel: I mean, why, in this day and age, do companies still want to do stuff like that, right? And this is, especially when we talk about sort of the modern software factory and CI/CD pipelines and so forth, right? We shouldn’t let software out there that hasn’t been fully vetted and tested. Why would we let software and things in the wild, where we haven’t already tested what our customer response, and our customer experiences are going to be and whether they will work?

It just seems like such a no-brainer. Why do you think it took so long for people to come to this realization?

Kulkarni: So, I think that’s a great question, Alan. And, you know, when we were sitting there noodling on whether we should start this, I remember going to my co-founder, Bonny, and asking him, “Hey”—because he wasn’t from the industry, and when we came up with this idea, he goes, “Surely, there’s somebody doing this.” Because it’s exactly what you said—it’s a no-brainer. And I said, “No, there’s actually no one doing this.”

And I think the reason for that is, one is, I don’t think people in the—if you’re not in the industry, you don’t even know that this is a problem, that’s one. Second thing is, even if you were in the industry, it is so complex. I mean, there are so many different moving parts, so many technologies. Then you have enterprise processes and systems and systems integrators and so forth.

So, by the time you’ve put that whole, all those components together, it becomes very difficult to build something simple that would solve these problems. So, when we did it, it just took off. And now, like you say, I think customers are realizing that there is a technology or a solution out there that can help them. So, we’ve had a tremendous, I guess, following of customers who actually just continue to expand what they do with Cyara and we’re signing new customers on as we go along.

So, just this last quarter, we signed about 25 Fortune 500 companies to our platform. So, I think it’s catching on, and now, what we’re seeing is the next wave, like you mentioned, this whole DevOps wave that’s really taking firm hold in the way that more and more organizations are putting out a software or capability. And I think in the CX world, that’s changing as well. So, I think, we’re also creating awareness that you can bring DevOps to CX and although the tool set might be a little different, you can actually do it. So, we’ve had a tremendous amount of traction in the market with that.

Alan Shimel: Absolutely. You know, Alok, it talks to something else that we’ve seen in DevOps. When we first started DevOps.com on March 11th of 2014, I think it was, so it’s almost five years now—the whole, “What is DevOps?” argument was raging. And there was a large percentage of the community that had a very orthodox view of DevOps, that if it wasn’t purely about software development and deployment in terms of operations and APM, it wasn’t DevOps, right? That’s what—there was a very narrow definition of DevOps.

We’ve seen that expand, right, to what I call DevXOps now.

Kulkarni: Mm-hmm.

Shimel: We’ve seen DevSecOps, we’ve seen DevBusOps, we’ve seen DevSalesOps. It’s really taking that DevOps mindset that DevOps can do and applying it to everything.

So, really, we’re almost seeing here DevCXOps, right, if you will.

Kulkarni: Yeah, totally. Yeah, I think we are in that era now of DevCXOps, just like you mentioned. Because, just like software organizations were putting out new capabilities in a rapid manner, I think customers were expecting customer facing technologies, and the way they’ve been—the way that they’re interacting with organizations to change rapidly as well. Because everyone’s time poor, they need the answers as soon as something goes wrong or if they want to buy something, they’re impatient, because we all have things to do and we’re on 24/7.

So, it’s imperative for companies providing customer experience to keep up with that. And I think DevOps provides a great framework to do that, and it’s aligned so, as you say, if you’re already in DevOps and the digital world, you can bring it to the CX world. And I think it’s really catching on.

Shimel: I don’t disagree. I think another thing, Alok, and you hit on it there, is customer expectations. You know, one of the sort of forgotten heroes or the forgotten catalyst behind all of the DevOps kind of movements is what really—people don’t go fast just to go fast. Well, maybe some do, right? There are speed freaks, right? [Laughter]

But, you know, people who adopt agile DevOps and these sorts of frameworks and methodologies do so to be more responsive to customers. And that’s really—and it’s nitty-gritty. That’s what it’s about. Because that’s why companies do things, to serve their customers better. And that’s really the guiding principle behind CX as well, right? How do I respond to customers better, especially in a world where customers demand more? They want 24/7 support and response, and they want it right away, and they want it now and they want it to work, right? There’s a low tolerance if your cellphone coverage is not good, or your internet—as we spoke about—your Internet at 30,000 feet on a plane is not working, and people get really upset about that now. And in so many other ways, customer demands are driving this. Correct?

Kulkarni: Yeah, totally. And you know, what’s sad is, we’re fickle. You know, we’ve been conditioned to now have choice. So, if we don’t like the service a particular company is offering, you know, we switch, and switching is so easy, because it’s very easy to find another provider who provides a similar service and offering and then if they have a better customer experience, you think when you actually have that moment of need where you actually need help and they’re providing it to you promptly and they’re resolving your issues quickly and they’re doing it how you want to be treated, maybe it’s a late night chat or a phone call because it’s super urgent or it’s complex. Or maybe it’s like, “I don’t want to talk to anyone today, but I need the information for my support, because one of these technologies that I’ve got isn’t working, so I need a knowledge base that I can refer to.”

Any of these customer-facing technologies play a very important part in customer loyalty and thereby, shareholder value for the company that they’re dealing with.

Shimel: Agreed, agreed. So, Alok, if you don’t mind, I want to talk a little Cyara—I’m sure you don’t mind. [Laughter]

Kulkarni: [Laughter]

Shimel: So, do you offer this as more of a Platform as a Service or as a SaaS based offering?

Kulkarni: Yeah, it’s a SaaS-based offering, so we have a cloud infrastructure environment which spans, which goes across the globe. Just last year, we placed 4.4 billion call seconds’ worth of synthetic interactions to assure customer experience around the world, and some of the largest brands of the world use it.

So, some customers, they use our platform to provide the whole design experience—like, the design, the customer experience in Cyara is able to, as a result, get a full automation and regression test suite that they can run as part of their DevOps factory, and then we have a real time customer experience monitoring platform.

So, for example, if you put something out in production, our platform actually is able to generate synthetic customer interactions from the outside in. So, we can actually emulate, Alan, contacting an organization on your behalf and actually see what experience you’re going to get, whether your interactions or your calls connected on time, whether the web chat gave you the right responses, whether the screen froze or not, and you can do this all in real time.

So, customers have a direct feedback loop that they can implement. So, as soon as something goes into production and it doesn’t work, before a real customer is able to have a poor experience, we’re able to detect it early on and the customers can then roll back the technology that they had implemented and then roll the previous last known good version out so that they maintain the sanctity of the customer experience.

So, it just—to me, that just goes hand in hand with the whole DevOps paradigm.

Shimel: I agree. It certainly does. So, Alok, if I ask you to kind of peer into your crystal ball of the future, where do you see this going now?

Kulkarni: So, as you mentioned, Alan, there’s a lot of companies out there who are not even aware that they can apply the whole DevOps—they can bring CX to DevOps and, as you call it, DevCXOps, and make it happen. So, I feel, over the next two years, we’re going to see a tremendous wave of customers adopting this framework, because they’ve already done it on the digital side and the CX side tends to be—I think they’re in an adjacent area and I think they are moving to this new model.

So, we’re going to see a lot of customers offering it, and I think we’re going to see a lot of new, innovative technologies coming out with integrated solutions for that. So, I think for Cyara, we want to support our customers as they go on this journey. So, we’re integrating with a number of platforms out there that enable the whole CX DevOps pipeline scenario. For example, we’ve just integrated with Splunk, we’ve integrated with ServiceNow. So, in Cyara, you can actually get real time incident notification of any technology that you’re implementing and automatically create service requests so that you’re able to keep ahead of the whole customer experience pipeline.

And the other thing that we’re doing is also investing heavily on the design aspect of it. So, we’re working with companies like Amazon and so forth to offer a platform that is able to take customers that are moving to the cloud or moving to cloud contact centers, which is becoming, which is a new wave that’s still catching on and enable them to essentially drive this whole assurance through to all their customers.

Shimel: Excellent, excellent, excellent. Well, Alok, as we—I think I told you before we started, the time goes really quick. We only have a few minutes left. I wanted, also, I’d like to finish up with kind of wrapping this whole thing back into the DevOps, back into what Cyara is seeing from customers.

Companies I’ve been involved in, and I’ve founded a few, you know, we had sort of a customer support, a customer help team. It was separate from developers, it was separate from Ops. It was part of the engineering team, but it was almost a red-headed stepchild within that engineering/IT team. Is that still the case? Is that a problem? Is that something Cyara runs into when you’re talking to folks? What’s the story?

Kulkarni: So, I think you, again, Alan, are right up there with it. So, I think one of the decisions organizations that we deal with are grappling with is, do they make engineers who understand software and make them CX developers, or do they make CX developers who have real code domain expertise and bring them onto the DevOps world?

And I think that’s a question a lot of companies are asking themselves—like, do we need to really understand this space from top to bottom, or do we get developers? Is it easier for developers to learn this versus the other way around?

And I think that’s currently in the experimentation stage. So, a lot of companies who have tried the old model feel that it’s just very hard to change the mindset of the old engineering folks to—you know, who’ve been traditionally used to waterfall and doing large scale implementations and using systems integrated to put those out to really just come onto this whole new, you know, go fast, break things mentality versus getting those guys to understand CX.

So, I think there are two horses running right now, and I think we’ll see the results of that in the next year or two. But what I am seeing is a lot of companies trying to get their developers onto the CX world, because they’re finding that that seems like a much easier path.

Shimel: I don’t disagree with you. Crazy. Interesting times.

Kulkarni: Yeah.

Shimel: Anyway, Alok, I know we’re doing some other, you’ve published some more—well, not you, but Cyara has published some nice articles on DevOps.com lately, we’ve done some other activities.

Where else can people find out more information, though, about Cyara?

Kulkarni: Well, they can obviously come to our website, so Cyara.com, that’s C-Y-A-R-A dot com. And I think we have, we’ve built a huge library of resources thanks to our fantastic team that we have at Cyara, and they can also—I think over there, there’s a whole library of collateral that they can view. We’ve got a YouTube channel that they can subscribe to.

And we also have Cyara Academy. So, as part of that, they can go in and if they want to actually get trained on Cyara, we offer that on demand as well. And you don’t—I think there are some courses where you don’t have to pay. So, I think you can, if you’re new to this space, I think it’s a great place to get scaled up, because I think this is a very exciting space. Because, as you’ve said, Alan, every company, to be successful, needs to really deliver a superior customer experience to their end customers and I think it’s just the core of any fundamental for any company to get this right.

So, come on over to Cyara.com and get yourself educated.

Shimel: Cool. Well, Alok Kulkarni, CEO and Co-founder of Cyara, thanks for being our guest on this interview, on this episode of DevOps Chat, and we hope to have you back on again soon.

Kulkarni: Thanks, Alan. Would love to come back.

Shimel: Alrighty. Hey, this is Alan Shimel for DevOps.com, Security Boulevard, Container Journal. You’ve just listened to another DevOps Chat. Have a great day, everyone.

— Alan Shimel

March 8, 2019
Full-Time Employment in the Age of Automation

Back in 1930, the economist John Maynard Keynes wrote a short essay, “Economic Possibilities for our Grandchildren,” in which he predicted that in a hundred years the 15-hour work week will be commonplace. Keynes made this assertion based on two factors: first, the increase in capital due to extraordinary yields from the compound interest that was made possible by increased foreign (global) investment; second, the growth of technological achievement made necessary by the competitive forces of capitalism and made possible by the availability of excess capital.

Keynes pointed out that these events are recent in terms of the entirety of human history, taking place over the last 500 years. Before that time, things were stagnant. Gold reserves remained static until the opening of the New World and technology, save for a few episodic breakthroughs, was pretty much unchanged. For example, the way cloth was made during the time of Joan of Arc, around 1400 AD, was not that different than the way it was made when the Roman emperor Hadrian had a wall built across northern England in 100 AD.

But, the growing availability of money and technology changed everything. By 1920, the more affluent in the population wore factory-manufactured clothing bought in a store. Those of lesser means might still be making clothes at home, but the cloth from which the garment was made came from a factory.

Mass-market capitalism powered by technological innovation increased human productivity on a scale unique in the human experience. Abundance on a global scale seemed a real possibility within a few generations. According to Keynes,

“If capital increases, say, 2 percent per annum, the capital equipment of the world will have increased by a half in 20 years, and seven and a half times in a hundred years. Think of this in terms of material things—houses, transport, and the like.”

Yet, today most people work 40 hours a week, if not more. Considering that Keynes was essentially a quant who lived and breathed data, how could he get it so wrong?

My thinking is not so much that Keynes got it wrong, but that we’re having a hard time accepting that he might have gotten it right.

Allow me to elaborate.

The Facade of Productivity

I have a theory: For the average contributor-employee in a medium- to large-size corporation (with 500 employees and more), of all the tasks he or she performs during a 40-hour week, only about half—20 hours’ worth—actually add value to the enterprise. The rest is organizational overhead. Thus, there is a good argument to be made that when you do the math, what we can call real full-time employment is closer to Keynes’s prediction of the 15-hour work week than not. The remaining time, which I call “organizational overhead,” is really just a facade of productivity.

This theory occurred to me a while back, when I was sitting in a sprint planning meeting observing a project manager and tech-leads do task assignments. The first thing the project manager did was to determine how much time each member of the project team had available to work on the project’s tasks. The agreed-upon number was 20 hours a week.

The 20-hours a week number struck me as strange. All members of the project team were completely dedicated to the project. They had no side work. The project was their one and only focus. What were they doing with the other 20 hours?

I asked the project manager and he answered, “Well, they have to do things like answer emails, go to meetings and sometimes there’s some firefighting to be done.”

Oh.

The Amazing Ability to Absorb the Cost of Organizational Overhead

I wish I could say that the project manager’s response was unique. But, in my experience, it’s not. I’ve been in more than one company in which meetings, email and firefighting occupy at least half of a full-time employee’s work week. And, I’ve got to tell you that, except in the rarest instance of mission-critical firefighting, most of these situations have marginal productive value.

Granted, my theory is based on experiences that are anecdotal. The actual numbers might prove me wrong. Obviously, a thorough, quantitative study is needed. Still, whether it’s five, 10, 20 or even 35 hours a week, what’s amazing is not that employees spend a lot of time in activities that have questionable productive value, but rather, that businesses can actually operate profitably despite these ongoing time-sinks. Why? Because of automation. Machines and software are allowing people to do more work in less time—and it’s not only confined to IT.

The Dirty Little Secret of Working on an Assembly Line

Doubling up has always been the dirty little secret of automotive factory work. Ben Hamper revealed the details of technique in his 1986 book, “Rivethead: Tales from the Assembly Line.” Here’s how it works: Imagine that you and I work in a GM plant and do jobs at the same location on an assembly line—say, putting headlights and taillights in a car. Your job is to put in the headlights; my job is to put in the taillights. One day I notice that I can probably put the headlights and taillights in a car in the same amount of time it takes two of us to do the tasks separately. So, I propose a deal to you: I’ll do your job and my job for four hours a day in exchange for you doing the same for me. This way we can both work half time for full-time pay. We might have to pay the line foreman a small bribe to look the other way, but what the heck? The benefits are obvious, so we do it. Win-win, as the saying goes.

How can we pull this off? Simple: as stated earlier, automation.

Without the technology of the assembly line, we just couldn’t double up. The car needs to be brought to us for us to increase productivity to the point where one person can do the work of two. The automation of the assembly line effectively reduced our work week while maintaining our productivity, just as Keynes predicted.

As you can see, the 15-hour work week is quite possible—and, in many cases, quite real. It’s just that the facade of productivity, which exists in larger companies, hides its existence. But, what about the smaller companies such as construction companies, law firms, small manufacturers, dental offices and software startups that employ fewer than 100 people? These types of companies cannot afford a lot of non-productive activity. How do these companies get to the 15-hour work week? Is it possible?

My answer is yes, but the world that will need to exist to make the 15-hour work week possible will look dramatically different than the one we have today. What will that world look like? Allow me to illustrate using my neighborhood cafe, the C&M, as an example.

The Real Implications of the 15-Hour Work Week

My favorite neighborhood cafe is the C&M. It’s a hangout sort of place with good food, good coffee and Wi-Fi. The C&M is usually staffed by two employees during its business hours—7 a.m. to 5 p.m., seven days a week. Between them, they take orders as well as make the food and deliver it to the tables.

Let’s do the math. Let’s figure that the actual working day at the C&M is 12 hours—10 hours of operation time and two hours of setup and cleanup. That comes out to 84 hours a week. Thus, excluding the owners’ time, the number of employee hours needed to run the C&M is 168. (two employees at 84 hours a week.) This comes out to around four people required to staff the business using the current 40-hour work week model, again excluding the owner’s time.

Now, let’s say the business is quite profitable and the owner can afford to pay employees $20 an hour, plus health insurance. Adding in payroll tax and workman’s compensation (more than $5 an hour) plus the cost of health insurance ($400 a month, for illustration purposes), the weekly cost of each employee working 40 hours is $1,100, which translates into a total weekly labor cost for the C&M of $4,400.

So far, so good.

This time, let’s interpret the C&M labor situation in terms of the 15-hour work week. To cover the 168 hours per week that the C&M is operational, at a 15-hour work week per employee, the C&M needs to employee 11 people—actually, it’s 11.2 employees, but I rounded down. So, under Keynes prediction, if each employee is entitled to the established full-time compensation of $1,100 as calculated earlier, the weekly payroll for the C&M goes from $4,400 a week to $12,100—an almost three times increase, which is not an affordable number. Even though the number of employees has gone up, the odds are that the actual sales will remain the same. Instead of having to employ four people producing $14,000 a week in sales—$2,000 a day over seven days, again for illustration purposes—now the owner of the C&M will be employing 11 people to produce the same amount. Bankruptcy is imminent.

Clearly, the C&M cannot tolerate 11 people working 15 hours a week for a full-time wage under current conditions. So much for the 15-hour work week. Well, not so fast. Let’s reimagine the scenario from a different angle: Suppose that the number of employees stays at four, but instead of working 40 hours a week, each employee works 15. What could we add to the mix to make this scenario possible? Give up? OK, I’ll tell you: robots.

Imagine that instead of having two people on hand to set up the cafe, take orders, make the food, bring it over to tables, bus the table and then clean up at the end of the day, we had one person on hand to do what we’ll call human essential work. All the other work gets done by robots. Then, the typical interaction looks like this: Customers enter orders directly into an iPad, the robotic coffee maker gets the order and makes the double espresso, a robot in the kitchen makes the food, with the intermittent help of a human when necessary, and a robot delivers the food to the table. The one human on hand interacts with customers and picks up the slack work the robot can’t do. You can think of the scenario as the restaurant equivalent of a driverless Uber ride.

Is such a world possible? Yes. In fact, it’s happening as you read this article. There’s already a chain of waiterless sushi restaurants in Japan. As the technology drops in price, more restaurants will make the transition.

The 15-hour work week could indeed become a real possibility provided that two conditions exist: affordable robotic technology with a high degree of manual dexterity is available, and the employer is willing to pay the higher wages necessary to support the model.

In the past, workers such as Ben Hamper used their ingenuity to take advantage of the reduction in labor that automation made possible. Sadly, such efforts were clandestine and deceitful. All that GM needed to do to realize a better return on labor was to speed up the assembly line. Yet, when you think about it, back then GM wasn’t doing that badly when Hamper was doubling up. 1984 was a record-setting year in sales, despite his shenanigans. Speeding up the line would undoubtedly increase GM’s bottom line. But, would it double Hamper’s take home? Probably not. (Author’s Note: GM’s sales dropped 26 percent in 1986, but profits were still a healthy $1.06 billion.)

So here are two questions to contemplate: As companies, large and small, adopt robotics to increase productivity, will they indeed share the benefits of the increased productivity with the average worker so he or she can enjoy a 15-hour work week? And then, should the 15-hour work week indeed become standard, what will the average person do with all this newfound leisure? As the saying goes, idle hands make fretful minds. According to Keynes:

“Yet there is no country and no people, I think, who can look forward to the age of leisure and of abundance without a dread. For we have been trained too long to strive and not to enjoy. It is a fearful problem for the ordinary person, with no special talents, to occupy himself, especially if he no longer has roots in the soil or in custom or in the beloved conventions of a traditional society.”

For those of you that think about such things, I will leave up to you to answer these questions. As for me, I can’t wait for the robots to take over so I can go back to my studies, full-time.

— Bob Reselman

March 5, 2019