Life in Revenue Ops

A friend shared this article (by Grace Harbison) with me and I loved it. So much so that I thought it would be fun to share my version based on my myriad of experiences. At conferences or even in online social spaces when chatting with people a lot of situation they are going through many of us have gone through. They are a little difference depending on the level you are at in your career and the company you are at. Most times when you step into a role there is a lot of baggage that comes with it. Processes, technology, contracts, unwritten agreements with other teams. If you are lucky most of it you can change. But know there are a large segment of the population that says they want change until they see it coming.

You will inherit someone else’s decisions

Unless you are starting a startup, No one starts with a clean slate. You walk into systems and processes that have been shaped over time — guided by different leaders and built by different people, under different constraints (culture, budget, time, philosophy, etc). Some of it will make sense. Some of it won’t. Some of it will look like it was built for a completely different company.

You’ll find yourself asking, “What were they thinking?” And sometimes there’s a good reason. Sometimes there isn’t. Most of the time, it’s a mix of both. Hopefully there will be documentation but it will rarely explain why they chose this path only what the path is.

Story time... I was very excited to join this company mainly because I was passionate about thier mission and I loved thier product. On my first day, I wanted to dive in and understand the systems and the business processes my team was responsible for. I asked the team to share docs with me so I could start to get up to speed without taking up too much of their time. Unfortunately documentation was light compared with what the standard I had in place with my teams in the past. I spent the next two months working with the team to build out documents. This exercise wasn't just for me but to help us all as the understanding of how processes worked was not uniform (my team and other teams). If we are all on the same page then everyone has a chance to contribute and evolve the systems. Two of the senior people on the team who managed large portions of the previous build out and with most of the knowledge were less than enthusiastic to share. Explaining the bare minimum and point to the light documentation. Perhaps they were not used to a Senior Director getting their hands dirty and wanting to get into the details. Or perhaps questions about how things worked made them uncomfortable and they saw their knowledge on the current systems is what makes them indispensable. They left the team within the first few months.

Jim Collins' books resonates with my thinking. In Good to Great, he contrasts the ineffective "genius with a thousand helpers" model with the superior "clock-builder" approach found in good-to-great companies.

• Genius with a Thousand Helpers: This model relies on a singular, charismatic visionary who sets the vision while others execute. Collins notes this model is fragile because the company lacks a strong management team; when the genius departs, the organization often fails or loses direction.

• Clock-Builder: Good-to-great leaders build systems and teams that can thrive beyond their presence. They prioritize getting the right people on the bus first, creating a culture of discipline and a "Level 5" leadership style characterized by humility and fierce professional will, ensuring the company’s success is not dependent on a single individual.

No systems is gonna look pristine, especially if it had multiple updates that were more like band-aides than evolution. Just remember there were constraints at the time that may no longer exist and your job is to make things a better match for the current needs and constraints. To do that you need a plan that you stick to. How much time this takes will depend on the culture of accepting change, your free budget, contract expiration timelines, and your team's ability to build and document.

You will have to say no — even when it would be easier to say yes

Too often people don’t come to you with problems. They come to you with solutions.

“I need this field.” “I need this layout in the templates.” “I need this report.”

The problem is their solutions may be a short-term (near sighted) fix with long-term consequences. Always dive deeper to understand what issue they are facing and why they are ultimately trying to do, then see how it best fits into the systems. I remember at one job, I was working with the team to integrate a new systems and part of the process was create data sync. I saw this strange field on the Contact table in SFDC. National Geographic. I thought that's so strange not a typical field and I thought maybe these is a business process I don't know about and I didn't understand what it means. Surely is can't be National Geographic as in the magazine... right? Well the field hadn't been used in years and it was for a one time sales campaign involving subscriptions given to prospects. I found many many more orphaned fields that were sync to and from other systems. Another example there were multiple Industry fields with overlapping values between fields and some were misspelled. Everyone was afraid to delete them because they might have some obscure use or an unknown down stream affect. As time progressed the problem only got bigger.

