Welcome to "Meet the Developer Advocate," a HackerNoon interview series exploring DevRel philosophy, community growth, product-led marketing, and the launches that actually worked. In this installment, we chat with Ondřej Chrastina, a Developer Advocate at CKEditor. With a rich background building DevRel teams across the content management and big data spaces, Ondřej shares his hands-on approach to earning developer trust, the reality of shipping AI-ready documentation, and why transparency is the best strategy for enterprise products.

The Road to CKEditor and Building Scalable Content Workflows

My name is Ondřej Chrastina, and I work as a Developer Advocate at CKEditor. Before taking on this role, I spent years building and scaling DevRel teams for various companies, primarily focusing on the content management and big data fields. After managing teams for a while, I decided I wanted to get back to being hands-on with developers, which led me to CKEditor.

While many people know CKEditor as a rich text editor, it has grown into something much more comprehensive. It is essentially a complete content platform designed to help teams build scalable content workflows. We provide toolkits for real-time collaboration, interoperable converters, and AI integration.

This allows teams to build complex, content-centered applications tailored for business needs. You will find our editor and platform embedded in all kinds of systems. Sometimes it operates as a standard plugged-in editor, and other times it functions as a completely white-labeled developer component hidden inside large-scale enterprise applications.

Defining DevRel Beyond the Marketing Echo Chamber

I see DevRel as a highly flexible field. Depending on the company or the specific product, it can sit anywhere from Research and Development, all the way through Marketing, to Customer Success and Support. For me, the core of the job is about earning your target audience's trust by delivering consistent, hands-on value.

Most of the time, that audience consists of developers, though in my past roles, I also worked closely with data engineers and content editors. You have to genuinely understand their daily needs. Once you have that empathy, you can show them the actual possibilities of the brand, solution, or product you represent.

In my day-to-day practice, I work right alongside the product teams. I follow the internal roadmap, monitor industry news, and plan my projects around what is actually shipping. I have a specific test to see if my approach is working: the product team sends me early ideas or builds, and I try to use them to provide feedback before launch.

When developers in the community start asking me technical questions they would never dream of asking a salesperson, I know I am doing my job right. I will end with one slightly controversial note: if DevRel is only amplifying, or in the worst cases simply repeating, what marketing already says, it is not DevRel.

Bridging the Gap Between Engineering and the Community

Finding a balance between speaking for the company and speaking for the developers requires finding a solid middle ground. I always try to base that middle ground on a real project, a specific use case, or at least a close-to-reality showcase. This grounds the conversation in reality.

On one side, developers get to see an actual example of how the product is used, and sometimes how it can be pushed to its limits. On the other side, I receive much more focused feedback when we discuss a concrete implementation instead of abstract concepts. It creates a neutral zone where everyone can spot issues that might otherwise get ignored due to professional blindness.

When it comes to pushing back internally, examples curated by the developers themselves become an incredibly credible source of feedback. They help steer product decisions toward the developer's actual point of view. I try to be deliberately honest in my talks, articles, and showcases.

Delivering a completely configurable and customizable solution is honestly quite hard. It naturally leads to a complicated API. Sometimes the fix for developer friction is just a simple renaming of a variable. Other times, it takes an entirely new layer of abstraction that wraps the complexity so the default configuration is easy to use.

And sometimes, especially now, you have to take that huge pile of information and make it approachable for AI agents. Remaining open to feedback means understanding the end users' requirements, not just the developer struggles, and bringing that aggregated data back inside the company.

Meeting Multiple Communities Where They Are

Our community is not just one monolithic group; it is really several communities operating at once. First, there are developers who embed CKEditor directly into their React, Vue, Angular, or .NET applications. Then, there are multiple CMS and DMS ecosystems relying on robust content editing capabilities that ship our product as their main rich text editor.

Each of these ecosystems has its own distinct community. A huge part of my job involves showing up on their terms. I go to their conferences, hang out in their Slack workspaces, and participate in their forums, rather than expecting everyone to migrate to our spaces.

Contributing back is exactly what helped these communities grow. When I visit a CMS community, I might run a workshop about something that is not strictly editor-related, like setting up your own AI agents, which actually covers a part of my DevRel workload. I might also share insights on my personal development processes and open source work.

