I started my career as a developer at a worker’s compensation case management company. We wrote software that nurses, who were employees, used to manage worker’s compensation cases in hopes that we would get people back to work quicker and thus lower costs. I had a talented and opinionated boss who gave me a lot of room to learn and grow. It was a great first job.

After a couple of years, however, it became clear that the software I was working on wasn’t seen as increasing the revenue of the company but decreasing its costs. Within this business model, the key operational revenue was coming from the nurses who were managing the cases. I was making the nurses more efficient, but I wasn’t directly contributing to revenue.

In business terms, I was not contributing to the top line, I was contributing to the bottom line. For those of us who don’t handle P&L every day, here’s what that means:

Insurance Companies pay for Case Management (Revenue) - TOP LINE
SUBTRACT Cost of Nurses to Manage Cases (Cost)
MY SOFTWARE Lowers the Amount of Nurses We need (Lower Cost)
Company Investors get money left over (Profit) - BOTTOM LINE

So in this job, I was contributing to the bottom line by lowering the cost of operating the business. This is wonderful, but I quickly realized the downsides to this:

1. There is a ceiling to the financial impact I can have to the company. Within this model, I can only add value to the level that the operations cost. And the further down the road I get, the less efficiency I can extract out of this system. For example, if in the first year it costs $5M to run this group and I make software changes that mean we only need to spend $4M on nurses, I made a great impact. But in the next year, I’ll need to…reduce costs by another $1M? At some point the efficiency runs against the core business model.
2. The rewards are going to the top line. Who are the people getting the large bonuses and promotions? The people who are closest to the top line revenue. That is an unfair fact of business but a very real one. So I saw myself with fewer options than my peers within other business models. I’ve often wondered why this is, and the closest I can get to is the previous reason: if you have a rockstar sales person, they could create millions of dollars of revenue for the company by creating a new deal. For those dealing with the bottom line, the upside is limited to costs.

I quickly came the conclusion that I wanted to work at a software company and got a job at Radiant Systems (which later was acquired by NCR). At NCR there is a different equation:

Restaurants pay for My Software (Revenue)—Top Line
Subtract cost of support, services, operations
Company investors get money left over (Profit)—Bottom Line

Within this model, my software is what the company is selling. This changes everything. The upside to my work is unlimited. If I work with sales to get a feature in the software, that could move the needle tremendously for the company.

For years, I enjoyed the career benefits to being aligned with revenue at a business.

And then I moved to a Cloud Engineering role.

A strange thing happened at that point. In people’s minds, I was moved into the cost side of the business. Therefore, I was making the cost of the business more efficient but also was missing out on the upside. In the revenue-aligned positions that I enjoyed in the past, I was rewarded for innovation because that meant there would be upside. But in the operations world, I fought a perception that innovation would disrupt the efficiencies already gained and take us (and our careers) backwards.

In my mind, Cloud Engineering is the biggest revenue driver opportunity that I’ve ever seen. If we can find a way to ship ideas and features more quickly, then by definition our revenue will increase. It’s a force multiplier for development. However, I’m guessing that most businesses out there will not see it this way. Most businesses see DevOps through an efficiency lens, because efficiency is all IT Operations has been about since it began.

Last night a friend of mine was talking about this with me, and he said that he worked a DevOps job for six months writing Chef scripts, getting paid well, for an application with few to no users. He ended up having very little financial impact on that company. Then he pivoted to a development role where he increased his company’s revenue by 1/3 in a year. In the latter role, he used Cloud Engineering principles to create a CD pipeline, etc., but he also developed the capability to fundamentally change his business. What an exciting story.

What’s interesting to consider though: let’s say I split my friend up into the rockstar Developer and rockstar Cloud Engineering person. They work together to create this same outcome. At the end of the day, who will the company reward and nurture more? I’m thinking the Developer.

If that’s the case, then those of us headed down the pure DevOps path might want to consider the limitations we are imposing on ourselves.

I would love to hear your thoughts.