Site icon Spherical Cow Consulting

What It’s Actually Like to Serve on the W3C TAG

Heather Flanagan

Group of Business People Meeting Teamwork

“Every so often, I talk to someone who would probably make a very good member of the W3C Technical Architecture Group and discover that they have never seriously considered running.”

Sometimes they assume the TAG is mostly for browser engineers. Sometimes they think they do not know enough about the Web platform. Sometimes they have no idea what the work actually involves.

So, with TAG election season coming up soon, here is the version of the job description I wish more people had. I’m writing as myself, for myself, without TAG endorsement. I’m a TAG member, but this blog is mine, all mine.

The formal description is that the TAG is responsible for stewardship of the Web’s architecture: documenting and building consensus around architectural principles, helping resolve architectural issues, and coordinating architectural work across technologies and communities.

In practice, that means looking at a fairly astonishing range of technologies and asking what their design means for the Web as a whole. That breadth is one of the hardest parts of the job. It is also one of the coolest.

A Digital Identity Digest
What It’s Actually Like to Serve on the W3C TAG

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 does the TAG actually do?

A substantial part of the TAG’s work is reviewing emerging Web technologies. Working Groups and other standards developers bring proposals to the TAG for architectural review, often while those technologies are still being designed. We look for early architectural concerns, ask questions, and try to help make those designs fit coherently into the Web.

The TAG also develops broader guidance, including the Web Platform Design Principles, TAG Findings, and other work that extends beyond a single specification. The TAG is also part of the last-resort process for resolving Formal Objections.

Nobody is expected to be an expert in everything we look at. Everyone is expected to participate. That means contributing where you have expertise, but also being willing to read and think about areas where you do not.

You do not need to know everything

This is probably the part I underestimated most before joining. I know quite a lot about digital identity, Internet protocols, and standards. There are other areas where my expertise is considerably thinner.

Looking at you, CSS.

Grappling with technologies I know very little about has been one of the harder parts of TAG work. It turns out, though, that understanding the basics of how computers and the Web work still gives me something useful to bring to those conversations. Sometimes that is an architectural observation. Sometimes it is a naive question. Naive questions are a superpower.

If you have spent years immersed in a technology, some of its assumptions eventually become invisible. Things that seem self-evident to an experienced specification writer may not be obvious at all to someone approaching the design from another part of the stack.

Asking “Wait, why does this work that way?” can expose an assumption that needs to be explained, reconsidered, or at least made explicit.

That is part of why the TAG needs a variety of expertise. Browser implementation and Web API experience are extremely useful, but so are security, privacy, accessibility, identity, protocols, internationalization, distributed systems, user experience, and many other areas.

What matters is not only how deeply you know your own field; it’s also whether you can use what you know to reason about consequences beyond it.

This can be a career goal

You also do not need to wake up one morning already qualified to run for the TAG. (Actually, if you do manage to do that, tell me. I am deeply curious about how you’ve managed it!)

More realistically, this is something you build towards.

Start by developing real depth somewhere. Then work on breadth. Read specifications outside your immediate specialty. Participate in standards discussions where other people have different assumptions than you do. Practice explaining why something concerns you without assuming that everybody starts from the same mental model. Most importantly, if the TAG is a serious goal, get involved with W3C.

There is no formal requirement that TAG candidates have prior W3C experience. In practice, though, I think it matters a great deal.

The TAG is elected by the W3C Membership. If nobody in W3C knows your work, understands what perspective you bring, or has seen how you participate in standards discussions, you should be realistic about your chances of being elected.

That does not mean you need decades of W3C history. It means you should give people the opportunity to see how you work. Join a Working Group or Community Group. Participate in horizontal review. Contribute substantive comments. Help resolve issues. And learn the W3C Process.

I don’t mean memorizing procedural rules, though feel free if that’s your jam. What you need to understand is how groups make decisions, how consensus works, what authority Working Groups have over their specifications, how Formal Objections work, and how escalation and review happen.

That knowledge is critical once you are on the TAG. It also helps establish that you understand the institution you are asking members to elect you to help lead architecturally.

The commitment is real

TAG participation is not a couple of interesting calls each month. You should plan on at least one business day a week, and sometimes more.

