A DevOps Approach to Improving Marketing/IT Relations

Back in the 60s, “marketing technology” meant a desk, a carton of smokes and three martinis. The mad men of the era would create amazing concepts, the secretaries would type them up, and the ads would be embraced by an easily-persuaded public.

Imagine a Don-Draper-type trying to wrap his head around a modern marketing operation. Marketing is now driven by data and executed with a dizzying array of technology. A quick look at the Marketing Technology Landscape Supergraphic shows just how much tech is out there:

The increasingly technical nature of marketing means the marketing department has a closer relationship with IT than either is comfortable with. These two departments often have completely different sets of priorities and goals. But they need to work together—or at least not at cross purposes—to drive results. At many startups and SMB companies, engineering resources also serve the role of IT. This means they can be pulled from core product work to help with the marketing tech stack. 

We have found that aligning our organization along DevOps principles helps eliminate that friction. DevOps is a cultural and professional movement that is focused on building and operating high velocity organizations. The movement started in the software industry, but it’s more concerned with people and structure than with technology.

One key aspect of DevOps is the relationship between accountability and empowerment. The DevOps philosophy says that those who are most accountable for a specific change should be empowered to make that change themselves.

For example, if your marketing department is accountable for your website’s content, marketing should be able to change that content without going through a chain of ticket requests or the daily engineering standup.

Conversely, if IT is accountable for the site’s uptime, they should be empowered to work on ensuring that uptime, instead of managing content requests. When the two teams coordinate efforts and align accountability with responsibility, they can get out of each other’s way.

Here are three real-world examples of companies—including Pantheon, of course—that improved their operations by adopting a DevOps culture.

1. AdRoll Separates the Website from the Product

AdRoll is the global leader in retargeting. They offer a software-as-a-service (SaaS) solution for businesses looking to capture attention with personalized ads based on a user’s internet activity.

Today, the company is a giant. When they started, however, they were like any startup: Lean, hungry, and looking to get the most out of every resource. So they built their SaaS product into their website. That meant there was a tool for logged-in users and promotional marketing material uneasily sharing the same space.

Whenever marketers wanted to put up new website copy, they had to go through engineering. Engineering had to push the whole site again any time a change was made. This meant engineering could either take time away from development to push marketing’s content, or keep improving the product while the content went stale.

In other words, two core competencies of the company were at odds with each other. When they looked at it from a DevOps perspective, they realized the website and product needed a conscious uncoupling. It took time and effort to untangle the two, but now engineering is free to develop the product. And marketing has full ownership of the content for which they’re accountable.

Once each department had full ownership of their responsibilities, the company as a whole could move forward much more quickly.

The Moral: Empower each team to do what they do best, rather than tripping over each other.

2. Tableau Finds Success with a Third-Party Web Platform

Business intelligence has traditionally operated on a “report factory” model. If you need a report, you fill out a ticket, send it off to another department, and they pull the data and send it back. Need a refinement, a different data-set, a new view? Fill out another ticket and send it down the assembly line.

Tableau has been instrumental in creating a self-serve model for business intelligence. They specialize in freeing up the flow of information in an organization—but their internal structure didn’t always match that ideal.

The company had a separate SaaS product and website, so they didn’t have AdRoll’s problem. But they still had the same IT team controlling the website infrastructure and the SaaS product.

On the SaaS development side, the team did great. Their goals of quick deployment, solid uptime, stability, and security were right in their wheelhouse. But the website quality was suffering. The deployment flow from marketing requesting changes to actually seeing them implemented was frustratingly long. Even worse, it took the IT team away from product development time.

Finally, the two departments sat down together to think about what a DevOps solution would look like. The marketing department needed to spin up staging environments and deploy from local to staging to live with a minimum of IT knowledge required. The IT department estimated it would take at least a year to develop the solution marketing needed, all taking time away from SaaS development.

In the end, both departments decided to run the web infrastructure on Pantheon. That freed up IT to keep developing the product, and gave marketing the resources they needed to own their accountabilities.

The Moral: Sometimes the core responsibilities of each team are best served by bringing in an outside partner.

3. Pantheon Builds Cross-Functional “Tiger Teams”

When our founders started marketing Pantheon, it seemed like website hosting would be a no-brainer. Our product is a website platform; why not run the marketing website on the platform?

It made sense, and the hosting was top-notch. But after a few cycles of development and deployment, they found our small team was starting to retreat into silos. Each person on the team had crucial information about how one or two aspects of the site worked. No one had a complete picture of the whole thing. We couldn’t get much done without playing telephone throughout the organization.

We knew we had to build a complete skillset within the marketing organization to help the team manage the website more efficiently.

To accomplish that, we took the traditional DevOps approach of combining teams and built a “Tiger Team” with stakeholders from every part of the company. This team shares knowledge with each other and works together daily to solve problems. The team is now empowered to keep things running smoothly without having to play phone or email tag.

The Moral: Communication problems can be just as much of an obstacle as technical problems, and just as worth solving.

Marketing & IT, Happily Ever After

Marketing is an increasingly technical practice. That means marketers need to work together with the IT/Engineering department, and vice versa, to get the best results. These examples show how the two can trip each other up, and how a DevOps approach can make an organization run more effectively.

Just remember: DevOps isn’t always about finding the right technology to solve an organizational problem. DevOps is about developing a culture among the people in your organization. It’s an approach to solving problems, not any one solution. As such, it takes time to create a DevOps culture—but that time is well spent.

Pantheon is a website management platform designed to make collaboration easier—Try it for free.