Site icon Spherical Cow Consulting

Contributor Skills: How Standards Are Created

Heather Flanagan

Minimal high angle view at African American software developer working with computers and data systems in office

“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.

A Digital Identity Digest
Contributor Skills: How Standards Are Created

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:

But here’s the reality.

Chairs don’t usually write standards.

Instead, they serve as:

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:

Their value isn’t just knowing things.

It’s knowing where systems break.

Subject matter experts help by:

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:

Implementers are often the first to say:

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:

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:

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:

—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:

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:

Those alternatives might be:

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:

You can challenge past decisions—but do it thoughtfully.

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

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:

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:

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:

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:

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:

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.

Exit mobile version