The TAG currently has a plenary call every other week and breakout calls every week. Members are expected to participate in two breakouts each week, plus the plenary when it is held. There is also substantial work outside meetings: reading specifications and explainers, participating in design reviews, discussing issues on GitHub, reviewing documents, and contributing to TAG publications.

Some weeks are much busier than others. On average, I’d say it’s about a day a week worth of work.

And then there is travel.

The TAG meets face-to-face three times a year, including TPAC. Remote participation is supported, and it is possible to participate remotely. But I get more out of the face-to-face meetings. Several days of sustained architectural discussion create a level of bandwidth that is hard to reproduce through a series of video calls.

It’s important to know that W3C does not fund TAG member travel. Depending on where meetings are held, flights, hotels, meals, and related costs can easily add up to thousands of dollars a year.

There is also an opportunity cost. I have written before about why I still think traveling to conferences and standards meetings is useful. TAG meetings are absolutely useful, but attending them means I do not go to something else. There are only so many days in a year I am willing or able to spend on airplanes and in hotels. Three TAG meetings take up some of that finite space.

That is not an argument against doing it. It is simply something you should understand before you run.

Your employer needs to actually support this

This is the other practical issue I think prospective candidates need to consider early. If your employer says, “Sure, go ahead, but it is not going to be part of your day job,” I would push back. Doing TAG work on top of a full existing workload is not a sustainable long-term plan.

You may be able to do it for a while by working evenings, weekends, or longer days. That is not the same thing as organizational support.

Meaningful employer or sponsor support includes time as well as money. Travel funding is critical. So is having explicit permission to spend working hours on something that may have no immediate relationship to quarterly revenue, the current product roadmap, or this month’s customer commitments.

TAG participation exposes you to architectural questions well before many of them become mainstream implementation problems. It improves your ability to reason across domains, identify hidden assumptions, and think about consequences beyond one product or specification. It also puts you in sustained technical discussion with people from across the Web ecosystem.

Those capabilities come back to an employer even when a particular TAG review has nothing to do with what the company is shipping this quarter. But there is an important boundary.

Your employer needs to support the work while also accepting that you do not represent them on the TAG. TAG participants serve as individuals. Your sponsoring organization needs to be comfortable with you holding views independent of theirs. If your employer is only willing to support TAG work after you have completed everything they already expect you to do, they are not really supporting TAG work.

So, should you run?

Maybe not this year for the majority of people reading this. But if the idea of spending time on technologies you know well, technologies you barely know at all, and questions that sit somewhere between them sounds interesting, the TAG is a pretty remarkable place to aim for.

Develop deep expertise somewhere. Learn to reason beyond it. Get involved with W3C. Learn the Process. Build a track record of contributing constructively. Make sure you have the organizational support to give the work the time it deserves. And do not rule yourself out because you do not know everything about the Web platform.

If you are worried that perhaps you are not expert enough, ask people you work with. Ask current TAG members. See what they think. People who understand the limits of their own expertise are often exactly the people I would like to see consider running.

I have one more year, more or less, in my current appointment. I’d love to answer any questions you have about what it’s like.

📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Transcript

Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity, from credentials and standards to browser weirdness and policy twists.

If you work with 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.

What Does the W3C TAG Actually Do?

Every so often, I talk to someone who I think would make an excellent member of the W3C’s Technical Architecture Group, also known as the TAG. Then I discover that they have never seriously considered running at all.

The reasons are usually pretty familiar.

They assume that the TAG is mostly for browser engineers. Or they’re quite sure that they don’t know enough about the web platform. Or they’ve read the formal description and still have no idea what serving on the TAG would actually involve.

To be fair, the formal description doesn’t really help much with that last one.

The TAG is responsible for stewardship of the web’s architecture. It documents and builds consensus around architectural principles, helps resolve architectural issues, and coordinates work across technologies and communities.

Which is great. That’s true.

But what would you actually be doing on any given Tuesday afternoon?

With the TAG election season coming up, I wanted to offer my take on the job: what the work looks like, what makes someone effective at it, how to build towards it, and what support you need to do it sustainably.

I’m speaking for myself here, without TAG endorsement. I am an appointed TAG member, but this blog is solely my own thing.

Reviewing Emerging Web Technologies

A substantial part of the work for the TAG is reviewing emerging web technologies.

