The Windows Vista project is nearing its end. It seems like a day doesn’t go by without someone announcing they are moving to a new group and someone else announcing, “I am tremendously excited to be joining [fill-in your favorite organization].”
Yes, life is uncertain, and change leads to ambiguity and chaos, but I love reorgs. I even wrote a column about them (How I learned to stop worrying and love reorgs). How does one stay sane while dealing with misinformed or apparently clueless new management? One of the more amusing pastimes is to imagine you are the new one in charge.
How would you change things if you became King of Windows? What would you do? Do you have the guts to stand up and be heard?
What’s that? What about me? I thought you’d never ask…
Eric Aside I wrote this column shortly after my senior vice president, Jon DeVaan, got reassigned to run the core Windows division. I asked him if he wanted to review the column because people knew I worked for him. Jon said, “I think it would be best if I didn’t edit you.… I am sure I. M. Wright would not listen to me if I tried : ).” Since that time, Steven Sinofsky took over as president of Windows and switched it to a functional organizational structure like the one he had in Office. For Windows 7, Steven followed the basic outline of my plan, but he didn’t bother with PUMs and applied much more control over individual teams’ engineering processes. You certainly can’t argue with his success, and I don’t. Windows 7 is a wonderful product, notwithstanding the current competition with slate devices.
Have you any last request?
Here’s what I’d do if I became King of Windows:
- Oh sure, I’d talk to everyone and all that. Yeah, yeah, yeah. Then…
- I’d make the organizational structure match the architecture.
- I’d determine the architecture based on the user experience.
- I’d drive the user experience based on key scenarios in each usage category.
- But before selecting the key scenarios, I’d select my staff.
- My staff and I would analyze and establish the key scenarios.
- I’d assign staff members to lead the user-experience and architecture efforts.
- When these steps were completed, I’d set the organizational structure and assign leaders.
- I’d devote the first milestone of the new organization to quality and building out the engineering system defined in the architecture.
- I’d set feature priorities based on scenario priority and critical chain depth.
- I’d manage the release by minimizing feature completion cycle time in priority order.
- I’d demand that complete features meet or exceed the dogfood quality bar enforced by the engineering system.
Note that I don’t mention any specific methods here, like Test-Driven Development or feature crews. While excellent methods like these should be supported and encouraged by the engineering system, they shouldn’t be top-down edicts. Team dynamics should be driven from the bottom up.
Now let’s break down each piece, since the details hold all the interest.
Prepare the ship
Talking to everyone and all that. This is more than a gratuitous gesture to the existing staff. Later I’ll need to select my own staff, so I need to understand both the current situation and who I have available to serve. The key word here is “serve.” I’m not looking for people to serve me or themselves. Either kind would poison my staff and our goals. I’d sooner see them fired. I’m looking for people to serve Microsoft and our customers.
Eric Aside If there’s anything I would change about management at Microsoft, or any company, it’s the criteria used to judge who’s available to serve. Yes, the best managers serve the company and our customers, but mixed in are managers who serve themselves, their superiors, or only their own organizations—and that is unconscionable.
Making the organizational structure match the architecture. You want the org chart to look like the architectural layout. This allows groups to operate with local control and independence as defined in the architecture. It also makes enforcing architectural boundaries easier. Naturally, you can’t do this until you have an architecture. However, you can still think through what the structure would look like. I’d have product groups defined by the major components of the architecture. Each group would have a product unit manager (PUM), architect, group program manager (GPM), dev manager, and test manager.
Eric Aside Drop the PUMs, but keep the GPM, dev manager, and test manager as a “triad,” and you’ve got what Steven Sinofsky did for Windows 7.
Determining the architecture based on the user experience. This begs questions around timing and responsibility. Clearly, defining the Windows user experience and architecture must happen before any product groups are formed and any work begins; otherwise, you couldn’t set up the organization based on the architecture.
However, even after the experience and architecture are defined, they’ll be constantly reexamined, improved, and refactored. For this I’d have the user experience (UX) organization reporting directly to me under a UX director. I’d have a product-line architect with all product unit architects dotted-lined to her, and all of them meeting regularly as the Windows architecture team.
I’d also have directors of program management (PM), dev, and test reporting to me. They would be responsible for the engineering system and the long list of quality requirements like security, privacy, reliability, performance, maintainability, accessibility, globalization, and so on. The directors of PM, dev, and test would have all the product unit discipline managers dotted-lined to them. As such, my staff would drive engineering across the division.
Eric Aside Steven Sinofsky has the UX team report to the director of PM and the product-line architect report to the director of development. The GPMs, dev managers, and test managers report to their respective directors, and the directors report to Steven (no PUMs). It’s very simple and, dare I say, an improvement over what I proposed. Then again, he is King of Windows and I’m not.
Set a course
Driving the user experience based on key scenarios in each usage category. What makes a key scenario? It’s one that creates compelling customer value that differentiates the next version of Windows from all previous versions and all competitors. Naturally, we have marketing and technical research people to tell us what value would be compelling within each market segment. Heck, there’s no shortage of opinions on such things. However, my staff needs to choose our bet, what’s called our “value proposition,” because we are the ones who must believe in it and commit ourselves and all our resources.
Selecting my staff. Choosing my staff will be the most important thing I do. As I mentioned earlier, I’m looking for people whose whole focus is serving Microsoft and our customers, not me and not themselves. They may have career aspirations, but they figure if they serve Microsoft and our customers well, their careers will take care of themselves. As for their personal lives, I would expect my staff’s priorities to match my own: serving my family, friends, and community first, Microsoft and our customers second, and my own interests third.
Analyzing and establishing the key scenarios. Once my staff is in place, we start the hard work of defining the value proposition for the next version of Windows. This will mean long days filled with heated debates and detailed analysis. The result will be a clear vision for Windows and the centerpiece of our success.
Engage
Assigning staff members to lead the user experience and architecture efforts. With the value proposition in place, the work starts in earnest on the user experience and architecture. These teams should work closely together, informing each other of what’s possible and what’s impractical. At the end, we should have prototypes that key customers have validated and a product-line architecture that gives us confidence our goals can be achieved. The teams my UX director and product-line architect put together will form the core of their expanded teams once the organization is built.
Setting the organizational structure and assigning leaders. With the architecture defined, we can fill out the organization. My extended staff who helped create the value proposition, user experience, and architecture would have first choice at key leadership roles. After that, my staff would assign or acquire the rest. The full transition would be timed to occur a week or two after the Windows Vista ship date.
Devoting the first milestone of the new organization to quality, and building out the engineering system defined in the architecture. One of the critical pieces of the architecture is the definition of the engineering system—that is, the set of tools and processes that enable the engineering team to build and ship our products. Often a new architecture will require new technologies and new methods. Hopefully, we also apply lessons from past mistakes. The first milestone provides an opportunity to focus on unresolved quality concerns and building out improved tools, measures, and processes.
Eric Aside Many Microsoft product lines now devote the first division-wide milestone to quality and building out the engineering system, including Windows. That trend got started well before this column.
Navigation
Setting feature priorities based on scenario priority and critical chain depth. When the quality milestone is completed, the engineering staff will be ready to create new customer value. Creating that value in the right order is critical to shipping on schedule. I’d set the order based on scenario priority (do the most important features first) and critical chain depth (do the most critical dependencies first). This priority ordering and the way it was determined must be transparent to the entire engineering staff.
Managing the release by minimizing feature completion cycle time in priority order. How I choose to manage the release will be the third most important thing I do. The most important is choosing my staff; the second most is defining “done,” which I’ll describe next.
As for managing the release, I choose to minimize feature completion cycle time in priority order. In other words, I want features completed in priority order and in the shortest amount of time from when the feature team starts talking about the spec to when the feature is ready for dogfooding.
Eric Aside Dogfooding is the practice of using prerelease builds of products for your day-to-day work. It encourages teams to make products right from the start and provides early feedback on the products’ value and usability.
Naturally, I’d use proven project management practices to track progress across Windows, but the division’s ability to ship quickly and reliably is tied directly to each feature team’s ability to do the same.
I will not specify how feature teams are structured or what methodology they follow. That is best determined by the teams themselves. But I will insist that we produce customer value efficiently, ensuring complete high-quality features get delivered as quickly as possible.
This will help everything we do, from early customer feedback to last-minute competitive responses. If lean methods like Test-Driven Development and feature crews happen to produce the fastest feature completion cycles times, all the better.
Demanding that complete features meet or exceed the dogfood quality bar enforced by the engineering system. The most important thing I do, besides choosing the right staff, will be demanding that features not be called “complete” until they meet a high quality bar. The quality bar I’d choose is that of being ready for dogfood. I’d enforce this quality bar within the engineering system and by always installing the latest dogfood build on my own machine. That way, my staff and I will keep a constant eye on whether or not the engineering system is applying the right metrics to maintain standards. Simply put, if your feature doesn’t meet the quality bar, it can’t and won’t get checked into the main branch (or “main”).
Eric Aside Feature crews typically work on branches of the source code from the main branch. This allows them to use the source control system to manage conflicts and builds, without impacting anyone beyond their small team. When the feature is fully developed and tested, ready for dogfood, the feature crew branch is merged and checked into the main branch. Of course, other feature crews check into main, so the longer a feature crew stays on a branch, the more difficult it is to merge at the end. That’s another reason why you want to minimize feature completion cycle time.
Accountability
Having a bulletproof definition of complete is a key part of an overall philosophy of accountability without blame. Architectural boundaries are upheld because they match organizational boundaries. The right value, scenarios, and experiences are delivered because we enforce a priority ordering based on delivering that value. There is little wasted effort because we measure and reward those who deliver completed value the fastest. High quality is built in because you don’t get credit for completing anything until it meets the bar.
There’s no blame because the system, not an individual, enforces the requirement that quality, value, and a robust architecture are delivered efficiently. The only way to break the architecture, value, or quality is to clearly and transparently break the rules in collusion with your management. Maybe doing so is the right thing to do, maybe it isn’t. Either way, the accountability is clear.
Windows, the next generation
There it is, 12 steps to a new Windows. Nothing too complicated or harsh—a few timing issues, perhaps, and some tool and measurement work to construct—but overall, I think it would be both doable and effective. Alas, I am not the king. At best, I could hold his bucket.
However, with change comes opportunity, and there’s plenty of change afoot. Make your own voice heard. If you’re not a king, send this to someone who is with your own thoughts and ideas. Who knows, we might even start a revolution.
Eric Aside The changes Steven Sinofsky put in place were difficult adjustments for many Windows engineers. However, the results speak for themselves. Windows has been far more efficient and innovative since Steven took over. It needs to be with the iPad and other slate devices becoming popular substitutes for consumer PCs. Personally, I don’t think PCs are dead. Sure, some PCs may be multipurpose devices that fit in your pocket as phones and dock into a keyboard, mouse, and screen. Some may be slates that dock in a similar way. But some will remain in the nice laptop form factor. And I believe that five years from now, most will be running Windows regardless of their size or shape.
Be First to Comment