Standards Evangelization Isn't Optional

Rolling out any kind of software quality initiative is hard. API design standards - the kind that promote consistency, intuitiveness, dare I even say, user delight - are no different. And as an invited observer to a standards working group, when the pushback began at a recent session, I felt my breath catch. 

This was the moment that every standards leader eventually faces: the first real resistance. 

The group had been meeting for several months in relative harmony. The work wasn't trivial, but the desired outcomes were clear, and disagreements were minor and quickly resolved. The draft of the new policy appeared to be reaching consensus. It was just weeks away from being published to the rest of the company. Then Denny [not their real name] showed up.

There are those of us in love with the sound of our own voices. Then, there are those whose tortured existence is a constant struggle to be seen as right. And, sadly, there are people that light things on fire for the sake of watching things burn. Each of these people, when placed into a consensus experiment with weak controls or limited oversight, can spell disaster. 

Denny was not any of those. 

Denny is bright, curious, and capable. Like nearly all of us, he's being asked to do more with less. He's spinning a lot of plates, so when he hears about a new mandate that's coming that'll put more on his plate, he's the kind of self-identified, pro-active problem solver who starts asking questions. 

"Why are we doing this? What are we trying to achieve? Is that the best way to do it?"

"How many hours is this going to add to our planning? Does this retroactively apply to stuff already in prod? How much time is that, cumulatively? Is it worth it?"

"No, really guys, for real - how does this help? Why are we doing this?"

How not to win friends and influence people

Denny's questions weren't malicious. However, as the standards working group was caught unprepared, the arguments supporting the standards initiative dissolved like tissue paper in a shower. The responses were stumbling, stunned, and, worst of all, self-defeating. 

Instead of having credible answers ready to answer straightforwardly and with curiosity, they reached for the nearest crutch:

• Allusions to authority figures. "Because audit requires it." "Because the regulator said so." That kind of justification might end the conversation in the boardroom, but to a team in the trenches, it feels like a limp passing of the buck. In giving that answer, the working group wasn't building the legitimacy of their role as standard bearers in the larger organization; they cemented the perception that they were enforcing clueless busywork. 
• Hand-waving away the cost. When Denny raised that the proposed changes could consume 500-1000 developer hours (cumulatively), the reply was little more than, "You just need to account for it in your capacity planning." That response isn't just crass. It sends a signal that the team's pain doesn't matter. 
• Vague promises of better days. "This is just the first step; we'll automate later." Without timelines or milestones, "later" translates to "never." Denny is no fool; he knows how resource-strapped the entire organization already is. Instead of reassuring, this gaslighting erodes trust. 
• Defensive posturing. One working group member, frustrated with the digression, snapped, challenging, "What's the alternative?" and "I'm not sure which team you belong to." Both came across as less questions said with legitimate curiosity and more as attempts to shut down a critic.

Each of these tactics has something in common: they reduce the legitimacy of the standard itself. The primary source of the standard, the working group that had been putting together some good work over the course of months, sounded unsure, evasive, and defensive. 

It was an unfortunate textbook example of how not to respond to legitimate questions from your community of practice.

A better playbook of responses

If you're overseeing standards work, you will encounter questions like Denny's. The difference between standards that gain legitimacy and standards that wither under suspicion often comes down to how you answer in that moment.

Here are five reframes that turn weak defenses into credible, persuasive responses:

1. Connect standards to resilience and auditability

• Instead of: "Audit requires it."
• Try: "Auditors have pointed out that inconsistent error formats and lack of correlation IDs make it impossible to trace incidents reliably across services. A uniform standard isn't just about satisfying regulators; it gives us confidence that when something breaks, we can detect, diagnose, and recover faster."

Whether the change is mandated by a group or is a "bottom-up" community effort to solve a common problem, the group proposing the change must own its effort. The era of ivory-tower architects drafting ideals and expecting others to enforce them is a thing of the past. 

2. Make "first steps" concrete

• Instead of: "This is just the first step; we'll improve later," or the cliche, "Crawl, walk, run," hand-waving-
• Try: "Yes, the initial rollout means new APIs must adopt the standard response objects immediately. By the next release cycle, we'll provide template support, build it into the default framework, and update our linting tools. The end goal is that developers won't even think about this standard; the tooling will make using the format the default."

Don't wing it or invent next steps on the spot. Recognize ahead of time that people will want to know how this intrusion into their daily routines will be minimized over time. And if you are caught without a plan, be honest about what still needs to be decided; even go so far as to use that as an opportunity to invite the challenger into the circle, to co-create what the next step might be. 

3. Acknowledge the burden honestly

