“It occurs to me that while I wrote a post on working group chair skills a while back, I never wrote specifically about the contributors.”

Which is silly, since it’s the contributors that make everything happen.

Let’s recap: Standards don’t get written by chairs. Chairs are conveners, facilitators, and stewards of process. They organize discussions, manage scope, and make sure the group follows the rules it agreed to operate under. They create the conditions for progress, but they do not (usually) supply the substance.

That work belongs to contributors.

The ideas, the arguments, the draft text, and the uncomfortable reality checks all come from the people who show up and engage with the problem the group is trying to solve. Without contributors, there is no specification, only a meeting agenda.

“Contributor” is not a single role. It’s a set of skills, behaviors, and ways of engaging that help a group move from abstract goals to implementable text.

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!

There isn’t just one way to contribute

Most contributors move between several roles over time, sometimes within the same discussion.

Some show up as subject matter experts. They bring deep knowledge of a particular domain—cryptography, browsers, enterprise deployment, regulation, privacy—and use that knowledge to surface risks, edge cases, or design constraints that aren’t obvious at first glance. Their value is both in saying what’s possible and in explaining what’s hard and why.

Others contribute primarily as implementors. They read specifications with a builder’s eye and ask whether the text can actually be turned into running code. Implementors are often the first to spot ambiguity, missing assumptions, or requirements that sound reasonable but collapse in real systems. Their feedback grounds the work in reality.

Reviewers play a different but equally important role. They may not be proposing new mechanisms at all. Instead, they read drafts carefully and check whether the document is understandable, internally consistent, and plausibly implementable by someone who wasn’t in the room for every discussion. Good reviewers catch problems early, before they become baked into published specifications.

Healthy working groups need all of these perspectives. No single role is sufficient on its own.

Keep feedback focused on the technical problem

Effective contributors aim their energy at the work, not the people doing it.

That doesn’t mean avoiding disagreement. Standards work depends on disagreement. But productive disagreement stays anchored in technical questions, trade-offs, and consequences, not in intent, competence, or motivation.

Clear, direct feedback is a kindness in this environment. What doesn’t help is vague dismissal. Saying “this won’t work” without explanation leaves the group stuck. Explaining why something doesn’t work, what it breaks, or what assumptions it relies on gives others something concrete to respond to.

The goal is not to win an argument. It’s to improve the outcome.

Objections matter more when they come with proposals

Identifying problems is necessary, but it’s rarely sufficient.

The contributors who consistently move work forward do more than object. They explain the problem, describe the trade-off being made, and, when possible, offer an alternative. That might be revised text, a different architectural approach, or even just a clearer framing of the decision the group needs to make.

Those proposals don’t have to be perfect. They just have to be concrete enough that the group can react, refine, or reject them. Progress comes from having something on the table.

Preparation is part of participation

Standards discussions are cumulative. They build on previous decisions, closed issues, and earlier drafts.

New contributors add the most value when they take time to understand what’s already been discussed. That doesn’t require reading every historical email, but it does mean skimming past meeting notes, reviewing open and closed issues, and getting a sense of which questions are still open.

If you believe a past decision should be revisited because you have new information (NOT because you disagree with the outcome), the most effective way to raise that is to acknowledge the earlier discussion and explain what has changed. New information, new deployment experience, or new constraints can all justify reopening a question. Simply restating an old argument rarely does.

For contributors who have been around longer, the expectation is higher. Institutional memory is part of the job, and yet you cannot necessarily expect everyone to have it. Be kind to new participants and avoid inside jokes when talking about the work.

Consensus isn’t unanimity, and it isn’t optional

Consensus does not mean everyone agrees. It means the group has reached a point where it can move forward, even if some participants would have preferred a different outcome.

Good contributors engage during the decision-making process, make their objections clear and specific, and then accept the result once consensus is called. They don’t keep reopening the same debate in the hope that persistence will eventually override the group. I can’t even begin to tell you how annoying that is, and a person who regularly does that ends up with a reputation that hinders any future contributions they might offer.

That can be hard, especially when the topic matters deeply. But refusing to accept consensus undermines trust and slows the entire group.

Process knowledge is part of being effective

