Before We Ship, Just One More Question
“Go away please, Colin Robinson.” - Nandor the Relentless
No one wants to be the person who drags out a meeting with a big question in the last 3 minutes left for a Q&A.
In many organizations, engineers, project managers, content people, designers, and leadership don’t regularly share the same room. Calendars are tight, priorities compete, and decisions move forward in silos, or within a limited group.
It really depends on the operating philosophy of the organization.
When everyone comes together, it might be one of the few chances to surface questions that cut across the whole system and unfortunately, that meeting just ran long.
Within an organization, different roles can be inadvertently set up to have competing priorities. For instance, if your work is focused on human-centered outcomes, like mine, you tend to orient your decisions around whether people can actually understand and succeed with what you build. If your work is not focused on human-centered outcomes, your attention is usually directed toward whether or not what you’re building works, and when it’s delivered.
Teams work better when human-centered roles are embedded rather than advisory, but it doesn’t always happen.
In an organization that defines success in terms of outputs and not outcomes, people focused on usability can feel like they’re the one slowing things down. Are you facing an accessibility compliance deadline and your role is buried in organizational layers? You might even feel like Chicken Little, trying to surface issues without the ability to steer what comes next. In that situation, the most responsible thing you can do is clearly communicate the situation and offer practical paths forward:
Frame the work in the language the organization already uses to prioritize action.
Explain the concrete consequences and risks: exposure, legal liability, increased customer service volume, remediation costs, and the scope of what can be prevented.
Show the scale of the impact.
Frame the consequences in concrete terms: millions of page views, thousands of users, or hundreds of hours of customer service time.
Break the work into solvable pieces.
Turning the problem into smaller steps makes it a manageable program rather than an abstract request.
Create the structures that allow the work to happen.
Establish standards, prioritize actions, train stakeholders, and implement tools that allow teams to check and maintain the work over time.
People who are attentive to clarity can feel “intense” because they’re seeing implications others aren’t thinking about. The person asking the questions in the last 3 minutes of the meeting is usually just trying to catch gaps before they reach the user. And the closer someone is to the mechanics of language and structure, the more their questions can sound pedantic to people who are farther from that layer of the work.
These questions come from noticing how easily small ambiguities can grow into real confusion once a solution is released. They may feel inconvenient at the moment, but they can be the difference between a solution that exists versus a solution people can actually use.