• Instead of: "You just need to plan for it."
• Try: "We know refactoring error objects or aligning with taxonomy adds work. That's why we're phasing requirements: new APIs must conform now, while existing ones will transition over the next two quarters. We'll publish migration guides and sample code to reduce the overhead."

Leadership is always challenging, but after the constant whiplash of the last five years, many team leads feel like they're tasked with maintaining their respective house of cards. A little empathy and letting them know that they (and the job they are doing) are seen can go a long way. 

4. Provide clear guardrails for exceptions

• Instead of: "Probably exceptions can be approved."
• Try: "If a legacy service can't adopt the error handling right away, exceptions are possible, but they're time-bound and must include a migration plan. This ensures we don't stall teams while still keeping pressure on to converge."

Similar to "first steps", recognize that there will always be some edge case or weird dependency that will only surface after you've created a new blanket requirement. There will always be the need for some kind of exception process. Account for that during standards creation and, failing that, acknowledge it's on the shortlist of post-launch fixes. 

5. Frame the north star

• Instead of: "What's the alternative?"
• Try: "We agree it's more work upfront. But our north star is a developer experience where standards enforcement is invisible: linting, code generation, and CI/CD will do the heavy lifting. The short-term inconvenience leads to a long-term ecosystem that's faster, safer, and easier to extend."

"What's the alternative?" is one of those challenges that really bothers me. The person asking the question hasn't been privy to the same information, hasn't been in the same in-depth conversations, or hasn't worked the solution for the past six months. Flipping the discomfort around and challenging someone to improvise a better solution on the spot is just a dick move. Rather than burning a bridge by becoming defensive, working group members should seize the opportunity to reassert shared principles - undisputable, desirable things that everyone should want - and then articulate how the proposed changes bring people closer to that goal. Denny, understanding what the desired outcome is, may have a better idea of how to accomplish that. But even if he doesn't, he can appreciate why what is being proposed is being proposed. 

Taken together, these responses flip the script: instead of sounding like minions of arbitrary busywork, the standards team sounds like stewards of resilience, efficiency, and developer experience. In short, it seems they genuinely care.

From "how to answer" to "who needs to be able to answer"

One of the unspoken dynamics in many standards bodies is how people actually get there. Rarely do participants raise their hands out of sheer enthusiasm. More often, they're picked - or "voluntold" - because of their technical expertise or their proximity to the problem being solved.

That's not a bad thing. Technical credibility matters. But it's also not enough.

The difference between a working group that produces policies no one follows and one that drives lasting change usually comes down to something softer: communication. Every participant has to operate, at least part of the time, like an internal developer evangelist. Not everyone needs to have a "walkaround" deck prepped and ready to go. But it does mean being able to:

• Reframe "because audit" into "because resilience."
• Translate technical mandates into clear developer impact and business benefit.
• Show empathy for the cost of change, without losing sight of why it matters.

These aren't innate talents handed out at birth. They're skills. And like any skill, they can be learned, practiced, and refined.

And as a bonus? Those skills are portable. Answering objections with clarity and empathy in a standards meeting, you'll find the same techniques work in design reviews, executive briefings, and even one-on-ones with skeptical peers.

For individuals who aspire to succeed in these roles - and, frankly, for those who aim to be effective change agents throughout their organization - these are investments worth making.

Standards evangelization isn't optional

It's tempting to believe that once the draft is written, the consensus secured, and the slides polished, the hard work of standards creation is over. But as the meeting with Denny showed, that's when the real work begins.

Standards don't succeed because they're technically elegant. They succeed because people defend, explain, and carry them forward into their daily practice. That belief isn't generated by authority or policy documents - it's generated in the moment when someone asks, "Why are we doing this?" and the answer resonates.

That's why standards evangelization isn't optional. It's not a job title, and it's not something you outsource to a single charismatic individual. It's a skill every participant in a working group needs: the ability to reframe, to empathize, to connect technical mandates to real outcomes.

The irony is that many of the people "voluntold" into standards groups already have the hard technical skills. What will make them truly effective is investing in the soft skills (listening, reframing, and communicating) that turn defensiveness into dialogue and policy into practice.

If you're leading or participating in standards work, remember: creating the standard is only half the job. Defending it - persuasively, empathetically, and repeatedly- is what turns paper into progress.

Wrapping Up

Thanks for reading! If you're not already subscribed, consider doing that so you can get the latest, greatest Net API Notes delivered directly to your inbox. OR, you can get updates via RSS or follow @index@netapinotes.com on the Fediverse. 

That's a wrap on August - bring on September, and the end of year rush!

Till then,

Matthew (@matthew in the fediverse and matthewreinbold.com on the web)