You don’t need to be a process expert to contribute, but you do need to understand the basics of the organization you’re working in. (I have a post that might help, especially if you’re experienced in one SDO and are interested in joining another.)

Knowing how consensus is determined, when votes happen (if they happen at all), what intellectual property rules apply, and what the code of conduct expects of participants helps keep discussions productive and focused. It also protects you, the group, and the work itself.

Most process failures in standards work aren’t the result of malicious action as much as they are misunderstandings. Familiarity goes a long way to avoiding unnecessary drama.

Reliability outweighs brilliance

The contributors who shape standards over time are not always the loudest or the most original.

They are the ones who show up consistently, follow through on actions, review drafts when asked, and stay engaged even when the work becomes slow or repetitive. Reliability builds trust, and trust gives your technical input weight.

Standards work is a long game. Sustained contribution matters more than occasional flashes of insight.

Being a good contributor is a learned skill

None of this comes automatically.

Contributor skills are developed by observing how groups work, by participating, by getting things wrong, and by adjusting over time. The barrier to entry is lower than many people think, and the impact can be significant.

If you want to influence how technology evolves, being a thoughtful, constructive contributor is one of the most effective ways to do it.

Unlike being a chair, being a contributor, at least in most open standards orgs, doesn’t require a nomination or an election, just the willingness to do the work and to work well with others.

📩 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 to the Digital Identity Digest [00:00:04]

Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting.

I’m Heather Flanagan, and each week I break down interesting and often complex topics in digital identity—ranging from credentials and standards to browser quirks and policy twists.

If you work in digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.

Let’s get into it.

---

---

Why Contributors Matter More Than Chairs [00:00:29]

Last year, I wrote a post—one that never made it into audio—about what it takes to be a working group chair. If you’re interested, you’ll find a link to that post in the corresponding article for this episode.

However, I realized something important was missing.

I hadn’t written about what it takes to be a contributor.

If you haven’t spent much time around standards work, it’s easy to assume that chairs are the ones responsible for standards. After all:

• They run meetings
• Their names appear in charters
• They explain outcomes to the outside world

But here’s the reality.

Chairs don’t usually write standards.

Instead, they serve as:

• Conveners
• Facilitators
• Stewards of process

They create the conditions for work to happen.

The actual work—the ideas, arguments, draft text, and trade-offs—comes from contributors.

Without contributors, you don’t get a specification.
You just get a calendar invitation.

---

---

Contributor Is Not a Single Role [00:01:55]

Today, I want to talk about contributor skills—not in an abstract or aspirational way, but in a very practical sense.

Specifically, what actually helps standards move from an interesting idea to text that someone can implement.

First, it’s important to understand this:

Contributor is not one role.

Instead, it’s a collection of ways of showing up. The most effective contributors move between these roles over time, depending on what the group needs.

There is no single “right” way to contribute.

---

---

Subject Matter Experts [00:02:32]

Some contributors primarily show up as subject matter experts.

They bring deep knowledge in areas such as:

• Cryptography
• Browsers
• Enterprise deployments
• Regulation
• Privacy
• Payments

Their value isn’t just knowing things.

It’s knowing where systems break.

Subject matter experts help by:

• Spotting edge cases early
• Explaining why simple designs create downstream risk
• Highlighting proposals that look elegant on paper but fail in practice

This role is critical—but it’s not the only one.

---

---

Implementers [00:03:28]

Other contributors participate mainly as implementers.

They read specifications with a very particular eye and ask questions like:

• Is this text ambiguous?
• Do requirements conflict?
• Do assumptions align with real systems?

Implementers are often the first to say:

• “I don’t know how I’d ship this.”
• “This sounds reasonable, but it won’t work in production.”

That feedback is invaluable.

Specifications that ignore implementer input often look fine—right up until no one implements them.

---

---

Reviewers [00:04:18]

Then there are reviewers.

They may not propose new mechanisms or architectures, but they play a vital role.

Reviewers ask:

• Is this understandable?
• Is terminology used consistently?
• Could someone implement this without attending two years of meetings?

Good reviewers save working groups from themselves.

They catch problems no one else sees—often because everyone else is too close to the work.

---

