New: Markdown + AI Website vs CMS

< What gets lost during leadership transitions />

Flywheel.png

Over the past few years, I’ve seen the same pattern repeat across different companies, teams, and stages. It stopped feeling situational and started feeling structural. Leadership changes. Direction shifts. Teams reset. Then the same sequence plays out again.

I don’t think this comes from bad intent or poor leadership. It looks more like a system responding to incentives. Over time, I started thinking about it as a flywheel. Not a formal model, just a way to explain why the same behaviors reinforce each other and keep repeating.

A pattern I keep seeing

It usually starts the same way. A new leader joins with a mandate to fix things. Expectations are high, time is limited, and the organization wants to see movement quickly. There’s pressure to create clarity and confidence, both internally and externally.

That pressure shapes the first decisions. Change becomes the most visible signal of ownership. Direction gets reset, priorities get reshuffled, and the org starts moving before there’s full context on why things look the way they do.

What follows is consistent enough that it’s hard to ignore:

  • A rebrand or reset of priorities
  • A restructure to match the new direction
  • People exit, sometimes by choice, sometimes not
  • New roles open that look a lot like the ones that were removed

Within a year to eighteen months, leadership changes again. The next person inherits a partially reset system, and the cycle starts over.

The leadership flywheel, as I see it

I think of this as a leadership flywheel because each step reinforces the next. New leadership enters under pressure to show progress. Visible change signals momentum. Structural and team changes follow. Outcomes take time. Leadership tenure runs out before those outcomes fully materialize.

The flywheel keeps moving not because anyone wants disruption, but because motion is easier to measure than durability. The system rewards visible change more than sustained execution.

Why leadership transitions often start with change

From the outside, change reads as action. From the inside, it often reads as necessity. New leaders inherit teams they didn’t build and strategies they didn’t choose. There’s limited trust in inherited context and little patience for slow understanding.

Resetting direction, structure, or messaging establishes ownership and creates distance from what came before. The issue isn’t that change happens. It’s that change becomes the starting point instead of the result of learning.

What gets lost first

The earliest losses are quiet. Context disappears. The reasoning behind past decisions fades. Work that was in motion loses sponsorship and stalls, not because it failed, but because no one is left to carry it forward.

Each transition removes another layer of institutional memory. Over time, teams stop assuming their work will compound. They expect it to be revisited.

What gets lost over time

As these transitions stack, the cost becomes harder to ignore. Strategy turns into something that’s constantly reworked instead of built toward. Teams get cautious about long-term bets. Confidence in direction erodes, even when the direction itself is sound.

People adapt by narrowing scope and shortening time horizons. Not because they lack ambition, but because they’ve learned what survives resets and what doesn’t.

The professional impact no one plans for

Leadership transitions don’t just reset strategy. They reset careers. Performance gets evaluated by managers who weren’t there for the work. Progress has to be re-explained. Advocacy disappears when leaders leave, often through no fault of the people they supported.

Growth becomes uneven. Not tied to output or impact, but to timing. This is one of the harder realities to talk about without sounding bitter, but it shapes how people experience their careers more than most organizations acknowledge.

I’ve experienced this firsthand, including situations where positive reviews, bonuses, and pay adjustments existed right up until a leadership change reset the narrative. In those moments, the work didn’t suddenly stop delivering. What changed was how success was defined and which outcomes mattered.

A leadership assumption worth challenging

Teams often get labeled as underperforming when the real issue is instability. Work doesn’t fail because the people were wrong for the role. It fails because the system never gave it time to land.

Strategy gets blamed when continuity was the missing ingredient. Changing players is easier than stabilizing the field, but it rarely addresses the underlying problem.

Entering a team without restarting the cycle

There’s another way to enter an organization, though it’s slower and less visible. Spend time with the team before reshaping it. Separate inherited issues from structural ones. Learn what’s already been tried and why it stalled.

Most teams don’t need to be replaced. They need space to operate without being reset every year. This doesn’t mean avoiding change. It means earning it.

Living inside leadership transitions

For people inside the system, there’s no clean answer. Some leave early. Some stay and adapt. Some get reshaped into roles they didn’t come in to do. Occasionally, a leader arrives who builds with what’s there instead of tearing it down, but you can’t plan on that.

What you can plan for is the reset.

You shouldn’t assume your previous performance reviews will be read. You shouldn’t assume context will carry forward. You shouldn’t assume the work you did speaks for itself once the people who sponsored it are gone. That’s frustrating, and it’s draining, but it’s also the reality of how often leadership changes.

Writing things down helps more than people want to admit. Not as self-promotion, but as continuity. Capture what you worked on, why it mattered, what changed because of it, and what didn’t get finished. Keep a record of decisions, outcomes, and tradeoffs while the context is still fresh.

This isn’t about selling yourself constantly. It’s about not starting from zero every time the org resets.

Over time, these notes become your own internal handoff doc. They make transitions survivable. They give you a way to ground conversations when direction shifts again. They help you advocate for your work without relying on memory or missing context.

You can’t stop the leadership flywheel alone, but you can make sure it doesn’t erase your contribution every time it turns.

Handbook
Developer Marketing Handbook

Goals