Working groups and other standards developers bring proposals to the TAG for architectural review, ideally while there is still time to change the design.

At this point, we’re asking questions about the technology, looking for assumptions that may have gone unexamined, and trying to figure out how the technology fits coherently into how we all use the web.

In addition to that, the TAG develops broader guidance, including things like the Web Platform Design Principles and other TAG findings.

The TAG also has a role in the last-resort process for formal objections, which is a whole other part of W3C governance that I’m not going to get into here.

You Need Breadth as Well as Expertise

What makes all of this interesting, and occasionally exhausting, is the sheer range of topics we cover.

One discussion might be about a browser API. I’ve talked about the Digital Credentials API and the FedCM API, for example.

The next might be about:

I know quite a lot about digital identity, Internet protocols, and standards.

In other areas of web technology, my expertise is not quite as extensive.

Looking at you, CSS.

One of the hardest parts of serving on the TAG has been engaging seriously with technologies that I ultimately know very little about. It can be uncomfortable to sit with people who have spent years on a subject while I’m still trying to figure out the basic model that this thing is wrapped around.

However, I have discovered that if you understand the basics of computers, networks, and the web, you probably have something to contribute.

You may recognize a pattern from another part of the stack or see a consequence that is familiar from your own field.

Sometimes all you have is a naive question. Surprisingly, that can be useful.

When people spend years immersed in a technology, some assumptions simply disappear from view. Then somebody asks, “Wait, why does it work that way?”

There may be a very good answer.

Sometimes, however, simply asking the question reveals that something needs to be explained further. Perhaps an assumption should be made explicit, or a design choice should be reconsidered because it doesn’t actually make all that much sense in today’s world.

I’ve become quite convinced that naive questions are kind of a superpower.

What Makes Someone Effective on the TAG?

That experience has changed how I personally think about expertise on the TAG.

We do need browser engineers and people who understand web APIs and implementation realities very deeply.

At the same time, we also need people who bring depth in areas such as:

The question is whether you can use what you know now to reason beyond your immediate specialty.

Can you look at a specification and ask, “What assumptions is this creating elsewhere?”

Can you read outside your field without deciding that you have nothing useful to say?

And can you explain the concerns you do have constructively?

Another question to ask yourself is whether you can tolerate a problem that doesn’t have an obvious correct architectural answer, where several competing constraints are all reasonable and sometimes mutually exclusive.

Working through that ambiguity is a big part of the job.

So is building consensus.

I promise the TAG does not always completely agree with each other. However, you have to listen to your colleagues, reconsider your own assumptions, and care more about reaching a useful conclusion than winning an argument.

How to Build Towards Serving on the TAG

If this sounds interesting but beyond your current qualifications, this is something you can absolutely build towards.

I think the TAG can be an excellent career goal.

So how would you do that?

Start by getting deep expertise somewhere. You do need some substance to bring to the table.

From there, work on the breadth of what you do.

Read specifications outside your specialty. Join discussions where you’re not the person who knows the most.

When you start noticing how decisions in one area create constraints in another, that’s a really useful thing.

If serving on the TAG is a serious goal, get involved with the W3C.

Prior W3C experience is not a formal requirement for nomination, as far as I know, but it matters. You need to understand the environment you’ll be working in.

The TAG is elected by W3C membership or appointed by the W3C Team. If the members and the team don’t know your work or how you participate in standards discussions, they have very little basis for deciding whether you would be good at the job.

That’s part of the realities of an election, regardless of your technical qualifications.

So what do you do?

You can:

You’re essentially letting people see how you think and how you work through disagreements.

Learn How the W3C Process Works

In general, you’re also going to need to learn the W3C process.

I don’t mean memorize it, because that is one beast of a document.

I do mean understand:

Technical brilliance gets you pretty far. However, it won’t get you as far as you need to go if you don’t understand how this particular standards organization functions.

The TAG Workload Is Significant

Now let’s talk about some of the less glamorous bits, such as the amount of time that this kind of work requires.

TAG participation is definitely more than a couple of interesting phone calls a week or a month.

You should assume that you’re going to spend at least one business day a week on TAG responsibilities.

The current meeting cadence includes a plenary where all of us get together every other week. There are also weekly breakouts split into three separate, time-zone-friendly sessions.

