One of the most underrated skills in marketing operations is knowing when a problem does not require a sophisticated solution.
Every team has access to people who are very good at building complex things. Technology teams, automation specialists, data engineers — talented people who can architect end-to-end workflows, integrate platforms, and build dashboards that pull from six different data sources. The temptation, when you bring a problem to these people, is that they will solve it at the level they operate.
Which is sometimes exactly what you need. And sometimes massively counterproductive.
We call this the right-size rule: the complexity of the solution should match the complexity of the problem. And in marketing operations, more often than not, the problem is simpler than the solution that gets proposed for it.
The Over-Engineering Trap
Here’s a pattern we see repeatedly. A marketing team has a recurring manual process — a monthly reporting pull, a data handoff to a partner team, a content delivery workflow. It’s slightly broken: maybe one step happens too late, maybe the format isn’t right for the downstream recipient, maybe one team is doing work that another team should be doing.
The team brings it to the automation or technology group and describes the problem. The response — from genuinely capable, well-intentioned specialists — is to propose a comprehensive solution. Build a new dashboard. Automate the end-to-end workflow. Create an integration. Stand up a new platform.
The proposed solution is architecturally sound. It’s also 12 weeks of development work for a problem that could be solved in an afternoon by changing who uploads a file and where they upload it to.
The cost of over-engineering isn’t just the wasted build time. It’s the opportunity cost of the technology team’s capacity going toward a low-value problem at PhD complexity when there are genuinely complex problems that need their expertise. It’s the delay in actually fixing the process while the comprehensive solution is being designed. And it’s the operational risk of introducing a complex system where a simple behaviour change would have worked.
The Right-Size Test
Before escalating any operational problem to a technical team, it’s worth running a simple test: can this problem be meaningfully resolved by changing behaviour rather than infrastructure?
A recurring reporting workflow that arrives in the wrong format can be fixed by communicating the correct format to the team producing the report and giving them direct access to the destination. That’s a communication and access change, not a technical build.
A project tracker that doesn’t have timestamps on comments can be fixed by moving to a tool that does have timestamps, not by building a custom tracking layer on top of the existing spreadsheet.
A campaign brief that consistently arrives incomplete can be fixed by defining what “complete” means, building a simple intake template, and creating a rule that incomplete briefs get returned — not by building an automated brief validation system.
In each case, the technical solution exists and is achievable. But the simple solution also exists, works immediately, and consumes a fraction of the resources. The right-size rule says: use the simple solution first. If it fails, you’ve learned something specific about why the problem is harder than it looks, and you can brief the complex solution more accurately.
When Complexity Is Warranted
This isn’t an argument against automation or sophisticated tooling. There are genuinely complex marketing operations problems that require technical solutions: real-time audience segmentation, multi-touch attribution, behavioral trigger logic, cross-platform data synchronisation. These problems can’t be solved with a behaviour change and a better spreadsheet.
The distinction is straightforward: if the problem involves processing data at a scale or speed that humans can’t match, or integrating systems that don’t share data natively, technical complexity is warranted. If the problem is that the wrong person is doing a task, or the task is being done in the wrong format, or the work is flowing through an unnecessary middleman — those are process problems, not technology problems. Fix the process.
The Brief-First Principle
The right-size rule has a practical implication for how to work with technical teams: always clarify your own vision and minimum viable solution before going into a build conversation.
If you arrive at a technology team with a vague problem — “our workflow is inefficient, can you help?” — you will get a response calibrated to their expertise. They’ll propose what they’re good at building. That may or may not be what the problem actually requires.
If you arrive with a specific, right-sized proposal — “here’s the current state, here’s the change we’re proposing, here’s the minimum viable version that would solve the immediate problem” — you have the basis for a much more productive conversation. The technology team can tell you whether your proposal is technically feasible, whether it conflicts with any existing systems, and whether there are reasons to go further. That’s a scoping conversation, not an open-ended discovery.
The best marketing operations teams we work with have learned to do this instinctively: solve at the simplest level that actually works, document what they learned, and bring that documented understanding to the technical team when the problem genuinely warrants more. They’re not anti-technology. They’re just precise about when technology is the right tool.
Agni Consulting
Agni Consulting helps B2B SaaS marketing teams diagnose operational problems at the right level of complexity — and fix them with the right solution, not the most impressive one.
Book a Strategy Call →Frequently Asked Questions
What is the right-size rule in marketing operations?
The right-size rule is the principle that solution complexity should match problem complexity. Most day-to-day marketing ops problems are process or behaviour problems, not technology problems — and they can be solved faster and more reliably with simple process changes than with complex technical builds.
How do you know when a marketing problem needs a technical solution vs. a process fix?
If the problem involves processing data at a scale humans can’t match, or integrating systems that don’t share data natively, a technical solution is warranted. If the problem is that the wrong person owns a task, the task is being done in the wrong format, or work is flowing through an unnecessary step — those are process problems. Fix the process first.
What happens when marketing operations problems are over-engineered?
Over-engineered solutions consume technical resources that could go toward genuinely complex problems, delay the fix while a comprehensive system is being built, and introduce unnecessary fragility. A 12-week development project that solves a problem fixable in an afternoon is a net negative — even if the final system is architecturally sound.
How should marketing teams brief technology teams on operational problems?
Clarify your minimum viable solution before the conversation. Arrive with: the current state, the proposed change, and the simplest version that would actually solve the immediate problem. This gives the technology team something to react to and scope against, rather than an open-ended prompt that will generate a solution calibrated to their expertise rather than your actual need.