Quality. Value. Motherhood. Ideals we can all agree are good things. Not too many people argue against them. But what is quality? What is value? I’d ask about motherhood, but my wife claims I’ll never understand.
I’ve been at offsites where we’ve been asked to define quality and value. It’s offsites like these that make hellfire and brimstone sound appealing. Of course, we get nowhere. If it weren’t for the free chocolate chip cookies, the entire time would be wasted.
The trouble is that quality and value are wrapped in perception. Even if we built a product that precisely matched the spec with zero bugs, customers and reviewers might still hate it. If it doesn’t work the way they think it should, it’s junk. If it doesn’t solve the problem the way they expect, it’s trash.
At the same time, I-Puke can produce a buggy piece of glorified plastic that crashes twice a day, and it will get showered with praise and command premium pricing just because it reminds people of their pet rocks. Life isn’t fair. The market isn’t fair. And customers are fickle.
You’ll have to do better than that
Of course, whining about unfair markets and fickle customers is pathetic. Microsoft has traditionally dealt with customer capriciousness in two ways: wowing customers with new must-have features and chasing down competitors.
Unfortunately, as the software market matures and broadens, customers get featured-out and computer usage becomes more critical, making customers more conservative. These days, customers often equate more features with more headaches. “Make the features we already have work” is the kind of enigmatic advice customers offer.
Even chasing down competitors has its limits. The strategy works well because you know exactly what customers want. Unfortunately, when you catch up, you are back to being clueless. You have jumped ahead only to fall back behind.
A change would do you good
How do we break the cycle? That’s easy—with designers and architects. By designers, I mean the people involved in defining the user experience—the “what.” By architects, I mean the people involved in defining the end-to-end implementation approach—the “how.” Customer and business needs define the “why” and “when.”
There are two sides to quality: design and execution. At Microsoft, we execute like nobody’s business. Though we still have a way to go, we are improving the quality of our execution all the time.
Eric Aside The insight about quality being a combination of experience design and engineering execution is another key piece of wisdom I’ve gained over the years. Too often people don’t separate the two or think about only the experience or the engineering.
But what good is perfect execution if you produce a product nobody cares about? You need great design, and that’s where designers and architects rule.
Good designers really understand the entire customer experience. They think it through, end to end, and design a solution that looks beyond hardware, software, networking, and other technical boundaries. The result focuses simply on how to thrill the customer. Key aspects for designers are simplicity, seamlessness, key scenarios, differentiation from current solutions, customer-driven constraints, and perceived value.
Good designers produce a pipe dream. Good architects make it real.
The man just got it wrong
Many developers think architects are all about diagrams, abstractions, and deep thoughts, instead of practicality, efficiency, and execution. They’ve met architects who concentrate on purity and elegance instead of being down and dirty in the code. There’s a name for smug, detached architects: unemployed.
Good architects have a firm grip on reality. It’s what differentiates them from designers. Though, the best designers and architects can dream beyond boundaries, yet live within them. Architects break down the pipe dream created by designers into a variety of implementation options. Each option has its own advantages and issues.
Doing it well
Good architects keep all their options open for as long as possible. As they think through how to translate the current state of technology into the designer’s future vision, constraints will arise that restrict their options—constraints like cost, performance, security, reliability, legal considerations, partnerships, and dependencies. Eventually, few options will remain and an optimal, high-level implementation design—AKA the architecture—will emerge.
The next task for architects is to clearly articulate the architecture to all the products and components that together realize the designer’s vision. The two most important factors are the interfaces and the dependency graph between the pieces. Often existing components and interfaces must be refactored to avoid circular dependencies or enable new variations of behavior.
Naturally, the lowest-level dependencies must be the most stable and developed first. Part of the job for architects is to devise practical ways of accomplishing this. Often it means first updating the interfaces and leaving them stable while the code underneath is reformed.
Eric Aside At the risk of sounding conceited, I’d say the last three paragraphs are worth another read. They cover the simple steps that great architects follow yet most architects miss.
Next time, try sculpturing
Regardless, before a single line of shipping code is written, the designers and architects must envision and describe the road map to realize customer value. Oh, I can hear naysaying nitwits crying “Waterfall!” at even the hint of thinking before acting. But the idea is to create a road map, not a full-scale replica. By knowing what you want to achieve and thinking through the pitfalls, you might actually have a chance of shipping a real solution.
Because the road map isn’t the real thing, there’s still plenty of work for the product teams that are fleshing out and executing the design. What do the designers and architects do during that time? Jump to the next project? Draw more pictures? Present papers at conferences? No, ding-a-lings—that would be disastrous.
Designers and architects must keep the product teams honest and resolve all the conflicts that arise. No one has a big enough brain to think of everything, nor should you waste years trying to do so. Good designers and architects leverage what they know as a foundation and then work with the product teams to resolve the remaining issues as answers emerge.
This means designers and architects must have strong communication skills. They must work well together as well as with the product teams to present a consistent message and guidelines. They must also have large enough brains to keep the big picture in mind as they review the details that make it possible.
Just the right tool
In addition to their vision of the future, the key tools designers use for keeping product teams on track are end-to-end scenarios and critical-to-quality (CTQ) measures. While the practice of defining and testing end-to-end scenarios is gaining critical mass support at the company, CTQ measures are just taking hold. These are the small handful of measures that will make or break the customer’s sense of quality and value. They could be performance or reliability measures, like time to complete a task or uninterrupted connectivity. They could be usability features like only authenticating once or consistency of interface. Whatever speaks “quality” to the customer the loudest, those are the CTQ measures.
In addition to the architecture, the key tools architects use for keeping product teams on track are the interfaces and the dependency graph. (The dependency graph could be as simple as a block diagram or as complex as a wall-sized component graph.) The whole idea is to allow hundreds of small teams to work independently while still creating a seamless experience. The pieces will never fit without the right interfaces. The work will never remain independent without respect for clear boundaries between layers.
Eric Aside The whole idea of small team independence was important enough that I devoted the next column in Blessed isolation—Better design.
Beyond these walls
Designers and architects play different roles, but they share one aspect in common: broad, end-to-end scope. Their job is to think across feature boundaries, product boundaries, and even market boundaries to seize opportunities. That’s because customers don’t see any boundaries. They just see incomprehensible, unmet potential. Designers ignore the artificial boundaries to bring out the value. Architects wrestle the boundaries into submission to make it real.
Sure, we could continue to frustrate customers, play catch-up, or blow years of a lead messing around until we realize that nothing fits together. Or we could take advantage of our breadth and depth to deliver unparalleled and uncompromising value to our customers. It’s not hard, but it does require the discipline to think broadly before we act, then the focus to follow through. Achieve that, and we will finally beat our toughest competitor in the market: ourselves.