Hire engineers who don't mind talking, with Brian Douglas from OpenSauced
By Friday of the week he started reaching out, Brian Douglas had 20 of the top 25 JavaScript open source projects testing GitHub Actions. His actual advice for hiring your first advocate: skip the dedicated DevRel hire and find an engineer who doesn't mind talking.
Brian Douglas, also known as bdougie, is the founder of OpenSauced, an open source intelligence tool. He was previously employee number 3 and Developer Experience lead at Netlify, then Director of Developer Advocacy at GitHub through its acquisition by Microsoft.
We get into the 30/60/90 day plans he pitched at both companies, why he mapped his boot camp tour to NFL cities, how GitHub identified which open source projects actually mattered for GitHub Actions adoption, and why he thinks GitHub stars are close to a meaningless metric today.
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 joined Netlify as employee number 3 with a 30/60/90 day plan. What was actually in it?
I'd been a power user of Netlify for about a year before joining — they didn't even have a paid plan yet — running my own blog and podcast on it. In what was really more a coffee chat than an interview, they asked how I'd make an impact, and I pitched a 30/60/90 that looked more like a business development plan than an engineering one. Netlify's whole value was taking what you'd normally do by zipping a project and uploading it through the AWS console, which was a beast to use back then, and making it dramatically simpler. In the first 30 days, the plan was just: make the product good — we were moving from Angular to React and adding onboarding tools. In the first 60 days: go to every boot camp and teach students to build a portfolio site, because it's low effort — build a template, ship it on Netlify. The whole pitch was that within 30 seconds to a minute of hearing the name Netlify, you should have a site live.
What did actually executing that boot camp strategy look like day to day?
I mapped out every NFL city — there are 32 teams, and if a city has an NFL team, it's a big enough market to have a university and probably a boot camp nearby too. The plan was to go to the city, meet boot camp founders and CS professors, and teach their students how to use Netlify. I'd leave behind a curriculum — literally a standard URL, backed by a GitHub repo, that instructors could embed directly into their own curriculum with zero rewriting. It helped that create-react-app launched that same summer, which meant you could go from a brand-new React app to a live Netlify deploy from the command line in about 30 seconds — I wrote a blog post called '30 seconds to deploy React' that did well on Hacker News. Once the product story was in place, I just worked my existing network from a previous job at a boot camp, offering free lunch-and-learns where I'd talk about my own career transition into engineering and casually show how to use Netlify along the way.
How did the conference and meetup side of that strategy actually work logistically?
The goal was multiple touch points per city — if I got accepted to speak at a conference in, say, Chicago, I'd also reach out to two or three boot camps there and call up local meetup organizers directly: I saw you on meetup.com, I'll be in town on these dates, would you like Netlify to sponsor pizza — about $500 — in exchange for me speaking about deploying React apps in 30 seconds. It took about six months of doing that before it really got moving, flying around on a shoestring budget, staying in cheap Airbnbs, but conferences would cover travel once you were accepted, so it was sustainable. By the time I left Netlify, we were approaching 400,000-500,000 users, though I deliberately never obsessed over the exact number day to day.
Would that same boot camp playbook still work for a dev tool today?
Boot camps have passed their peak — there are still a lot of them, but the space isn't as vibrant as it was. That said, the underlying model transfers to other communities: Twitch streamers, YouTubers, Discord communities. Build something useful for that group, like a Discord bot integration on your API, and go pitch it around — it's really just business development, sales 101, figuring out a repeatable way to knock on doors. It's a law-of-averages game: the more doors you knock on, the more yeses you get, and the content lives on in that community afterward.
You had a similar 30/60/90 at GitHub. How was that different?
My original plan was to focus on marketplace integrations built on the GraphQL API, but that pivoted hard once GitHub Actions shipped, which was clearly the better opportunity. GitHub explicitly doesn't own community spaces the way you might expect — there's no official GitHub Discord, no official GitHub subreddit — but there are huge adjacent communities like JavaScript, TypeScript, and Rust. So the explicit goal was to become genuinely close with the maintainers of those ecosystems, so they knew exactly who to contact at GitHub when they had a question — building the Rolodex, so whenever we needed a conference speaker or wanted to test a new feature in a specific community, we had a real relationship to call on.
How did the GitHub Actions open source adoption push actually happen?
When GitHub Actions CI shipped in 2019, the goal was getting the top open source projects using it — but first we had to figure out what 'top' even meant, since stars clearly weren't it. jQuery has 50,000 stars and is basically in maintenance mode; reaching out to them wouldn't have moved anything. We built an internal ranking focused on JavaScript specifically, since it was the easiest language to pull good data on, and identified the top 25 or so projects. With just two developer advocates on the team at the time, I DMed and messaged people directly on Twitter — 'hey, GitHub Actions is shipping CI, want to test it, can we jump on a call' — and by the end of that week, 20 of the 25 were using GitHub Actions in some part of their project.
Why do you think GitHub's early bottom-up growth worked so well, before any of this formal DevRel structure existed?
GitHub took no VC money for its first four years and bootstrapped on $5 a month for private repos, catching the market at exactly the right moment for people to start adopting Git and GitHub. Before I was hired as the first proper developer advocate in 2018, the system was essentially every engineer acting as an advocate — if someone loved open source and joined the team, you'd just ask them to go talk to the Rails community about whatever GitHub was working on. It was pure word of mouth, which is honestly a great way to start a company. I think most companies would be better off hiring engineers who genuinely don't mind talking or writing a blog post — someone who knows the product intimately and can also communicate about it — rather than a separate dedicated advocate hire. The same logic applies to early engineering hires generally: someone who can act as a de facto product manager, triaging issues and talking to users, is far more valuable early on than adding a dedicated PM to your burn rate.
What's the actual job of a developer advocate, in your view?
The number one job of a developer advocate is to create other advocates for your product. If you're the only person who can walk into a room and talk about it because you're the only one who cares, you're not doing the job well — you need to be able to step back and watch the machine run on its own. That's exactly what happened with the boot camp strategy at Netlify: once people had that moment of realizing they didn't need to configure the AWS CLI and could just connect GitHub and deploy in 30 seconds, they moved on to solving harder problems themselves — headless CMS integrations, background jobs — which became the next things Netlify built.
You've said GitHub stars aren't a good signal of a healthy project. What should people look at instead?
Stars can be gamed pretty easily — I've seen a widely used project whose onboarding flow had you authenticate with GitHub and automatically star their repo as a side effect of just using the product. And once a project crosses a thousand stars, which is already the top 1% of everything on GitHub, the number stops being meaningful unless you're in the true top handful of projects overall — most star counts plateau somewhere around 50,000 today. At OpenSauced, we built a ranking called Hot, which isn't based on total stars but on how many stars a project got today — a hundred stars in a single day is a much stronger signal that something real is happening than 100,000 stars accumulated with zero new ones in the last three months.
How do you think about vanity metrics like Slack community size for early-stage dev tools?
I constantly hear founders point to something like '7,000 people in our Slack' as proof of traction, and my honest answer is: okay, but what does that actually mean? A lot of the time that's just noise — people who signed up, got auto-invited, and never engaged, quietly using the free tier and getting support without converting. It'd often be far more useful to funnel that energy into something discoverable and SEO-driven, like blog comments or Twitter, where you can actually measure engagement — response time to a support question, click-through rate on a blog post. The question I always ask founders with a big Slack is simply: what are you actually doing with that?
What's the one thing you'd want a dev tool founder to take away from all this?
First, build a genuinely good product. Second — and this is where I see people consistently fall off — actually talk about it. That second part is the part people underinvest in.