“Thought leadership.” Does the term make you want to run away? Well, hold on to that feeling because that’s likely what your developer audience wants to do too.
That feeling, however, valid as it might be, doesn’t mean you shouldn’t create thought leadership content and that it can’t succeed — even for a developer audience.
As developer marketers, we have to balance competing interests. Empathy for our audience shows that many developers hate marketing but deeper analysis reveals that developers do like blogs and tutorials — partially because developers often don’t consider that kind of content to be marketing.
Teresa Garanhel
The same pattern maps to thought leadership: Developers likely hate what thought leadership most often resembles (think of the cringy posts on LinkedIn) but essays from people like Paul Graham, Dan Luu, and Charity Majors frequently rocket to the top of Hacker News.
Developer marketers need to rethink and reconsider thought leadership. Given creativity and empathy — and maybe never ever calling it “thought leadership” to a developer’s face — this kind of content can do really well.
In this article, I’ll provide three approaches (plus examples) that will demonstrate how thought leadership for developers can work.
1. Share your mistakes and be transparent
“Leadership” is in the name but, if you’re creating thought leadership content for developers, it’s a red herring. For most developers, there are very few — if any — sacred cows and untouchable leaders.
If Paul Graham and Marc Andreesen will get roasted instead of blindly trusted on HackerNews, then so will you.
Don’t lead; instead, build and share your mistakes along the way and provide transparency into your decisions.
Make mistakes and share the details
Developers are builders. Many companies pay their individual contributor (IC) developers as much as an executive; many leaders at tech companies consider it their primary responsibility to “get out of the way” and let developers work; and many companies employ numerous project managers tasked with eliminating blockers so ICs can remain in flow.
The downstream effect this norm has on your content is this: Developers don’t want to be led.
And for good reason! Software development is a craft and even if a truly technical CTO writes about the way everyone else should do things, the resulting content is going to be about as appealing as an architect telling carpenters how to use their bandsaws.
Leading is a red flag for developers — whether you’re taking on an instructive tone or framing an article as containing The One Way to do something. This pattern is subtler than you might think, especially if you come from a marketing background.
Even if your tone is conversational, an article that only pushes a conclusion or a lesson is likely to trigger skepticism.
Instead, effective thought leadership for developers needs to focus on mistakes. If you’re aiming for authenticity, it’s less important to sound any particular way and more important to describe the journey, and the bumps along the way, toward the lesson you want to share.
In the same way that the warm crack of a vinyl record or the sound of a singer straining to reach a note without autotune creates the feeling of authenticity, so too do mistakes in your content cue readers to trust you.
Jennifer Hooper
Right or wrong, developers tend to associate marketing with slick, corporate advertising but if you write about your mistakes — especially if you can do so in a way that opens you up to criticism — then you can at least get past the “ugh, this is just marketing” filter.
Be transparent enough to be uncomfortable and then go a little further
If you talk to developers, one of the top reasons they’ll cite for hating marketing is that it’s dishonest. Much of this expectation is formed by genuine dishonesty in the consumer space but the takeaway is that if you want developers to trust your content, you can’t merely be honest. You actually have to go out of your way to prove that you’re being honest.
“Transparency” is the term for what you need to do but after years of companies bandying the term about to describe their content, culture, branding, and more, it’s been diminished. Many companies now claim to be transparent and have some evidence to back it up, whether they share some small mistakes, talk about their business more bluntly, or publicize their feature roadmap.
All that is good but it’s not enough to provide the counterweight necessary to show skeptical developers that you’re actually transparent, that you’re actually honest, and that you’re not “just marketing”.
Remember, you can’t just be honest; you actually have to think intentionally about how to demonstrate your honesty.
An effective heuristic for this is discomfort. If you’re not at least a little uncomfortable with your thought leadership, then you’re likely not being transparent enough. Push the levels of honesty forward until you’re uncomfortable and then push a little further.
Anthony Witherspoon
A good side effect of this discomfort is that this level of transparency will likely reveal some rough edges to your thinking, your company, or your product. This is great.
Bad thought leadership often sounds sanitized, as though legal and marketing teams took turns chewing and spitting it out. Your goal is to defy the expectations developers likely have of slick, streamlined, too-safe marketing.
Example: Sourcegraph did a deep dive on a mistake
When I worked at Sourcegraph, I edited a piece — written by a developer — about how he fixed a database migration problem that bothered the users managing and upgrading their Sourcegraph instances.
Much of the credit goes to the writer for being transparent. Still, as we worked on it, I re-positioned the article slightly and came up with a title that emphasized the mistake in question: Broken database migrations: How we finally fixed an embarrassing problem.
By using the words “broken,” “embarrassing,” and “problem” in the title itself, we were able to signal to readers that the post was honest and thorough. The same article, positioned as leading the reader to do things right, wouldn’t have had the same appeal.
Example: Hey shared hard numbers
DHH, and the 37Signals team in general, is great at transparency. In a recent example, "We stand to save $7m over five years from our cloud exit", DHH writes about the company’s plan to shift from cloud hosting to self-hosting.
The post is bracingly transparent about the company’s numbers and offers advice:
“Any mid-sized SaaS business and above with stable work loads that does not benchmark their rental bill for servers in the cloud against buying their own boxes is committing financial malpractice at this point. I suggest you call Dell, then call Deft. Get some real world numbers. Make up your own mind.”
DHH earns the ability to offer a lesson in three ways: One, he has earned some trust after years of honesty; two, he’s transparent about the numbers so it’s harder to be skeptical or dismissive; and three, instead of leading, he advises based on his direct experience and tells readers to think for themselves.
“Trust,” here, doesn’t always mean loyalty, either. You might be hesitant to share your mistakes or to be too transparent because you’re worried about trust. But when you’re creating content like this, the goal isn’t to capture followers; your goal is to show readers they can trust you to be interesting and your content to be generative.
Loads of people disagree with DHH but almost everyone trusts the numbers he’s sharing and trusts that he stands by his own work.
Sachin Jha
2. Build hypotheses and frameworks
Lessons tend to be prescriptive and speaking down to a developer is a great way to get them to close the tab. Thought leadership for developers is more effective if you create and communicate an idea that’s more substantial, more adaptable, more caveated, and more nuanced.
Instead of telling developers what to do, provide a hypothesis or framework informed by personal experience and caveated by outside experience.
A hypothesis is more trustworthy than a diagnosis
Thought leadership often takes the form of a diagnosis and for many people, but especially developers, a diagnosis from an outsider can feel insulting.
A lot of thought leadership presumes authors have the ability to understand the nuances of a reader’s problem and provide the right solution. Sometimes too, and this is even worse, authors don’t take the time to identify a problem but just tell readers what to do.
Unless you’re Google and have an enormous amount of credibility, this just doesn’t work. You might read your article back and it might sound authoritative but that tone of expertise will stretch and snap when a reader reads it. Your expertise will sound like a show or a performance. Even if you’re providing genuinely good advice, readers will either poke holes or dismiss it out of hand.
Instead, provide a hypothesis or hypotheses. Write about an experience in the way described above, emphasizing mistakes or demonstrating transparency, and then propose reasons why a mistake happened or why a solution worked. You’ll sound less authoritative but more trustworthy.
Teresa Garanhel
There’s a dual benefit to this too: Now, you can lower the threshold for building or thinking in public because you’re not trying to come up with The One Right Way. Throw out a few ideas; ask for feedback from your community; respond to the feedback; and after a cycle of building, learning, and sharing, you might have a substantial and substantiated idea.
A framework is more powerful than a lesson
Let’s say you’ve done the above or, for other reasons, think you now have a compelling idea to present. Even then, steer away from framing the idea as an instruction.
Despite, however, how much battle testing you’ve done inside your company or with your colleagues, the nature of communicating to the masses will make an instruction fall flat. Once you publish and make your idea available to thousands, readers will either find flaws in your idea or share experiences that make your idea seem less applicable or effective.
There’s a needle to thread here: not all criticism of this kind will be fair but you want some criticism because that’s a primary way people engage. The worst criticism is silence; apathy is a good sign your thought leadership looks like marketing and wasn’t worth a click.
The goal is to create content that encourages engagement and discussion but doesn’t trigger dismissal. The best way to do this, I think, is to create frameworks instead of firing off lessons.
Frameworks take more work than lessons because they require thinking and testing and cycles of feedback and revision. But the result is powerful in two ways: The upfront investment makes a framework useful enough to supersede the “it’s just marketing” instincts and when readers engage and share, new readers are more likely to trace a framework back to you.
In Ask Your Developer, Twilio CEO Jeff Lawson writes about what he calls the “Third Era of Software” — an era defined by companies building tools and APIs rather than end-to-end, one-and-done products. In his words, we shifted “from solutions to building blocks” and my argument is that thought leadership needs to do the same.
Teresa Garanhel
With frameworks, readers can agree or disagree with the particulars but use and adapt a framework to their specific contexts. There’s a distinct open-source feel to content like this and developers will be familiar with the pattern of forking an idea and building on it.
Example: Martin Fowler built a framework so good everyone is still citing it
It feels almost unfair to cite a writer as legendary and respected as Martin Fowler but there’s a takeaway here that’s too important to ignore.
In the post TechnicalDebtQuadrant, Fowler tackles the problem of defining technical debt and categorizing different kinds of technical debt. The post isn’t long — just over 800 words — and while the post makes a couple of references to people like Uncle Bob, Fowler relies primarily on his own experience and thinking.
The result, which closes out the post, is a simple but compelling quadrant diagram.
It’s a good post but this is why it’s a great example: Fowler posted this in 2009 but, over a decade later, people are still citing it and the post is still influencing readers.
If you Google “tech debt,” in fact — a keyword that almost 4,000 people are searching per month, according to Ahrefs — half of the top results cite this post and Fowler by name. The very top result, from ProductPlan, even reproduces the same diagram.
It’s worth noting here that Fowler hasn’t found lasting success because he’s correct. Even though some people disagree with his framework, a substantial amount of people clearly find it useful.
Fowler’s post works because he doesn’t provide a solution but instead provides a framework that is so compelling that people want to use it as a building block.
Example: Sym provides a compelling narrative and a best objection
When you start writing content, a common and mostly correct piece of advice you’ll receive is to ditch everything you learned about writing five-paragraph essays in high school. If you’re writing thought leadership though, I recommend bringing back one lesson: the best objection.
In this example, titled The Authorization Game and written by Sym co-founder and CEO Jon Bass, the author not only makes an argument but announces in the first line of the article that he’s going to make an argument. Before proceeding, he even gives readers an out and links them to a guided onboarding if they just want to try the project.
Then, across about 2500 words and numerous memes and screenshots, the author lays out a story that positions the problem the product is solving as important and contextualizes the problem in a broader history.
There’s a lot to like about this post but I want to draw your attention to the last section, which is titled “Contrary Views on the Main Question”.
In this section, which is essentially a best objection, the author explains “how Sym’s take on the authorization game fits into the wider landscape” and describes products with orthogonal strategies.
Writers are often afraid to include objections because they seem to threaten to weaken your point but the opposite is actually true. In this case, the author wrote a long, compelling narrative about the problem that makes his company’s product necessary — which readers could potentially dismiss as marketing — and ended the post with an objection that reframes the rest of the argument as a hypothesis.
This makes a subtle but lasting difference: If you’re arguing on behalf of a hypothesis, readers feel free to disagree, which makes the content feel less “pushy.” It even gives you a license, as this post shows, to talk extensively about your product.
3. Root your thoughts in the past (both personal and historical)
You’ve seen these pieces: they typically start with a semi-random stat, talk superficially about the industry, cite an example or two (usually from the top results of a Google search), and close with a pitch for the product.
There’s a little research but it’s nothing an experienced developer hasn’t seen before and the author is merely citing it instead of engaging with it. There’s a little thought but you can usually tell pretty quickly the author hasn’t done the work they’re describing or faced the problem they’re illustrating — or even used the product they’re pitching.
Instead, go to one of two extremes: Write from personal experience or do substantial research.
Think of it as a spectrum with personal writing, informed by on-the-ground experience on one end, and research-driven writing, informed by a range of interviews, books, papers, and more on the other end. Most content lies in the messy middle but you can stand out by reaching for either end.
People trust people, so write like a person
I wrote previously about the five-paragraph essay but another bad habit you might have picked up is the idea of “writing from nowhere.” You’ve likely seen journalists and reporters do this but it won’t work for you.
The reason reporters often write like this is to avoid the perception of bias (which is a debatable goal) but if you’re writing thought leadership, your bias is inevitable and unavoidable — even desirable. Embrace it.
When you write based on your personal experience, the ideas can become more narrow and yet, ironically, more trustworthy. “Messy middle” content doesn’t work because even though it might feel more objective or broad to the writer, the content feels thin to the reader.
Personal writing is more trustworthy because your experience provides the evidence and it’s more useful because your engagement with the problem will at least provide readers with a direction.
As I said in the previous section, a building block is often more useful and trustworthy than a lesson. In the same way, a personal experience is often more interesting and thought-provoking than a series of broad statements. Readers don’t have to agree and you don’t have to lead to help.
Jade Warne
That said, personal writing creates a few initial limitations.
Founders and developers likely have the most relevant experiences but they’re not always comfortable writing about them or writing in general. A good writer, however, can interview a person with personal experience and translate that interview, especially given some feedback from the interviewee, into an authentic and compelling post.
A good interviewer can synthesize different experiences into more ideas than the interviewees themselves might initially realize. Do you have predictions about the future of your industry or a framework or a language? Do you believe certain companies should take a particular stance toward a new technology or trend?
During an interview, you can articulate these thoughts and brainstorm supporting evidence. The writer can interview others at the company for more thoughts or, as necessary, prove out your ideas with outside research.
Lead by following
The advice above is more useful the more experience you and your team have. If this is your first company or if you’ve pivoted to an industry you have less history in, it might be harder to rely on personal experience. And even if you do have experience, it’s worth considering the other end of the extreme too: do a whole bunch of research.
If you’ve worked with a writer, they’ve likely mentioned the fact that they do research but this research often leaves much to be desired. I wrote a three-part series on research skills for Superpath because the quality of research is so often lacking.
You can read that series for the long version but some of the research methods you can employ include:
- Building a research database supported by articles, books, podcasts, and papers.
- Assembling a list of smart, influential thinkers in your industry and consulting their writings first.
- Interviewing subject matter experts inside and outside your company.
It bears repeating that a splashy stat in your lede won’t convince a skeptical developer. You need deep and extensive research and ideally, the research includes voices from authorities developers trust.
Abhishek Ratna
Like it or not, if Paul Graham tells people to work hard, they listen, but if you say the same, they won’t.
But if you’re not Paul Graham, you can borrow some of his authority by citing him, citing others, and referencing enough other sources to compile a compelling, believable argument. In fact, you can boost your authority even more by disagreeing with the experts, pitting experts against each other, and comparing expert opinions against studies and vice versa.
The primary point is to make a compelling argument but the secondary point — one that might be even more important — is to demonstrate that you’re immersed in the industry and engaging with its experts and its history.
Think about how you can combine both extremes: a primarily personal article could cite some key studies and a primarily researched article could sound more convincing with a few personal anecdotes.
The best thought leadership has elements of personal experience and deep research but either end of the extreme is much better than anything in the messy middle.
Example: Linear writes from a user perspective and an end-user perspective
In the article "Settings are not a design failure", Linear product designer Adrien Griveau makes the argument that product designers should reconsider the value of settings in their apps. To support the article, Griveau uses personal experience — both as a designer and as a user.
He starts the article with the inspiration behind it, describing a flight that was so boring it caused him to explore his iPhone settings. From there, he argues that settings are not necessarily a design failure, writing that:
“There’s a difference between product settings that a product needs to get right by default and preferences that designers deliberately shouldn’t have a strong opinion on.”
He shifts back and forth from his experience as an iPhone user to his experience designing Linear. And eventually, he marries the perspectives, writing about the experience of Linear users.
He lands his point by avoiding the instinct to write about Linear users as a monolith. Instead, when he writes about mimicking the feeling of a desktop, he writes both about “users [who] never notice it” and users who would think it “feels really weird.”
With personal experience, written through the language and the considerations other product designers would have, Griveau sounds convincing and trustworthy.
Example: Authentik grounds theory in industry research
Authentik is a brand-new startup. The company originates from an open-source project that began in 2018 but it only became a company — using the open-core model — in late 2022.
Many startups at this stage count themselves out of thought leadership. On the one hand, the company hasn’t been around long enough to learn and test many lessons, and on the other, the founders have an impressive background but not a background so esteemed that it would immediately capture interest.
(Like it or not, whether it’s fair or not, that benefit is pretty exclusive to darlings like Google, Meta, and Stripe).
But Authentik led anyway. Instead of focusing on personal experience, CTO Jens Langhammer saw a trend and did the research to argue for that trend’s precedent and potential impact.
In this post, "SaaS apps conceal being hacked, so self host", the topic is the potential rise and return of self-hosting as a software delivery model.
The post dives into five incentives a SaaS company might have to suppress bad news. Each subsection cites relevant research or a compelling example, such as research showing security risks can affect vendor reputation and the conviction of a former Uber CTO showing how legal consequences are changing.
Even still, this feels like a question instead of an argument. Would companies actually consider shifting to a self-hosted model? The article answers this objection by citing three examples of companies changing their delivery models, including the startup Retool, the enterprise Dropbox, and the influential leader 37Signals.
Perhaps most compelling is how the post incorporates a broader history of technology by citing the book Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones) by Marianne Bellotti.
By threading in quotes from this book, Langhammer achieves the dual goal of supporting his argument and looking well-read and thoughtful in the process.
By the end of the piece, readers don’t even have to agree with the thesis to come away thinking of him, and the company, as thoughtful and interesting.
You actually have to be interesting
Up until now, I’ve pulled a small trick on you by offering recommendations despite skipping a fundamental step: You actually have to be an interesting person or offer an interesting product or follow through on interesting projects to create good thought leadership.
The good news is that you or your company are likely already doing more interesting work than you realize. All of the examples I’ve cited above could have been boring without the right framing or without the work done to turn an experience or an idea into something readers might find useful.
Return to the sometimes boring seed of a good article and you might realize that, as a founder, you too have some interesting thoughts that could become essays, or that as a developer marketer, you might know developers who don’t realize their day-to-day work could become a story worth telling.
And on the other end, the opportunity to write and share interesting content provides an incentive to do interesting stuff. Replit, for example, wrote about how users were chatting in the HTTP requests of the company’s blog logs. The growth of this dynamic was bottom-up and top-down, with the community starting it and the company encouraging and facilitating it.
The resulting post about the experience, "The Internet of Fun", shares what happens and uses this moment to make a larger point about what the Internet can be — a message that supports (and demonstrates) Replit’s vision.
I’ve cited some great examples throughout this post but the truth is, examples are hard to find. Developer marketers tend to fall into a content rut, letting the idea that developers hate marketing limit their imagination so much that they only produce product updates or tutorials.
But where there is scarcity, there is opportunity: If you can become one of the few companies that write well about issues that affect software developers, then you can — perhaps ironically — become a leader in an industry that hates thought leadership.
Explore our blog for more expert content, sign up to our membership for exclusive articles, videos on demand, and more, or join our Slack channel to chat with other marketers and get inspired!
Developer Marketing Alliance
