.shock - Fotolia
Imagine a DevOps engineer named Pat. You're the vice president of engineering, and Pat has been a superstar in your organization for years. She's always pleasant in standups. Any criticism she makes is positive and supportive. She's always reliable when on call, and Pat makes few mistakes.
Then, something changes. She becomes snippy in standups. It's taking her longer to answer emails. Last month, she altered a deployment script that caused the Amazon bill to jump. You sense something is wrong, and suspect a case of developer burnout. So you go to her boss.
Pat's boss reports having a similar experience. Pat, who used to be the poster child for an exemplary DevOps engineer, is dramatically regressing. You're both mystified.
Something is obviously amiss. You ask to see her work schedule over the last year and the tickets assigned to her. In addition, you take a trip to HR and request the budget history of the group Pat works in, as well as the head count history.
As you review the reports, certain facts pop out. First, Pat has not had a vacation in the last year. Also, her last raise was only 3% due to company revenue issues. Half of Pat's past work tickets involved issues related to the new automated container-provisioning framework the company implemented last year. Your suspicions appear correct.
Pat is burnt out. Now, conventional wisdom has a way to prevent developer burnout. Just give employees enough time to rest, refresh and acquire the skills necessary to do the work required of them. This is the route organizations typically take to addressing developer burnout. And this is the flaw: Organizations are addressing the symptoms.
The disease is undercapitalization.
Allow me to elaborate.
No capital? No profit
Capital is anything that enhances a person's or organization's ability to perform economically useful work. Capital can take the form of money, time, machinery, information or real estate, for example. Businesses require capital in order to make goods and provide services. The mistake many businesses make is to not have enough capital on hand to meet objectives. This is particularly true of startups. I've experienced this personally.
Earlier in my life, I wanted to be in the restaurant business. I had the necessary expertise. So, I saved some money and found some investors to pitch in to cover the startup costs and projected operating expenses for a year.
However, my business plan had a serious flaw: I overestimated revenue growth. I thought my cash flow would start to cover expenses within three months of operation. Turns out I was wrong. I was not getting the number of customers needed within the time frame required.
I started to run out of money. I fell behind paying my bills. I had to cut back on staff. I found myself working seven days a week to make up for the staff I had to lay off.
Eventually, the business closed its doors. I was a mess physically and emotionally. Upon reflection, I came to realize I had just run out of time. My customer rate was growing, and the business was becoming more efficient. The shortcoming was I didn't have the capital -- in this case, time -- to meet my objective.
Let's go back to Pat and her developer burnout.
Pat had not had a vacation in a year. She had been given a small raise and was working with technology new to her and the organization. How did this come about?
Pat had not had a vacation in a year because the department is short-staffed. She had been given a pittance of a raise because the company couldn't afford more. And she is struggling with new technology because the company needed to implement automated provisioning in order to meet the growth requirements necessary to stay competitive.
To put it succinctly:
No vacation = not enough staff = undercapitalization
Small raise = not enough money = undercapitalization
Struggling with new technology = not enough time = undercapitalization
The business does not have the capital required to meet its objective. And, thus, burnout sets in.
Ten tech terms the business side needs to know
Scott McCarty, head of technical product marketing for containers at Red Hat, has a handy list of tech terms business folks should know, DevSecOps and CI/CD, if they want to collaborate with the software side.
So, how does a company avoid developer burnout?
The answer is to make sure it meets its capital requirements.
This is easier said than done. Most companies think they have enough capital. Not surprisingly, most companies are overly optimistic, particularly small to medium-sized tech companies that have growing DevOps departments.
These companies get the value of DevOps, but underestimate the capital requirements necessary for success. Many follow the lean startup mentality -- fewer employees using more automation, while getting more back massages at their desks and free food at the snack bar.
Providing automation, back massages and free food are not necessarily the best tactics for ensuring adequate capitalization. Having adequate capital on hand is a continuous activity that requires ongoing, dedicated attention. Just look at AT&T.
AT&T executives understood from its inception that the company was engaged in a capital-intensive business. Its leadership kept raising capital. In the beginning, the capital was needed to lay landlines. By the 1950s, the capital was used to put telecommunication satellites into space. Today, with the acquisition of DirecTV, the company is moving into on-demand video streaming. The company has a voracious appetite for capital, and it's become quite good at acquiring it.
This is the lesson to be learned. Burnout, in general, and developer burnout, in particular, can be traced back to undercapitalization. Undercapitalization is rarely a temporary condition. Rather, it results from of a business failing to plan from the start to ensure its capital needs are always met. This means making sure there is enough money, time and staff to meet the demands at hand. Doing more with less rarely works for a long period of time. Eventually, a company will pay the price. One of the first signs is employee burnout.
We in DevOps know there is no way automation will make bad code better once it's out the door. You need to get a new version out as soon as possible. The same is true of adequate capitalization. Once the symptoms set in, the only way to beat the disease is to release a new version of the business, with plans to continuously meet the business's demand for the capital required to satisfy its objectives.