But the most credibility always comes from contributing directly back to the communities themselves. Ideally, I bring useful information straight from CKEditor to the community, while staying reachable so I can carry their voices back to our teams. We also have an invisible community of OEM and white-label developers who integrate us deeply into their own systems. You rarely see them in public forums, but they are a massive part of who I work for.

Enterprise Transparency and the AI On-Premises Campaign

One campaign I am particularly proud of is our CKEditor AI on-premises launch. Enterprise developers kept asking the same uncomfortable questions at conferences. They would say, "This is nice, but can it run inside our walls, with our models?" They wanted to know where the data lives, if they could bring their own keys, and how deeply they could customize the solution.

These are standard, critical questions in enterprise and regulated industries. So, instead of throwing together a glossy marketing launch, we built the entire campaign around deployment honesty. We hosted a webinar entirely focused on running CKEditor AI on-premises with Model Context Protocol tools.

We also created a series of short videos progressing from the simplest on-prem setup to a full Docker Compose walkthrough. We paired this with technical articles covering custom LLM configuration, Bring Your Own Key setups, and model fallbacks. I learned a huge lesson here: for enterprise developers, architecture transparency is the marketing.

The content that performed best was actually the least polished and the most concrete. I am also very proud of our internal dogfooding project. People across our company now use CKEditor for their own content operations, like taking notes, writing summaries, and building reports. Getting the team hands-on with the product right where they work provides incredible internal feedback.

Making Documentation Readable for AI Agents

You can test out CKEditor in minutes, but running a real evaluation with an actual integration into an internal system takes much more effort. Enterprise procurement processes are notoriously complicated, and evaluating an entire list of technical requirements takes significant time.

This is why the free trial matters so much, and why prolonging that trial for enterprise-grade evaluation makes a real difference in adoption. To truly hit the heart of the developer running that procurement, you need to provide:

• A prolonged enterprise trial
• Comprehensive developer documentation
• Interactive demos
• Sample applications

When you offer these resources upfront, you find yourself right on the spot, solving their problems before they even have a chance to encounter issues with your product. Having the actual editor deployed interactively on our documentation and website works very well.

We also maintain dozens of demos configured for specific, repeating use cases, which is a massive help for procurement, marketing, and DevRel alike. You do not need to set up a new demo for every single repetitive use case when people can just try it themselves.

The change I am most excited about lately is making our docs readable by AI coding agents. We shipped a docs MCP server and an AI best practices skill. Now, when a developer asks Claude Code or Cursor to integrate CKEditor, the agent pulls real, current documentation instead of hallucinating a configuration from 2019. The first integration a developer sees is increasingly written by an agent, making it a crucial part of our onboarding process.

Storytelling Through Code: Vibe-Coding and Best Practices

My absolute favorite content is based on actual projects. It might be the internal dogfooding project I mentioned, or a specific repository I put together for a technical talk. The secret is showing the whole journey, complete with errors and debugging, rather than just the final happy path.

The holy grail of our profession is to ship a tool or a content piece that gets used so frequently it eventually becomes part of the product itself. I have been lucky enough to see this happen with some of my pieces. Though, with AI agents, it is getting harder to track how many times a piece of content gets reused.

Agents have massive memories, so they do not need to repeatedly visit a single article to know how a problem was solved. Still, I always aim for every piece to contain something you can take and reuse. It might be a GitHub repository or a code snippet you can just bookmark for later.

A great example is my DrupalCon Chicago article about vibe-coding my very first custom Drupal module to extend CKEditor. It showed the entire messy process:

• The raw prompts
• The technical exploration
• The specific gotcha that cost me an evening
• The final fix

Those learnings migrated directly into the Drupal AI best practices library. The best content tells the whole story, and ideally, it becomes part of the product itself.

Measuring DevRel Success with Goal-Oriented Metrics

Measuring success is the eternal question in this industry, dating back to before DevRel was even cool. My rule of thumb is simple: do not do initiative-based tracking. You must aim for a goal-oriented strategy instead. I have tried many planning approaches, but OKRs are the ones that have stuck with me.

I like to focus on a foreseeable future, usually mapping things out by the quarter. You decide the core focus areas, pick the objectives you can meaningfully contribute to, find your unique value to add, and then define the key results. Because DevRel is so wide, it varies heavily based on your specific activities. At its core, my focus areas typically break down into four pillars:

• Developer enablement
• Developer advocacy
• Developer community
• Developer marketing

Some companies mistakenly think DevRel is only developer marketing, which usually just mirrors traditional marketing KPIs with a developer persona slapped on top. I tend to focus where my strengths lie, which means developer enablement always comes first.

