As a young product manager without an engineering background (like myself), you’ve undoubtedly heard of the word “DevOps.” You also think it’s completely different from product management. However, I think DevOps and Product Management have more commonalities than product management has with most other areas of the company.

About DevOps

I’ll share GitLabs definition because there’s no reason to believe I could state it any better: “DevOps is a combination of software development (Dev) and operations (Ops). It’s defined as a software engineering methodology that aims to integrate the work of software development and software operations teams by facilitating a culture of collaboration and shared responsibility. DevOps focuses on incremental development and the rapid delivery of software. Success relies on the ability to create a culture of accountability, collaboration, empathy, and joint responsibility for business outcomes. Stemming from an Agile approach to software development, DevOps expands on the cross-functional approach of building and shipping applications in a faster and more iterative manner.”

I’ve been a product manager contributing to building digital products for over ten years, and I believe most people outside of engineering have no clue about that definition. I think their lack of understanding can be summarized as believing:

• DevOps is a person or team name.
• DevOps is just server management.
• DevOps contributes primarily to pre-production engineering needs.
• DevOps is new.

Similar to product management, the practices and responsibilities of ‘DevOps’ can be different depending on your company. This will primarily be driven by company age, size, and industry. Just like Product Management tends to look slightly more similar across newer, smaller startups (until more specialization is required), DevOps tends to look more similar at startups than larger established corporations.

In actuality, DevOps is all about collaboration (again, similar to product management). A culture of good DevOps practices results in fewer silos, hard handoffs, and fence tossing. It results in less finger-pointing. When done correctly, it should also result in enabling agility, increasing speed, decreasing risk, and improving quality. It improves predictability and visibility. It helps a lot of things!

Team members may have DevOps in their title or may have SysAdmin, SysOps, or something else. Regardless of title, they focus on enabling development teams with processes and tools so that they don’t get hung up on operational or infrastructural details related to deploying code. Remember earlier when I said most people think DevOps just manages servers? When done right, DevOps engineers are responsible for a lot more than that. They’re accountable for driving a culture of automated testing, continuous integration (CI), continuous delivery (CD), and breaking down the old silos of in-development vs. post-release operations.

Back in my day…

I’m in my early 30’s, but I’ve been fortunate enough to work in a variety of different stage companies and experience a couple ‘agile transformations’. 4–6-week releases were the norm where I worked about ten years ago. Roadmapping revolved around this cadence. We almost always did releases at an ‘off-time,’ like 3 am. Usually, about ten people would be on the release call (product, QA, release management, dev leads, etc.). They could take hours and often required periods of downtime for various apps. If something went wrong or seemed unknown or risky, a rollback of the entire system was the likely outcome (in which case we’d try a couple of nights again later). If downtime was expected, then we also had to manage a lot more communication and training with customer service teams, finance, and even customers.

This is still a reality for many companies, but generally not younger, newer startups. The reason isn’t that startups are more ‘innovative’ or better. I hate that line of thinking because it’s wrong. The rise of cloud services and newer dev tools, intersecting with ‘lean agile’ is what enabled the concept of DevOps to take shape and thrive. And the momentum is strong. In the future, it’ll probably dovetail with the current “no-code” movement that’s brewing. But don’t be unfair to larger, older companies and say they ‘do things wrong’ or are not innovative. That’s short-sighted. These companies have far more at risk so they can’t just ‘cut-over’ and adopt a completely different way of doing things. They have to chip away at changing their culture and then at figuring out what changes to make and how to make them incrementally. It likely starts with education and people. You can’t change a strong, legacy culture without new blood. There are also unique technical challenges that companies with existing systems, products, and customers have that new challengers don’t. Anyway, I digress. My point is that DevOps isn’t new, but it’s not very old. And it’s not just a person, team, or blueprint of practices. It’s the intersection of a lot of change this past decade that will continue throughout the next decade.

Today

