Devrelshow Episode 56 - Tamas Piros From Storyblok

Devrelshow Episode 56 - Tamas Piros From Storyblok ![rw-book-cover](https://i.ytimg.com/vi/mk6zJTLqLtA/maxresdefault.jpg) 🔗 **Source:** [Devrelshow Episode 56 - Tamas Piros From Storyblok](https://www.youtube.com/watch?v=mk6zJTLqLtA) > [!note]+ Document Notes > tags: [developer-relations, devrel-metrics, webmcp, agentic-web, ai-and-devrel, developer-experience] > author: Frédéric Harper with Tamás Piros (Storyblok) > source: The DevRel Show (YouTube) > reference: https://www.youtube.com/watch?v=mk6zJTLqLtA > date created: 2026-09-04 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > > [!warning] Auto-caption artifacts. The guest's name renders as "Tamas," "Damash," and > > "Tomasz" across the episode. "Storybook" appears once for Storyblok, "NerdyRella" for > > Nerdearla, "Versel" for Vercel, and "gear mode rock" for Guillermo Rauch. The next guest's > > company ("Kick House") and Frédéric's employer entity ("Tiny MC Tiger") are both unresolved. > > Verify names before quoting. > > # 🏷️ Title: devrelshow episode 56 - Tamas Piros from Storyblok >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Source: https://www.youtube.com/watch?v=mk6zJTLqLtA (The DevRel Show ep. 56, 1:08:42, streamed 2026-09-04) - Tamás Piros — leads DevRel at [Storyblok](https://www.storyblok.com/); his LinkedIn articles on AI-era DevRel metrics are referenced twice and linked in the stream, not named on camera - Frédéric Harper — host; DevRel at Tiny Technologies (TinyMCE), the show's sponsor - Guillermo Rauch (Vercel CEO) — the "Recursive founder mode" podcast, recommended at length - [WebMCP](https://developer.chrome.com/docs/ai/web-mcp) — the Chrome/Microsoft proposal demonstrated; official docs on developers.chrome.com and web.dev - [Google AI Studio](https://aistudio.google.com/) — where the demo's Gemini API key comes from - Upcoming appearances named: Moodle Moot Brazil (São Paulo, Sept 10–11), Nerdearla Buenos Aires (Sept 22–26), Umbraco US Festival (Chicago, Sept 30–Oct 1) ## 📝 Summary - **What this is.** A 69-minute DevRel conversation in two halves: a genuinely unresolved discussion about how to measure developer relations when AI has collapsed the cost of output, followed by a live WebMCP demo that fails once and then works. - **The central problem, stated honestly.** Piros leads a DevRel team and cannot work out what to measure them on any more. The old metrics — a sample app, one or two articles a quarter — assumed those artifacts were expensive. They are not. His question is sincere and he asks listeners for help with it. - **Harper's sharpening of it.** "Quite often we measure the action not the outcome." Forty videos at 400 views total versus two videos at 10,000 each — the second is the better quarter, and activity metrics score it worse. - **The complication neither resolves.** Harper names real DevRel work that resists measurement entirely: connecting people to jobs, building relationships, conference conversations where attendees ignore your UTM link and convert months later. Both agree outcome measurement is right and neither claims it covers everything. - **The best transferable artifact.** Piros describes a value model from a previous employer that scored a 200-person talk equal to a roughly 50-person workshop, on the reasoning that a talk audience is partly captive while a workshop audience separately registered and can be talked with directly. - **The WebMCP half.** Websites expose callable tools to visiting agents rather than making agents parse the DOM and take screenshots. The architectural detail worth the whole demo: his watch-collector site exposes 6 tools logged out and 14 logged in, registering and removing tools based on auth state. - **Bottom line.** Two experienced practitioners thinking out loud rather than presenting conclusions, with one unsolved measurement problem stated clearly enough to be useful, and one emerging standard demonstrated warts-and-all including a live failure. ## 📖 Main Content - **The measurement problem is the episode's real subject and it is not solved.** Piros joined Storyblok roughly a month before recording, found the team's measurement lacking, and built a framework for evaluating articles and events. But the framework runs into a wall he states plainly: what DevRel was measured on ten years ago assumed the artifacts were costly to produce. AI removed that. If two pieces of content a week is now achievable, then twelve pieces in a quarter is not obviously good — why not twenty-four, why not thirty-six? A sample repository takes a day at most, so one a week is feasible and therefore meaningless as a target. - **He is explicit that he does not have the answer.** He gestures at usefulness of the tools built, and whether they show the value of the product, then says "this is where I'm a little bit lost" and invites listeners to chime in. That is the most valuable thirty seconds in the episode — a DevRel lead publicly admitting the measurement model is broken and not substituting a confident replacement. - **Harper's reframing is the sharper version.** Activity versus outcome: four blog posts a month or two events a quarter are commitments about effort. Forty videos totalling 400 views is worse than two videos at 10,000 each, and only outcome measurement can see that. He adds the honest edge — moving to outcomes makes DevRel *more* accountable, which he supports rather than resists, on the grounds that he needs to be able to prove the salary makes sense rather than merely assert he is good at his job. - **But Harper immediately complicates his own position, and this is why the exchange is worth listening to.** He names DevRel work he believes has real business impact and cannot be measured: spending time on LinkedIn connecting people, introducing a job-seeker to someone hiring, building the relationship where someone later thinks "Fred is a nice guy who helped me." And conference attribution leaks structurally — you can put a UTM on a link, but people in the room go directly to the site, or convert months later when that conference is no longer being tracked. Neither participant pretends this is solved. - **Experiments as the operational answer.** Piros wants his team to embrace the word "experiment." The worked example: they are going to try short-form video for one quarter, on multiple platforms, because their long-form YouTube output gets few views. If it does not work they kill it, and that is explicitly not a failure. His observation about why this is newly practical is the interesting part — the pace of experimentation itself has changed, mostly enabled by AI, so you can test, pivot, kill, or double down much faster than the old quarterly rhythm allowed. - **The workshop-over-talk value model is the most portable thing in the episode.** His argument: a 400-person talk audience has 400 people partly because there is nowhere else to be in that time slot. By his own estimate maybe 200 are half-listening and maybe 100 are genuinely engaged. A workshop requires separate registration, which self-selects for exactly that engaged 100, and permits direct conversation that a stage does not. So the model his previous team built weighted them accordingly: a 200-person talk and a roughly 50-person workshop scored the same. Whether or not the specific weights are right, the *principle* — score for depth of interaction rather than headcount — is a defensible answer to the outcome-measurement problem for events specifically. - **Events as a product-feedback channel, not a lead channel.** Both push back on events being justified solely by leads. Harper acknowledges the funnel argument honestly — if he does his job the top of the funnel fills and he keeps getting paid — but argues events also produce the product feedback that never arrives through official channels. Piros's point about who does not send feedback is well made: some developers will email or use Discord, but not most. Harper adds the sharper version — when someone *does* reach out unprompted, they are often already so frustrated that the relationship is past recovery. And feedback from non-users is equally valuable: understanding why someone with the need does not use your product. - **Harper's self-correction on positive feedback is the most quietly useful item.** He realized he had been routing only negative feedback and problems to engineering, on the reasoning that problems drive the roadmap. With TinyMCE most users have nothing negative to say — it is the kind of product you embed and forget. So his engineers heard nothing except annoyed GitHub issues. He is changing that deliberately: bring back "this feature saved me a lot of time" as well. That is a small, cheap, concrete practice change with a real morale effect. - **The AI thesis, and where the two differ.** Harper's stated position is blunt: trying to replace yourself with AI in DevRel means you do not understand DevRel. His reasoning is historical — the role exists because traditional sales and marketing could not connect with developers, who dislike being sold to and require credibility from a peer. He extends it to himself: he is hired for his personality, his jokes, how he gives talks. Remove the person and there is nothing left that distinguishes the function. His practical conclusion is not anti-AI — he says you will not have a job if you do not use the tools — it is that the personality is the product. - **Piros agrees and then describes a materially heavier usage.** He frames AI as an enabler and grounds it in seniority: both of them worked pre-AI, through the LAMP era, hand-writing code for hours, and that experience is what makes their usage different from a junior's. His illustration is precise — debugging a Sentry issue, Claude proposed one approach, he redirected it to three specific files, and it confirmed the intuition was right. His claim is that experience lets you point the agent at the right place so it can do the groundwork. - **His concrete DevRel applications.** Ideating talk titles and abstracts, which he flags as genuinely helpful because English is not his first language — ask for fifty, get fifty. Slide production: bullet points in a bare Keynote document, then "make this look really cool," a minute instead of half a day, retaining his own logic and flow. Data analysis through MCP connectors: he was handed a newsletter spreadsheet of click-through and open rates, could not read it, and got solid pattern recommendations in about ten minutes. And onboarding — with Slack, Notion, and Google Drive connectors he answered most of his own new-job questions without interrupting colleagues. - **The interruption argument, which is better than it first sounds.** Piros compares asking a colleague a basic question to tapping a headphoned developer on the shoulder in an early-2000s office and destroying their flow state, and identifies Slack as the digital equivalent at scale. Framing internal AI connectors as flow protection for *other people* is a more persuasive case than the usual speed argument, and it is the framing organizations tend to miss. - **Harper's counterpoint on losing the craft.** He does not code much any more and says he would not want to be a full-time developer now. Two things drew him to the work: creating solutions that help people, which remains, and the act of coding and debugging, which he genuinely enjoyed. If the job becomes writing prompts and lightly correcting output, the second is gone. He is careful to note that many people say the job was never about the typing — and he agrees in principle — but the enjoyment was real and its loss is real. That is an honest statement of a cost that most AI-productivity conversations skip. - **The Rauch recommendation and its one memorable idea.** Piros recommends a roughly ninety-minute Guillermo Rauch podcast, "Recursive founder mode," saying it articulated things already in his head. The line he carries away: it is not you, your colleagues, or AI — it is you and your agent in one room working together, with the agent as the first stop for information before you go to a person. - **WebMCP: the problem it solves.** Agents currently interact with websites by opening a URL, parsing the DOM, and taking screenshots — Piros calls the process complex and unreliable, and gives the recognizable failure: you ask an agent to find a product in stock, it returns a link, and the page 404s or says out of stock. WebMCP applies MCP's model to the web: a site exposes tools, and an agent that finds them calls them instead of scraping. - **How it is implemented, from the demo.** A `tools` array where each entry has a name, a description, an input schema, and an `execute` property pointing at an ordinary JavaScript function — a shape he correctly notes will look familiar to anyone who has used function calling or Google's ADK. Registration is via a new browser API, `document.modelContext.registerTool`. There is also a declarative API which he says is simpler: add attributes to existing forms and agents read them through WebMCP. He demonstrates the imperative one. - **Setup friction, reported accurately.** Chrome flags must be enabled — search WebMCP. A Chrome extension is required, and finding the official Google one is genuinely hard: the publisher shows as Google Ireland with no Google logo, which both hosts stumble over live. Piros's identifying advice is the hedgehog logo. A Gemini API key from AI Studio is needed, free for limited use. - **The second demo carries the actual insight.** His watch-collector side project — Next.js with Clerk for auth, roughly 20,000 watches and 160 brands — exposes six tools when logged out and **fourteen when logged in**, because he registers additional tools once he has authentication state and removes them on logout. Tool surface as a function of session state is a real architectural pattern and the most interesting thing in the demo half. - **The demo fails first, which is worth noting.** Running in the ChatGPT desktop app requires the side-panel browser on the *work* tab rather than chat, and the model matters — of Terra, Sol, and Luna, one cannot use WebMCP and he cannot remember which. His first attempt uses the wrong model and the agent falls back to ordinary browsing. On the second attempt it calls two exposed tools, the site's own filters visibly change, and the Omega chronographs with blue dials appear. - **His caveat is the honest part.** The browser side exists; the client side is lacking. Getting this working in Claude desktop required enabling the Chrome plugin and Chrome usage and was "a lot of work." And being outside the US, he does not have Chrome's built-in Gemini, so he cannot test that path at all. He is hopeful the hackathon attention changes this. - **Uncertainties.** Every metric discussed is described rather than shown — no actual numbers from either team. The previous-employer value model is recalled from memory with approximate weights. The talk-audience breakdown (400 present, 200 listening, 100 interested) is explicitly his impression from the stage, not measurement. The WebMCP challenge's sponsor list is recalled mid-sentence with an admitted omission. ### 🗒️ Notes #### ⏱️ [05:34](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=334) The setup - Piros leads DevRel at Storyblok, a headless CMS; roughly one month in, of which a week was vacation. - Title: senior team manager, developer relations and community. - Self-described data-driven; first move was building a measurement framework for content and events. - Strategic event selection as an open question: JavaScript events, framework-specific events, AI events. #### ⏱️ [09:37](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=577) The measurement problem - Ten years ago DevRel was measured on sample applications and one or two articles a quarter. > [!quote] > AI makes this cheap or even free, so to speak, right? ... So, now do I say, "Oh, you've written, I don't know, 12 pieces of content in a quarter. Is that good or is it bad? Why didn't you do 24? Why didn't you do 36?" - A sample repository is a day's work at most, so weekly output is feasible and therefore not a meaningful target. - His admission: "this is where I'm a little bit lost." Invites listeners to respond. - Notes he is "AI-pilled" and holds strong opinions about how AI should be used at senior level and above. #### ⏱️ [13:06](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=786) Action versus outcome - Harper: "quite often we measure the action not the outcome." - Forty videos at 400 views total versus two videos at 10,000 each — the second is the better quarter. - He supports accountability explicitly: he needs to prove the salary makes sense, not merely assert competence. - The complication he raises himself: LinkedIn networking, job introductions, and relationship-building have real impact and resist measurement. - Conference attribution leaks structurally — UTM links miss people who go direct or convert after the campaign stops being tracked. #### ⏱️ [16:39](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=999) Experiments - Piros wants the team to embrace "experiment" as a working term. - Worked example: short-form video for one quarter, across multiple platforms, because long-form YouTube output underperforms. - If it fails they kill it, and that is explicitly not a failure. - Why now: the pace of experimentation itself has increased, mostly enabled by AI — test faster, pivot faster. #### ⏱️ [19:20](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=1160) Workshops over talks > [!quote] > You only have 400 people because there's nowhere else to go. - His estimate: of 400 in the room, maybe 200 half-listening, maybe 100 genuinely interested. - A workshop requires separate registration, so it self-selects for the engaged hundred and permits direct conversation. - The value model from his previous employer scored a 200-person talk equal to a roughly 50-person workshop. - Events also as product feedback: talk to developers at the booth, write it up, route it to product. #### ⏱️ [21:46](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=1306) Feedback that never arrives - Harper on TinyMCE: the leads-only justification for events misses the feedback value. - Most developers will not email or use Discord; those who reach out unprompted are often already past recovery. - Non-user feedback is equally valuable — why does someone with the need not use your product? - **Harper's self-correction:** he had routed only negative feedback to engineering, reasoning that problems drive the roadmap. - With a product people embed and forget, engineers therefore heard nothing but annoyed GitHub issues. - He is deliberately changing that — bring back "that feature saved me a lot of time" too. - Piros: post-event reporting in Notion with a product-feedback column; capture everything, decide later. #### ⏱️ [25:44](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=1544) Harper's AI thesis > [!quote] > If you are trying to replace yourself with AI doing developer relation, from our point of view, I don't think you understand developer relation. - The role exists because sales and marketing could not connect with developers, who dislike being sold to and require peer credibility. > [!quote] > People hire me for who I am, for my personality, for how I connect with people ... for my really bad jokes. - Practical conclusion: use the tools or you will not have a job, but removing the person leaves nothing distinguishing. #### ⏱️ [28:42](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=1722) AI as enabler, and the seniority argument - Both worked pre-AI — the LAMP era, hand-written code for hours. "We've done the grunt work." - Claim: senior usage differs from junior usage because experience directs the agent. - The Sentry debugging example: Claude proposed one route, he redirected it to three specific files, it confirmed the intuition. - DevRel applications: talk titles and abstracts (fifty on request; English is his second language); slides from bullet points in a minute rather than half a day, retaining his own logic. - MCP connectors for analysis: an unreadable newsletter spreadsheet became solid pattern recommendations in about ten minutes. #### ⏱️ [37:09](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=2229) Onboarding without interrupting people - Slack, Notion, and Google Drive connectors let him self-serve most new-job questions. - The analogy: tapping a headphoned developer on the shoulder in an early-2000s office and destroying their flow; Slack is the digital equivalent. - The Rauch podcast recommendation, "Recursive founder mode," roughly ninety minutes. - The idea he carries: not you, your colleagues, or AI — you and your agent in one room, the agent as first stop before a person. #### ⏱️ [38:56](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=2336) What is lost - Harper does not code much now and would not want to be a full-time developer today. - Two draws: creating solutions that help people, which remains; and coding and debugging, which he enjoyed. - If the job is writing prompts and lightly correcting output, the second is gone. - He grants the counterargument — the job was never the typing — and says the enjoyment was real anyway. - Nostalgia: debugging with console output, no breakpoints, no proper IDE. Firebug. At Mozilla they struggled to move people off Firebug onto Firefox devtools because Firebug got there first. #### ⏱️ [42:25](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=2545) WebMCP, the problem - Agents currently open URLs, parse the DOM, and take screenshots — complex and unreliable. - The recognizable failure: ask for an in-stock product, get a link, the page 404s or shows out of stock. - WebMCP applies MCP's model: sites expose tools; visiting agents call them instead of scraping. - Attributed to Google and Microsoft. - A WebMCP challenge promoted by OpenAI, Vercel, Netlify, Cloudflare, Shopify and Chrome drove a spike in attention that week; Harper notes registration appears to close that day. #### ⏱️ [46:10](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=2770) The todo demo - Ordinary JavaScript functions: add todo, toggle todo, complete todo. - A `tools` array — name, description, input schema, `execute` property — which he notes resembles function calling or Google's ADK. - Registered through `document.modelContext.registerTool`. - Two APIs: imperative (demonstrated) and declarative (add attributes to existing forms; he says it is simpler). - Setup: enable Chrome flags for WebMCP; install the official Google extension — publisher shows as Google Ireland with no Google logo, identified by a hedgehog; add a Gemini API key from aistudio.google.com. - "Add a new item to call mom" adds it; "mark call mom as done" completes it. #### ⏱️ [53:49](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=3229) The watch demo, and the tool-surface pattern - A watch-collector side project: Next.js, Clerk for auth, roughly 20,000 watches, about 160 brands. - Chrome shows an indicator beside the domain; clicking reveals six available tools. > [!quote] > What's really interesting ... is after you sign in, there are actually 14 tools. ... when I get the authentication state, so I know someone is logged in, I register additional tools. - Tools are removed again on logout. - Runs in the ChatGPT desktop app: side-panel browser, **work** tab not chat. Model matters — of Terra, Sol and Luna, one cannot use WebMCP and he cannot recall which. - First attempt fails on the wrong model; the agent falls back to ordinary browsing. - Second attempt works: two exposed tools are called, the site's filters visibly change, and the Omega chronographs with blue dials appear. #### ⏱️ [60:26](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=3626) The honest caveat - The browser side exists; the client side is lacking. - Claude desktop required enabling the Chrome plugin and Chrome usage — "a lot of work." - Outside the US he lacks Chrome's built-in Gemini, so that path is untestable for him. - He has two upcoming talks on WebMCP and the agentic web, and recommends following Chrome team members working on it. - A live viewer from India reports doing WebMCP research and calls the possible experiences amazing. #### ⏱️ [61:27](https://www.youtube.com/watch?v=mk6zJTLqLtA&t=3687) Languages and close - Piros: Hungarian first language; also Italian, Spanish, some German and French, some Japanese. - Harper: French first language, 44, learned English around fourteen years ago, now sometimes thinks in English and mixes both in a single sentence of notes. - Next episode October 8th. Harper's travel: Moodle Moot Brazil (São Paulo, Sept 10–11), Barcelona briefly, Nerdearla Buenos Aires (Sept 22–26, free, talk plus workshop, sponsoring), Umbraco US Festival Chicago (Sept 30–Oct 1, keynote with Jason from ProWorks). - The show is sponsored by TinyMCE, Harper's employer, disclosed on air. ## 📚 References - [Storyblok](https://www.storyblok.com/) — the guest's employer; headless CMS - [TinyMCE](https://www.tiny.cloud/) — the host's employer and the show's disclosed sponsor - [WebMCP on developers.chrome.com](https://developer.chrome.com/docs/ai/web-mcp) and [web.dev](https://web.dev/) — the official sources he recommends - [Model Context Protocol](https://modelcontextprotocol.io/) — the underlying protocol WebMCP extends to the browser - [Google AI Studio](https://aistudio.google.com/) — free-tier Gemini API key for the demo extension - [Clerk](https://clerk.com/) and [Next.js](https://nextjs.org/) — the stack behind the watch-collector demo - Guillermo Rauch, "Recursive founder mode" podcast — recommended at length, linked in-stream via a Bitly Harper created live - Tamás Piros's LinkedIn articles on AI-era software development and DevRel metrics — referenced twice, linked in-stream, not named on camera ## 🗣️ Paraphrase - **The new job.** Piros leads DevRel at Storyblok, about a month in, and started by building a measurement framework because he found the team lacked one. - **The problem with the old metrics.** Sample apps and a couple of articles a quarter were meaningful when they were expensive. AI made them cheap, so counting them measures nothing — and he says openly that he does not yet know what to replace them with. - **Action versus outcome.** Harper's version: we measure what we do rather than what results. Forty videos nobody watches lose to two that land. - **What resists measurement.** Introductions, relationships, and hallway conversations have real impact and no clean attribution. Conference UTM links miss most of the room. - **Experiments.** Try short video for a quarter. If it fails, kill it, and call that a result rather than a failure. AI makes the whole loop faster. - **Workshops beat talks.** A talk audience is partly there because there is nowhere else to be. A workshop audience registered on purpose and can be talked with. Score accordingly. - **Feedback.** Events surface product feedback that never reaches Discord or email, including from people who chose not to use your product. And route the positive feedback to engineering too — otherwise they only ever hear from angry people. - **On AI replacing DevRel.** Harper: the role exists because developers need a credible peer rather than a marketer. Personality is not decoration, it is the function. Use the tools, but do not remove the person. - **On AI as an enabler.** Piros: experience is what makes agent use effective — knowing where to point it. Titles, slides, spreadsheet analysis, and self-serve onboarding through internal connectors that spare colleagues the interruption. - **What is lost.** Harper enjoyed coding and debugging as activities, not just as means, and would not want to be a full-time developer if the job became prompt-writing. - **WebMCP.** Instead of agents scraping your DOM, your site exposes callable tools. A small array of name, description, schema, and function, registered through a new browser API. - **The interesting bit.** His demo site exposes six tools to anonymous visitors and fourteen to signed-in ones, registering and removing them with auth state. - **The state of it.** Browser support exists; client support is thin, the setup is fiddly, and the demo fails once on the wrong model before working. ## 📰 Newsletter **A DevRel lead admitting on camera that he doesn't know what to measure his team on any more — and being right to admit it.** Tamás Piros joined Storyblok about a month before this recording and started, as a self-described data-driven person, by building a measurement framework. Then he hit the wall the whole discipline is hitting: the old metrics assumed the artifacts were expensive. > "AI makes this cheap or even free... So now do I say, 'you've written 12 pieces of content in a quarter. Is that good or is it bad? Why didn't you do 24? Why didn't you do 36?'" A sample repository is a day's work now. You could ship one a week. So what does counting them tell you? He gestures at usefulness and product value, then says "this is where I'm a little bit lost" and asks listeners to chime in. That's more useful than a confident answer would have been. Frédéric Harper sharpens it: **"quite often we measure the action not the outcome."** Forty videos totalling 400 views versus two videos at 10,000 each — the second is obviously the better quarter, and activity metrics score it worse. He's also refreshingly pro-accountability about it: he wants to be able to *prove* the salary makes sense, not just assert he's good at the job. Then he complicates his own argument, which is why the exchange is worth an hour. Some real DevRel work has no clean attribution — introducing a job-seeker to someone hiring, the relationship that pays off two years later, the conference room where nobody uses your UTM link because they just type the domain, or convert months after you stopped tracking that campaign. Neither of them pretends that's solved. **The most portable thing here is a value model.** Piros's previous team scored a 200-person talk equal to a ~50-person workshop. His reasoning: *"You only have 400 people because there's nowhere else to go."* Maybe 200 are half-listening, maybe 100 actually care. A workshop requires separate registration, so you get that engaged hundred and you can talk *with* them. Whatever you think of the specific weights, scoring depth of interaction over headcount is a real answer to the outcome problem for events. **And the smallest useful idea:** Harper realized he'd only ever routed *negative* feedback to engineering, on the logic that problems drive the roadmap. But TinyMCE is a product you embed and forget — so his engineers heard nothing except angry GitHub issues. He's deliberately changing it to bring back "that feature saved me a lot of time" as well. Cheap, concrete, and I'd guess most of us have the same gap. On AI, Harper's position: *"If you are trying to replace yourself with AI doing developer relation, I don't think you understand developer relation."* The role exists because sales and marketing couldn't connect with developers, who need a credible peer. He's hired for his personality and his bad jokes — that's not decoration, it's the function. Use the tools or you won't have a job; remove the person and there's nothing left. Piros agrees and then describes heavier usage than that framing suggests — talk titles (fifty on request; English is his second language), slides from bullet points in a minute instead of half a day, and an unreadable newsletter spreadsheet turned into pattern recommendations in ten minutes via MCP connectors. His best framing is on internal connectors as **flow protection for other people**: asking a colleague a basic question is the digital equivalent of tapping a headphoned developer on the shoulder in 2003. **The second half is a WebMCP demo, and one detail justifies it.** WebMCP lets a site expose callable tools to visiting agents instead of making them parse your DOM and take screenshots. His watch-collector site exposes **6 tools logged out and 14 logged in** — he registers extra tools once he has auth state and removes them on logout. Tool surface as a function of session state is a genuinely interesting pattern and I haven't seen it discussed elsewhere. He's honest about the state of it: browser side exists, client side is thin, Claude desktop took "a lot of work" to wire up, and the live demo fails once on the wrong model before working. Setup involves Chrome flags, a Gemini API key, and finding the official Google extension — which is hard, because the publisher shows as "Google Ireland" with no logo. His identifying tip: it's the one with the hedgehog. Links: [WebMCP docs](https://developer.chrome.com/docs/ai/web-mcp) · [Storyblok](https://www.storyblok.com/) · [MCP](https://modelcontextprotocol.io/) ## ✅ Action Items #### DevRel - Developer advocacy: adopt the workshop-over-talk weighting. Scoring depth of interaction rather than headcount is the single most actionable idea here and it survives removal from their specific numbers. - Education: teach the activity-versus-outcome distinction explicitly to anyone building a DevRel plan; activity targets are the default and they are now actively misleading. - Developer experience: events as a product-feedback channel needs a capture mechanism, not good intentions. Piros's post-event Notion columns are the minimum viable version. - Developer marketing: route positive feedback to engineering deliberately. If your product is the embed-and-forget kind, your engineers currently hear only from angry people. - Community management: non-user feedback — why someone with the need chose not to adopt — is the most underused signal available at a booth. - Cross-project: the "experiment for one quarter, then kill it without calling it failure" frame is a cultural prerequisite for outcome measurement to work at all. #### OSPO - Policy & Governance: if DevRel metrics move from output counts to outcomes, the reporting relationship and the definition of success both need rewriting. That is a governance change, not a dashboard change. - License Compliance: not applicable to this source. - Security Management: WebMCP exposes callable functions from a page to arbitrary visiting agents. The auth-gated tool registration pattern is the right instinct; the threat model deserves scrutiny before anyone ships it. - Software Inventory: internal MCP connectors to Slack, Notion, and Drive are a data-access surface that should be inventoried like any other integration. - Developer Support: self-serve onboarding through internal connectors measurably reduces interruption load on existing staff — worth piloting and measuring. - Community Engagement: not applicable to this source. - Strategic Alignment: "we cannot measure what we used to measure" is a live problem for any advocacy function, not only DevRel. Technical writing and community teams have the same exposure. #### Community - Maintainers: the positive-feedback routing gap applies directly to open-source maintainers, who hear almost exclusively from people with problems. - Contributors: not applicable to this source. - Sponsors: not applicable to this source. - Ecosystem: WebMCP would change how agents interact with documentation sites, plugin directories, and forums. Worth watching before it arrives rather than after. #### WordPress - Core: not applicable to this source. - Core Performance: not applicable to this source. - Core AI: WebMCP is directly relevant — a WordPress site exposing structured tools to visiting agents is a plausible near-term capability, and the auth-gated tool surface maps cleanly onto capabilities. - **Core Program Team:** not applicable to this source. - Mobile: not applicable to this source. - Playground: a Playground instance exposing WebMCP tools would be a compelling demonstration of agent-driven WordPress. - Community: the workshop-over-talk weighting is directly applicable to WordCamp programming decisions. - Training: workshops already outweigh talks in the Training team's model implicitly; this gives the argument an explicit form. - Marketing: activity-versus-outcome applies to every content plan in the project. - Support: the "people who reach out are already past recovery" observation is a support-team truth worth naming. - Design: not applicable to this source. - Documentation: if agents call tools rather than parsing pages, documentation sites need a tool surface, not just better markup. That is a strategic question worth opening early. - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: both participants work in a second language and one uses AI specifically to compensate for that in written output — a real accessibility use case for contributors. - Accessibility: an agent-callable tool surface is a genuine accessibility opportunity, and nobody in the episode raises it. - Meta: WebMCP on WordPress.org properties — plugin search, forums — is speculative but would be significant. - CLI: not applicable to this source. - Hosting: not applicable to this source. - Tide: not applicable to this source. - Openverse: search over a large media catalogue is close to an ideal WebMCP use case. - Themes: not applicable to this source. - Plugins: a WebMCP tool surface would be a plugin-shaped capability before it is a core one. #### The WPOCC - Programs: not applicable to this source. - Projects: not applicable to this source. - Funding experiments: the measurement problem applies to funded community work too — output counts are equally poor proxies there. ### FAIR - Technical independence: if agents interact with sites through declared tools rather than scraping, a federated directory could expose a standard tool surface without depending on a central index. Worth thinking about early. - Policies and covenants: not applicable to this source. - Productized governance artifacts: the event value model — weights assigned to interaction depth — is a reusable governance artifact for any advocacy team. ## 🧪 Hypotheses - Teams that switch DevRel targets from output counts to outcome measures produce fewer artifacts and higher aggregate reach within two quarters. - Workshop attendees show measurably higher product-adoption and retention rates than talk attendees at the same event, supporting the weighting Piros describes. - The proportion of a talk audience genuinely engaged is closer to his estimate (roughly a quarter) than to headcount, and is measurable through post-session action rates. - Routing positive user feedback to engineering measurably improves engineering-team morale and reduces perceived product-quality pessimism, independent of any roadmap change. - Internal AI connectors reduce onboarding-related interruptions of existing staff by a measurable margin, and that reduction is a larger organizational gain than the new hire's own speedup. - Sites exposing WebMCP tools produce higher agent task-completion rates than equivalent sites requiring DOM parsing, with the gap largest on filtered search and transactional flows. ### 📊 Methodology - **Outcome versus activity.** Instrument a DevRel team through one quarter on activity targets and one on outcome targets; compare artifact count, aggregate reach, and any downstream signal the org already tracks. Confounded by novelty; run at least two cycles. - **Workshop weighting validation.** Tag workshop and talk attendees at the same conference with distinct identifiers and compare trial signup, activation, and retention. This is the study that would confirm or kill the value model, and it is straightforward. - **Talk engagement measurement.** Post-session action rates — QR scans, page visits, follow-ups — against headcount, to test the 400/200/100 breakdown. - **Positive-feedback effect.** Introduce a positive-feedback channel to an engineering team and measure sentiment and perceived-quality survey deltas over two quarters against a control team. - **Interruption load.** Measure ask-a-colleague message volume during onboarding before and after internal connector availability, on the interrupted party's side rather than the new hire's. - **WebMCP completion rates.** Same site, tools exposed versus not, identical agent tasks; measure completion and error rates. - **Data sources.** Team dashboards; conference registration systems; internal comms metadata; agent traces. - **Limits.** No numbers are given anywhere in this episode. The value model is recalled approximately, the engagement breakdown is one speaker's impression from a stage, and both participants are describing intentions more than results. ### ❓ Questions - What does Piros actually land on for measurement? He states the problem well and the episode ends without an answer, which is honest but leaves the most important thread open. - Was the previous employer's value model ever validated against downstream outcomes, or was it an internally agreed heuristic? - If output is cheap, does volume still matter for discovery and SEO even when it does not indicate effort? - How do you measure the relationship work Harper describes without creating a metric that immediately corrupts the behavior? - What is the security model for WebMCP? A page exposing callable functions to any visiting agent is a new surface and nobody raised it. - Does the auth-gated tool registration pattern generalize, and what happens when the agent holds a session the user did not intend it to act under? - Which of Terra, Sol, and Luna cannot use WebMCP? It matters for anyone trying to reproduce the demo, and neither host knows. ### 🔮 Future Research - Outcome measurement for advocacy functions generally — DevRel, technical writing, community management — where attribution is structurally leaky and the literature is thin. - Whether interaction depth predicts adoption better than reach, which is the empirical claim underneath the workshop weighting and appears untested. - The effect of feedback valence routing on engineering teams, an area with obvious morale implications and little study. - Agent-website interaction protocols: WebMCP versus DOM parsing versus structured data, compared on completion rate, token cost, and failure mode. - Security and consent models for agent-callable web interfaces, particularly around authenticated sessions and transactional actions. ### 💡 Implications - **Practice.** Three things are immediately actionable: weight workshops above talks, capture product feedback at events in a structured place, and start routing positive feedback to engineering. None requires permission. - **Policy.** If output volume no longer signals effort, DevRel goal-setting needs rewriting before the next planning cycle, not after someone is reviewed against a meaningless target. - **Security.** WebMCP moves a website from something an agent reads to something an agent operates. The auth-gated tool surface is a good instinct; the consent and session model deserves attention before adoption, not after. - **Education.** The seniority argument — that experience is what makes agent use effective, because you know where to point it — has an uncomfortable implication for how juniors build that experience in the first place. Neither participant follows it there. - **Funding.** Not applicable to this source directly, though the measurement problem determines how advocacy work gets justified in budget conversations. ### 🧠 Learning Styles Assessment - Reading level estimate: conversational, roughly Grade 9. Both speakers work in a second language, producing long clause chains and self-corrections. The WebMCP half assumes MCP, JSON schema, Next.js, and Chrome flags without explanation. #### 👀 Visual learners - Present: strong in the second half — live code, the tools array, Chrome flags, the extension, the address-bar indicator, and the filters visibly changing. - Improve: the first half is fifty minutes of talking heads about metrics with nothing on screen. A single slide showing the value model's weights would have made the most portable idea in the episode legible. #### 🔊 Aural learners - Present: excellent. Genuine two-way conversation with disagreement, comfortable pacing, no music. - Improve: the host flags his own camera and latency issues early; audio holds up but the opening five minutes are largely equipment talk. #### 🗣️ Verbal learners - Present: strong. Both explain reasoning rather than conclusions, and the host explicitly invites disagreement as a norm for the show. - Improve: acronyms accumulate — MCP, ADK, UTM, DOM, CMS — with only UTM getting even a passing gloss. #### 🧩 Kinesthetic learners - Present: good in the demo half. The setup steps are shown end to end, including the failure, which is more instructive than a clean run. - Improve: no repository link stated on camera for the demo code; a viewer wanting to reproduce it has to reconstruct from the screen. #### 🧠 Logical learners - Present: the episode's strength. The measurement argument is properly structured — premise, consequence, admitted gap — and the workshop model is reasoned from a stated mechanism rather than asserted. - Improve: zero numbers from either team. Every claim about measurement is made without a single measurement. #### 🧑‍🤝‍🧑 Social learners - Present: excellent. Live chat is read out, a viewer comment is incorporated, and the host explicitly invites people to meet him at named events. - Improve: Piros directly asks listeners to chime in on the measurement question and no mechanism is offered for it — no thread, no follow-up post named. #### 🧘‍♀️ Solitary learners - Present: adequate. Self-contained and followable alone. - Improve: sixty-nine minutes, two entirely distinct halves, no chapters. Someone who wants only the WebMCP demo has to scrub past fifty minutes of metrics discussion. #### 🌿 Naturalistic learners - Present: minimal. - Improve: the travel segment lists four international trips in a month, and the sustainability dimension of conference-driven DevRel goes entirely unremarked — a live question for the discipline. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: not evaluable for a video artifact. - Improve: a description-box outline separating the metrics discussion from the WebMCP demo, with timestamps, would serve the two distinct audiences this episode has. #### Keyboard navigation - Present: inherits YouTube's player. - Improve: no chapters across sixty-nine minutes and two unrelated topics. This is the most acute chaptering need in the batch. #### Contrast and readability - Present: screen-shared code and Chrome UI at streaming resolution. - Improve: the presenter says "I don't know if I can zoom in on this one. Apologies for that" while showing the extension — the code and the tool list are likely illegible on a phone. Zooming during code demonstration is the fix and he identifies the problem himself. #### Text resizing and reflow - Present: not applicable to video content. - Improve: applies to the linked articles and docs. #### Media and captions - Present: auto-generated captions, unreliable on exactly the load-bearing terms — the guest's name renders three different ways, Storyblok becomes "Storybook," Nerdearla becomes "NerdyRella," and Guillermo Rauch becomes "gear mode rock." - Improve: for an episode whose value is specific product names, protocol names, and people to follow up on, uncorrected captions materially reduce usefulness and searchability. A corrected transcript would also make the WebMCP API details quotable. #### Forms and interactions - Present: not applicable to the source video. - Improve: worth noting that WebMCP itself has an accessibility dimension nobody in the episode raises — a site exposing semantic, callable tools is exposing structured intent, which is adjacent to what assistive technology has always wanted from the DOM. #### Standards reference - WCAG 2.2 AA notes: 1.2.2 Captions met only nominally, with errors on nearly every proper noun. 1.2.3 Audio Description is genuinely unmet and matters here — the demo half is substantially visual, and the narration does not fully convey what changes on screen. 2.4.5 Multiple Ways unmet: no chapters, no transcript, no outline. ### 🌍 DEIB Assessment #### Cultural breadth - Present: genuinely good and structurally so. A Hungarian guest and a French-Canadian host both working in English, an explicit conversation about second-language work, a live viewer from India acknowledged by name, and events across Brazil, Argentina, Spain, and the United States. - Improve: the technology discussion is entirely Anglophone-ecosystem and US-platform centric — and Piros notes he cannot test one WebMCP path at all because he is not in the US, which is a real geographic inequity mentioned and not examined. #### Inclusive language - Present: warm and non-gatekeeping in the discussion half. The host explicitly frames disagreement as normal and impersonal, which sets a good tone. - Improve: the demo half is dense with unexplained acronyms. Some casual profanity may limit workplace sharing. #### Neurodiversity support - Present: mixed. Steady pace, clear turn-taking, and the two halves are internally coherent. - Improve: sixty-nine minutes with no chapters, an unrelated topic switch at the midpoint, and a long equipment digression before the content starts. #### Representation - Present: two DevRel practitioners with different national backgrounds and career paths; a viewer voice included. - Improve: both are senior men at vendor companies, and the seniority argument — that experienced people use AI better — is made entirely by people with that experience, about people without it, with no junior voice present. That is the gap most worth naming. #### Psychological safety - Present: strong, and the reason the episode works. Piros says "this is where I'm a little bit lost" and asks for help; Harper admits a practice he got wrong for years and is changing; the demo fails live and neither panics; the host jokes about not knowing what a chronograph is. Disagreement is explicitly framed as impersonal at the outset. - Improve: nothing substantive. The willingness to be publicly unsure about a core professional competency is the episode's best quality. ### ✅ Logical Validity #### Strong reasoning - **The measurement argument (09:37).** Premises: old metrics counted artifacts; artifact cost has collapsed; a count is only informative if the counted thing is costly. Conclusion: the metrics no longer inform. Valid, and he refuses to paper over the resulting gap. - **The workshop weighting (19:20).** Reasoned from a mechanism — talk attendance is partly a function of scheduling constraint, workshop attendance requires deliberate registration — rather than from preference, and it yields a concrete weighting. - **The DevRel-exists-because argument (25:44).** Harper derives the irreplaceability claim from the discipline's origin: the role exists because impersonal channels failed with this audience, therefore removing the person reinstates the original failure. A genuine argument rather than an assertion of value. - **The seniority-directs-the-agent claim (28:42).** Supported with a specific, checkable example — redirecting Claude to three files on a Sentry issue — rather than asserted abstractly. - **Self-correction on feedback valence (24:16).** Harper identifies a reasonable-sounding heuristic he held (problems drive the roadmap), notices the systematic distortion it produced, and states the fix. Clean reasoning about his own error. - **The flow-protection framing (37:09).** Recasting internal connectors as reducing interruption load on colleagues, rather than as personal speedup, is a stronger and less self-serving argument for the same tooling. #### Fallacies - **Anecdotal estimates presented as structure (19:20).** *Location:* 400 in the room, 200 half-listening, 100 genuinely interested. *Weakness:* an impression from a stage, converted into weights in a formal value model. *Fix:* post-session action rates would make this measurable; the model's shape may be right and its numbers are currently invented. - **Argument from personal luck (28:42).** *Location:* "both of us are in a very lucky position because we've done stuff and we've seen stuff pre-AI," with the implication that junior AI use is worse. *Weakness:* asserted from introspection, generalized to a cohort, and it has an uncomfortable corollary neither addresses — if experience is prerequisite to good agent use, and agents now do the work that built that experience, where does the next generation get it? *Fix:* state the corollary. It is the interesting part. - **Unfalsifiable self-assessment (30:09).** *Location:* "I knew that because I I just I just know." *Weakness:* the debugging anecdote's whole weight rests on intuition that cannot be examined, and Claude agreeing ("you are absolutely right") is weak confirmation given known sycophancy in these systems. *Mitigation:* the broader point about directing agents stands on other grounds. - **Appeal to authority by proxy (35:41).** *Location:* the Rauch podcast, praised as articulating what he already thought and "95% applicable." *Weakness:* endorsement substitutes for the argument; the one idea relayed is interesting but thin relative to the ninety-minute recommendation. - **No numbers anywhere.** *Weakness:* an hour on measurement containing not a single measurement from either team. Both describe frameworks they built or intend to build; neither reports what any of it showed. *Fix:* one real before-and-after would have grounded the entire discussion. - **Overgeneralized product claim (23:43).** *Location:* "if you use it, usually you like it," about TinyMCE, from conversations at conferences. *Weakness:* survivorship bias — people at your booth are selected for using and tolerating your product. *Mitigation:* he arrives at a good conclusion anyway (route positive feedback to engineering), and separately values non-user feedback, which partly corrects for it. #### Tone of voice - Collegial and unguarded — two peers talking shop on a live stream, complete with equipment troubleshooting, a failed demo, and a host who reads chat aloud mid-thought. The register is notably non-promotional despite the host's employer sponsoring the show, which he discloses plainly and then jokes about. What distinguishes it is the comfort with uncertainty: the guest says he is lost on the central question of his own job, the host says he got a years-long practice wrong, and neither treats admission as a loss of standing. The trade-off is a lack of rigor — an hour about measurement without a number in it — but the honesty is worth more than a tidier episode would have been. ### 🛡️ DARVO Analysis - **Deny:** Not present. Both acknowledge problems directly, including in their own past practice, and the guest's central admission is that he cannot solve the problem he is describing. - **Attack:** Not present. The closest is Harper's "if you are trying to replace yourself with AI... I don't think you understand developer relation," which criticizes a position rather than named people, and he explicitly frames disagreement as impersonal at the start of the show. Piros pre-emptively softens his own criticism of his new team's prior state. - **Reverse victim/offender:** Not present. No accusation is in play and neither participant positions himself as wronged. - **Assessment:** DARVO patterns are absent. This is a collegial professional conversation where both parties volunteer their own errors. Retained per template requirement; the finding is a clean negative and consistent with the episode's unusually high psychological safety. ## 🎯 Conclusion - **Bottom line.** The old DevRel metrics counted artifacts that used to be expensive and no longer are. Piros states that clearly, admits he has not solved it, and asks for help — which is more useful than a confident replacement framework would have been. - **The idea to steal.** Weight workshops above talks, on the mechanism rather than the headcount: a talk audience is partly captive, a workshop audience registered on purpose and can be talked with. His previous team scored a 200-person talk equal to a ~50-person workshop. - **The cheap fix worth making this week.** Route positive feedback to engineering. If your product is the embed-and-forget kind, your engineers currently hear only from people who are angry. - **The technical detail worth remembering.** WebMCP tool surfaces can vary with session state — six tools anonymous, fourteen signed in, registered and removed with auth. That pattern will matter more than the protocol's current rough edges. - **Practical next steps for readers.** If you set DevRel goals, rewrite the output targets before the next planning cycle rather than reviewing someone against a meaningless one. If you run events, add a structured product-feedback capture. And if agents calling your site's tools sounds relevant, read the Chrome docs now — the browser side works, the client side does not yet, and the shape of it is settling while it is still cheap to influence. ## 🔄 Refactor Appendix — devrelshow 56 ### 📚 Literature Atoms (H3) #### [H1] Counting artifacts stopped being informative when artifacts stopped being expensive > [!quote] > AI makes this cheap or even free, so to speak, right? ... So, now do I say, "Oh, you've written, I don't know, 12 pieces of content in a quarter. Is that good or is it bad? Why didn't you do 24? Why didn't you do 36?" **Context & use**: - ~09:37, a DevRel lead describing why he cannot measure his team the way the discipline always has. - The count was always a proxy for effort. Remove the effort and the count measures nothing — which generalizes to every function whose output AI has cheapened. **Tags**: #xref #articleseed #aphorisms  #### [H2] A talk audience is partly captive; a workshop audience chose you > [!quote] > You only have 400 people because there's nowhere else to go. **Context & use**: - ~19:20, explaining a value model that scored a 200-person talk equal to a roughly 50-person workshop. - Reasoned from a mechanism rather than preference, and it produces a concrete weighting — a rare instance of an event metric that measures something other than headcount. **Tags**: #xref #articleseed  #### [H3] Engineering hears only from angry users unless you deliberately route the rest > [!quote] > The engineers never heard those things from their users. And most of the time when they heard something, it's someone annoyed creating an issue on GitHub. **Context & use**: - ~24:16, Harper describing a practice he held for years and is now changing. - A selection effect with a morale cost: if only complaints have a channel, the team's picture of its own product is systematically negative. **Tags**: #xref  #### [H4] The exposed tool surface can be a function of session state > [!quote] > What's really interesting ... is after you sign in, there are actually 14 tools. ... when I get the authentication state, so I know someone is logged in, I register additional tools. **Context & use**: - ~55:36, the watch-collector WebMCP demo. - Six tools anonymous, fourteen authenticated, removed again on logout. Capability-scoped agent access, implemented on a side project — the pattern that will matter after the protocol settles. **Tags**: #xref #articleseed  #### [H5] DevRel exists because impersonal channels failed with this audience > [!quote] > If you are trying to replace yourself with AI doing developer relation, from our point of view, I don't think you understand developer relation. **Context & use**: - ~25:44, Harper deriving the claim from the discipline's origin rather than asserting its value. - Sales and marketing could not reach developers, who require peer credibility; automating the person back out reinstates the original failure. **Tags**: #xref #aphorisms  ### 🧠 Permanent Candidates (H4) #### [P1] A count is only a measurement while the counted thing is costly **Claim** (one sentence, Courtney's voice): Output metrics work by standing in for effort, so the moment production gets cheap they stop measuring anything and start rewarding volume. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds wherever a metric was adopted as an effort proxy — content counts, commit counts, ticket throughput, lines of code. Breaks down where the count is intrinsically valuable regardless of cost, such as coverage of a required surface, where more genuinely is better. **Links**: - [[Automation moves the bottleneck to judgment, not away from it]] — because extends the same shift into what remains scarce - [[Alarm fatigue before adding alarms]] — because contrasts on metrics that stop carrying signal - [[When an input becomes cheap, doubling down on it is the fear response]] — because applies-in the individual version of the same mistake  #### [P2] Self-selection is what makes an audience worth measuring **Claim** (one sentence, Courtney's voice): The friction someone crossed to be in the room is a better predictor of impact than how many people are in it. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds where attendance is partly incidental — conference tracks, default-enrolled programs, broadcast channels. Weakens where the friction filters for something other than interest, such as cost or travel, in which case it selects for privilege rather than engagement. **Links**: - [[A count is only a measurement while the counted thing is costly]] — because extends the same critique of headcount as proxy - [[Community engagement]] — because applies-in event planning - [[Silence in a source is filled by the audience's prior, so name what is absent]] — because contrasts on what a number leaves unstated  #### [P3] A feedback channel that only accepts complaints produces a false picture of the work **Claim** (one sentence, Courtney's voice): When the only route to the team is a problem report, the team's model of its own product is built entirely from its failures. **Evidence pointer**: [[#H3]] **Scope & conditions**: Holds for any team whose inbound channel is issue-shaped — maintainers, support, platform teams, moderation. Does not apply where praise and complaint share a channel and arrive in proportion, which is rare. **Links**: - [[Ask who was harmed, not whether someone was wrong]] — because contrasts on what a channel is designed to surface - [[Maintainer sustainability]] — because applies-in open-source burnout - [[Volunteer capacity is the real security boundary of an open ecosystem]] — because extends into what unpaid teams absorb  ### ✏️ Fleeting Queue - [F1] The workshop-over-talk weighting is directly applicable to WordCamp and Training-team programming decisions — write the connecting note #fleeting #inbox - [F2] Start routing positive user feedback to engineering deliberately; the gap Harper describes almost certainly exists in the plugin work too #fleeting #inbox - [F3] Read the Chrome WebMCP docs — the auth-gated tool surface pattern maps onto WordPress capabilities and is worth thinking about before it arrives #fleeting #inbox - [F4] The seniority-directs-the-agent argument has an unaddressed corollary: if agents do the work that used to build experience, where do juniors get it? That is its own note #fleeting #inbox - [F5] Find Tamás Piros's LinkedIn articles on AI-era DevRel metrics — referenced twice, linked in-stream, never named on camera #fleeting #inbox - [F6] Guillermo Rauch "Recursive founder mode" podcast — recommended at length, ~90 min #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Rewrite any DevRel-shaped output targets as outcome targets before the next planning cycle — professional practice #things - [ ] Draft the "a count is only a measurement while the counted thing is costly" permanent note #things  📄 **Full text:** [[Full Document Contents/Articles/Devrelshow Episode 56 - Tamas Piros From Storyblok.md|Devrelshow Episode 56 - Tamas Piros From Storyblok by Frédéric Harper]] ## Highlights - That is no longer relevant, I feel, because And then again, you know, people can hate me for this or or whatever it is. AI makes this cheap or even free, so to speak, right? So, so the the fact that, you know, you can write two pieces of content per week, that's possible. So, now do I say, "Oh, you've written, I don't know, 12 pieces of content in a quarter. Is that good or is it bad? Why didn't you do 24? Why didn't you do 36?" Technically, we are in an age where you should be able to do this. So, so what I'm struggling with right now is trying to figure out how do I really measure what the team is doing? How do I measure the success? The success cannot be I created an example repository. That again, you know, there are many sides to this discussion, but that could take you a maximum of day maybe. ([View Highlight](https://read.readwise.io/read/01m1p7s2bqtnrgwj9nqcfcrdvg)) - Note: The episode's real subject. Output metrics work by standing in for effort — the moment production gets cheap they stop measuring anything and start rewarding volume. Generalizes past DevRel to every function AI has cheapened. He states it and then admits he has no replacement, which is the honest and more useful move. - Tags: atom/zettel/z1, atom/literature/h1 - 400 people at the conference and therefore you have 400 people in the room. You only have 400 people because there's nowhere else to go. Let's face it, right? There's It's not because 400 people are actually listening to you cuz I don't like for my experience I see them, I know half of them are not paying attention to what I'm saying, right? So you have, you know, maybe 200 that are actually listening kind of to what you say and you maybe have 100 who are really, really interested in what you're saying. Now if you do a workshop, which requires like separate registration, sign-ups, etc., you get that 100 people in the room. You can interact with them. You can have direct conversation with them, which you cannot have from the stage. So in this value model that we built, we basically gave a higher weight, a higher value to a workshop. So basically an event um you know, an an event that has 200 people attending and then and we had a talk with 200 for 200 people was scored at exactly the same level when we had a workshop for, I don't know, about 50 people in the room. ([View Highlight](https://read.readwise.io/read/01m1p7segkc9a14xqrmktqmrcx)) - Note: The most portable artifact here: a 200-person talk scored equal to a ~50-person workshop. Reasoned from mechanism (talk attendance is partly a scheduling constraint; workshop attendance is self-selected) rather than preference. Directly applicable to WordCamp and Training-team programming. Note the 400/200/100 split is his impression from a stage, not measurement. - Tags: atom/literature/h2, action/h1 - This page actually exposes a set of Web MCP tools. Now, the way I know that is because, obviously, I created that, but the other way to know this is because you see there's a little I don't know if that's like a pointer or a triangle next to the um domain in the address bar. If you click that, it now says you have six available tools. And it has search watches, explore watches, search by movement, get filter options, get watch details, and sign in. What's really interesting, I'm not going to sign in cuz that will take a lot of time out of this demo. But what's interesting here is after you sign in, there are actually 14 tools. So you So I'm using Next.js and Clerk for authentication. And when I get the authentication state, so I know someone is logged in, I register additional tools, and I expose that to through Web MCP. ([View Highlight](https://read.readwise.io/read/01m1p7st5pe6n7xrj7wymagd3r)) - Note: The technical detail worth the whole demo: tool surface as a function of session state. Six tools anonymous, fourteen signed in, removed again on logout. Capability-scoped agent access — maps cleanly onto WordPress capabilities if a WebMCP surface ever lands there. - Tags: atom/zettel/z1, atom/literature/h3