One of the most gratifying things about writing publicly is when someone doesn’t just agree or disagree in passing, but takes the time to really engage with your thinking. Matt did exactly that in post about Marketing Platform Engineering on his blog, and I want to start by saying thank you.
There’s something deeply nostalgic and deeply right about this kind of interaction. A blog post responding to a blog post. Thoughtful engagement that stays where the thinking originated, rather than being flattened into a tweet or a LinkedIn comment. That kind of exchange is rarer than it used to be, and I’m genuinely grateful Matt chose to engage this way.
Matt is also one of the smartest people I know. He’s spent far more time thinking about organizational design than I have, and he brings a managerial and leadership lens that I simply don’t yet have. I learned a lot from his post, even in the places where I ultimately land somewhere different.
Today, I want to focus specifically on the organization design aspect of his piece. If you haven’t read his post yet, go read that first. 🙂
MPE as a dual-alignment function
One of the core points Matt makes, and one I fully agree with, is that MPE’s purpose comes from two departments, and must align with both.
That framing resonated deeply with me because it mirrors how the work shows up day to day. Regardless of where MPE sits on the org chart, the team is constantly operating in between marketing and engineering. There is a lot of translation involved. A lot of making implicit assumptions explicit. A lot of helping each side understand not just what the other wants, but why.
This isn’t something unique to one reporting structure. It’s inherent to the role itself. Because MPE lives at that intersection, alignment with both sides isn’t optional, it’s part of the job.
Company context shapes what “right” looks like
Another part of Matt’s post that really sharpened my thinking was his distinction between platform companies, SaaS companies, and what he calls “regular” companies.
Reading that section made me realize how unspoken my own lens has been throughout this series. I’m used to working in software-first organizations, where engineering is always present, central, and structurally important. That’s a very particular slice of the world.
Matt is absolutely right that in many companies, engineering either doesn’t exist in the same way or exists in a form that has very little overlap with marketing technology. In those contexts, it would make no sense at all for an MPE team to sit within engineering. In a mechanical engineering firm, an insurance company, or a manufacturing business, MPE should very clearly live inside marketing.
That nuance matters. It doesn’t invalidate the engineering placement argument, but it does limit the contexts where it makes sense.
Budgets, accountability, and structural tradeoffs
Matt also raised something I hadn’t thought through carefully before: budgets.
In theory, “the company funds the team.” In practice, departments own budgets. Someone pays.
I agree with Matt that in most cases, it makes sense for MPE’s budget to come from marketing. Marketing is the customer. Marketing is who the platform primarily exists to serve. That alignment is clean and intuitive.
Where I start to diverge slightly is in the assumption that budget ownership must automatically determine reporting structure.
Engineering organizations already fund teams that don’t build end-user features: infrastructure teams, enablement teams, internal platforms. You could reasonably argue that a marketing platform is another internal platform, and that from an accountability and rigour perspective, it belongs within engineering, even if marketing is funding it.
That setup is undeniably messier. It introduces friction with finance, with planning, and with incentives. But it may also create clearer accountability and stronger pressure for the two organizations to learn how to work together.
I’m currently living inside that experiment. Marketing funds the work, while the team reports through engineering. So far, it’s workable. Whether it’s sustainable long-term is still an open question.
Rigour, speed, and the value of tension
In one of my posts, I implied that placing MPE within engineering allows a CTO to provide air cover around rigour and standards. Matt pushes back on that framing in a thoughtful way, and I think he’s right to.
The more I sit with this, the more I think rigour isn’t primarily enforced by org charts. It’s a function of how MPE behaves and what standards it chooses to hold itself to.
What is very real, and something Matt’s post helped me articulate more clearly, is the tension between marketing’s desire to move fast and engineering’s desire to move right. That tension isn’t a problem to solve away. It’s a productive force.
Where MPE teams lose their ability to create compounding value is when they collapse that tension, when they fully optimize for speed or fully retreat into purity. Either way, the platform stops being a platform.
In some organizational setups, including ones where budget and reporting don’t perfectly align, that tension becomes harder to ignore. Not because MPE should be responsible for fixing organizational dynamics, but because the structure itself resists oversimplification.
That balance is difficult. I’m still learning how to navigate it.
Continuing the conversation
I’m deeply grateful to Matt for engaging with my work so thoughtfully and generously, and for taking the time to write such a considered response. His post is excellent, and this piece only engages with one part of it. I’m looking forward to engaging with other aspects of his thinking in future posts. 🙂
Leave a Reply