Get AI summaries of any video or article — Sign up free
Work Week in the Life of a Developer Advocate/ Performance Testing Advocate (k6 and Grafana Labs) thumbnail

Work Week in the Life of a Developer Advocate/ Performance Testing Advocate (k6 and Grafana Labs)

Nicole van der Hoeven·
5 min read

Based on Nicole van der Hoeven's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Developer advocacy at Grafana Labs’ k6 team is organized into three pillars: content, community, and product feedback.

Briefing

A developer advocate at Grafana Labs’ k6 team spends a typical week juggling three jobs at once: creating practical learning materials for developers and performance testers, participating in community discussions as an active user, and feeding real-world customer pain points back into product decisions. The role matters because it turns performance testing from a niche craft into something teams can adopt confidently—through hands-on guidance, not sales pitches.

The week begins with preparation and live participation. After waking up, the advocate shifts quickly into operational work: getting up to speed on the current state and limitations of a k6 plugin so they can speak credibly on upcoming sessions. They then join a weekly live stream (“office hours”), including a conversation with Pawel Suwala, the CTO at k6. The day also includes coordination with community members—such as testing how to use the Clubhouse app with a good microphone—and a customer demo booked through the k6 customer success team. The pattern is consistent: show up, answer questions, and translate practical experience into guidance people can use immediately.

Content production runs in parallel with community and product work. On Saturday, the advocate handles post-publication tasks for the prior week’s office hours: creating thumbnails, transcription, and playlist tagging so viewers can find relevant topics without hunting through a long catalog. They also map out the content calendar and reflect on what worked. Sunday and the following days bring writing and planning: responding to Grafana Labs team member profile requests, drafting talking points for an audio-only Racket.com group, and writing a blog post unrelated to performance testing—about note-taking for Dungeons and Dragons.

Midweek shifts toward editing and preparation for upcoming talks. Editing days focus on reducing interruptions—blocking time to avoid Slack and email noise—then exporting and uploading videos to YouTube and sending them for colleague review. Planning also includes two major upcoming presentations: one for TestCon Europe and another webinar in September tied to Grafana Labs and k6.

The role’s “developer advocacy” framework shows up clearly in how work is categorized. Content includes workshops, documentation, blog posts, and videos that teach how to run load tests and how k6 works. Community means joining the same groups as users and participating in discussions from an insider’s perspective—because developer advocates are target users who use the product, not outsiders trying to sell it. Product work happens through feedback loops: collecting criticism and pain points from k6 users (and sometimes users of other load testing tools) and bringing that input into k6 product cycles as a subject-matter expert.

By the end of the week, the advocate’s goal is not just to explain what developer advocacy is, but to show the day-to-day mechanics—live support, content pipelines, customer conversations, and product feedback—behind a job that stays interdisciplinary and changes constantly.

Cornell Notes

A developer advocate at Grafana Labs’ k6 team uses real performance testing experience to help developers and testers adopt k6. The work clusters into three pillars: content (tutorials, workshops, docs, videos), community (active participation in user groups rather than sales), and product (feeding user pain points into k6 product cycles). The week’s schedule shows rapid context switching between live office hours, customer demos, community events on Clubhouse and Racket.com, and heavy content operations like editing, transcription, thumbnails, and playlist tagging. Time is also protected for deep work by blocking Slack and email to avoid interruptions during filming and editing. The impact is practical: turning load testing guidance into usable workflows and shaping product priorities based on what users actually struggle with.

What three pillars define developer advocacy in this role, and how do they differ from marketing?

The role is organized around three pillars. Content focuses on advocating to developers and testers by teaching how to use k6—through blog posts, documentation, videos, and even planned guided workshops. Community emphasizes being part of the same groups as users and participating in discussions as an active user; the primary goal isn’t selling, which contrasts with marketing’s outside perspective. Product advocacy uses day-to-day conversations and feedback from k6 users (and sometimes users of other load testing tools) to inform feature priorities and join internal product cycles as a subject-matter expert.

