I ’ve seen the same basic marketing mistake play out at some of the best software companies in the world: If your marketing team needs help from engineering to update their website (publish new posts, edit copy, upload images, etc.), then they have been set up to fail.
This mistake is most often made when executives of companies (often engineers themselves) are unfamiliar with the day-to-day job of the marketers, website designers and developers they employ. I know of software companies with hundreds of millions, even billions of dollars of revenue on the line where marketers are simply unable to do their jobs and have to wait on engineering for days/weeks/months to make updates to their websites.
Launching new online campaigns can mean waiting for the engineering team of the company to de-prioritize working on product features to create time for marketing’s needs. It can become a large-scale organizational dysfunction.
This is insane (making the same predictable mistake over and over again) and it should stop. It’s 2016 — we should not still be having this debate.
In this post, I want to dive deep on how this problem gets created, why it can be ignored for so long and what marketers (and enlightened startup executives) can do to fix it.
What is a website?
There is a reason one of the first marketing investments your company made was building your website. When companies first get going they will often put up a website before they print business cards. Your website is literally the face of your company — it is instantly accessible by anyone in the world via the Internet, putting them at the strategic center of any digital marketing effort. For this reason, more dollars are spent on websites ($190 billion) than all of the digital advertising ($154 billion).
The website at early startups often is seen (and built) literally as an extension of the product — with flat HTML/CSS and deployed on the same code-path as the company’s core product. This makes sense when the same team that designed and built the product has all the marketing responsibilities themselves.
But some day you need to grow up, hire marketers and build a proper website. I know of multiple startups with >$50 million revenue where website updates require a new deploy of their core product. This means every time marketing wants to update their website copy, they have to convince engineering to make a new deploy.
A good marketer obsesses over messaging, writing, branding, SEO, SEM, analytics, etc. Some of them can code, some of them are analytics engineers — but they are not software engineers (they are marketers!). Requiring marketers to learn how to submit a GitHub Pull Request and go through your engineering approval pipeline to do their job is taking dogfooding a few steps too far. You are now needlessly bottlenecking their work and making it needlessly challenging for them to do their jobs.
What is a website?
There is a reason one of the first marketing investments your company made was building your website. When companies first get going they will often put up a website before they print business cards. Your website is literally the face of your company — it is instantly accessible by anyone in the world via the Internet, putting them at the strategic center of any digital marketing effort. For this reason, more dollars are spent on websites ($190 billion) than all of the digital advertising ($154 billion).
The website at early startups often is seen (and built) literally as an extension of the product — with flat HTML/CSS and deployed on the same code-path as the company’s core product. This makes sense when the same team that designed and built the product has all the marketing responsibilities themselves.
But some day you need to grow up, hire marketers and build a proper website. I know of multiple startups with >$50 million revenue where website updates require a new deploy of their core product. This means every time marketing wants to update their website copy, they have to convince engineering to make a new deploy.
A good marketer obsesses over messaging, writing, branding, SEO, SEM, analytics, etc. Some of them can code, some of them are analytics engineers — but they are not software engineers (they are marketers!). Requiring marketers to learn how to submit a GitHub Pull Request and go through your engineering approval pipeline to do their job is taking dogfooding a few steps too far. You are now needlessly bottlenecking their work and making it needlessly challenging for them to do their jobs.
Let engineers code, and let marketers publish their content! Marketers who can’t control their content can’t do their job.If you delay too long and take this to the extreme, you end up with a marketing team of dozens of employees where they can’t update and control the content themselves. How would you like to work on an engineering team where in order to deploy code you had to wait in line in the copyediting queue to get marketing to approve the grammar and sentence construction of your code’s comments?
Enter content management
Simply put, content management software enables marketers to update the content of their websites themselves via a graphical interface. No coding, no pull requests, no code-review — no engineering intervention required. Content management works. Content management enables marketers to do their job.
Content management software has been around for more than 20 years but, strangely for such a large ($190 billion) industry, it has only recently matured. Drupal and WordPress between them now command 65 percent share of the market (going to 80 percent quickly). WordPress and Drupal have won the market primarily because the industry of professional website designers and developers have, by and large, standardized their work on the software. Increasingly over the last few years, if you are professional website developer you won’t get hired by marketers unless you use Drupal or WordPress.
Most marketers by now know how to use these tools and are comfortable using them (just ask them!). There is an increasingly robust vendor ecosystem (in which Pantheon competes) that specializes in operating — hosting, scaling, tuning, developing — WordPress and Drupal sites. But it is a specialized industry with its own tools and vendors, connected but separate from the wider software engineering industry. I’ve found many engineers at startups who are pulled into website projects but often are not up to speed on the content management industry, which contributes to this disconnect.
How website technology decisions at startups go down
Does this sound familiar?
- Pre-seed: The engineering and product design team for the company’s product own the website. It’s often flat XHTML/CSS hanging off product code base. Life is simple and engineers manage the content themselves. This works!
- Seed stage: You have your first marketer on staff. You try to teach them how to update the website. It’s pretty hacky, but it kind of works. You know you are bottlenecking them, but who has time to go implement a whole new website?
- Series A: You are now scaling up your marketing team. You have a marketing executive who keeps bringing up the website and how they can’t really update it themselves. They want WordPress. You suddenly remember how much a PITA that last WordPress site was that you had to manage, so you plead “I hear you, but I don’t think we can prioritize this right now.”
- Scaling: You now have a sophisticated marketing team built. Content marketers, writers, editors, designers, demand gen, the whole shebang. The marketing team has given up on owning the website. You’ll hear the odd grumbling now and then, but “it is what it is.” Your product team (designers and engineers) must be heavily involved in any new marketing campaign launch. Things seem to move much slower than they should, but the thought of re-building the website feels totally overwhelming to everyone involved. At this point, nobody wants to own it.
- Then: One night you are browsing a competitor’s or sister company’s website and you realize how much you hate your website. Your website may be well-designed, but it is incredibly thin on content. You know it doesn’t fairly reflect the quality and depth of your product and your company . You know demand-gen is suffering and you can see why — the volume and quality of publishing on a proper website is incredible. You’re sitting in a (stunning) 1967 Camaro to drag race with a Tesla. Your website may look cool at first blush, but you are being left in the dust.
Even if you are convinced that marketing needs content management, it’s not like you can just snap your fingers. Let’s get into the real horse-trading that happens when it comes to managing your company’s website. And let’s make sure marketing is properly armed because it’s not always fair pitting a marketer against your world-class engineers weighing in on a technology decision.
Top reasons engineers will use to try to explain why you don’t need content management software (and what to tell them)
We can’t run WordPress or Drupal because it’s insecure.
This is a very lazy excuse. While it’s true that you need to manage Drupal and WordPress security updates, that is true of all software for which engineers are responsible. It would be like a marketer saying “We can’t invest in PR because it may result in bad PR.” Technically true, but wrong nonetheless.
It may be true that the engineer may not want to take on the security burden themselves, which is fair, but there are a number of great options for outsourcing this responsibility.
My follow-up question for your security-minded engineering: Do we really want to run our public, Internet-accessible website on the same infrastructure as our product and user data? Breaking out your website from your product can improve security via security in depth.
Our website developers don’t want to use WordPress or Drupal.
This often happens if you are borrowing engineers from your product team to develop your website. Engineers who build products for a living are more familiar with tools for software engineers — React, Ruby on Rails — as opposed to the tools professional website developers use, such as WordPress and Drupal. This can be especially tricky if these developers are shared between product and marketing; it is hard to ask engineers to flip back and forth between two very different kinds of environments.
However, to be fair to marketing, you are making an implicit trade-off. You need to sit down and decide what’s more important: for your front-end engineers to use the tools they prefer or for your marketing team to be able to manage their content. That’s a decision that requires thoughtful weighing of trade-offs.
Long term, obviously, the real answer here is to get marketing their own resources for developing the website. The sooner the better, because it will become increasingly hard for the product teams to carve out time to help to market; they have their “real” jobs to do, of course.
This flat-file website technology I use to update my personal website is way better than Drupal and WordPress, so we should use it instead. I’ll teach you how to make a Pull Request, it’s easy!
This is pure hubris. Marketers, not your engineering team, are experts in evaluating marketing software. What would happen if your marketer went up to your CTO and told them “I went to this conference and saw a demo of this data-center management software from Oracle that is SUPER powerful? I am really concerned that we are missing the boat here.”
If an engineer ever tells your marketing executive they know how to evaluate marketing technology better, your marketer should smile politely and stay firm (and feel free to send them to this post).
WordPress and Drupal are overkill, our engineers are going to build you a custom CMS that will work way better.
This is beyond hubris. It’s really stupid. Anyone planning to spend hundreds of thousands of dollars (let alone millions) building a custom CMS is on a fool’s errand. I am not understating the risk. In extreme cases (e.g. at digital publishers) I have seen these decision derail companies.
What would you say if your CTO came to the conclusion that in order to build your product they needed to develop their own proprietary replacement for the Linux kernel?
WordPress and Drupal are huge, established open-source projects with thousands of contributors and ecosystems of hundreds of thousands of professional developers, marketing users, and vendors. In terms of successful open-source projects, they are right up there with the Linux kernel. They have leveraged hundreds of millions of dollars of open-source engineering effort. They are incredibly robust products.
Your engineering team may be talented, but they are not going to build a replacement for WordPress or Drupal overnight. They are going to build you a complicated, buggy website money pit that your marketing department will be married to indefinitely. For a marketer, this can be job-ender.
If your engineering team came to this conclusion, you need to push them hard — your company cannot afford this mistake.
We are too invested in our current website stack right now and there is no way we can prioritize rebuilding it right now.
This is a tough one as it’s a high-level and high-stakes prioritization decision for your company.
You first need to answer for your company, how important is our website? I would start this exercise by finding out what percent of your leads originate on your website. (For software companies this is often as high as 95 percent.)
You will then need to weigh the cost (time and money) of rebuilding your website against the opportunity cost of having a high-functioning website. To be fair, you will need to weigh in the project risk of the transition itself as these projects can be complicated.
Finally, you need to answer: If we don’t rebuild our website now, then when will we?
Slowly, but surely rational business decision making will win the day.
