Tag: Recruiting

Have you ever seen the sign, “Will work for food”? If you deconstruct the premise a bit, we all work for the rewards systems that interests us. We “trade” our labor (ideally, focus our passion), for a set of acknowledgements that range from survival to pride. And ultimately it is our employer (whether the boss or the board of directors) who decides what our rewards systems will be.   That is the common sense part. But when something such as DevOps enters the picture, it alters traditional thinking throughout an organization, and the ripple effects should (and eventually will) reach the HR department.

The most immediate effect of DevOps on HR occurs around talent acquisition. Finding a qualified DevOps engineer that it is possible to afford—and the company can retain—becomes the unicorn of recruiting departments from one coast to the other. The alternative is creating or adopting a training curriculum that can move a traditional programmer or engineer into a fully qualified DevOps engineer. Of course, advice varies on exactly what that is, and if it’s successful, your organization becomes a feeding ground for every other competitor to poach your folks right after training.

Because this HR acquisition problem is so great for most organizations, they can overlook some other underlying issues that continue to occur. These problems have always been there, but DevOps brings a spotlight to them that did not exist prior to its implementation. As stated earlier, we “do” what we are “paid” to do. In organizations that innovate in the software discipline, we have always “paid” that entire division to innovate. Prior to DevOps, the pace of that innovation, was slow and manageable. Once DevOps begins to take hold, the pace of innovation begins to enter the 400mph superhighway, where traditional control mechanisms no longer work.

In itself, the success of the controls over change—transitioning to a high rate of speed—will be determined by how we implement DevOps. It is the other half of DevOps that needs some focus. While our Dev organization is cranking out change exactly as we have always paid them to do, our Ops organization traditionally has been paid for exactly the opposite characteristic. We pay our Ops organization for stability. We want the trains to run, on time. We do not want a 2 a.m. phone call from an angry CEO—or, much worse, an angry customer—because our operations have “broken.” And, of course, the No. 1 culprit for causing breakage in operations is … [drum roll, please] … “change.”

In the yesteryear of Waterfall construction and manual delivery, our Ops teams had time to digest what change was coming, prepare for it, adjust to it and get it implemented smoothly (or at least pretend to). In the current day of Agile construction and DevOps delivery, I might have moved six new builds into production in the time it has taken you to read this article. Ops has no time anymore to digest and prepare for change, so if the quality of that change is not significantly better than it used to be, the angry-phone-call potential goes up exponentially. And yes, there are technical remedies to ensure quality (I will reserve discussing those for another time).

But the tradition of how we compensate remains in place. We comp Dev to innovate, and we comp Ops to remain stable. This makes not only silo thinking, but also mortal enemies during the adoption of DevOps into an organization. All of a sudden, each views the other as potentially causing harm to their ability to continue earning compensation. And they are right to see it that way, as HR has yet to alter the models to create partnerships instead of combatants.

To fix this, the compensation models must be adjusted to pay Ops teams to get involved in the software development lifecyle (SDLC) process from the upfront. The Ops teams should have extensive visibility into the testing cycle of new changes and how that works, and become the organization always asking Dev how it can “prove” its change works. The Ops teams must become the in-process auditors of the Dev teams. This keeps the Ops teams from being compensated for conditions that only exist at the end of the SDLC process, where they feel “dumped-on” by more rapid change delivery. The new comp model for Ops must focus on the number of changes successfully introduced into the production environment (i.e., the quantity of change that works), not just the stability they traditionally maintain.

The Dev team, on the other hand, must begin to be compensated only for after-action success. Dev teams must look at their code after delivery to production—and only if the code is validated (i.e., it works), is adopted by its intended customers (a completely different angle) and performs within expected timing parameters (i.e., it scales well). This becomes the criterion that is the foundation of the Dev team’s measurement of success. This puts an Ops set of glasses on the programmer instead of making him blind to those business issues. The Ops teams become the key advisors to the Dev teams on how to prove quality. And the joint discussions lead to a more sensible monitoring strategy, which is needed across the board.

There’s Compensation, and Then There’s the Bonus

Changing the point of view for the compensation is only a start. Next up: Begin to alter bonus compensation to a more lean model. Instead of large annual bonuses, where the basis for achievements often are colored by my boss’s mood over the last six weeks, organizations should increase the frequency of bonus payouts to match the duration of epic completions—or, if possible, of sprints. The idea is to tie meaningful bonus payouts to the length of time it takes to produce only successful change. If the change works, the company offers additional bonus comp; if not, then the team must improve to secure the next bonus opportunity.

Tie the bonus duration (whether to epics or sprints) to meaningful business impacts. In this way, each contributing employee understands “why” the work he or she offers has meaning to the company or its customers. This kind of bonus system allows for extreme flexibility in the priority of what teams work on throughout the year. Bosses can change priorities or shift them to match what executives see on the horizon. Employees are not tied to some list of annual work accomplishments that in a DevOps rapid world they had little shot of achieving unless they did them in a week. Instead, they have real-world goals, tied to real world time frames, where employees see the reward as they succeed at the work.

Organizations can add even more bonus comp this way if over-and-above work is needed. And “if” organizations compensate both Ops and Dev only for successful change (which implies quality in the SDLC and stability in Ops) they create a new rewards system that enables adoption rather than repel it. Beyond finding the talent they need, organizations need innovative methods of retaining them. Substantial rewards in real time might just be one way to do that.

Finally, being able to see the business impact of the change the joint effort of Dev and Ops teams produce allows for better ability to offer “appreciation” ideas as well. A simple “thank you” goes a long way in employee satisfaction, and when the executive and the team member understand “why” they are being appreciated, they go even longer. DevOps is not just a catalyst reserved to the “techies” who practice it; DevOps is instead a new way of thinking about how a company innovates. This kind of infectious thinking can easily spread to tertiary support organizations such as HR and Legal, if you let it.

To continue the conversation, feel free to contact me.