New today in Hardcore Software—086. The Memo (Part 2). Windows continued to struggle to finish Vista. I was busy mostly on my own trying to figure out what comes next. Last week I shared the analysis half of a memo I wrote only for three ppl. Part 2 1/ …rdcoresoftware.learningbyshipping.com/p/086-the-memo…

Note/ This thread is just an outline. The post is rich in detail, commentary, PDFs on what was really going on. If you’re into reorgs and trying to understand what makes for a positive experience in times of turmoil this is good background for the next post which is the “how-to.”

2/ I wanted to document a combo of observations and aspirations. I wasn’t going to just jump to solutions or a plan, or simply going to complain. Three topics repeatedly surfaced talking to hundreds of individuals: • Decision-Making • Agile Execution • Discpline Excellence

3/ Decision-Making was such a weird thing. How could this be a problem—made decisions all the time in Office. I learned the about “swoop and poop” when mgrs/execs show up briefly and make a mess. I learned about scorecards and KPIs used to prevent work. How about “RACI” and OARP?

4/ The most insidious tool used to stifle innovation and collaboration was a “culture of escalation.” It was a way of never having plans be settled. Want to change what someone else is doing then “escalate” and coerce them in front of execs with all layers of mgmt present.

5/ When you see the old org chart illustration of groups pointing guns at each other at MSFT, what it doesnt tell you is why. The reason is because groups were constantly trying to upend each other by escalating the work of others they didn’t like to execs to make changes. Ack.

6/ Those were observations (tons of detail and color in post). What I set out to do was tell BillG, SteveB, KevinJo what we wanted to aspire to: • Consensus among engineering peers • Consensus among disciplines • Agreeing to disagree is failure

7/ Agile execution was a super painful topic for me. I spent an enormous amount of time and wrote endless blog posts about. My main challenge was Office “baggage” or as it was referred to by the Windows Live team “boxed software”. Whatever Office was, it was definitely not agile.

8/ People referred to Office as a “waterfall” which is totally wrong. Office was filled with milestones (aka sprints) and iterations throughout the planning process. Waterfall is such a misused term. It comes from this 1970 paper. Interestingly, Royce was saying “don’t do this”

9/ I made this image to try to explain how we might want to work and also how Office worked. It was not particularly convincing to Windows Live who thought Office was slow. OTOH, the Windows half wanted to slow down! Vista’s problem was *not enough time* to do al the big stuff.

10/ Here I ran into a perception of me personally. The assumption people on Windows made was that the reason Office shipped on time was a) you can cut features in Office, can’t in Windows and b) Sinofsky was a tyrant. What?

11/ That seemed crazy. But as I learned more I realized that view was based on the assumption that Windows worked “just like” Office, only Office was better. Meaning more meetings, more top-down, more process, etc. Except Windows was where someone punched a fist through a wall!

12/ My friend @marcoiansiti @HarvardHBS coined an expression “Agility = Execution + Impact” and that became our aspiration for the team. As a team we weren’t delivering what was promised (not executing) and what we delivered wasn’t having market impact. So it wasn’t agile.

13/ Discipline excellence was a strange one to explain, awkward and painful. Basically with thousands of engineers with more domain experience than anywhere the team still lacked the breadth of talent to build products at scale. No one wanted to hear that. So I used data.

14/ If there were 2500 engineers but they were organized into 100 autonomous teams of dev/test/pm then that is not the same as one 2500 team in unison. This mattered because the combination of Windows/Live was about delivering a single unified customer experience not 100 things.

15/ But organizing this way has a real drawback. First, there simply aren’t a ton of people that can successfully lead multi-disciplinary teams. Second, that shortage means you can’t grow/manage senior engineers to report to those who aren’t very senior or strong.

16/ People were pulled (or drawn) into multi-disciplinary roles before they had developed the skills within their discipline. This created a negative feedback cycle wherein those people were then on the hook to hire people without the experience to either hire or manage. Ack.

17/ So our aspiration was really about structuring a team in a different way. A way that emphasized excellence in engineering roles. To that end we were going to aspire to:

18/ I was worried no one would take this seriously, not these three observations but what to do. People really wanted a plan. I had to make a case that we had some time and it wasn’t a crisis. I wish I had known the phrase “product market fit” but didn’t. I reverse engineered it.

19/ A friend researched the reviews across Windows 3.0 through XP) and literally proved out the odd-even curse through product reviews. What it really showed though was that the business model and momentum sustained the product. Rhetorically we could have released most anything!

20/ We needed to build a much better product and win the business and customers, not just keep going on momentum. The memo would propose a new organization to deliver a single unified experience across Windows /Live (and the core OS division which was busy finishing Vista).

21/ Next week will detail the rationale and process of rolling out the organization. The biggest reorg I’d ever imagined! In the meantime, please enjoy this post in audio form here and consider subscribing. Check out …rdcoresoftware.learningbyshipping.com/p/pod-086-the-… 50% off link: …rdcoresoftware.learningbyshipping.com/windowsfans

BONUS Post in Hardcore Software: Avoiding Escalation in Decision-Making — follow up on questions/comments about avoiding escalation / tools used from a mgmt perspective to change culture of "review meetings." Some posts I wrote at the time for the team. …rdcoresoftware.learningbyshipping.com/p/bonus-avoidi…

I loathed being asked to escalate. As a healthcare IT manager, I would tell my leaders about new issues the team was having, and immediately would be asked if I've escalated; every time. No, I haven't, I'm giving my highly paid employees time to do their paid jobs.

Loved #86! Follow up question: how does one distinguish between design by committee vs building consensus?

🙏 two key things: there is a project vision and plan that outlines the goals. often the problem in reaching consensus is just not paying attention to the original goals. thinking broadly—equally often, there's a challenge in thinking too locally making consensus difficult.

🙏🏼