TBM 47/52: Operations (and ProductOps)

In operations, we take a look at a sociotechnical system, consider its goal(s), and then think about how to help that system “operate” more effectively.

Operations can be a formal role. Or it can be a hat we wear as part of another role.

Someone good at “Ops” will consider emergence, constraints (real or perceived), the nature of complex adaptive systems, human psychology, human factors, ergonomics, and safety science. Someone less experienced will take a more deterministic, centralized, process-centric view. Good at Ops knows the best option is often to do nothing and observe. They think in safe-to-fail experiments, service design, and the needs of the humans in the system. Less Experience at Ops makes everything a process-centric (or technology-centric) project with a beginning, middle, and end.

As we might expect, there are thoughtful and less thoughtful (or less experienced) approaches to doing ProductOps.

To make matters even harder, companies may have views like:

• Developers shouldn’t interact with customers

• We need to buffer the teams

• We need process conformance across our teams

• “In our environment, we can’t have independent teams”

• “We’re not mature enough to _______”

• “We can’t possibly do ______”

• “You need a centralized ownership structure for everything”

These view will color the ProductOps hat-wearer's view of “what the system is trying to achieve”. I am concerned that in many organizations, there is a wicked combination between 1) people inexperienced in operations, and/or 2) people inexperienced in product, and/or 3) who have rather constrained views of teams, and what’s possible.

Another factor to consider is whether the product organization is:

• Scaling something that is working, but cracking a bit at the seems, or

• Big and broken, in need of fixing

So wrapping up, your approach to addressing operational concerns in these two environments will be very different. When people ask me to define ProductOps I always say it depends on:

• What the system is trying to achieve

• The experience level of the people involved

• The biases of the organization

• The “motion” (scaling what works, fixing what is broken at scale)