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