I focus on helping developers reach their goals. The key results might be the number of downloads, API calls processed through our tools, or providing the exact feature that ticks a procurement box. Once that foundation is solid, I move to advocacy, then community, and finally marketing. Each field has its own KPIs, and this progression feels logical to my developer heart.

Showing the Code in an AI-Assisted World

Linus Torvalds saying, "Talk is cheap. Show me the code," is basically my entire job description. Every single claim I make on a conference stage ships with something runnable. It could be a GitHub repository, an interactive playground, or a full Docker Compose file.

When I talk about AI-assisted development, I refuse to just show static slides about the concepts. I show the actual session in real-time. I walk the audience through the prompt, the exploration phase, the inevitable gotcha, and the final fix.

If I cannot build a working demo of a new feature, I do not try to hide it behind nice marketing wording. Instead, I treat that failure as a critical signal worth sending directly back to the product team. If I cannot build it, the community will struggle with it too.

Respecting the Developer's Allergy to Marketing

I definitely agree that developers are skeptical of traditional marketing, which is why I constantly try to put myself in their shoes. If I am the developer deciding on, trying, customizing, or integrating a product, I want to know exactly where the product's strengths lie, and equally important, where they do not.

Knowing where NOT to use a product provides just as much value to me as knowing where it fits perfectly. Only after establishing those boundaries do I want to know exactly how to use it. If that honest message is clear, the content can safely carry a bit of marketing.

It is perfectly fine to brag about strengths or show off impressive benchmark results, provided the technical meat is there. The developer needs to extract real, tangible value first. Once they have that, they are usually happy to be empowered with marketing materials to pass forward to convince the rest of their team.

Making the Developer the Hero

Kathy Sierra's philosophy of making users awesome shows up in my work in two distinct ways. First, in content creation, the goal of a tutorial is never to say, "look what CKEditor can do." The message is always, "look what you just shipped."

We want developers to realize their application now has real-time collaboration, and their editors have stopped fighting disjointed text boxes. The developer is the hero of the story, and our product is simply the trusty tool they used to save the day.

The second way this shows up is when I attend conferences. I run a video format called "Ondrej Askin'," which consists of short interviews where I put the interesting people I meet in the spotlight. The primary goal is to show the audience that these developers are awesome.

I usually ask about their perception of the conference, which gives viewers real value when deciding whether to attend next year. Of course, the guest's company name is in the video, and they sometimes mention what they do. Both sides get immense value, and it opens the door for organic co-marketing.

Learning CSS and Growing with HackerNoon

I remember discovering HackerNoon back when I started at my first company. The senior developers were always dropping industry news into our internal messaging platform. I think almost every software company has a dedicated dev-news channel where the team shares interesting finds.

After a while, I noticed HackerNoon links consistently popping up in that channel. Back in that era, I had no idea which resources were credible and which ones were not. However, the sheer frequency of mentions in a channel full of senior engineers was a pretty good hint about what I should be subscribing to.

To be completely honest, at that time, the majority of the links in our chat led directly to StackOverflow, but HackerNoon was right up there near the top of the list. What really stuck with me from those early days was finally learning the "proper" CSS constructs by reading StackOverflow answers and deep-dive guides on HackerNoon.

There are several people whose DevRel work I deeply admire. I vividly remember Nader Dabit's talk at one of the early Jamstack conferences. He had built his own CMS from scratch, using the very AWS technologies he was advocating for at the time.

It impressed me immensely because he actually built something real. The best part was that his talk was not a pitch for the product he built. It was an honest look at the journey, the learnings, and the technical gotchas he hit along the way. Since seeing that, I aim for that exact kind of plot in my own talks and articles.

There are other DevRel legends I look up to, like Jason Lengstorf, Lee Robinson, and Tim Benniks. I appreciate something different about each of them, whether it is their video post-processing, their quick reactions, or just how incredibly natural they stay on stage or on camera. I constantly try to match the high bar these professionals set.

Huge thanks to Ondřej for taking the time to share his experiences, strategies, and candid thoughts on the evolution of Developer Relations. From embracing architecture transparency to making documentation ready for AI agents, his hands-on approach is a masterclass in building genuine trust with technical communities. Keep an eye out for his next runnable repository, and stay tuned for more conversations in our "Meet the Developer Advocate" series!