Working Group Chair Skills: Standards Work Isn’t Just for Coders
“This one’s for everyone who’s ever said, ‘I’m not technical enough to participate in standards development.'”
If you’ve wondered what working group chair skills actually matter, I have news for you: you don’t need to be a spec-writing wizard to be effective.
I do get it, though. I chair working groups, and I still can’t read specs the way implementers do. Half the time I open a technical specification, my eyes glaze over after the abstract. I couldn’t code myself out of a wet paper bag. (Unless that wet paper bag happens to include m4 and sendmail rulesets. Those, I can do.)
That said, if you take nothing else away from this post, take this and embed it in your brain: you don’t have to be a spec-writing wizard to be an effective contributor, or even to chair a working group.
In fact, some of the most valuable skills in standards work have nothing to do with writing code.
You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.
And be sure to leave me a Rating and Review!
What a chair actually does (and doesn’t do)
There’s a misconception that working group chairs must be the ultimate subject-matter experts, the kind of person who can answer any question off the cuff. I used to believe that too. *buzzer sound* Wrong, try again! The job is about facilitation and neutrality, not encyclopedic knowledge.
A good chair brings the right working group chair skills to the table:
- Manages time, the agenda, and the meeting queue.
- Keeps the room neutral and separates their “chair hat” from their personal opinions.
- Tests for consensus and documents objections.
- Guides the group back to its charter when things start to sprawl.
What a chair doesn’t do:
- Decide the technical design.
- “Win” arguments on the mic.
- Gatekeep new contributors.
Yes, a baseline of knowledge helps, mainly to keep the group on track and ask the right questions. But if you’re the loudest voice in the room or the person with the most opinions? That’s a red flag.
The Madrid moment
This post was inspired by a moment at the recent IETF meeting in Madrid.
I was sitting in a session (not one I was running) feeling wildly inadequate. The chair of that meeting seemed to know everything: answering questions without pause, bouncing ideas around, and generally radiating expertise. I thought, I can’t do that. I’ll never be that person.
Later, I mentioned my self-doubt to a friend who’s been in standards work since Gandalf was a baby (i.e., a very long time). They said something that stuck:
“That kind of deep subject-matter expertise isn’t what makes a good chair. The job is to be neutral, help the group come to consensus, and keep the process fair. If you’re too invested in the outcome, you can’t do that well.”
And they were right. In a session I chaired the next day, I reminded myself of that. Instead of getting pulled into the details, I paused, restated the questions we were debating, and asked for commitments to review from experts in the room. We left the meeting with clear decisions and action owners. Go, team!
No wizard-level technical knowledge required.
Where non‑coders shine
Even if you’re not a chair, these are the same skills that make you a great contributor and help you develop working group chair skills if you want to take that step later. Non‑coders are often the ones who:
- Turn pain points into crisp user stories. “We need X because Y breaks if we don’t.”
- Write readable summaries for product managers, lawyers, and execs.
- Triage issues on GitHub—label them, close duplicates, line up proposals for meetings.
- Spot interoperability gaps. Help set up test plans, track what passes/fails, and document blockers.
- Herd the cats. Draft pre-reads, take notes, and make sure decisions actually get written down.
These are the unglamorous but critical pieces that keep work moving forward. Without them, groups stall, meetings get repetitive, and good ideas die in the noise. Groups well and truly need someone brave enough to ask “stupid” questions (that are never actually stupid) about how it all works.
How to start if you’re “not technical enough”
If you want to get involved but don’t know where to start, try this:
- Read the charter of the group and two or three recent GitHub issues.
- Introduce yourself on the mailing list with a sentence about what you can help with (e.g., “I’m a PM and can help with use cases or meeting notes”).
- Volunteer once. Scribe a meeting, write a summary, or draft a use-case doc.
- Ask the chairs: “What would unblock you this week that doesn’t require coding?”
- Shadow a consensus call and notice how the chair phrases questions and records outcomes.
These small steps get you known as someone who adds value quickly. That reputation goes a long way.
For managers: send the right people
If you lead a team, the worst thing you can do is assume only senior engineers belong in standards groups. You should be sending:
- PMs, solution architects, and analysts.
- Tech writers who can make decisions and docs accessible.
- Support or operations leads who know what customers actually need.
Give them specific assignments: draft use cases, clean up issues, track interop progress. And measure their impact by outcomes that matter: fewer rehashed meetings, clearer issues, faster consensus.
Common traps (and how to avoid them)
Even experienced chairs and contributors stumble into these:
- Wearing the company hat too heavily. Remember: your job is to move the group’s work forward.
- Turning meetings into tutorials. Save deep dives for dedicated docs or issues.
- Letting the loudest voice set direction. Ask for explicit “can live with it” signals from the room.
- Treating silence as consent. It usually isn’t.
A simple chair’s checklist helps: agenda posted in advance (see the Important Dates page for IETF meetings) → pre‑reads linked → scribe/timekeeper assigned → decisions written down → minutes posted within 48 hours.
Why this matters
Standards work touches every part of the identity world—federation, digital credentials, browsers, payments. These decisions shape products and policies your teams will live with for years. I mentioned this a while back in Standards Versus Reality with how even well‑intentioned technical choices can clash with deployment realities, which is why diverse voices are so important.
But the process isn’t self-sustaining. If only engineers and spec authors show up, important perspectives get lost. And that hurts interoperability, usability, and deployment.
You don’t need to be the smartest engineer in the room to develop strong working group chair skills. You need to listen, ask questions, and help the group get to a decision.
Your turn
If you’ve thought, standards aren’t for me, try showing up once. Scribe a meeting. Draft a use-case doc. Or if you lead a team, send someone who can listen, write, and keep things moving.
📩 If you’d rather track the blog than the podcast, I have an option for you! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
Introduction
[00:00:26] Let’s get into it.
[00:00:29] Hi everyone, and welcome back to the Digital Identity Digest.
[00:00:33] Today I want to talk about something I hear often from people who are curious about standards work but never take the leap to participate.
[00:00:42] It’s that feeling of “I’m not technical enough. Standards are for engineers, so I’ll just sit this one out.”
[00:00:50] If that’s you, this episode is for you.
[00:00:54] The truth is, standards work is not just for coders. Some of the most important roles in working groups don’t involve writing a single line of code.
***
Why Standards Work Isn’t Just for Engineers
[00:01:04] I want to pull back the curtain on my own experience as a working group chair. I’ll share:
- The skills that actually make standards work successful
- How non-coders can contribute
- How to build the confidence to jump in
[00:01:24] Here’s my confession: I chair groups in the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C).
[00:01:33] But if you handed me a technical specification to implement — I couldn’t do it. I can’t code my way out of a wet paper bag.
[00:01:42] I can read the text of a specification.
[00:01:48] I can follow the arguments and track design decisions.
[00:01:53] But I don’t read specs like implementers do.
And that’s okay. Because being a chair is not about being the ultimate expert — it’s about facilitating process, guiding discussion, and keeping the group focused.
***
What a Working Group Chair Actually Does
[00:02:16] So what does a chair really do?
[00:02:24] On a good day, you’re:
- Setting the agenda and keeping discussions on track
- Managing the queue so everyone knows when it’s their turn
- Listening carefully and testing for consensus
- Making sure objections are heard and documented
- Guiding the group back to its agreed charter
[00:03:06] Importantly, chairs do not decide technical design. They don’t win arguments or gatekeep contributors.
[00:03:14] Yes, technical knowledge helps — but being the loudest, most opinionated person in the room? That’s a liability for a chair.
***
Lessons from Experience
[00:03:30] This all came to mind recently at an IETF meeting in Madrid.
[00:03:36] I was sitting in a session I wasn’t chairing and felt completely inadequate. The chair was brilliant — answering every question instantly and recalling years of history.
[00:04:06] I shared my self-doubt with a long-time standards veteran. Their advice stuck: A good chair isn’t about deep expertise. It’s about neutrality and guiding consensus.
[00:04:28] The very next day, while chairing my own session, I leaned on that advice. Instead of diving into debate, I paused, restated the question, and asked the group to continue the discussion asynchronously.
[00:05:09] The result? We left the room with clear decisions and owners for next steps.
***
Why Non-Coders Are Essential
[00:05:19] Here’s the truth: non-coders bring incredible value to standards development.
[00:05:31] Examples include:
- Turning pain points into crisp user stories
- Writing clear summaries for product managers, executives, and legal teams
- Triage work: labeling GitHub issues, closing duplicates, organizing proposals
- Spotting interoperability gaps between specifications
- Setting up test plans and documenting blockers
- “Herding cats” by taking notes and tracking decisions
[00:06:44] None of these require writing code — but all are vital to progress.
***
How to Get Started in Standards Work
[00:06:58] If you’re wondering where to begin, here are practical steps:
- Read the group’s charter and skim recent issues to understand scope
- Introduce yourself on the mailing list — even a short message offering to scribe is welcome
- Ask the chairs directly what one thing you could do this week to help
- Observe consensus calls to learn how experienced chairs guide groups
[00:08:20] These small steps build confidence and help you learn core chairing skills: listening, documenting, and facilitating decisions.
***
Advice for Managers
[00:08:31] If you lead a team, don’t assume only senior engineers should join standards groups.
Send your:
- Product managers
- Solution architects
- Analysts
- Technical writers
[00:08:56] Give them specific assignments like drafting use cases, cleaning up issues, or tracking interoperability progress. Measure outcomes such as:
- Fewer rehash meetings
- Closed issues and pull requests
- Documented progress
[00:09:23] This builds institutional knowledge in your organization while helping the group succeed.
***
Common Traps to Avoid
[00:09:31] Even experienced chairs fall into these traps:
- Wearing your company hat too heavily
- Turning meetings into tutorials that eat time
- Letting the loudest voice set direction instead of true consensus
- Treating silence as consent instead of seeking explicit signals
[00:11:04] A simple checklist can help avoid these pitfalls:
- Post agendas in advance
- Share pre-reads
- Assign a scribe and timekeeper
It’s basic, but it works.
***
Why This Matters
[00:11:30] Standards work touches every part of digital identity — from federation to credentials, browsers to payments.
[00:11:46] But if only engineers show up, critical perspectives are lost. That hurts usability, interoperability, and adoption.
[00:11:57] You don’t need to be the smartest engineer in the room to contribute. You just need to listen, ask questions, and help the group reach decisions.
***
Final Thoughts
[00:12:10] If you’ve thought “standards development isn’t for me,” I challenge you to reconsider.
Show up once.
Scribe a meeting.
Draft a use case.
Or, if you lead a team, send someone who can write, listen, and help keep things moving.
[00:12:26] These are the skills that keep standards work healthy.
[00:12:30] So ask yourself: What non-coding skill could you bring into a working group this month?
[00:12:48] Thank you for listening to the Digital Identity Digest.
[00:12:59] If this episode helped make standards clearer — or at least more interesting — share it with a friend. You can connect with me on LinkedIn @hlflanagan.
And don’t forget to subscribe, leave a rating, and find the full written post at sphericalcowconsulting.com.
Stay curious, stay engaged, and let’s keep these conversations going.
