DevRel from the ground up with Sean Falconer from SkyFlow
Sean Falconer's first hire at Skyflow took eight months — not because good candidates were scarce, but because he refused to fill the seat with anyone who wasn't the right person. His warning: hiring a junior generalist into a first DevRel role is like hiring a new grad as your founding engineer.
Sean Falconer is head of developer relations and product marketing at Skyflow, a privacy API for sensitive data, previously worked in DevRel at Google, hosts the Software Daily and Partially Redacted podcasts, and was previously a startup founder himself.
We get into when a company should actually build a dedicated DevRel function, why the very first hire needs a founder's mindset rather than deep specialization, why outsourcing content rarely solves the underlying strategy problem, and why he refuses to see any tension between DevRel and marketing.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
When should a company actually start building a dedicated DevRel function?
There's genuinely no one-size-fits-all answer — it's highly context dependent. The first thing to understand is that if you're a developer-first or developer-plus product, you're already doing developer relations whether or not you call it that, the same way customer support always exists at a company even without a formal support agent — someone, maybe the founder, is already doing it. A useful signal from my own founder days: if someone at your company, possibly you, is spending 20-30% of their time on something that isn't core to their actual role, that's when it's worth considering hiring someone dedicated to it, so that 20-30% becomes 100% and effectively triples the effort going into it.
DevRel can mean very different things depending on the company. How does that affect the decision to hire for it?
You need to be clear on what you're actually hiring for — community, product influence, awareness generation — and that comes down to your specific pain points right now. A lot of this is a long-term investment; SEO-driven content strategy or community building can take 6-12 months to show real payoff, and event strategy often needs someone to show up at the same events three, four, five times before people start recognizing them. As a founder, you have to weigh this decision viciously against every other way you could deploy the same resources — if you're a ten-person seed-stage company, dedicating one person, 10% of your total headcount, to DevRel is a real strategic bet, and you need to be confident it's genuinely the highest-leverage thing you could be doing before making it.
What does a minimum viable DevRel hire actually look like?
One of the most common mistakes is hiring a junior person for this role — it's the equivalent of hiring a new graduate as your founding engineer. You're essentially asking someone who may have never worked in DevRel before to own execution, strategy, metrics, and tone for the entire function, grow a community, and build authentic trust with real engineers, all at once. That's a recipe for failure. You need someone who understands strategy and can also execute, who isn't rigidly attached to one specific toolkit, because a startup changes direction constantly — something that made total sense today might be irrelevant in a month. Startup experience specifically is key for that first hire.
Why does that first hire need a 'founder mindset' specifically?
Early-stage DevRel usually isn't about long-term strategic plans and clean KPIs, because at that stage you may not even know which KPIs matter yet — it's mostly experimentation. As Mike Tyson put it, everyone has a plan until they get punched in the face, and that's exactly what happens when a whiteboard idea meets real users. Companies go through phases: early on you need innovators who can build the machine from scratch, and later, once you have product-market fit, you need people who can scale it — and it's rare for the same person to be great at both. At the earliest stage, you specifically need innovators, not scalers, which is why that first hire needs a founder mindset: they're creating almost everything from nothing.
You mentioned it took you eight months to make your first DevRel hire. Why so long?
It wasn't about filling a seat, it was about filling a role with the right specific person, and I was patient about it. I talked to a lot of people along the way. I'd generally rather hire slowly and get the decision right than hire quickly just because I technically could. You can consider outsourcing pieces of the work — if writing isn't your strength, for instance — but most people already do a mediocre job with content themselves, and outsourcing that without a clear strategy just outsources the mediocrity. When you do work with an outside contractor, they'll typically only deliver exactly what you ask for, so you need real clarity upfront about what you actually want, or the arrangement won't succeed.
You said outsourcing content usually doesn't fix a weak content strategy, even if the writing itself improves. What's the actual gap?
Writing quality is only one component. A real content strategy, especially for a startup, has to reckon with the fact that your blog is not a destination site — nobody's checking it daily the way they might check Google's or Snowflake's, because you're not yet a known entity people are inherently curious about. You have to manufacture interest, which mostly means assuming your traffic will come from paid marketing or, better, organic Google search — meaning every piece of content needs real discovery value. That starts with understanding what people are actually searching for, the volume behind those searches, and how hard it would be to rank for them, then crafting content deliberately against those specific keywords and building the SEO signal around it. Most people instead generate a pile of ideas that seem interesting to them personally, producing thin content with little discovery value — every page you publish that doesn't add real SEO value is actually dead weight dragging the rest of the site down. Sometimes removing pages helps more than adding new ones; it's quality over quantity.
What specifically were you looking for in that first hire at Skyflow?
The consistent challenge for most startups, unlike a company like Google, is that the biggest DevRel pain point sits at the very top of the funnel — pure amplification and awareness, making people realize you exist at all. At Google, we barely touched developer marketing because Google already has built-in mechanisms for generating interest; our effort went further down the journey, toward developer success and experience. For a startup it's the opposite, which shapes who you hire. I also needed someone fairly general, since the team would stay small for a long time — someone experienced and mature enough in their career to own entire programs independently, while still being flexible enough to pivot on a dime and experiment constantly. Finding that specific combination — real breadth, real independence, and startup-level adaptability — is genuinely hard, which is part of why it took so long.
As the team grows beyond one generalist, how do responsibilities typically get divided?
Over time you get more specialization — some people lean toward the engineering side, owning SDKs, samples, and demos; others own awareness generation, speaking at events and creating content; others own community engagement specifically. With a small team, though, everyone has to be able to context-switch and own multiple areas at once. When bringing someone new in, I try to give them real choice in what they take ownership of, aligning their genuine interests with what actually needs doing — that's when you get the best out of people, rather than assigning ownership top-down. And even once someone owns content, say, that doesn't mean everyone else stops contributing to it — it stays a team effort until you're large enough to afford genuinely siloed specialists.
If measuring everything precisely isn't realistic early on, how do you actually demonstrate DevRel's value?
I'm not saying don't measure things — you absolutely should. The point is that your north star metric can and often should change over time as you learn an early bet was wrong, or the product itself shifts. You need that data for your own sake, even if you're not surfacing it formally at the executive level, just to know honestly whether something you invested time in actually worked, and if not, whether to adjust or kill it. Because DevRel touches so many different parts of a business, no single person internally has full visibility into everything you do — marketing sees you through the lens of your contribution to marketing, sales sees their own slice, product and engineering see theirs. So part of the job is deliberately articulating your impact across each of those areas yourself, since nobody else will assemble the full picture for you.
Does that fragmented visibility create a real risk during budget conversations?
It's exactly why building genuine trust and relationships with cross-functional leaders matters so much — they become your internal champions. DevRel is fundamentally about building relationships with people, usually external developers, but the same instinct has to apply internally. If sales, marketing, engineering, and product leadership are each independently telling the CEO that DevRel is critical to their own success, the CEO ends up with overwhelming cross-functional evidence of value, even without full visibility into the work themselves — and that's what protects the function when budget cuts come up.
You lead both DevRel and product marketing at Skyflow. Is there real tension between the two disciplines, as some in the DevRel community suggest?
Recent industry reports suggest 30-35% of DevRel teams report into marketing, and I'd guess that's even higher at startups specifically, since top-of-funnel awareness is usually their biggest DevRel pain point in the first place. Regardless of reporting line, DevRel shouldn't be confined to that structure — even reporting into engineering, you should still be working across marketing, sales, and product, building those same internal champions. There's a somewhat unproductive tension some DevRel and marketing people feel, almost like being associated with marketing or having ROI-style KPIs taints their technical credibility — I think that comes from a lack of confidence, or a historical bias where engineers saw marketing as less technical or less important. But ultimately none of that matters if the company fails; building something great is a team sport, and silos don't matter compared to that.
How do you personally think about the overlap between DevRel and product marketing?
I think of DevRel as sitting at the intersection of engineering, product, and marketing, while product marketing sits at the intersection of product, marketing, and sales — there's real overlap between the two, especially at a highly technical company. Both are fundamentally about storytelling: in DevRel you're telling stories primarily to engineers, and in product marketing you're often telling stories to a broader audience — but if your actual product sells to engineers, as Skyflow's does, you're telling stories to a technical audience either way. Since Skyflow is a data privacy vault delivered as an API, with developers, architects, CTOs, and CISOs as our primary users, it genuinely makes sense to have someone with a strong engineering background leading both functions at once.