Standards have been an important part of my career for some years now. I've served on—and chaired—technical committees in a number of industry consortia (W3C, OASIS, IETF, and Liberty Alliance). Standards are important in technology: using them brings benefits to go along with the costs, even though, as the old cliché says, "The good thing about standards is there are so many from which to choose."
Working on standards committees poses special challenges, and I have lots of respect for those who can do so full-time for years on end. It takes persistence, patience, and a special sense of humor—the type of qualities you also find in caregivers for three-year-olds. (And believe me, sometimes committee members throw tantrums, just like kids. Although the tantrums are quieter, and there's no rolling around on the floor screaming, they're tantrums nonetheless.) There are also lots of benefits, both for the company sending you to the meetings and for you, personally. You work with experts in the field from different companies, you discuss different points of view in an area of interest to you, your company will be more aware of what's happening, and it's a great antidote to the dreaded "Not Invented Here" syndrome. If, like me, you can combine standards work with other projects—particularly those related to implementing or using those standards—you, your company, and the committee will benefit.
Meeting the needs of the ultimate users is what writing specifications and standards is all about; spending large amounts of time on standardizing specifications that won't be used is a waste for everyone concerned. Yet this happens all too often, for a variety of reasons. Often the standard is too complicated to be usable. Or other, better technologies come along and supersede it. People generally want standards so that they have some guarantee that the products that implement those standards will work together, or that they are replaceable by another product that implements that standard. One corollary of this is that small specifications that solve well-defined problems are generally more worthwhile to work on than large tomes promising solutions to all problems. All other things being equal, small specifications are easier to implement more completely and correctly than larger ones.
"All other things being equal," of course, is the contentious point; how does a committee make the specification as good as it can be? It all comes down to the people on the committee and how well they work together. Most committees have a certain number of roles that should be filled if the resulting specification is to be of high quality; some roles require more technical expertise than others.
In the ideal case, the committee is small enough that everyone gets a chance to contribute, but large enough to get a good spread of opinion. (The W3C DOM Working Group, which I chaired, had around 15 participants most of the time, which was a good size.) It's also best if there's continuity, so that the committee doesn't constantly have to bring new participants up to speed on the current issues being discussed. Although it's often difficult to keep the same people on the committee, they're much more effective that way.
Personally, I like a mix between people from big companies, small companies, and individuals; the differing points of view often mean that the resulting specification will meet more needs. It would be good if more committees had diverse opinions represented on them. I've often been the only woman, or the only person not from a big company on a committee, or the only person who's lived outside North America. I think that my being able to point out different experiences of how technology is used has been valuable (at least I like to think it has been!). As an example, small companies need systems that are easy to implement and set up. Large companies need systems that can cope with tens of thousands of users, or more. If a standard is to meet both sets of needs, it helps to have people from small and large companies on the relevant committee. Other examples abound. Of course, being able to have more diverse opinions on the committee requires the support of the companies sending people to the committee, so that they pick the right people for that diversity. This may also include convincing companies that they will benefit from taking a more active role on the committee.
The biggest distinction on any technical committee is between the active members and the lurkers. Lurkers, by definition, want to know what you're doing and may have objections to specific items, but, in general, they aren't going to be doing any work. So you need to ensure that they are kept informed and that they have a chance to raise the specific issues in which they're interested, without stopping the active members from working efficiently. How this is done will depend on the standards body you're working in and on the Chair.
The active members take several roles. There are the obvious ones, such as the Chair of the committee and the Editor(s) of the specification. The Chair is effectively the project manager as well as chairing the meetings, while the editors need to know the subject matter well, and have the ability to distill the discussions of the group into reasonable prose. They're both challenging and necessary roles.
Then there are the less well-defined roles. To me, these roles are also important if the specification is to be properly understood by people who weren't on the committee. They are more fluid, they're not assigned by name, and often people who appear to be lurkers will take on one of these roles. One is the "I don't understand" role. When the technical experts get going, they decide on something, and then they need to figure out how to word it in the specification. Making these experts come up with a good way of explaining the issue and the resolution is incredibly important, but often doesn't happen as the others on the committee are too embarrassed to admit that they don't understand. If the people on the committee don't understand, how is anyone outside of the committee to understand? This is where the "I don't understand" person helps, by ensuring that the ultimate wording makes sense. A related role is the nitpicker: the person who says "In this section, it says X; but in that section, it says Y, how can they both be true?". If these little details of inconsistency are often not picked up by the editor or if they're not picked up by the people who are deeply involved in the discussions, they become problems for the poor implementers later on. The more those inconsistencies can be resolved early in the process, the better.
In the end, technical committees need members who can talk to other people; who listen to a different point of view and can respectfully disagree; who can admit when someone has a better idea; and who can check their ego at the door. Most organizations I've worked with want the specifications to reflect the consensus of the participants. Getting to that consensus is hard work, but it is also satisfying.
I've always been surprised that more women aren't involved in standards work; it's a great way to contribute to the community and to benefit your company, regardless of its size.
Series creator and editor Tatiana Apandi Recommends: Joining a Standards committee (such as, W3C, OASIS, IETF, and Liberty Alliance).
Return to Women in Technology.
Copyright © 2009 O'Reilly Media, Inc.