1) POV
Quality is the thing I refuse to negotiate with.
Not because I am stubborn, or because I like polished UI. Because in enterprise software, quality is trust. It’s whether someone feels safe clicking “Submit”. It’s whether the workflow holds up when the data is messy, approvals are missing, or the user is rushing through a task between meetings. And it’s whether the product still feels coherent when five different teams touch it over a year.
Over time, my definition of quality has only expanded. And I have learned an uncomfortable truth: when teams are busy, quality does not degrade slowly. It drops off a cliff. Once it drops, it becomes expensive to win back.
So quality became a fundamental tenet of my leadership. Not as a slogan. As a habit.
2) What “quality” means to me
Quality is not decoration and it’s not taste.
For me, quality is the product keeping its promise when reality shows up.
Clarity when the user is stressed
Correctness when the workflow is complex
Coherence when multiple teams ship into the same experience
Dignity, especially in edge cases
A polished happy path is not quality if the empty state confuses, the error message blames the user, or the workflow falls apart the moment a policy exception appears.
In enterprise, the edges are not edges. They are the job.
3) An early chapter that sharpened my view: Microsoft SDM Plus
Microsoft SDM Plus (Service Delivery Management) reinforced what quality looks like when people depend on a system to do their work.
It was a process repository tool used across many personas: project managers, sales executives, solution consultants, product managers, and marketing. The first-gen SDM was a legacy tool and needed a meaningful upgrade. I was the only designer on the project, effectively the UX lead.
What we heard from users wasn’t “make it prettier.” It was quality debt expressed as friction:
too many clicks to reach the artifact they needed
navigation was complicated, even to find a method and its activities
content was old and needed updates
teams had updated templates and samples based on field experience, but the tool made updates difficult and admin-gated
That project reinforced a simple lesson I’ve carried since: quality is often won or lost in unglamorous places, like findability, information structure, and keeping content current. If people can’t get to what they need quickly, or if the system can’t evolve with reality, the product becomes something they work around.
4) How I advocate for quality when reality gets messy
Here’s the part people don’t always say out loud: most quality debt is not created by bad designers or bad engineers. It’s created by silence.
Silence when we accept “we’ll fix it later” without naming what later means.
Silence when we trade user clarity for internal convenience.
Silence when timelines squeeze and we treat correctness like a nice-to-have.
My job, as a design leader, is to break that silence early and constructively.
I advocate for quality by making it explicit, not personal. Instead of “this doesn’t feel great,” I’ll say:
“This breaks trust at the moment of commitment.”
“We’re shipping an experience that will teach users to avoid the product.”
“If we launch this, support tickets become the QA team.”
I’m not trying to be dramatic. I’m trying to be honest about cause and effect.
And when push comes to shove, I protect the bar by changing the question from “Can we ship?” to “What are we willing to ship and stand behind?”
5) Quality under pressure: CLM (CM Pro)
CLM was where my quality leadership got tested in the most real way.
Resources were thin. Timelines were tight. The domain was complex, spanning multiple business areas and personas. And we were competing with established industry players, which raises the bar instantly because users already have expectations for how “serious” systems behave.
In that environment, quality can easily become a casualty of “just ship something.” The risky part is that it rarely breaks in demos. It breaks in the moments where users need certainty: when they submit, approve, negotiate, or move a contract forward and the system must behave predictably.
So I anchored quality around a few non-negotiables that cross-functional partners can align on quickly:
Moments of commitment must be unambiguous: what will happen, what changes, who gets notified
The experience must stay trustworthy in messy reality: roles, permissions, exceptions, recovery
The product must stay coherent across surfaces: the same concept behaves the same way even as workflows expand
When timelines squeezed, I didn’t defend quality as taste. I defended it as risk management and user trust. We reduced scope where we had to, but we protected correctness, clarity, and coherence.
That’s what “gold standard” means to me in practice: not perfection on day one, but a refusal to ship something we can’t stand behind.
6) A tradeoff that changed how I think about quality
In CLM, we made a strategic sequencing call: we prioritized building the bulk of employee and agent-facing experiences first, and parked admin experiences for later.
It wasn’t a miss in the delivery sense. We shipped meaningful value. But in enterprise, quality is also what happens before users ever see the UI.
What we learned was that the absence of strong admin experiences raised the cost of getting started. Time-to-value stretched, implementations became more complex, and new customers often needed solution consultants earlier than we wanted, simply to configure and operationalize CM Pro effectively.
That tradeoff changed how I define and advocate for quality. I started treating admin and setup experiences as part of the quality bar, not a “phase two” convenience. If the product is hard to stand up, front-end polish doesn’t matter, because adoption friction begins at implementation.
What changed in how I operate: when we sequence work now, I push for a minimum setup-quality baseline alongside the core user flow, so customers can activate value without a heavy services dependency.
7) How I make quality scalable
If quality depends on one person, it’s not quality. I feel it is a hero moment.
I try to scale quality in three ways:
1) I teach the team how to see.
Quality improves fastest when people can recognize it. I invest in critique habits where feedback is specific, grounded, and kind. Over time, the team starts catching issues before I do.
2) I bring quality forward in the process.
Most quality fights happen too late, when changing things is expensive. I pull the hard conversations earlier: what we will not compromise on, what we will defer explicitly, and what “done” means for this release. I’d rather have a slightly uncomfortable conversation in week one than a painful scramble in week eight.
3) I build shared defaults without turning it into bureaucracy.
I’m not interested in giant rulebooks. I’m interested in patterns and examples that make the right decision the easiest decision: consistent behaviors, clear content, and a common expectation for correctness.
8) The culture I want my teams to carry
Quality is not a phase at the end. It’s a way of working.
It’s not a standard I enforce on people. It’s a standard I build with them, model myself, and keep alive through the messy realities of software development.
Because anyone can ship when conditions are perfect. Leadership is keeping the bar when they aren’t.
Gold standard is not a finish line. It’s the direction.
