Progressing Your Pitch
Cashing in on earned trust
The first four years of my Microsoft career were contributing to Windows 3.1, Windows 95, and Internet Explorer 3 (IE3). My area of expertise had been UI (User Interface) controls (e.g. button, scrollbar, listbox, and treeview). After IE3, I connected with Ian Ellison-Taylor and Microsoft’s Java team. From my experience with controls, I wanted to experiment with a compositional model for controls. Rather than each control being its own separate world, there would be a common base element that all controls, from simple to complex, would be composed of.
The two main points of my pitch were that (1) I could rebuild Windows’ library of controls (there were a dozen different controls at that time) in Java in three months, and (2) they would be richer in functionality due to them all sharing this same element-based construction. It played out well, and I still recall the 1996.12.13 deadline because I hit it … to the day! 🥳 There were some rough edges with this first implementation, but it was an important stepping stone for what came next.
After releasing a couple versions of Microsoft’s Java, our UI team moved back into Windows. The compositional model for UI was already picking up steam there, where HTML was being used in this compositional fashion. The problem was that HTML was a more general purpose framework, and was heavier weight because of that. So the parts of Windows that were written in HTML were benefiting from the customizability of compositional controls, but they were hitting significant performance problems.
This led to a relatively big idea in 1998. Still under Ian, I pitched the idea that what we had been experimenting with in Java in 1996 and 1997 was applicable to the Windows space now, and that we could build a special purpose compositional UI framework that would give Windows all the benefits of HTML without the performance problems. Ian gave me the green light, and I partnered with Jeff Stall and Mark Finocchio, who were both already building relevant pieces, to build Direct UI.
To test the readiness of our framework, we took the most demanding Windows experience that was currently written in HTML, “Add/Remove Programs”, and built a feature-for-feature equivalent in Direct UI.
We put the two side-by-side to present to the Windows Shell team, several individuals I had worked with in my first four years. We first had them look at the app and play with it, to prove the functionality was all there. Then we highlighted how much quicker our version rendered, with the HTML version drawing in waves: the text appeared first, and then the items shifted as the icons appeared later. For the grand finale, we showed them the memory being used by both. The DirectUI version was 1/10th the size of the HTML version.
They were impressed with what they saw, but they were also nervous about an unproven technology. So they asked us to prove it with two move experiences: the Task View of File Explorer, and the new Login experience. There were now six people involved in the DirectUI effort. We nailed both in pretty short order, showed them the results, and they were sold.
This success created a collision between our Direct UI team and Microsoft’s HTML team, which led to another opportunity for a pitch. HTML is a standard that we don’t control, being “governed” and evolved by a web consortium. Microsoft’s HTML implementation was one of several implementations in the market, and to be competitive, it had to be as compatible as possible with this moving target. In my pitch, I argued that this compatibility is the reason for all the performance challenges we were facing with HTML, and we should build our own compositional UI framework that we can control and tune.
This pitch framed a two month debate about the best path forward for Microsoft. In the end, the HTML team and the Direct UI team joined forces to create the Windows Presentation Framework team, a 200 person organization dedicated to building a new UI framework.
This is one example of how bottom-up leadership drives direction in an organization1. It also shows the fuel that drives bottom-up leadership: the pitch. You have a theory, so you test the theory out. If you have success, then you need to pitch your idea to get broader adoption. A successful pitch begets bigger pitches, with increasingly broader scope. The above arc grew from one person to three people, then six people, and then 200 people.
The earned trust prerequisite
If Ian hadn’t seen my work in Windows, he probably wouldn’t have had much basis to believe me on when I initially pitched compositional controls. And if the Windows Shell team hadn’t similarly worked with me for years, I wouldn’t have had any track record with them to get even a first meeting with them.
How far can a pitch go without earned trust2? Not far.
Eight years after the above successful pitch progression, we were brought into the Windows Mobile product. Terry Myerson had taken over this product, and was intentionally bringing in fresh perspectives from other organizations. So our Splash team of about 20 engineers was recruited.
The Splash team was a UI framework that had shipped multiple versions of Media Center and Zune. We were coming off of these successes into a team that had been stuck in “the milestone from hell” for something like six months. Over the course of the previous 18 months, this team had iterated through four different UI Frameworks, each time getting some gains, but never fully achieving what they were tasked with building. So this team was understandably not all that enthused to hear anything about “yet another UI Framework”. The Splash team wasn’t just starting with zero trust, we were starting from a place of negative trust.
I had tried bringing my best can-do attitude, seeing that as a way of cheering them up and building some momentum3. But this came across as both overconfident and dismissive. My a-ha moment was in a meeting with my peers when I said, “I bet my paycheck on this technology.” One of my peers said, “You’re betting all of our paychecks on it.” I was humbled. I agreed. And that is the moment that my tactic changed: first and foremost, we had to build trust with our new team.
With Terry’s reorganization, we had also brought in the design team that Splash had worked with in both Media Center and Zune. The new combined design team was putting together new designs showing a bold new direction for the phone user interface. It borrowed many principles from these earlier products, with a focus on simplified content and ambient animations. These designs were pretty close to how the product actually came out, so it’s easy to just share the retail demo video to show you the essence of this new “Metro” design:
We took several motion studies (short mock up videos built by the design team to show the visuals and the animations all working together) from this new design and started doing “bake offs”. For each bake off, we had two parallel teams attempt to build that experience, one team using the existing Windows Mobile UI framework, and one using Splash. There were three bake offs, and each ended with the same result: the Splash version was done in less time, with a more polished and performant result. Each bake off convinced a few more people.
But this team had been burned before by flashy demos that didn’t pan out in the long run. So the initial decision was to build just the Start experience with Splash, and the other apps would continue to use the exiting technology until they saw a reason to convert. This removed the sales pressure, and made this instead about slowly building a comfort level with each app team. These teams would observe the progress, and when there was enough meat for them to feel they could put their trust in Splash, they took the leap.
As each team moved, this built momentum for increasing trust. The more teams that moved to Splash, the more the remaining teams could see it working out, and more easily believe it would also work for them. When we shipped Windows Phone 7, every first party app was written in Splash, and the result was a highly polished and cohesive experience across the product. Had we not found a path to earning trust, this never would have happened.
Build the trust before you make the pitch.
“I’m an engineer, not a salesperson”
A common response I get when coaching a developer through the pitch process is, “I’m an engineer, not a salesperson.” My response is always, “You can just be an engineer. But if you want to be a leader, then you need to be a salesperson as well.”
If you want to bring about change, if you want to influence the direction of the broader team, then you’re going to need to find the salesperson in you. You need to articulate the value proposition of your idea. You need to define the target audience. You need to detail the cost. And you need data to prove your idea works.
This can seem daunting at first, and the solution to that is to start small. You’re building a new muscle, so don’t overexert yourself right out of the gate. Start small, and build over time. I chose my words for this post’s title very carefully. Like I said in one of my first uplevel pro posts, “I don’t like the phrase practice makes perfect. I prefer practice makes better.”4 It isn’t about perfecting the pitch. It’s all about progressing the pitch. You build your pitch muscle over time, by incrementally pushing the limits of that muscle, stretching it to new levels of capability.
Your own journey as a leader can be summarized by a progression of pitches. I can capture my 33 years at Microsoft with an arc through five different phases of pitching.
Features - I started with easier feature pitches, like proportional thumbs in scrollbars and resizeable non-client area. Then I moved into larger features like redesigned listbox to increase limits on size of lists.
Frameworks - This is the stage I captured above with the Direct UI and Splash examples. Now I was thinking more broadly about the problem space.
How the Team works - I realized that I had a lot of ideas around how a team can work more effectively together. What started with us exploring different designs for Team Space progressed to the point where our Real Estate and Facilities (RE&F) team built my team a custom space to highlight the benefits of a hybrid design for open space. Then RE&F included our space in their tour of different Team Spaces on campus.
How we connect to customers - For the products that I worked on at Microsoft, most of the time our customers were developers. We were building frameworks and tools that other developers would use to build their applications. And the most direct way to connect to developers is through open source. I pitched for more and more of our work to move to open source. At the end of my product management career, my team owned six open source projects, and we were celebrating the level of trust we had built with our developer customers through monthly community calls and the transparency of open source.
How the team grows - I was part of the pitches that created “early in career” support to help our newest employees get a stable footing. Once I realized it wasn’t only the newer employees that benefited from some attention given to learning and development, I pitched a rhythm of learning for our 1,000 person organization that created predictable space in our calendar for people to pause their “day jobs” and invest in their own growth. The more time I spent advocating for this, I realized that learning and development is what I cared most about in the latter stage of my career, so I pitched my Windows Director of Learning and Development role5.
Look at how my scope of influence grew as I developed my pitching muscle. Release your inner salesperson, and start progressing your pitch!
My second curve
After 33 years of building trust withing Microsoft, I’m now starting off at zero with Virginia Tech6. Okay, that’s a bit of an exaggeration. I’m probably at a 10% trust level based on the work I did to build the Microsoft chapter of the Virginia Tech Alumni Corporate Network.
I’m not at all dissuaded by this. This is just reality. Trust is not easily transferrable. It has to be earned with each individual and each organization. So I’m starting small and being patient. My current track record is two small pitches approved, and two denied. I’m building the muscle. Let’s see how far I can take my pitch progression with my alma mater. Wish me luck!
LOVE hearing stories of the early years, and how you tied it to trust. I think your 33 years at MSFT in and of itself bumps your Virginia Tech trust level up at least another 5-10%!