Lazy engineers leverage the Product Operating Model

“We are a team providing services, why should we care about this new Product Operating Model?”

Meet Yuval. Yuval is an engineer on the IT networking team. They are a shared services team responsible for the organization’s networks as well as helping application teams in his organization get their applications working in production. It is 1995, PowerBuilder UI over SQL*Net accessing an Oracle Database is all the rage. (And the term DevNetOps is decades in the future, but already being practiced… but let’s talk about that another day…)

Yuval and his colleagues are lazy*. While they enjoy driving to a remote branch once in a while to help an application team deploy and stabilize their new application, it’s become a bit repetitive to go out there and see that the new application isn’t really tuned for the slow networks between the branch and HQ.

*_I’m lazy. But it’s the lazy people who invented the wheel and the bicycle because they didn’t like walking or carrying things.(_Polish Nobel Peace Prize winner Lech Wałęsa)

Yuval and his team come up with the idea to improve the service and provide a simulated branch environment at HQ, and offer the service of testing your application in the lab before you release to production.

This is great. Time passes and Idan, an even lazier colleague figures out that there might be better things to do than to offer the lab environment for these test (it’s still work for the network engineering team). He comes up with a simulator that can run on the PC desktop from which the application developer is testing.

Idan just made the networking engineering team a platform team that enables developers to self-serve.

What is happening here?

Yuval, Idan and colleagues are doing two things at the same time. They are providing an ongoing service, while they are thinking about ways to improve the service. They are thinking about the service as a product. They are constantly thinking about how to create leverage - more value to the organization (and less work and more time to play video games - that’s the best test for the LAN performance…)

Fast forward 30 years.

Shared services teams are asking “Why is this new Agile Product Operating Model applicable to us?”

If you care about improving the services you’re providing and/or struggling to service demand with limited capacity, you need to think about how to productize your services. What can you automate? what can you systemize and expose as a self service? There might be many opportunities - which of them is most valuable? what would create the best outcomes for the people you are serving?

Once teams start to think this way - everything in Product Thinking and in a Product Operating Model suddenly becomes useful. Agility becomes a useful way to navigate the uncertainty of which self-service capabilities will be consumed and which will be rejected.

Before you conclude that shared services / operational teams need to use agile/product ways of working for all their work, note that this isn’t necessarily useful, repeatable operational work. Many shared services teams focus on the flow of operational work and use agile/product techniques to manage developmental/capability improvement work.
​
So…