Early in my career as a developer working with educational institutions, media organizations and other large companies I could see that I stood on a figurative battlefield.
IT departments had fought a war with their marketing or communications counterparts over who truly owned the website. IT departments had incentives to slow down changes to prioritize stability and security. Marketing professionals had incentives to chase faster changes. That often meant giving more people access to more layers of the stack.
As a developer trying to keep up with the pace of requests coming in from marketers, I occasionally broke sites in ways the IT departments did not appreciate. Over the full course of my career, I moved between roles and could see more clearly the interconnections:
IT Departments need stability to remain credible in their jobs. If this DNS change breaks the website completely, am I going to get fired?
Developers and designers are often measured on (a proxy for) productivity. How many billable hours did I work last week? How many story points did I complete?
Marketers need to show the impact of their work. How many people clicked the new call to action I put up on this theater's site?
In a healthy team, all members in each role recognize that they each contribute to the stability, productivity and impact of the website. These needs complement one another. It's kind of like a hierarchy of needs. In unhealthy teams, these departments can go to war to maximize their core needs at the expense of others.
At Pantheon, we see ourselves as positioned to end the wars between these departments by providing a mix of stability that IT needs with guardrails that make it safe for teams to move fast.
What happened in the 2010s?
Now be careful what you wish for. In the 2010s, the world of website operations found another way to reduce the tension between these roles: ignore each other! The jobs of each role became so complicated that there was no time to argue (or collaborate) with people in other roles.
For IT departments and marketers, the 2010s felt oddly similar. At the beginning of the decade, there was a new crop of Software as a Service tech that makes portions of the job easier.
Call it the Martech 150.
By the end of the decade, marketing leaders have to keep track of 8,000 different tools. Really? That's not realistic. Marketing gets sliced into countless subspecialties.
That explosion of marketing-focused SaaS was fueled in part by the growing number of cloud computing products used to build these SaaS products. At the beginning of the decade, IT leaders could look at Amazon Web Service's S3 product and EC2 instances and see a path toward making their jobs easier. Fewer servers in the basement! Cost savings! Now AWS is so complex and sells so many products that before long you need a cloud economist to track where the money is going.
DevOps to WebOps
I can't summarize the human side of the 2010s without mentioning the rise of DevOps. The DevOps movement grew to solve the tension between developers incentivized to move fast and break things and the system operators incentivized to keep the systems stable (again by slowing changes down if necessary). The DevOps culture trumpeted best practices like the improved stability that can come from releasing code changes very quickly. DevOps showed that the needs of these groups could complement one another instead of contradicting each other.
But the DevOps culture does not cover all the roles on a web team. The turbulent 2010s split apart developer roles into narrower and narrower slices. "Back-end developer" and "front-end developer" are barely descriptive enough anymore. Two front-end developers can sit in a bar and have nothing to talk about because one is working on the front of the front end and the other is working on the back of the front end.
However broad or narrow a web professional's specialization may be, success for the whole team often depends on the individuals having enough time and space to look past the edges of their focus. That's WebOps in a nutshell.
Seeing the explosions of new technology in the 2010s that propelled each web role to chase its own version of excellence shaped Pantheon’s new Front-End Sites offering.
In my last blog post, I covered from the technological side how the LAMP Stack architecture that brought these roles together in the 2000s was followed by an outbreak of initialisms (as I called it on YouTube) like SSR (Server-Side Rendering), SSG (Static Site Generation) and more. We intend for customers using Front-End Sites to spend less time picking between an ever-growing list of initialisms for every site or different pages within a site.
You might also like:
- Introducing Pantheon's Front-End Sites Blog Series
- The Anatomy of WebOps Teams: Pantheon's Experience
- Building Decoupled Better
Topics: Decoupled CMS