Digital Transformation
Showing results for 
Search instead for 
Did you mean: 

So, who should we have in our "DevOps" team?


In my last blog post, I talked about how DevOps and Continuous Deployment will really struggle if all you involve is the dev and ops teams. So, what other groups need to be involved and how do they need to be involved?


who involved in DevOps.png

The Product Owner
The other day, I was talking to someone who has used Agile Development for a number of years. She said that her biggest problem was the Product Owner. He was set in his ways. For the last 30 years, he had been creating a requirements spec followed by an external spec, followed by a pause of about a year while R&D did the coding. He would then sign up a few beta customers, send them the tape (he called it a "tape" even though we've moved on from tape) and call them "to see if it was OK". (I was a product manager for many years. This is what I did too).

This is not Agile; it’s not Continuous Innovation. The Product Owner needs to create user stories for the sprints. He needs to work with the team on story prioritization in sprint planning. And then he needs to actively get each sprint accepted – “I’ve had a play with the latest sprint – it looks good” simply doesn’t cut it.

And if the product owner is not prepared to change from his waterfall habits, then I would suggest you need to get another product owner (or, you can do what a lot of teams do which is to leave the product owner in place and use an architect to act as the true product owner, which is not really a good solution, but is sometimes all you can do).

Of course operations needs to involved in DevOps. And if we can get some "operations shift left" into what we do, this will make a huge difference. What do we mean by "shift left" in an operations context?

"Shift left" is a phrase popularized by DevOps where we do things as early as possible - we shift things left in time (left being earlier, right being later).

Design for Operations
One of the key "shift lefts" we can do as regards operations is to “design for operations”. Get the operations team involved in the design so that the released produt is easier to manage. (A slight aside : when Paul Muller is asked "what is the one thing you would do to get DevOps implimented?", his answer is, "give the apps guys pagers and ensure that they get paged when there are problems with their app".) So, if you have problems getting the design team to accept the idea of "operations shift left" and designing for operations, give them pagers and ensure they get awoken at 3:00am when the app has operations problems.

Infrastructure desired state as code - under version control
A hot topic for operations is “Infrastructure (desired state) as code” – the ability to specify infrastructure's desired state in code. HPE IT is a huge fan of DevOps. Probably their two key recommendations to anyone starting out in DevOps would be a/ take time and energy to form the "work unit" well (more on this in my next blog post) and b/ put everything, everything, everything under version control. The great thing about "infrastructure desired state as code" is that you put this code under version control too.

Put the application under monitoring as soon as possible
Another area where Operations can "shift left" is the “monitor-ability” of the application. Traditionally, operations monitoring is only applied to an application when it's put into product. But under "shift left", you test the monitor-ability of the application as soon as possible. Typically, this means getting the app under monitoring when you first start system testing. In other words, we are assuming that monitoring of the app is something we need to test, so let's get testing it as soon as possible.

Ditto for the security team
Most of what we've said about operations can be applied to the security and compliance teams too. Shift left by ensuring that the application is designed for security and compliance checking and monitoring.

Google has a scalability expert on every product team.

I worked on the development of an enterprise email system many years ago. The system worked really well with 2,000 users. Then a sales guy went and sold it to a telco who wanted to use it for 15,000 users. It didn't scale - you couldn't just add more servers and more disk in order for it to handle the 7.5 times more users. So our performance expert was called in. After days of pouring over performance data printouts, he declared that a major rewrite of a portion of the code was required. Has this happened to you? I'm sure it has.

The next time we created a new product, we had the performance expert on the team from start. And the product owner (that was me by this time :-) had a series of performance long-term requirements that the design had to meet. The bottom line is that performance doesn't scale linearly. As our performance expert used to say, "performance is like peeling an oninon. You solve one performance constaint (one layer of the onion) and then you bash up against another (layer of the onion). The number of layers of the onion you peel away depends upon the eventual performance you need".

Do what Google do and get a performance / scalability expert on your product team – design for scale from the start, because scalability re-architectures are always very disruptive and time-consuming. They are also frustrating for customers because lots of R&D resource is used up and no new features appear.

Data Scientists
I’ve recently done a review of digital disruptors and their use of data science (ref : blog post). Digital disruptors do two things with data science :

Use Data Science inside the product to create better products
Firstly, they use data science within their products, to provide product functionality. For example, Airbnb has one of the most world's most sophisticated recommendation engines to recommend what you should charge for a room. If you have a data scientist on your team they can suggest ways in which data science might be able to give you better functionality. I don't think most poeple realize just how quickly data science is advancing. Not only can we take in and analyze different data types like masses of machine data and human interaction data, but the algorithms used are improving too.

Use Data Science to create better products, faster
Secondly, they don’t rely on the “wet finger in the air” of a “stuck in his ways” product owner. Digital Disruptors record masses and masses of data and then they use modern data science to determine what customers like, don’t like, skip over, etc in their latest product releases. That’s what Sony’s gaming division do, it’s what Twitter do, it’s what Yammer do. This is hugely important. If you're going to use continuous delivery, you'll need to quickly and accurately find out what your customers think of your latest release. Don't rely on a product manager to phone up a few customers. Don't rely on customers putting their comments into some social media system. Suck information automatically from your product so that you can know what they are actually doing with your product, what they like, what they dislike, what they use and what they don't use.

I believe that as digitization takes hold, we'll see the use of data science for fast and accurate feedback increase - for cars, for smart cookers, and so on.

Get a Data Scientist on your team so you can do this too.


I go to a lot of DevOps conferences. At these conferences, there are typically a series of roundtables. Not a single roundtable participant has ever asked for advice on using Puppet or Jenkins. The discussion is always around getting the rest of the organization to help and stop fighting agile and continuous deplayment. In this blog post, we've talked about some of the people who should be in our DevOps team.

Of course, there is a huge omission from the list above. What about "the management"? This is a huge topic. It touches on objectives and upon allocation of resources at the highest levels. I'll cover "The Continuously Innovating Organization" in another blog post, and I'll be calling upon the work of McKinsey & Company and Geoffrey Moore.

In this blog post, I touched on the idea of the "Work Team" and how important the DevOps teams in HP IT found this concept. In the next blog post, I'll talk about how we form this team, who should be in it, and how it should operate, and a topic I could rant about for ages, the alignment of objectives (or, to put it another way, the difference between the pig and the hen in your bacon and eggs breakfast).





(picture : setting up the Work Unit) - goals, etc

(picture : change of roles) - how people have to behave differently

Mike Shaw
Director Strategic Marketing

linkedin.gifMike Shaw

0 Kudos
About the Author


Mike has been with HPE for 30 years. Half of that time was in research and development, mainly as an architect. The other 15 years has been spent in product management, product marketing, and now, strategic marketing. .

See posts for dates
See posts for locations
HPE at 2018 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2018.
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all