By Drew Gorton September 18, 2019
My colleague Steve Persch recently wrote an article talking about why we think WebOps is the term our industry should be moving towards. If you haven’t read it yet, take a moment to do so. I’ll wait. :)
WebOps or DevOps?
One of the points Steve makes is a contrast between DevOps and WebOps. He notes that DevOps is wider than WebOps in one dimension (technology) while also narrower than WebOps in a different dimension (people). Both of these dimensions make for meaningful differences.
Technology Dimension: WebOps is Narrower than DevOps
I think this is pretty straightforward. DevOps aims to improve the practices for anyone, anywhere, building anything with software. The Agile Admin offers a solid definition of DevOps:
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
It’s a good definition. It’s ambitious. DevOps aims to speak to a broad audience. In the real world, however, this can feel like a really wide conversation. If you are a web developer and go to a DevOps conference, for example, you might find a lot of people talking about a lot of things that sound really cool but you might ultimately struggle to connect those things back to your daily work.
By being narrower in the technology dimension, WebOps can focus our conversations and give those of us who work on the web more concrete recommendations and insights.
People Dimension: WebOps is Broader than DevOps
I think this is a much bigger difference. DevOps is focused on tools, practices and techniques that improve collaboration between developer (Dev) teams and infrastructure (Ops) teams. WebOps, on the other hand, seeks to explicitly (and equally) promote collaboration with a much broader set of stakeholders. Borrowing from Steve Persch:
WebOps brings together developers, designers, marketers, content editors and more. Everyone whose job it is to change the website in significant ways (the code, the visuals, the content, the measurements of success) needs to think of themselves on the same team and working towards the same goals.
Who Is On My Team?
Humans are a tribal species. We identify with groups and make decisions based on the groups we identify with. When someone is on our team, we go out of our way to find agreement and prioritize efforts that will benefit both of us. While this can manifest as altruism and being good to others, it can also have a darker side. Quoting the Be Human Project:
… when we are surrounded by people who agree with us, our views grow more unshakable and extreme. We tend to delegitimize those who are different, eliminating troubling cognitive dissonance without considering the possible validity of competing ideas. Such groupthink is powerful for rallying action around a single idea, but it is terrible when we need to brainstorm novel solutions. That, of course, is the challenge of every business today.
Put another way, when we define ‘Us’ as ‘the Dev and Ops people,’ we tend to start working against (or at least de-prioritize) the rest of the people involved.
Diverse Teams Produce Better Results
It’s a simple, well-studied truth. If you want better results, surround yourself with people who are meaningfully different from you. Borrowing from my own series on building great teams:
… it turns out that when we work with others who have different backgrounds than ourselves, we spend more time critically examining our own ideas and recommendations. That extra work produces better outcomes. Preaching to the choir is easy; when not everyone shares your worldview, it forces you to think deeper.
One of the interesting things about this is that meaningful differences exist on lots of dimensions. We all know about race and religion and gender and orientation, and all of those are powerful. Other differences can also have a major impact too, and the role you play on a team (designer, content author, developer, etc.) is another one of those powerful dimensions.
A Bigger ‘We’ in WebOps
When we define the WebOps team as one that includes developers, designers, marketers, content editors and more, we improve the chances that the team will produce better results. When all of these roles identify themselves as being on the same team, they will find better, more creative and more impactful solutions.
Practicing WebOps Improves Results
When your daily standup includes a content author, designer, developer and more, you will see your work in the context of a larger picture. When your sprint planning has more perspectives, you will come up with better solutions. When your end-of-sprint demo includes more roles, you will find novel ways to collaborate. When your project retro has more voices, you will identify improvements that will accelerate your whole team’s results over time.
Standing on DevOps Shoulders
Finally, I want to be clear that while there are meaningful differences between the two ideas, WebOps stands on the shoulders of DevOps giants. Good DevOps principles and practices should be presumed to be good WebOps principles and practices. (Both, for example, have a strong affinity for Agile methodologies.) At the same time, narrowing the technology dimension and broadening the people dimension can bring new insights and better results to those of us who focus on making things on the web. And that’s what WebOps is all about.