How does the advocate balance live engagement with production work?

Live engagement and production run side by side. The week includes joining weekly office hours (including a conversation with CTO Pawel Suwala), participating in customer success demos, and joining community audio groups. Meanwhile, content work continues on weekends and evenings: post-publication tasks like thumbnails, transcription, and playlist tagging, plus editing and exporting videos for YouTube and sending them for colleague review. The schedule shows that advocacy isn’t limited to one format; it’s continuous across support, events, and publishing.

What does “product feedback” look like in practice for k6 advocacy?

Product work comes from collecting criticism and pain points from people using k6 and related tools, then translating that input into concrete feature needs. Because the advocate is deeply involved in community discussions and uses k6 in real scenarios, they can identify what testers typically want—such as specific capabilities or limitations—and bring that perspective into k6’s product cycles.

Why does the advocate block Slack and email during editing and filming?

Interruptions are treated as a production risk. During editing days and full-day filming blocks, Slack and notifications are turned off so background noise doesn’t force re-takes and so the advocate can “put my head down” to finish work. The approach is to protect deep work time for tasks like scripting/talking points, filming, editing, and exporting videos.

What kinds of content operations appear in the weekly workflow?

Content operations include creating thumbnails, generating transcription, tagging videos to the right playlist for discoverability, exporting and uploading HD versions to YouTube, and then sending the finished video to a colleague for review. Planning also matters: the advocate drafts talking points for upcoming talks and avoids cramming by starting preparation early for events like TestCon Europe and a September webinar tied to Grafana Labs and k6.

How do community events extend beyond performance testing?

Community participation isn’t confined to load testing. The advocate joins audio groups such as Clubhouse and plans an audio-only session on Racket.com, while also writing a blog post about note-taking for Dungeons and Dragons. That mix signals an interdisciplinary approach: advocacy work can coexist with personal interests and still feed into the broader goal of communicating clearly and building community.

Review Questions

  1. How do the content, community, and product pillars reinforce each other in a developer advocate’s weekly workflow?
  2. Which specific tasks in the schedule support discoverability and learning (e.g., thumbnails, transcription, playlist tagging), and why do they matter?
  3. What strategies does the advocate use to reduce interruptions during filming and editing, and how does that affect output quality?

Key Points

  1. 1

    Developer advocacy at Grafana Labs’ k6 team is organized into three pillars: content, community, and product feedback.

  2. 2

    Content work focuses on teaching k6 through practical assets like workshops, documentation, blog posts, and videos.

  3. 3

    Community work prioritizes participation as a target user—answering questions and joining discussions rather than pushing sales.

  4. 4

    Product work turns user criticism and pain points into actionable input for k6 product cycles.

  5. 5

    Live advocacy includes showing up for weekly office hours and joining customer success demos to address real testing needs.

  6. 6

    Deep work is protected by blocking Slack and notifications during filming and editing to avoid interruptions and re-takes.

  7. 7

    The weekly rhythm blends live support, publishing pipelines, and early planning for upcoming events like TestCon Europe and a September webinar.

Highlights

The role’s core distinction from marketing is hands-on participation: developer advocates are active users who join discussions primarily to learn and help, not to sell.
A typical week mixes high-touch community moments (office hours with CTO Pawel Suwala, customer demos) with production mechanics (thumbnails, transcription, playlist tagging, YouTube exports).
Time-blocking Slack and email is treated as a production tool—reducing noise during filming and enabling uninterrupted editing.
Product feedback is gathered from community conversations and converted into feature needs inside k6’s product cycles.
Advocacy work extends beyond performance testing into broader communication and community building, including Dungeons and Dragons note-taking content.

Topics

Mentioned

Get summaries like this for any content

Videos, articles, research papers — all summarized by AI and searchable in one place.

Start building your library