Recently, we had the opportunity to hear from Charlie Betz of Forrester Research about the future of technology operations. He covered the shift from project-based work to product team orientation, the integration between DevOps and IT services and the ways in which the entire enterprise is getting value from investments in artificial intelligence. Check out some of the interesting questions and answers from the discussion and be sure to catch the full conversation in the video below.

What is the biggest hurdle to shifting from a project team to a product team model? 

I think the biggest hurdle is that project teams have historically been responsible for activities and outputs, deliverables if you will, and making cost, time, and scope to an agreed level of quality (the iron triangle). Whereas a product team is accountable for outcomes, including profitability, for example, although there may be other kinds of outcomes such as customer satisfaction. Typically, in the older model, the business sponsor would be responsible for the outcomes and they hire a project team to develop something that would hypothetically fulfill those outcomes. Now, the product owner is directly responsible, owns the delivery resources or has a very close relationship with them, and so there is less of a handoff. But this is a big change, and a lot of project managers are likely to say, “If I make the iron triangle, what happens after that is not my problem.” And this is how they were trained. So, this is probably the biggest issue or the biggest hurdle. 

How does the product team orientation change KPIs for service management teams? 

Metrics are not bad, KPIs are not bad, and there’s a big conversation around OKRs. But really what we’re seeing is less of an emphasis on ongoing and static KPIs. There’s always going to be a few like, call handle time and TTR, or whatever. But, more and more, the OKR conversation is a combination of what initiatives are you undertaking and then what will the measurable outcome be. So, we’re going to do X and we hope that NPS will increase by Y. There is a conscious effort to articulate a hypothesis and then an experiment that will test the hypothesis resulting in some measurable outcome. Rather than just looking at numbers, like on a boiler room dial or like at a nuclear power plant that’s already pre-designed, all the dials are pre-designed, and we just need to look at the numbers and tweak the controls. And that was never a good metaphor for service management and complex digital systems. I think we’re now pretty decisively moving away from that. 

What is your view on the impact of low or no-code development platforms on the future of IT operations? 

Well, the platforms need to be operated. What’s on them is more the challenge for the user. I think that really this is evolutionary, not revolutionary. Now, if a low-code, no-code platform is being owned and run, owned and operated by the business, that’s a different matter. That’s true shadow IT and I think that you have legitimate concerns/a legitimate reason to be concerned about a non-technical capability trying to own and operate a sophisticated low-code, no-code platform. But if you have professionals who are operating the platform, then there is, I think, a space, and there are many examples of this – it’s not a new conversation - there is space for citizen developers, end-user programmers, call them what you will, people who show the talent and aptitude for software development. But then I think the understanding has to be that if they get themselves into trouble, they have to be able to get themselves out of trouble as long as the base platform, the core platform, is being run in a stable way. 

Who is responsible for overall governance of integrated ITSM and DevOps workflow in a product team orientation? Is it IT or is it the dev team or both?

It is a combination of platform teams and the overall governance is under the CTO or somebody the CTO delegates for covering the entire IT control plane. But the dev team is a customer of the service management and DevOps platforms, and those platforms should themselves be run as products at scale. Now, in smaller scales you see development teams doing this, but really, it’s not the development teams’ job to mess around with Jenkins. Any kind of scale, you need a dedicated team doing that and running it as a product in a responsive way, not some kind of ticket-taking way that is slow and unresponsive and not customer-centric. I think that’s the key difference with platform teams versus older-school, shared-services. There’s a lot of commonality there but the idea that a platform team is run as a product I think is new and is essential to succeeding in this new world. 

With all of this changing mindset, what happens to ITIL best practices? 

Even ITIL never claimed best practices. At least if they did, it was a long time ago. They long ago switched to talking about good practices. And then I think even more it’s practices that work in certain contexts may not work in others. The idea of best practices, not to go too far down a rabbit-hole, that’s really manufacturing-centric where people were doing the same thing with the same raw materials and wanted to know the best practice for forging iron or something. ITIL and IT service management has always been much more contextual. It’s hard to say that they’re best practices. Now that said, I do think that ITIL version three has pretty decisively been left behind by history. The idea that you can have an enormous service management factory with twenty-five or thirty processes that kind of all fit together like finely machined gears in a watch and produce services, that was never an effective idea. It was never going to work. And so, I think the process-centricity of ITIL…moving from processes to practices I think is important and ITIL v4 took that step. ITIL recognized that there was significant concern to the overly process-centric way that ITIL V3 was expressed and that’s why they went with practices in ITIL v4. I do think as practices and documented as practices, there’s a lot of good and sensible things said in ITIL. But I will say this, there are a lot of companies succeeding who have never looked at ITIL. There are very highly scaled companies making hundreds of millions and billions of dollars that have never looked at ITIL, who just decided to leave it behind years ago. And so, the idea that ITIL is somehow necessary I think is really open for question. But if you’re using the modern version – version 4 – there’s a lot of beneficial material in there and it does give you a reference model for thinking about the things you need to do in a complex digital organization.

To learn more about what the future holds for technologists within IT and across lines of business-like HR, Facilities, Finance and Legal teams, check out Charlie’s compelling report.

The Future of Technology Operations