In Operations, we have to take a longer and broader view. Sure it's supper easy to create a field but is it that the right object? Is there a place to do this that makes more sense? Can we abstract the concept and create a structure that can work for more than just one campaign in one point in time? Most of us in Ops are wired to be helpful and we want say yes and be helpful. It keeps things moving. It keeps people happy in the moment. Saying yes solves today’s problem while quietly setting up tomorrow’s. Saying no — or even “not like that, tell me about your whole process” — is harder. It creates friction. It requires explanation. It forces trade-offs into the open and adds time to take the long view. But that’s the job. You’re not there as an order taker. You’re there to protect the business and the integrity of systems.

If you’re doing it well, no one will notice

A lot of our work is invisible. You fix things before they have any impact. You catch issues before they spread. You simplify processes that people didn’t even realize were complicated.

And when it works, nothing happens. No escalation. No urgency. No recognition. Just… silence. Sure there is a little anticipation from some folks for a new feature/capability you roll-out. But on the whole it's a a lot less eyeball on it from leadership. It’s a strange dynamic. The better your team gets and the systems are stable, the quieter it becomes. And over time, that silence can start to work against you. People begin to assume things are simple. Or worse — that they were always simple. Operational excellence doesn’t look like impact. It looks like the absence of problems. I'm sure this is how IT teams feel as well. Take a page from the IT playbook. Create a cadence (quarterly) around your team's work and some fanfare around roll-outs (creates some anticipation) and up-time style metrics around key processes (set the expectation perfection is not realistic but shows how close we actually are).

When something goes wrong, everyone will notice