Members are expected to attend at least two of those breakouts, plus the plenary when it happens.

The calls are only part of the work.

In between calls, you’re reviewing:

Some weeks turn out to be very manageable.

Some weeks are not.

Travel Is Part of the Commitment

The TAG also meets in person three times a year, including at the W3C’s annual TPAC meeting.

Remote participation is supported, and you do not have to attend every meeting in person to contribute.

For me personally, though, I get a lot more out of the face-to-face meetings by being there for several days of sustained discussion.

That offers a kind of bandwidth I’ve never seen reproduced by stacking video calls on a calendar.

You can follow an argument for hours, sketch something on a board, and continue the conversation over lunch. You can have informal conversations where you don’t necessarily want everything minuted, but that turn out to be really useful.

You can also say, “Hey, about that thing we were talking about three hours ago, can we come back to that?”

All of that is valuable.

However, it certainly requires a certain amount of travel.

The W3C does not pay TAG members’ travel expenses. Depending on where meetings are held, you, your employer, or your sponsor may need to cover:

For me personally, the opportunity cost is just as noticeable.

There are only so many days in the year, and three TAG meetings means three weeks of other conferences and events that I’m not going to attend.

At some point, you’re going to run out of weeks you’re willing to spend getting on airplanes. I promise you.

That’s part of the job description, and it’s why prospective candidates should talk to their employers pretty early.

Employer Support Matters

If your employer says, “Sure, go ahead, if that’s something you want to do,” but it’s not actually part of your day job, push back hard on that.

A commitment of roughly one day a week added to a full five-day workload becomes your nights, your weekends, or simply longer workdays.

You might manage that for a while.

I’m not sure it’s sustainable over the course of a two-year commitment, which is what you bring to the TAG when you’re elected or appointed.

Meaningful support from your employer or sponsor includes:

Your employer needs to be comfortable with you spending that time on questions that may have nothing to do with what the company needs to ship this quarter or this year.

The Business Case for TAG Participation

The business case can be difficult because standards leadership does not always produce a measurable short-term return.

Its value comes over time.

TAG work exposes you to emerging architectural questions. It sharpens your ability to see the consequences across domains, and it puts you in a sustained conversation with people who think differently from you.

All of that experience comes back to your organization and can be valuable.

However, there is a little bit of a catch here.

Your employer or sponsor is not buying a representative on the TAG.

TAG members serve as individuals.

Your conclusions may sometimes align with your employer’s preferred position, and sometimes they may not. An employer or sponsor needs to respect that independence.

So the conversation is about funding, time, and independence before you throw your name in the hat.

Should You Run for the TAG?

Should you run for the TAG?

Maybe. Maybe not this year.

But don’t dismiss the idea because there are enormous parts of web technology you don’t know.

I certainly don’t know all of them.

Instead, get really good at something, then practice looking outwards from it.

Get involved with the W3C. Learn the W3C process. Build relationships by doing useful work. And get comfortable asking questions when you genuinely don’t understand something.

Most importantly, make sure the people supporting you understand the commitment and what’s required.

Why Serving on the TAG Can Be Worthwhile

I think the TAG offers a pretty unusual chance to think across technologies about how the web is put together and how it needs to change over time.

That’s a lot of breadth.

It’s also a lot to consider for the World Wide Web.

The workload and travel costs are definitely real. There are days when I find myself deep in a discussion about a part of the web platform that I barely knew existed and wondering what life choices brought me here.

But then I ask what I’m sure is a stupid question.

And just often enough, that stupid, naive question turns out to be a really useful thing.

If that sounds appealing more than terrifying, serving on the TAG might be a good goal for your career roadmap.

I encourage you to go to the written blog post for this episode. It provides a bunch of links, and you’re always free to reach out to me if you have more questions.

Thanks for listening, and we’ll tune in again next week.

About the Digital Identity Digest

And that’s it for this week’s episode of the Digital Identity Digest.

If it helps make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan.

If you enjoyed the show, be sure to subscribe and leave a rating and review on Apple Podcasts or wherever you listen to podcasts.

You can also find the written full post at Spherical Cow Consulting.

Now stay curious, stay engaged, and let’s get these conversations going.

Exit mobile version