Pantheon Community

Feedback Wanted: Six Keys to WebOps Success

Hello friends,

Steve Persch here, Technical Product Marketing Manager at Pantheon. I’m looking for input on the evolution of some frameworks we’re using to describe how web teams succeed together.

Specifically, I want to know how well these six key practices align with how you think about your job as a member of a web team:

  • MEASURE success
  • ITERATE on high-value features
  • COLLABORATE within and across disciplines
  • AUTOMATE repetitive and error prone tasks
  • MAINTAIN critical dependencies
  • OPTIMIZE performance

Background

In the last year we’ve started using this hierarchy more and more to talk about how professional web teams need to make an impact of some sort. Focusing on that impact (for some sites it might be advertising revenue, leads generated, etc) requires a team to be productive and that their site be credible (performant, stable).

This three level hierarchy is a simplification of a Maslow’s hierarchy of needs version that I’ve been blogging about and presenting on for a few years.

While we’ve found this hierarchy helpful to illustrate where we think web teams need to put their focus, it alone does not describe enough of what actions a web team needs to take to be successful with WebOps.

And this is the part where I’d most like your thoughts and feedback. In some meetings with customers and in other forums we’ve started emphasizing six key behaviors or practices that we think any web team needs to engage in in order to be successful (with or without Pantheon).

Those keys again are:

  • MEASURE success
  • ITERATE on high-value features
  • COLLABORATE within and across disciplines
  • AUTOMATE repetitive and error prone tasks
  • MAINTAIN critical dependencies
  • OPTIMIZE performance

And we think that those keys align pretty well with the hierarchy:

In order to make an impact, a web team needs a shared definition of success and a clear way to measure that success. Without that, the team often gets pulled in whatever direction the loudest stakeholder wants to go.

And speaking of stakeholders, normal operating procedure for many teams involves churning through a never-ending backlog of new feature requests from stakeholders. We have a hypothesis that you’re often better off iterating on high-value features with small changes than spending big chunks of time on net new features that might not actually be valuable. And if you really do have a ton of new features to build, iterative releases beat the big relaunch.

Being productive with iterative releases requires that a team can collaborate closely within and across disciplines. Long-running waterfall projects often separate designers from developers from content editors and so on.

Getting changes released in a single sprint or a single day is a fast team effort that is often only achievable if you can automate repetitive and error-prone tasks. Before I worked at Pantheon or was a Pantheon customer I could only do releases to live websites every so often because that release process was about a dozen steps long (starting with “ssh into this box, run this mysql backup command” and ending with “pray”).

Of course it’s hard to focus on fast-paced, valuable releases if you have a credibility crisis; if your site is out of date or at risk of getting hacked. Maintaining critical dependencies might not be a fun part of the job but it is necessary. With this key I also want to emphasize the cross-disciplinary nature of the work. Just as developers need to maintain code, content editors and site owners need to maintain content. An information architecture that is outdated or broken might be worse for a team than an old plugin.

And all of the above keys are built on the assumption that your site loads at all before a visitor clicks away. Optimizing performance is a both fundamental question of how well the site is understood by its team, and it’s a direct connection to the top of the hierarchy. Improving the load time of a site is a surefire way to improve a conversion rate.

At Pantheon we want to enable teams to practice each of these key behaviors with less effort so that focus can move up the stack.

What do you think?

I’m looking for reactions around how helpful this framing, and these six particular words are. Please use this thread to answer any of the following questions or share any reaction you might have.

  • Do these six keys align with how you think about the work your team does?
  • Are there keys in this list that you don’t think belong?
  • Are there practices you engage in that you think should be added to the list?

Thanks!

1 Like