Developer marketing builds trust first, pipeline second.
The work connects your product to how developers actually build and helps that credibility translate into adoption and revenue.

A great developer experience is the foundation. It starts with discoverability, continues through docs, and carries into the product itself. Good documentation shortens time to value and builds confidence that your product can scale with real teams. Developers trust what they can inspect, so show how the product works and let the system speak for itself.

Success isn't clicks or vanity metrics. It's measurable engagement that creates product-qualified leads, builds influence across teams, and contributes to both product-led and sales-led growth.
When developers use your product by choice and advocate for it inside their company, you've done the job right.

Strategy

Start with reality, not aspiration.

Map where your product fits in the developer workflow, then help them do that job faster or with less friction.

Lead with clarity. Explain what it is, what it does, and why it matters.

Show the system behind the product. Architecture, examples, and tradeoffs explain more than positioning ever will.
If you can do it in a clever or playful way that still feels authentic, that's bonus points.

The best developer marketing respects time, delivers value, and makes something complex feel obvious.

Journey

Awareness → Evaluation → Adoption → Advocacy.
Each stage should connect clearly to the next.

Awareness happens in places developers already spend time: GitHub, Reddit, newsletters, blogs.
Evaluation happens in your docs, demos, and sandboxes.

For most developers, the docs are the real homepage, so accuracy and structure matter more than polish.

Adoption depends on how fast they reach first success.
Advocacy is when they start teaching others what they learned from you.

Personas

Create personas based on who buys the product and who actually uses it. For example:

Buyers: CTO or Engineering Leader, Senior Engineer, Implementation Architect.
Users: Frontend, Full-stack, App Developer.
Adjacent: Ops, Product, Design.

Each persona has different pain points and goals.
CTOs and Engineering Leaders care about governance and ROI.
Senior Engineers look for performance, flexibility, and code quality.
Implementation Architects focus on how well a tool integrates and scales.
Write for what each person owns, not what you wish they cared about.

Messaging

Be clear first. Be clever only if it helps.
Make every message easy to scan. Lead with the point before expanding on it.
Good developer messaging is specific, practical, and rooted in how people actually build.

Clarity earns trust, but a bit of personality makes it stick.
The goal isn't to sound like marketing. It's to communicate something real that developers recognize and care about.

Build around three pillars:

  • Speed: faster builds, fewer tickets
  • Efficiency: consolidated stack, lower maintenance
  • Control: safe scale, long-term confidence

If you can back it with code, data, or proof, keep it.
If it only sounds good, cut it.

Campaigns

Treat campaigns like product launches.
Plan, ship, measure, repeat.

Each campaign should answer three questions:

  • What developer problem are we solving?
  • What proof are we showing?
  • What happens next?

Treat developer feedback like bug reports and close the loop quickly when something needs to be corrected or clarified.

Make it easy for developers to try, test, or share.
Run retros on every launch and capture what worked, what didn't, and what to change next time. Always learn from what you launch.

Content

Write with clarity and intention. Every piece should help developers build faster, learn something new, or solve a real problem.

Strong content earns attention because it's useful.
Lead with the outcome or insight, then show how to get there. Make it easy to skim from top to bottom.
Show working examples, explain tradeoffs, and include visuals or code where it helps understanding. If it doesn't teach or demonstrate something real, it doesn't belong.

Core content types

  • Blog posts: tutorials, technical breakdowns, or opinionated takes grounded in experience.
  • Guides and tutorials: step-by-step instructions that lead to a working result.
  • Integration or workflow content: explain how tools connect and where they fit in a developer's process.
  • Technical guides and code examples: deeper material for experienced readers who want implementation detail.
  • Explainer or glossary content: clear, factual definitions written to answer specific questions directly.
  • Video or live sessions: demos, interviews, or walkthroughs that show real workflows.
  • Research and surveys: reports or insights that help developers understand the state of their field.

Content strategy buckets

  1. Awareness — generate buzz and discussion. Hot takes, thought leadership, or topics that invite conversation.
  2. Acquisition — bring new developers in through problem-solving content. Tutorials, guides, and explainers that answer real questions.
  3. Enablement — help existing users succeed. Deep tutorials, documentation extensions, and practical how-to content with long-term value.
  4. Convert Paid — drive upgrades or signups. Feature-specific walkthroughs or advanced use cases that show value worth paying for.

Each piece should fit into one of these buckets and serve a clear purpose. Awareness earns attention. Acquisition builds trust. Enablement drives success. Convert Paid turns success into growth.

Clarity is the standard. Use it to earn credibility.

Community

Reddit. GitHub. Discord. Slack. YouTube and other social platforms.
Join conversations, don't start pitches.

Be helpful. Add context. Share working examples.
When your content becomes the answer people link to, you've earned credibility.

Metrics

Measure adoption and revenue, not reach.
Awareness is useful, but only if it drives activation or expansion.

Focus on signals that show impact:

  • Product or API usage
  • Time to first success
  • Product-qualified leads
  • Developer-influenced revenue
  • Retention and repeat engagement

The goal is to prove that trust earned from developers shows up later in product usage and revenue.

Need more resources?

Check out my curated collection of developer marketing tools, newsletters, and resources.

ESC