Introduction: Why?

Operations oftentimes is least area people think about on producing products. Unless it’s built in certain way from the ground up (See Etsy), in many places, operations are second class citizen. Many people don’t think about what operations need to do in order to support the business, mostly because most people not in operations don’t understand what operations do. (Heck, sometimes many operations people don’t know what they do!) This often tends to lead to misalignment of company goal to operations goal, and the cycle gets worse as the company grows or bring new people.

At least from what I have experienced in my career, or from what I have heard/seen from other people in the similiar role, operations don’t operate necessarily in sync with business/product/engineering as far as product feature delivery is concerned. There are some occasaions when operations’ mission is aligned with business/product/engineering, and some people call it DevOps. I’ve also seen/heard/engaged in many debates/discussions whether agile/scrum works for operations or not, or whether operations should use Kanban instead. In some places, Scrum is forced on you as a standard method you need to follow, or in other places, there is a continuous debate.

Some of the best people have been talking about DevOps in the past 3-4 years as a solution, but in reality, unless you have a deep profound understandig of what people like Gene Kim, John Willis and other key people behind the initial DevOps movement, most people don’t have a good comprehension and think of it as people who can use tools, manage releases, etc. Folks like Dave Zwieback have been talking about why DevOps is not a team, people or role. It is a culture. But it seem like people don’t want to listen.

As I started a new job at Work Market, I wanted to take a moment how to think about this and articulate this issue. Since we are living in the world of Agile and Scrum, I decided to try using Agile concepts to think about this problem, which I assume exists EVERYWHERE, including the top dogs / unicorns.

I am starting to wonder whether all the discussions and problems we want to solve is NOT because of structure, process or tools, but rather we haven’t gotten to the point where we can treat operations as a full fledged product just like anything else. Operations produce tangible items (infrastructure, network, private cloud, aws orchestration, etc) but often times they are not taken into considerations when product feature is developed, because product is consumer/customer driven. If we can treat operations as a product, perhaps everything starts to make sense.

I don’t believe I can capture all my thoughts in one blog post. So I am thinking about doing 2-3 parts post. That helps me organize and shape up my thoughts. I plan to break up as follows:

1. Why Personas?
2. What type of persona types are out there?
3. What does Operations as a Product could mean?
4. What are the approaches on making the business successful

Personas

I am by no means a product person. Throughout my career, however, I have interacted various “Product Managers/Product Owners” enough to know that they all come from different backgrounds with different experience. One thing that is fairy common, however, is their reliance of Persona. For those who are not familar what Persona is, I encourage to read more about it. My very simplistic explnation of it is that it is a carefully crafted character that represents certain type of users/customers of the product(s). I’m fairly certain this is NOT the most accurate way to describe it, but hopefully at least it is an agreeable description.

With the concept of Personas stuck in my head, I started thinking about who I (or the teams I’ve been part of) have interacted with to get the business rolling, whether it’s implementing a solution or resolving crisis. I started jotting down some notes, drawed boxex, circles, and some more doodlings. Suddenly, some very interesting patterns started to emerge in front of my eyes. This might be an already established thought, but to me, this started opening up my eyes to a whole new world on how I should look at the problems. I’ll talk about it more on this in this series.

Operation as a Product

It feels very inhumane (and borderline insensitve) to treat Ops (usually refers to people who perform operations) as a product. I agree that it’s as wrong as thinking DevOps is a person to think that Operation is a product. I personally do not like the term Operation generally. Operation seems to imply that it is about maintenance and support (or ticket machines…).

In reality, many of the people in “operation” I’ve met/read/followed are as intelligent, hard-working, well-spoken, articulate and experienced as anyone in other areas. John Allspaw of Etsy, Gene Kim, are just very small sample of very well regarded people in the industry.

At the same time, Operation engineers tend to talk/think more about whats and hows for them, rather than whys. This probbably explains why it’s very hard to to scrum/agile for operations. I myself often falls under this trap.

BTW, Kanban doesn’t answer this either. This is not an issue of a work management for operation team. It is much bigger than that. (Mental note to myself: another good topic to post blog on!)

Anyway, back to the topic, I started forcing my brain not to think about the problems and solutions, but to think about what the expected outcome is. It is a very simple and small change in the way you look at things, but I am finding it very powerful.

Next

In the next one, I will write about what kind of personas that emerge from this thinking process.