Fast forward a few years and a few companies later. At Blispay, we didn’t have monthly releases. We were capable of releasing to production (with minimal risk) as frequently as we wanted most of the time. Jeff Silverman was our SysAdmin at Blispay (which was acquired earlier this year). He’s also been around the block a few times, so I asked him a few questions for this post.

Q&A with Jeff

How would you define your role at Blispay (specifically regarding DevOps related responsibilities)? As a startup, the “roles” at Blispay were a bit broader than what one may expect in a more mature company that has more clearly defined teams, roles, and responsibilities. That said, “DevOps” requires, to an extent, a broader skill set than traditional pure developer, pure infrastructure, or technical operations roles. But that’s ok with me.

At Blispay, from a “devops” perspective, I got to implement and work on technology that seems to be considered the devops tool stack these days:

• CI/CD pipeline and orchestration tooling
• Automation using bash, python, and related
• Infrastructure build and management
• Linux system administration
• Developer tooling and practices such as Git, Crucible, TDD
• “Embed” in developer scrums to better understand what was being built so as to better tailor the environment
• Interpersonal skills

What type of person would make a good fit for a DevOps role? I think anyone with a pure development background who enjoys tinkering with operating systems, infrastructure, and systems, would be a good fit in a DevOps role. Likewise, someone with a pure Linux system administration, or network engineering, or infrastructure management role, who likes writing scripts and automation, is also a good fit for a DevOps role. At Blispay, I think the role was defined more towards the latter — emphasis on infrastructure, with a high level of comfort using developer-like practices.

How have you seen the industry change over time-related to developer operations? Honestly, I’ve always operated with a DevOps mindset. I have very little (basically none) experience in either a traditional developer environment or in a conventional technical operations environment. Because of the roles I had leading up to what I consider my first “real” job — a system administrator/developer at a Baltimore for-profit startup — I never experienced the “old” way of doing things, the way that the “DevOps” movement was railing against. Specifically, things like “development create a thing > management uses waterfall management practices > thing is done > thing is ‘thrown over the wall’ to operations, who then must figure out how to run it without ever having seen it before…” I’ve simply never operated that way.

That said, I have observed general changes in the industry (some from experience, some just from reading trade articles). DevOps, as a movement, is something that it seems like all companies want, but few understand or know how to get. I think the key thing that gets missed is that “DevOps” is not an engineering discipline, like “software engineering” or “aerospace engineering.” It is merely a set of principles that can be helpful to organizations interested in creating better output faster, with fewer problems. I like to compare it analogously to the Toyota poka-yoke concept: “any mechanism in manufacturing that helps to avoid mistakes.” DevOps is to modern system engineering what poka-yoke was to automobile manufacturing 60 years ago.

So, yeah, who doesn’t want better output, faster, with fewer mistakes? But unfortunately, the most significant change I’ve seen with the rise of ‘DevOps’ is the overuse of ‘DevOps’ as sort of marketing/branding sparkle for companies that want to hire smart engineers, but are still doing things the same way they always have.

Conclusion

Similar to how a great compliance manager will create a culture of compliance, DevOps is more of a methodology and culture than a person or set of tools. When done well and at scale, DevOps can be a large driver of improved quality, speed, predictability, and collaboration. Product Management and DevOps have a lot in common with each other, often sitting at the intersection of multiple different groups, responsible for cross-collaborating and driving forward progress. If done right, you shouldn’t understand the meme at the beginning of this post (🙏🏿 Seth Vargo https://www.sethvargo.com/the-ten-myths-of-devops/).

‘A Product Manager’s Best Friend‘ is a series aimed at demystifying the role of young product managers. I’m Jared, a PM who has worked in a wide range of environments (fintech & adtech, seed-stage startup to large publicly traded tech & financial services companies, remote and colocated, etc.). I’ve found that there’s a need for practical, straightforward content for PM’s not fortunate enough to find themselves in powerhouses with top-notch product programs like Google & Facebook. Click here for more posts, and please reach out with suggestions or feedback.