Learning Notebook: Solving the Human Challenge of DevOps

For many years I worked as a product manager for two various styles of product development. The first was building shrink-wrapped software that was built using a long, two-year waterfall development process. We would scramble to put together our pitches for the next version of our software and work (usually) together to make sure that what one team was doing wasn't stepping on the toes of others, and sometimes defend the use cases that our product historically would own.

Through a massive shift, we migrated to agile development when we introduced lighter weight task-oriented software that was distributed through online downloads and updates. Suddenly the process went from two years to two months at a time. But the change wasn't universally adopted throughout the company so we had newer products created with agile and others created with waterfall. When it came time to ship, it was a mishmash of schedules and timelines that required project and program managers to help sort out and get our products into customers hands.

It didn't matter what tools we used. (Different teams shared some tools, but there were some unique tools that were exclusive to a specific product) But what the entire experience taught me, and a core tenet in the DevOps Fundamentals course I recently completed are the same: DevOps (and by association, software products) is a human problem, not a technology problem.

Taught from the perspective of the engineer or operations professional, the course breaks down the walls and silos between the two, but what was interesting was that as I watched, I understood many of the issues the instructors, Ernest Mueller and James Wickett, talked about, but didn't really have a way to communicate or convey them. Product management is a holistic practice, you are looking at all of the components of building software products. Resolving conflicts and turf-wars between teams would burn valuable time when, in reality, we are all going after the same goal.

The biggest challenge I can see as DevOps grows, is how to include the product management piece into the mix. It is easy for a product manager to prioritize user-facing features over the internal features needed to build the product. But the basic principles of DevOps require that your entire pipeline be an asset that is checked in alongside of your core program code. Product managers understand agile and lean. Build the smallest amount possible, but build it quickly. The tenet of "doing is more important than talking about doing" resonates with a product manager, but the scope of what that includes needs to be expanded--dramatically.

The first part is to learn. A product manager might not be as technically deep as their engineering and operations teams, but it is really critical to understand the scope of what they need to include when developing, and prioritizing user stories and including the concept of "infrastructure as code" along with the user-facing features. This change can be perceived as counter-productive, since fewer features seem to be making it to market.

But the reality is that prioritizing this work will result in more confidence in new features and accelerate the rollout of these features to customers. This includes greater transparency of these features--and failures with customers as well. Being honest and constructive is a large component of DevOps, and that needs to extend to your users. Often, this transparency to the users comes through communication from the product manager, and it is critical for them to understand how to rapidly pinpoint the root cause of the failure and communicate how the problem was identified and share remediation with users.

DevOps also changes the roles of those that work on projects. In addition to engineering and operations team, this extends to the product management organization as well. Being open to finding new ways to embed with others, share a common goal, and share a greater understanding of the responsibilities and work that each team member does is critical. When engineers and ops work together, there is a greater appreciation and understanding of what they do. The product manager is included in this as well.

DevOps reminds me of a phrase I learned from a family member years go. There aren't problems and solutions, there are challenges and opportunities. DevOps has already demonstrated opportunities for teams to work better together and result in better products and services for customers, but everyone, including product management needs to understand the challenges and how to overcome them to meet these opportunities. Thanks to Ernest and James, I'm more confident in how I can leverage DevOps.