Marketing and Engineering Aren’t Enemies. They Just Think the Other One Is Full of Shit.
Simple tips on filling the void between tech and non-tech teams and improving workflows
Yesterday I recorded a wonderful conversation with ReadyLayerOne, who is in charge of the Solana core team changelog. The premise was simple: a non-technical person (me) asked technical(ish) questions about Solana, and ReadyLayerOne answered. If you want to watch the recording, do it here.
I find conversations like that incredibly important because there seems to be a huge disconnect between technical and non-technical folks in crypto. Many of the crypto projects I’ve ever worked on have had the ghost of that disconnect haunting Slack. It shows up in the #general channel as passive aggressive thread reactions. It shows up in standups when marketing asks “is it done yet” for the fourth time this week. It shows up when devs ship a feature nobody promoted and marketing promotes a feature that quietly got deprioritized three sprints ago.
This communication breakdown between marketing and engineering/product seems to be much worse in crypto than in any other industry. We’re building products that are technically dense, moving at a pace that would give a normal PM a stress ulcer, and operating in a space where the token price makes everyone’s timeline feel like a hostage situation. Add all that up and you get two teams that fundamentally do not trust each other’s read on reality.
But how do we fix this?
What the friction actually looks like
Before we dive into solutions, let’s take a more detailed look at the root cause of the problem.
The friction between marketers and devs is rarely a dramatic fight but rather death by a thousand small disconnects. Marketing announces a launch date that engineering never confirmed. Engineering ships something marketing didn’t know was ready, so the announcement is three days late and reads like an afterthought. A dev explains a feature in language so technical that marketing writes copy that’s either wrong or so vague it says nothing. Marketing asks “can we just say it’s the fastest bridge in Web3” and engineering has an aneurysm because that claim isn’t true and now their name is on it.
Neither side is being malicious - everyone is just trying to do their job and do it well. But they’re operating on different information, different incentives, and honestly, different definitions of “done.”, and when that information doesn’t flow freely across the teams, things get messed up.
What’s actually causing this
In 99% of the cases, the underlying issues are poor communication skills and lack of documented processes for sharing information. In the remaining 1%, the reason is usually one asshole who sabotages on purpose or out of incompetence.
But let’s get back to the 99%; here are the most common culprits.
Different definitions of “finished.” To a developer, done often means the code works and passed review. To marketing, done means the thing is polished, tested by real users, and won’t generate a wave of “this is broken” replies the second it’s announced. Those are two different bars, and nobody agreed on which one they’re using.
Lack of feedback loops: Devs ship fun features that nobody wants, marketing doesn’t collect enough data about what users actually want to pass it on to engineering, and both sides are stuck with suboptimal products they can’t market.
Marketing gets looped in too late. In a lot of crypto teams, marketing hears about a feature when it’s already close to shipping, which means there’s no runway to build a real campaign, get assets ready, or push back if the feature needs more context to land well with the market. Late information forces marketing into reactive mode, and reactive marketing is almost always worse marketing.
Engineers get looped in too late, in the other direction. Marketing sometimes promises things externally, a timeline, a capability, a comparison to a competitor, without checking if it’s technically accurate or even feasible. That’s how you get a dev finding out from a tweet that their product apparently does something it doesn’t do yet.
Jargon runs both ways. Marketers throw around “narrative,” “positioning,” and “funnel” like everyone speaks that language. Engineers throw around technical architecture terms assuming marketing will just get it. Nobody’s translating, so both sides quietly disengage instead of asking the clarifying question that would’ve taken thirty seconds.
The incentive gap is real. Marketing is measured on visibility, growth, and narrative. Engineering is measured on shipping stable, correct code. When those two success metrics aren’t explicitly connected to a shared goal, every conversation becomes a negotiation instead of a collaboration.
How to actually fix it
This isn’t a “have more meetings” problem. It’s a process and translation problem but the good news is that it’s fixable. Here’s what I’ve done in my career to close the gap between engineering and marketing.
Build a shared source of truth for status. Whether that’s a shared roadmap, a Notion doc, or a dedicated Slack channel where engineering posts real, unspun status updates, marketing should never have to guess whether something is actually ready. Guessing is where the trust erodes.
Bring marketing in at the scoping stage, not the shipping stage. Marketing doesn’t need to understand your smart contract architecture, but they do need to know what’s being built and roughly when, early enough to plan a campaign that doesn’t feel bolted on at the last minute.
Create a lightweight technical review step before anything goes external. One quick check from an engineer before a claim, comparison, or technical detail goes into a tweet or article saves everyone from the special kind of chaos that happens when marketing overstates a feature and the community calls it out within the hour.
Agree on what “done” means, explicitly, per feature. Not in general. Per feature. “Done” for a UI tweak and “done” for a new bridging mechanism are not the same bar, and assuming everyone’s using the same definition is how launches go sideways.
What marketers should do to help
The first thing we should improve as marketers is learning enough of the technical basics to ask good questions, not just enough to nod along. You don’t need to read the whitepaper’s math, but you should understand roughly what the product does and why it’s hard to build, because that context changes how you pitch it.
Then, we should stop treating engineering timelines as negotiable. If a dev says two weeks, plan your campaign around two weeks, don’t plan around the date you wish it were and then get mad when reality doesn’t cooperate.
And last but not least, ask “can you explain that like I’m smart but not technical” instead of pretending you understood something you didn’t. Devs respect that question a lot more than they respect a marketing brief full of quietly wrong assumptions.
What devs should do on their side
Solving the disconnect is a two way street, and there are things engineers and technical people can do to avoid it too.
First off, looping marketing in early, even when the feature is half baked. Marketing can’t build a narrative around something they find out about the week it ships. Rough, early information is more useful than polished, late information.
Devs can explain the “why,” not just the “what.” Marketing doesn’t need architecture diagrams, but understanding why a feature is hard or why it matters to users is exactly what makes it easy to write compelling copy about it.
Last but not least, it helps to flag inaccurate marketing claims immediately, privately, and without the eye roll. A quick correction in a DM is a five minute fix. A public correction from your own community is a five day PR problem.
None of this requires either team to become the other. It requires both teams to stop assuming the other one is being difficult on purpose, and start building the habits that close the information gap before it turns into a launch day disaster.
Has this friction shown up on your team? I want to hear the actual stories, drop them in the comments. And if you’re dealing with a marketing and engineering disconnect that’s costing you launches, reach out for a consultation and let’s fix it before your next release.