What a year, huh.
A couple of weeks ago, I realized: I’ve now been a DevRel for more than a year! I want to celebrate this Devrolling milestone by sharing some personal takeaways, and perhaps you’ll find them interesting too.
0. How did I end up here?
Around March of last year, we were gearing up for the Devnet release of Citrea. We were a small, ambitious team, about to ship something truly unique: a ZK Rollup on Bitcoin, even though initially it was just on a custom Bitcoin Signet.
There was one tiny challenge though: In this new ecosystem at the intersection of Bitcoin, ZK, and EVM, we needed someone who could collaborate closely with developers, support them by answering questions, and work alongside them directly. With this in mind, I made a pretty radical decision together with the team: I switched my role at Citrea from Protocol Engineering to DevRel Engineering.
We’re now live on Bitcoin Testnet4, very close to Mainnet, in a much stronger & very bullish position and shipping consistently.
Let’s continue with some reflections…
1. Devrelling is not easy!
Sounds ironic, but true.
Coming from a mostly technical background, like many other engineers 💀, I used to think non-coding roles (including DevRel) were somewhat easy - they were just talking in meetings, socializing, and occasionally asking infra engineers interesting questions, you know ¯\_(ツ)/¯.
Yes, this is how many engineers think about it. I am now happy to say that this is completely wrong.
Most non-engineering roles require strong relationship management skills, context-switching rapidly between chats, meetings, deals, and more. Lose someone mid-conversation? You’ve lost them forever maybe. It is just insane, requires massive effort all around. As our game stepped up, I quickly realized I had been too arrogant about these stuff.
So yeah, while building a peer-to-peer network with bunch of technical decisions is a tough job, so does being a DevRel, managing social relationships & strategies, and more.
Show some respect to your teammates, love them :)
2. You cannot blame the code anymore.
I started using Rust Analyzer less and less. Compiler bugs became rare. No more tiny errors that take hours to debug. Instead, now you need to talk with real people with ideas, feelings, connections - and each step you take has real implications for the company. That means, you can no longer blame the code, blame the cache, ask Gemini 2.5 Pro or o3 to generate some code for you.
Which event to sponsor? Which workshop to conduct? Which bounty to put? Which builder to track?
These decisions become critical for long-term success. You’re the unit now. Good luck!
3. This is… marketing for developers?
Good luck posting full tx data to Bitcoin DA
DevRelling is, essentially, marketing your ideas and projects directly to developers.
In an industry where social consensus matters, attention also matters. Content matters, to the extreme.
You need to be punctual, rational, smart, sincere, and most importantly: chronically online. No more hiding in the dark late night broken NixOS builds. (well you still can do it but this time you also need to tweet about it as well, it is a must)
In short, you’re literally the face of the company towards developers. One must act responsibly, and I have to admit that I sometimes struggle with it. I will do better 🫡
4. Are DevRels… Solutions Engineers?
Common question. A good one.
In my view, DevRels don’t always need to be technical. Of course it is a positive, but not an absolute must. Your job is maintaining developer relationships, understanding their needs, and directing them to the right people.
A solid example to this question is my co-DevRel @yilmaz_btc, who’s a great DeFi Strategist by brain, and a pure degen by heart. He’s doing a superb job. He delegates technical problems to me when he cannot solve it. I delegate protocol designs to him when it gets too complex. We identify things together, fix or let our engineers step in.
So yeah, DevRels are not Solutions Engineers completely. We help hackers, point them into right directions, give them solid feedback, and pursue ambitious people.
5. Events, Hackathons, Grants, Incubations, Accelerators…
This is how a rollup on Bitcoin works, @jansuzg_ is a great artist.
When I transitioned into DevRel, I knew I’d travel, attend hackathons, and give out grants. But I underestimated how intense these things would be.
In one year, we attended 10+ events in 8 countries (I think?), sponsored hackathons, launched @CitreaOrigins incubation program for Bitcoin-first applications. And there’s still more planned.
Web3 is relentless. Events mean nonstop networking: finding passionate people, potential collaborations, exchanging contacts, and endless follow-ups. I have to admit sometimes they are too tiring, but they work.
Hackathons involve budgets, bounties, booths, on-call support, debugging, and filtering fake submissions (please don’t do this, folks). It’s a whole work that keeps you away from other stuff.
Grants… well it’s a debate among DevRels. I don’t think they work as intended, like many others. Many grants often lead nowhere - teams move on quickly. Good to see exceptions for sure, but that’s an opinion that gets more supporters to be honest.
Instead, we find incubation programs much more effective. Through @CitreaOrigins we actively partner with great teams that share the same vision like us, such as @tanaribtc, @nectraxyz, @satsumadex, and help them build sustainably. Some fantastic stuff coming soon :)
6. Design bounty tracks that shows the power of your protocol
Don't recycle your old project... you're in trouble if I find it...
For many hackathons there was this one common question: Which bounty should I put? I realized this question matters a lot more than my initial perception. To start, there are two types of hackers:
- Those who chase the interesting bounties
- Those who chase the $$$ bounties
Both makes total sense. However, if you can combine both, things become super interesting. You can be the center of attention and you can suggest crazy ideas for hackers to pursue. And guess what, sometimes they happily do it!
Build a Bitcoin-backed stablecoin. Build an intent-based atomic swap between EVM and Bitcoin. Build a privacy protocol, maybe an AI Agent for payments with privacy-by-default.
All possible on a ZK Rollup on Bitcoin with a trust-minimized bridge. Wdyt?🍊😏🍋
7. DevRel metrics are… super subjective?
Some insights from Carl's survey
As Web3 DevRels, we often get together at meetups to gossip and debate various topics.
Frequently, the discussion boils down to the big question: Do metrics matter? If yes, which ones are actually important?
I spent quite some time thinking about this, especially at the end of last year, reflecting on what I’d done and realized I lacked clear objectives. To fix this, I set some internal goals, numeric targets, and abstract thoughts, aiming to meet these expectations.
After hearing various opinions from other DevRels and checking @CahlDee’s awesome DevRel survey… I’d confidently say there’s no universally good metric for Web3. Wonder why?
The categories of companies vary widely:
- L1s & L2s
- Indexers
- Marketplaces
- Bridges
- Interops
- Abstractions
- Oracles
- and more…
Tech stacks differ significantly: pure EVM infra makes information easily accessible, but different VMs and specialized SDKs require unique expertise.
Team sizes differ dramatically too: some companies don’t have DevRels at all, some have just one, others (like us) have two, and some even have teams of ten or more. Each setup changes how things operate.
Budgets vary immensely: some spend less than $10k per year, others have budgets of $100k, and some even exceed $1 million.
Metrics need to align specifically with your project goals. Sponsoring every major hackathon or having a widely integrated interop solution naturally makes tracking simpler or more complex. If your product competes among countless other EVM chains, your metrics and incentives must be unique, as I mentioned in the above section.
8. Docs are dangerous!
Documentation matters. A lot.
It is the first thing hackers look after your website & Twitter. It’s the knowledge base for people.
It turned out to be a tougher job than what I thought to be honest. Especially because we’re shipping new stuff like crazy: the rollup upgrades, new bridge designs, new ideas & integrations… I will do better on this end, stay tuned :)
9. Your tech & audience shapes you very quickly.
I realized this a lot in the last two weeks, more than I initially thought.
If you’re not aware, there’s an interesting drama going on in the Bitcoin world. Following some discussions on the Bitcoin mailing list, a recent pull request was opened to Bitcoin Core, and well, some people didn’t really like it :)
In this Pull Request, Citrea is mentioned as a good example. Chaos ensued, and people are still debating its effects. I’m not diving deep into it here; maybe in my next blog post, I’ll explain how things unfolded and potential impacts. The only thing you need to know right now is we’re not damaging or lobbying anything :)
Reading the discussions and comments, I realized how much I’ve learned about this space compared to a year ago. This applies to Bitcoin and somewhat to the EVM space as well.
The same goes for other companies: If a company is focused on ZK stuff, their discussions revolve around implementations of zkVMs, open research problems, progress updates, etc.
All of this happens while you’re still actively engaging and learning tons of other stuff simultaneously. It’s not about pure specialization but rather a broad and deep addition of knowledge across all Web3 - if you spend enough time here. I wonder if it’s similar in Web2 DevRels, I don’t know :)
10. Last but not least: everything is on Twitter.
You must stay chronically online in Twitter as a DevRel (true for other roles too but you get my point). It remains essential for visibility, discussions, and outreach. It also distracts your focus a lot, so one must balance these and stay on the line while working.
Maybe a bit controversial but: Farcaster is also cool but still niche and sometimes noisy with airdrop farmers. I see soo many LLMs taking over there, unfortunately. And LLM to real people ratio seems a bit high…
Well, I’d say that’s it for now. Reflecting on the past year, I’m proud of my personal growth and grateful for this unexpected journey. DevRel pushed me in ways that years coding never did. It’s been difficult, rewarding, exhausting, and inspiring - often all at once.
Here’s to another year of learning, growing, and sharing it all with you, this time with Citrea mainnet 🙂
GM 🧡