Guide to Creating Great Web3 Technical Content

As a freelance technical writer in Web3, I have worked on many projects to help them create technical content. This has ranged from doing developer documentation to writing technical articles to Twitter threads and press releases. I don't think people hire me because of my profile picture (although they might) but because they understand that content matters when trying to win the hearts and minds of developers.

Through this experience, I want to share my thoughts on what I believe what type of content works and what doesn't in this crazy world of Web3. But before we begin...

Is This Really About Web3?

Whenever I write an article about Web3, someone always comments, "This sounds like it could have been written about anything!". I respond with "Good." But here are my thoughts on why Web3 is unique in terms of technical content:

I am on record saying Web3 is a Developer's World. What I mean by this is that there is still so much that needs to be built and scaled before "the masses" really use Web3 technologies without thinking, "I am using a Web3 product". In that way, any project needs developers to build on, test, and explore their product to the fullest.

Traditional content channels are terrible for Web3. In Web2, the lazy "content person" would probably submit a blog post to HackerNews or Reddit and hope it gets some visibility. If you look at almost anything Web3 related on those sites and communities, they get murdered by the "Web3 ate my baby" commentators. So the "good old trusty sites" are not a place for positive developer engagement.

Everything is still so new. I like to look at content with the "jobs to be done" lens. Web3 content has so many jobs to be done. It needs to educate developers with widely different experience levels in Web3; it needs to inspire them to build something and show them how. If I wrote a Web2 article, I would assume the reader understands the difference between clients and servers, but in Web3, concepts like validators, nodes, and addresses may still need some explaining.

So to the guide!

Twitter Spaces

As a major fan of Clubhouse, I was deeply saddened by the explosion of growth of Twitter Spaces /s. Like any content type, there is a right and horribly wrong way to use it. Let's start with the wrong way:

The Wrong Way

Too Many Guests

In a planning meeting, someone says, "We should do a Twitter Space on Blockchain Gaming since we want to get people excited about our new X in Blockchain Gaming." Somebody goes through Twitter and messages anyone remotely connected to that topic. They make a guest list, and everyone is happy that six guests are now secured! The designer is sweating on how they will fit all these profile pics in one image announcement, but I'm sure they will sort it out!

Not Enough Prep

Then the big day happens. It's your host's first time talking to these six fine folks, so the chemistry is about as alive as a Tuesday night Tinder Date. All the guests talk over each other, which is slightly okay anyway since they are all saying the SAME THING. Some people do some reactions early on and then leave. Boom, we did a Twitter Space! Results may vary.

The Right Way

Instead of loading your Twitter space with as many people as possible, limit it to 3 people, including the host(s). Moderation is not as easy as it looks, so do your host or yourself a favor and strive for quality, not quantity.

Find guests who might have some spark or disagreement. This is far more entertaining and educational than just listening to a giant ECHO ECho echo chamber. The The Blockchain Discussion series done by Angie Jones was famous because she openly invited crypto skeptics to debate her. And it got many people talking and researching facts and fiction from what the guest said.

Instead of doing a Twitter Space to secretly or openly promote some new drop from your project, create a recurring series. Series are great because you can build rapport with your audience and the host. It is nice to see familiar faces join. I like what Dawn / run4pancakes is doing with her Biscuit's Bytes Twitter space. The host(s) have good chemistry, and I can expect quality every time, no matter the topic. Plus points for cute names.

Also, prep your guests and hosts. A quick conversation before the Twitter Space will help create some chemistry between the participants and structure for the conversation. Callumat The Web3 Podcast does this well before his episodes.

Live Streaming

I understand people reach for Twitter Spaces first when looking for ways to make content. I do feel live streaming, although requiring more time and tech, is a way better investment. I would over-index in video/streaming.

Why?

• Visibility - Seeing the person coding and teaching is so valuable visually. Not to be too poetic here, but you can feel their emotions when things work (or don't). I also think in a workshop stream, I am highly likely to learn something new, even on topics I am already knowledgeable in, because I can see how others work.
• Replayability: I am much more like to watch a recorded live stream vs. a recorded Twitter Space. Although both were live, the "moment" of Twitter spaces seems to die much quicker than with a live stream.
• Community: On a live stream, I chat with frens. Instead of being limited to those five reactions on Twitter Spaces, I can express myself. This gives a unique sense of community to the audience. No one is doing it better than the WomenBuildWeb3 community in this category. Take notes.

Documentation

I can write 4372374 articles about what makes good documentation (and I just might one day). But here are some highlights:

• That it's there. No docs is a quick way to being irrelevant in the developer's mind.
• Written in Plain English (or preferred language)
• It has code samples with comments!
• It has guides that are end-to-end projects that developers can build.

Your project may have many different types of users - Devs / Product Managers / Major plus points if you include a course or series inside your documentation. Alchemy's Road to Web3 is probably best in class with doing this. As mentioned, onboarding new devs is a crucial job to be done for Web3 technical content.

Hackathons

Hackathons are a massive part of the Web culture. I am pretty sure people make a living by winning these things. My young heart could probably not take looking at the budget people are throwing into hackathons. I think these are a great way to get developers to use your project and also for your developers to get feedback from other devs. This is, of course, priceless but I do feel many projects fail to get the total return on investment content-wise.

Another job for Web3 content is to elevate developers . After a hackathon, you have real developers building actual projects with your product; you need to tell their stories. You can do this through interviews, case studies, videos, etc. But giving builders visibility helps you and them. The story doesn't end with you just tagging them on Twitter in a photo with those funny big checks.

If you are looking for an example of this, look no further than the Dev'N'Tell series from Developer DAO.

How to get started?

Okay, Dan, this sounds like a lot. How can I get started doing this?

Do I need to hire a developer relations person to fly worldwide and attend every conference? Probably not, as much as I love seeing all my frens going to exotic places while I sit behind this keyboard.

Do I need to hire a fancy Technical Writer that will be my content superhero? Probably not, but I do know a guy if you decide otherwise.

You probably have someone on your team who can start creating this content today. They know your product and your message. Before reaching out for external help and new faces, give that person time to build a content foundation. Then, when that foundation needs to be scaled, look for developer relations or technical writers. These people will have a much easier time starting with this foundation, and you will see the results of their work quicker.

This is just Dan's opinion. There are points you may disagree with. Good luck out there, frens making excellent technical content!