Making developer videos with Jamie Barton, DevRel Engineer at Grafbase
Jamie Barton's most-loved videos aren't platform walkthroughs — they're six-minute answers to the exact question he's seen asked twice in one month on Reddit or Discord. His rule for documentation on genuinely new concepts: only invent a new word if you're actually pushing the whole industry in that direction, not to sound cool in a headline.
Jamie Barton is a developer relations engineer at Grafbase, a real-time GraphQL platform, and has made well over a hundred developer-focused videos over his career.
We get into why his six-minute, single-concept video style outperforms long platform walkthroughs, why relationship-building is the only real way into creator partnerships, how tiny isolated videos fit inside documentation without going stale, and why he thinks changing your product's core messaging every quarter quietly loses everyone who found you the first time.
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.
You've made well over 100 developer videos. How did your style evolve over time?
I started years ago with an old YouTube channel doing unboxing videos, then small how-tos, all of which I eventually deleted because they were dated and honestly cringey. I moved into web developer content with what I'd call all the gear and no idea. Over the years I've settled into a very specific, short format — no umms and ahs, just straight to the point, so someone can follow along quickly. That style comes from Ryan Bates, from a site back in my Ruby on Rails days, and I've seen the same approach from John and Joel at Egghead. I genuinely prefer watching that kind of content myself, so I prefer making it — but that's my style, not a universal formula. Anyone getting into this should find what actually works for them and their own viewers.
Is it hard to stay disciplined about sticking to one style once you've found it?
Not really — once you have a specific style, it's easy to put it on repeat. What I think a lot of people, myself included, don't do well is reuse content. I've been guilty of posting a video once, tweeting about it once, and never recycling it, partly because repeating it feels spammy to me. But the honest advice from anyone serious about content creation is to reuse material across formats — turn it into a blog post, a short clip, whatever — because not everyone consumes content the same way. I find video quick and easy, but blog posts take me longer, and I've fallen on and off that particular wagon repeatedly. Not everyone likes video; some people would rather read, or watch something short-form on Instagram Reels or TikTok.
What's your actual process for making a video, especially since you find that easier than writing?
If I'm using a tool, whether for client work or personally, and I hit on something others might find useful, I isolate it into something I can teach very quickly. My style isn't walking someone through every dropdown in a platform — it's showing exactly how to do one specific thing, like adding authentication in a React context provider with a particular third-party tool. That specificity is actually a strength, because it opens up dozens of similar videos across different providers. Broader 'let's build this together' walkthroughs go out of date quickly — they're still needed, but I think the shorter and more isolated a piece of content is, the better, because someone can drop in, learn exactly what they need, and move on, and they'll come back for the next quick tip.
How do you actually come up with video ideas?
I don't have a rigid formula — I mostly watch what's happening on Reddit and Discord, tracking what questions people are asking. Once I see the same question come up once or twice in a month, that tells me there's a real opportunity to create something that helps not just those people, but the next wave of people who'll hit the same issue in six months. That's typically how these ideas come about, and it's why my videos tend to run around six minutes rather than an hour.
Is it better to make this content yourself, or partner with external creators?
Partnering is great, because outside creators bring their own ideas and style, often surfacing new and interesting ways to use a platform that I'd never think of myself, since I'm naturally biased toward what I'm already comfortable with. When I hand someone a fully prescribed project, the result tends to be fine. But when I just hand over the core idea and let them run with it, the results are often amazing, because the creator feels genuine ownership rather than following instructions purely because they have a big following — they get to explore and enjoy the process rather than feeling bored and restricted.
Finding creators willing to partner with you can be really hard, especially for a lesser-known dev tool. How do you actually approach that?
I focus on building real relationships and making genuine friends in the space, so there are specific people I can reach out to directly when an opportunity comes up. Doing something like this podcast, for example, puts you in people's minds after every conversation — keep those relationships alive and reach out over time, and you'll find you can reach people you otherwise couldn't. I've cold-messaged plenty of large creators over the years who never replied, simply because they get thousands of DMs — but now I can often go through a mutual connection instead. The more relationships you build, the easier this becomes; it really is who you know, not just what you know.
Does that relationship-building extend to company-to-company partnerships too, not just individual creators?
Definitely — startups I've worked at have built partnerships with like-minded companies in adjacent spaces, like a data company and a warehouse company that both deal with large amounts of data, to do genuine co-marketing together. It's really the same principle as personal relationships — if a friend has a hobby, you might invite them to go play football together. You build friendships in life to share experiences, and the exact same dynamic plays out in the content and business world.
How does video fit into documentation specifically?
Documentation is something I genuinely love, and it's usually the thing I end up spending real time on at any startup I join, because it needs to be right — developers need to be able to use it in a way that actually helps the product grow. Video can absolutely be part of that, in the same short, isolated format I described — if you have a documentation page on inviting your team, it's worth breaking that down even further into a video just about inviting a single user, then a separate one on updating a role, another on removing someone. Keeping each video small and isolated means it's easy to re-record just that one piece when the UI changes, without needing to redo everything else, and people are far more forgiving of small inconsistencies, like an avatar changing between videos, when each one stands alone.
If you're joining a startup with no video content at all, where do you start?
I look at the quick-start experience and the actual user base — what are people most familiar with, what's bringing them to the platform in the first place? Are most of them React, JavaScript, Next.js, Vue, or Svelte developers? I've been using Next.js since basically the day it launched, around when GraphQL was just taking off, and over time I built content specifically around that, which let me point new users to a video combining Next.js with whatever product I was working on — helping them grow in that ecosystem while also learning the product, and building relationships within that specific developer community at the same time.
What do you think startups tend to get wrong, or right, with documentation more broadly?
Documentation needs a clear starting point — don't clutter your docs homepage with a dozen competing calls to action. An advanced user who's used your product for a long time will usually head straight for advanced guides or the API reference; they don't need onboarding fluff, they want the raw technical detail. But documentation that works well also has a genuinely good quick start — get started with your favorite framework, the way Tailwind, despite being a hugely popular CSS framework, still maintains specific framework guides so you can quickly install it into whatever you're already using and get straight back into your own comfort zone. That kind of framework-specific quick start, along with copy-pasteable examples like API requests or functions, massively reduces the friction of just getting started.
There's a view that docs shouldn't introduce obscure new concepts or invented terminology early on unless truly necessary. What's your take?
I agree, and I've seen this go wrong directly — a previous startup wanted to call their dashboard something bizarre, like a 'cockpit' or 'command center.' It's just a dashboard — that's a term everyone already understands, so don't rename it to sound clever. The same applies to documentation generally: be clear and concise, with less invented vocabulary. That kind of thing is usually driven more by marketing's desire for cool-sounding language than by any real user need — just tell me what I need to know.
What about a genuinely novel concept, where there isn't an existing word that fits?
There's a legitimate place for new terminology when you're actually trying to move an entire industry in a direction, not just dress up a feature. Composable commerce is a good example — that term evolved organically over roughly five years, and the startup I was at then was talking about the underlying idea years before the label existed. Eventually you get real groups of visionaries and advocates, like MACH Alliance, coalescing around that broader movement. There's a place for that kind of language, but only if there's real substance behind it pushing the industry forward — not just a buzzword slapped onto a headline with nothing backing it up. And critically, don't use a trendy term in your own docs just to seem like you fit into a movement if your product doesn't genuinely support it — developers see through that immediately.
Can you give an example of a company stretching its identity too far with its messaging?
I've worked in headless CMS for the last few years, and before that in ecommerce. If you're a CMS that people use to edit content for their website, that's what you are — don't try to convince people you're something bigger unless you genuinely are. Some companies try to imply they control a much larger slice of a customer's stack than they actually do. If you want to expand into a new area, that's great — talk to your users, build toward it deliberately, which I've seen CMS companies do well by being upfront about the direction. But if you flip your entire marketing to be all-in on the new area and abandon the CMS positioning that got people there in the first place, it's genuinely jarring for developers who found you specifically because you were recommended as a CMS and now see something unrecognizable. Be truthful about who you are, and if you're evolving into something new, bring your existing users along rather than making an abrupt pivot that confuses everyone.
Does that same principle apply to how often a company changes its core messaging?
Yes — stay core to what you're actually doing, and persist your message for as long as you reasonably can. If you change it every quarter to chase more leads or signups, you risk losing everyone from the previous cohort who never saw the change and now sees you describing yourself as something entirely different. Just say clearly what you are, be consistent about it, and build from there — not everyone is checking your website every single day the way you might assume.
If there's one thing every dev tool should keep in mind, what would it be?
Never forget that documentation is part of the product. If product managers and CEOs genuinely understand how much documentation can generate leads and grow both new and existing users, that changes how much investment it gets. I think more people are starting to realize that as developer relations and advocacy have matured as a discipline — even if plenty of people still don't fully understand what that role actually does, it genuinely helps the bottom line.