---

Shifting Roles Over Time [00:05:02]

The most effective contributors don’t stay in one role.

They shift based on:

• The topic
• The phase of the work
• What the group needs at the moment

Regardless of role, however, one principle matters more than almost anything else.

---

---

Focus on the Technical Problem, Not the People [00:05:27]

This may sound obvious, but it’s one of the hardest skills to learn.

Standards discussions are long.
People get invested.
Decisions feel high-stakes.

Productive contributors keep critiques focused on:

• Ideas
• Assumptions
• Consequences

—not on the people involved.

Disagreement isn’t a failure in standards work.
It’s essential.

However, it only helps when it stays technical.

There’s a difference between:

• “This doesn’t work.”
• “This doesn’t work, and here’s why.”

Clarity, in this sense, is a form of respect.

---

---

Bringing Solutions, Not Just Objections [00:06:36]

Pointing out problems is necessary—but stopping there isn’t enough.

Contributors who help groups move forward do more than say no.

They:

• Explain the problem
• Describe the constraint
• Offer alternatives when possible

Those alternatives might be:

• Revised text
• A different architectural approach
• A clearer framing of the decision

The proposal doesn’t have to be perfect—or even right.

What matters is that it’s concrete.

Progress comes from having something to react to.

---

---

Preparation and Institutional Memory [00:07:42]

Preparation is another underrated contributor skill.

Standards work is cumulative.

When contributors show up without awareness of prior decisions, groups end up rehashing the same debates—and no one enjoys that.

If you’re new, one of the most valuable things you can do is:

• Read past meeting notes
• Review open and closed issues
• Understand what’s already settled

You can challenge past decisions—but do it thoughtfully.

The most effective challenges explain what has changed, such as:

• New deployment experience
• New regulatory pressure
• New technical constraints

If you’ve been around longer, expectations are higher.

Institutional memory is part of your contribution.

---

---

Consensus Is Not Unanimity [00:09:02]

Eventually, every contributor must grapple with consensus.

Consensus does not mean everyone agrees.

It means the group can live with a decision and move on.

Good contributors:

• Engage during decision-making
• Make objections clear and specific
• Accept outcomes once consensus is called

Bad contributors keep reopening settled debates.

That behavior erodes trust—and sometimes causes work to stall entirely.

---

---

Process Awareness Matters [00:10:01]

You don’t need to be a process expert, but you do need to understand the basics of the standards body you’re working in.

For example:

• How is consensus defined?
• Is voting used?
• What intellectual property rules apply?
• What code of conduct is expected?

Most process problems aren’t malicious—they’re misunderstandings.

Knowing the rules keeps disagreements technical and prevents procedural fights from derailing real work.

---

---

Reliability Over Brilliance [00:10:55]

Here’s one of the hardest truths about standards work:

Reliability matters more than brilliance.

The contributors who shape standards over time are the ones who:

• Show up consistently
• Follow through on actions
• Review drafts when asked
• Stay engaged—even when work is slow

Standards work isn’t a sprint.
It’s not even a marathon.

It’s a relay—with no clear finish line.

Trust is built through reliability, and trust gives your technical input weight.

---

---

Anyone Can Learn to Be a Good Contributor [00:11:18]

None of these skills are innate.

Being a good contributor is learned by:

• Watching how groups operate
• Participating
• Getting things wrong
• Adjusting

The barrier to entry is lower than many people think.

You don’t need to be the smartest person in the room.
You don’t need to have all the answers.

You just need to:

• Engage thoughtfully
• Do the homework
• Focus on solving the problems in front of the group

If you want to influence how technology actually evolves—not just how it’s marketed—being a strong contributor is one of the most effective ways to do it.

And unlike being a chair, it doesn’t require nomination or election.

Just a willingness to do the work.

---

---

Closing Thoughts [00:11:31]

Thanks for your time, and tune in again next week.

If this episode helped make things clearer—or at least more interesting—share it with a friend or colleague.

You can connect with me on LinkedIn @hlflanagan, subscribe wherever you listen to podcasts, and find the full written post at sphericalcowconsulting.com.

Stay curious.
Stay engaged.
Let’s keep these conversations going.