Uncharted Waters

Apr 1 2019   9:01AM GMT


Matt Heusser Matt Heusser Profile: Matt Heusser


To a programmer, DevOps typically means automating operations with Build/Deploy pipelines. I find that definition unsatisfying. The “right” answer, that DevOps is a culture change toward collaboration, isn’t much better. That second definition is vague enough that nearly anything can call DevOps. It is also vague enough that people can fundamentally disagree on premise and conclusions, talk “past” each other, and think they agree. One term for this is shallow agreement, and it’s terrible.

Eleven years since DevOps became big enough to have its own conference … e don’t know what it means.

Today I’d like to give up on defining DevOps. Instead, I’ll skip past it and introduce something even better: BizDevTestSecHRPRMarketingOpsOps.

That’s not a joke. Or, at least, it is not entirely a joke.

Let me tell you about it, starting with DevOps, but going very quickly.

DevOps Refired

When Extreme Programming and Agile Development became popular, there were usually two groups. Development’s job was to create change. That change was particularly in software, usually improving software that already existed. To do this added a bunch of crazy practices like bringing the customer into the room. writing requirements on small cards that were easily changed, exploring and time-boxing ideas. This new flavor of developer would actually work with people, adapt to change, and bring the software to production quality frequently. We loved it.

Then, at some point, that was supposed to be every two weeks but often turned out to be … less … we would throw the software over to operations. While the job of the programmers was to create change, the job of operations was to keep systems running. One thing the folks in Ops knew was that change tends to stop systems  from running. Thus, the easiest way for ops to keep the systems running yesterday’s build up was to prevent the uploading of today’s (broken) software onto the production. This inherent difference in goal (programmers create change, ops prevents it) led to turf wars. The turf wars subtracted from the little productivity we had in the first place. Suddenly it was possible to spend three months “keeping the lights on” without actually doing anything.

So DevOps was born, with a premise that Dev and Ops would actually work together. The simplest way to do this was to bring operations “into” the team, having the delivery teams themselves manage rollout and support of production. Other common ideas include bringing development tools, like code practices, over to operations. Most of the ops teams I worked with had always written code, often bash, powershell, or perl, without the benefit of version control or reuse. Meanwhile programmers knew  how to take log files and create graphs, or automate deploy pipelines.

Still, the basic idea was having the two work as a team, instead of enemies.

Since that time there are a bunch of news Ops. There’s DevSecOps, TestOps, DevTestOps, QAOps, and DevSecTestOps, to name just five.

I’m skipping ahead in line.

Let’s talk about BizDevTestSecHRPRMarketingOpsOps.


Let’s start with biz.

Peter Drucker, perhaps the most respect business guru of the 20th century, said the purpose of business is to create a customer.

That’s it.

You cannot have real success in business unless someone actually pays for your goods and services. Yes, you can get a grant from a foundation. Government organizations can be funded with someone else’s tax money. In some rare cases you might get tax incentives or loans that are greater than your operating costs. For the rest of us in long-business, we have the great equalizer. In order to keep existing, a business has to make stuff someone will pay for.

In software we tend to think of the people who think about this as “the business.” I am sad to say, we often have an antagonistic relationship to them. Those people want to know dates and commitments; we just want to build cool stuff. “Leave me alone to build cool stuff” is something I heard four times last week, and I run the tiniest of companies. It is likely that I was actually talking to myself when I heard that.

Fundamentally, we need to bring business into the team. Don’t laugh, this is actually possible.

A mature team at Amazon.com, with the right metrics, can measure how their work impacts sales, to calculate their own ROI. Calculating profit and loss may be hard, but it can also be done. The same is true for marketing. Hotmail became viral but putting “get your free account” at the bottom of every email. PayPal initially gave money away for new signups; Airbnb still provides a cash incentive for referrals. These “marketing gimmicks” are real live features the engineering team built that can be tracked.

Adding HR into the team is as easy as letting the team do their own hiring.

PR I just kinda threw in there. You could add legal too. Finance is a little trickier, but possible.

The Bottom Line

All too often – and I see it in groups as small as two people – we let our roles define success in mutually conflicting ways. We fight with this or that “team” and then wonder why the business suffers.

What I’m suggesting here is that all aspects of the business work together, as one team, to accomplish a common result.

I realize that BizDevTestSecHRPRMarketingOpsOps is a mouthful. It’s hard to say. And a bit silly. If you want a better term, I suppose you could try “A business.”

But who would have clicked on that?

Perhaps I should call it “whole team whole teaming.”

Happy first of April.

Hey. I told you this post wasn’t entirely a joke.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: