I’ve worked in businesses of all sizes. The principles of great operations are the same. The implementation and execution tends to be quite different.
This article is broken up into the key things that make enterprise marketing ops different. Here is the first one.
You are always trying to solve the problem of scale.
Marketing ops pros love to move quickly. We love to remove inefficiencies, to build new processes and implement them next day, love to discover new platforms and integrate them into our stack in a short timeframe.
At the enterprise-level, while you maintain the spirit of speed, there is a heavy, dark force that hovers above your team at all times. The problem of scale.
When large numbers of people, campaigns, and data need to interact every day, it causes problems. And the problems are unanticipated, not-your-average, makes you say “wait this really happened?” types of problems.
Here is a fun example: let’s say you work in small pie shop. Your scrappy team crafts custom pies each day and puts them in the window for customers to buy. If you run out of sugar, you can send someone around the corner to pick up extra. If a teammate gets sick, it’s not great, but you can manage and cover their work.
Now imagine you have a friend who works in a large pie factory, which is 100x the size of your pie shop. All aspects of the operation are magnified, and specialized. If your friend runs out of sugar, it means that a large shipment of supplies has not arrived, and it halts the production of 2,000 pies over the course of several days. Solving the sugar problem has nothing to do with pie-making – it involves supply chain and logistics, communication and negotiation.
In enterprise marketing ops, you may be dealing with a large data pipeline issue from a proprietary system, hunting down a stray patch of code that another team is hosting – both of which are impacting scores of marketers, and thousands of customer interactions. Solving these problems has nothing to do with platform knowledge, or even marketing.
Which leads me to the next point:
Problem-solving ability trumps platform knowledge.
In coming to work for a large enterprise, I was surprised that we didn’t use technology in the same way other organizations do. Each platform setup was extra sophisticated, or was completely bespoke to our needs (often to solve the problem of scale). And all the skills and knowledge that I had proudly accumulated over the years? They didn’t come as handy as I thought they would. In many ways, I felt like I was starting from scratch.
Here’s why problem-solving skills are more important – because often at the enterprise level, you have to figure out how to solve problems that no one has ever faced before. Let’s say 300 marketers are trying to send an email at the same time. What happens? Which email goes out first? What happens to the other emails? What if you find that millions of records have an error, what will the downstream impact be when you fix it? How will your stakeholders and customers react? Unfortunately, there aren’t any playbooks or checklists that will get you through these problems, and while talking with others can give your inspiration, the reality is that we have to discover the answers on our own.
Speaking of downstream impact, my next point is:
Problems cascade like dominoes. You can’t move as fast as you would like.
Before you read the next sentence, I want you to know that I’m an eternal proponent of moving quickly, and have always advocated the practices described in “The Lean Start Up”, which is a fantastic book every business professional should read.
But in a decentralized enterprise organization, there are numerous interwoven elements, and you may not know what specific benefits users are getting out of your systems. They could be running specific reports with dependencies, they could be using a field that no one else uses, and it could be the bloodline of their entire operation.
So while we try to move as quickly as possible, especially when decisions or changes are reversible, it’s important that we slow down to assess the possible ramifications of our work.
Quarterback of technical resources:
It’s common at mega-enterprises to have engineering resources dedicated solely to marketing. That means the need and skill to coordinate technical people and initiatives takes on a new meaning.
You have to be a pseudo-product manager in helping develop internal products and processes. This is why I’ve started telling marketers to study product management best practices in order to improve at their jobs.
Thinking like a product manager means asking these questions: Who is my customer? What are their needs? What are “needs to have” versus “nice to haves”? What can we reasonably deliver in this time frame?
In addition – adopting agile best practices in terms of product and project management can really help you level up your effectiveness, which is worth another post entirely.
A masterclass in people dynamics
I don’t like the phrase “office politics”, because it has a negative connotation. I prefer “people dynamics” (sorry I forget where I learned this from), and this refers to managing relationships up, down, and across. Now you will inevitably come across colleagues that are jostling selfishly for self-promotion, but that should be the minority. Influencing and getting things done with and through people is the true mark of a leader, and it’s a very important professional and personal skill that you need to develop.
In an enterprise with hundreds of even thousands of stakeholders, the keys are empathy and over-communication. Repeated, clear, and sometimes annoying over-communication.
In addition to over-communication is a deep understanding of your mission and purpose. Large change management initiatives can come apart if enough people make a racket. A solid purpose and sense of why will carry you through the inevitably tough conversations you will have to have in order to make change a reality.
Many of these seem like potential negatives, and for some of you indeed, you are probably reeling hearing about this and will decide that you never want to work for a mega-enterprise.
But I don’t think of it that way. I think that no matter where you work, or what business you are in, you will always be presented with a unique set of problems, which will require you to be creative, collaborative, and resilient to solve.
Mega-enterprise work is just a different breed of problems.