The flip side is less subtle. At some point, something will break — and it will be visible. Very visible because our systems are the heart of the revenue engine. It might be a mistake. It might be a missed edge case. It might be a decision that didn’t play out the way you expected. Or with a growing user base it could be just simple user misunderstanding. And suddenly, something that normally runs quietly becomes very loud. People feel it immediately. Questions come quickly. And more often than not, the issue traces back to bad data maintained by users, some conflicting logic required by the business (which they didn't realize conflicted), or logic errors your team missed because of the massive complexity of all the business rules implemented.

You don’t get to opt out of ownership just because the system is complex. What matters isn’t avoiding every failure. That’s not realistic. What's pragmatic is how you respond — how quickly you understand it, how clearly you communicate it, how decisively you fix it, how you you update processes to avoid that type of error or discover it earlier.

My team was responsible for lead routing which included taking campaign responders and attaching them to the right account and scoring them to identify those that should get follow-up. We had a set of automated rules that processed the logic. But when a salesperson gets assigned a lead that isn't at a company they can work... all hell breaks loose and it's an issue leadership takes note of. We saw some of this get worse toward the end of 3rd quarter and into 4th. Despite the systems processing this logic correctly for 99% of the funnel (we didn't have these published at the time)... a few leads were incorrectly routed... this became an high priority issue (as the "sky was falling") which lead to a multi-functional committee to solve. But did is really warrant all this manpower and urgency? Especially in light of the root cause. We discovered the sales management team hadn't been updating the Account team info in the Account records when they had churn on the team. So the system was running the rules as expected (routing based on Account Team membership)... it was just dirty data and poor human data maintenance. It was not material at all to business health. Perhaps if we had a dashboard that's like how IT show three 9 (99.9%) or four 9 (99.99%) up-time... we should have avoided the all hands on deck goose chase.

Even with stable systems and processes, a lot of your team's time is spent on troubleshooting and explanation. Chasing phantom issues that turnout to be not be any kind of misconfiguration but rather misreading of the data or misunderstanding of the logic. This can we helped with selfserve materials that are easy to understand to help team member internal and external understand the processes and logic.

Even the “right” decisions don’t always work

There’s a moment most teams hit eventually. You follow the project process. You align stakeholders. You evaluate options. You make a thoughtful, informed decision. And it still doesn’t work.

The outcome falls short. The environment/constraints changed. The system doesn’t behave the way you expected. The maintenance was understated. The configuration was far more complex than you were lead to believe. The value isn’t there. It’s uncomfortable, especially when you did everything “correctly.” It's not possible to know how everything works and interacts with systems and people before you get it into a working state. The reality of operating in complex environments like enterprise systems. You make the best decision you can doing enough due diligence scaled to the spend on that project to have a reasonably likely positive outcome. If the vendor is open to it a free pilot is a great way to reduce your risk. Otherwise a paid pilot is also a way to get into the inner workings (integrations, configuration and user interface) without getting locked into a multi-year contract. Set the success criteria ahead of pilot if possible and definitely before roll-out as it sometime change the focus on where you spend time during design and configuration.

I remember this project we were rolling out a new version of an email platform. It addressed many of the wish-list items the campaigns team had and implementing and training would be far simpler than to bring in a new platform and integrate into our systems and processes. Was it everything the users wanted? No. But it had everything they would use. It's downfall came in a couple parts. The leaders of the user base had already made up their minds their inability to meet their goals was a technology problem not a targeting, content, and messaging problem. They also bought hook line and sinker a another platform's salesperson's sweet whispers of a utopia if we just switched to their platform. The users really didn't give it a chance and we embarked on a accelerated migration path only to end up on a new platform that user continued to complain about and the campaign teams still could hit their goals. I don't think it was a technology problem.

You will carry context no one else has

This is where the job really shifts. Over time, you become the person who understands how things connect (business meets technology). Not just systems — but teams. Priorities. Trade-offs. History.

You know why something was built a certain way. You know what broke the last time someone tried to change it. You know which decisions will have ripple effects that aren’t immediately obvious. You’re the one holding the threads together.

Often you will hear IT teams describe themselves the same way and we are very similar except that on the spectrum of business expertise and technology expertise. Operations teams have a more business expertise (sometimes having come from practising the business role for a number of years and then shifting to operations). IT has more technical skills and practices, and broader visibility and concerns. My teams have always worked very closely with IT teams but I fundamentally belief tools that are not used across the enterprise should have their ownership and budget sit in the operations team not in IT. Once you lose control of the budget you lose control of pick the best tool for your needs and IT will pick the tool that check the most of the boxes across all teams, optimizing for spend on licenses and support. Deployment and maintenance can be shared responsibility but not budget and product ownership. When you loose control, you can adapt quickly enough to the ever changing business environment of the marketing, sales and customer success teams you support. The reason you can quickly assess and deploy is because you are intimately familiar with their worlds. Where as IT is intimately familiar with the tech and tech rollout and maintenance processes.

Nothing can teach judgment like experience.

You can learn the systems faster than ever now. But those are just tools in your toolbox. Documentation, templates, AI — they can get you most of the way there on how things work. But they don’t teach you what matters. And that depends on your environment. There are some frameworks that can help you navigate. See my other blog posts.

Which trade-offs are worth making is a very situational question. Or when to push back. Or when to let something go. That comes from experience.

From seeing the same patterns (same situation different details/tech) play out in different ways. From making decisions and living with the outcomes. From getting it wrong and living through the pain of having to fix it. It’s slower. It’s messier. It’s also the part that actually makes you effective and special. As you collect all these experiences you build up a database in your mind of these scenarios where the minor details can change but you know the right approach to solve. Decision making frameworks start to form in your head and they are how you deal get more comfortable with ambiguity. You make decisions faster. You stop looking for perfect answers and start looking for durable ones that create stability with regular evolution vs constant rebuild.

Someone else will inherit them and wonder why you did things the way you did. That’s the nature of the beast. We built what we could with the constraints we had and no system can be perfect without any need for change over time. The real value is honing the way you think about systems and processes. The judgment. The perspective. The ability to walk into complexity and make it navigable. That’s the part that compounds and eventually turns into decision-making frameworks.