084. How Many On the Team, Exactly?

Much of what Hardcore Software has been about was what we were building (and why). This chapter is about how. Specifically, I wanted to delve into the management structure and what we worked through to restore efficacy and build a new kind of Windows team. Over the next few posts, we will journey through understanding of the cultural challenges the team faced, figuring out a plan to lay the foundation to address those, and then putting that plan into action. This first post gets to the core of understanding what precisely the team is building by figuring out how many people work on what projects. That should be simple, no?

AUDIO for this post here.

Subscribe to AUDIO in your fav podcast app.

Back to 083. Living the Odd-Even Curse [Ch. XII]

Please consider subscribing. I’ve extended the “Windows Fans” 50% discount for another couple of weeks. Here’s the link: https://hardcoresoftware.learningbyshipping.com/windowsfans

When you move into a new job there are a lot of things that need to come first, too many. You want to touch base with the most critical individuals, but don’t want to minimize the importance of those less so. You want to focus on the high priority areas of work, but it is times like this that the lower priority work hardly needs to be reminded of that fact. You’re dying to ask a lot of questions, but people are dying to tell you things. Then there’s the political reality that the many things pushed to you or that arrive in your inbox are often those least needing your attention, but most likely to notice a lack of attention.

I had all this to think about while both being reminded of Windows Vista every day and needing to let the team in place finish the project without interference, inadvertent or otherwise.

It was extremely weird to commit myself to learning about Windows and the Windows team. I had, after all, essentially grown up around it, just not in it. I knew the Windows product. I knew the Windows people. I just had no idea how the people made the product. I knew the organization at a super granular level from Windows 3.x and Windows 95 working on toolbars and app compat and the shell from C++ and Office. I knew things at a strategic and executive level.

I had a high-altitude view of the organization, and I knew a lot of individuals, but between a few feet off the ground and 50,000 feet above the ground I had a lot to learn.

Little was as it seemed, however, when it came to the details.

There’s a well-known military principle on knowing the difference between lessons and lessons learned, between reading about something and having learned that same thing through the experience of changing how one operates.1 Any management book will tell you to know the budget and resources on a team and that’s a good lesson. In the Microsoft culture filled with cookie licking, shiny objects, and side projects my most important lesson learned is to actively track how many developers there are and what code are they writing. Every time I was uncertain of what a team was actually building or if a project was real, understanding the number of developers assigned to which code was the most valuable information to have and the most critical to keeping a project on track. I learned that with NetDocs, the Tablet PC, and so many 1990s internet projects long since passed. Everything other than actual working developers is just talk.

Therefore, the first thing I chose to do was to get a handle on the composition of the team. With the help of Kristen Roby Dimlow (KristenD) from HR, one thing became clear: I was in a new world. KristenD was previously our finance partner in Office, coincidentally, and brought with her a refreshing analytical view of the structural challenges I (now we) faced. Kristen began immediately trying to collect the data on who was doing what.

In Office, headcount, resource allocation, and org structure were readily visible and, for the most part, easy to figure out by looking at the company’s online system headtrax. Windows was a different apparatus. While there was a headcount number, what they were working on, for whom they were working, and even their actual physical location, were all less clear, or fuzzy.

In keeping with Windows tradition of reorgs that “split the baby,” or product organizations that were structured such that accountability and ownership were muddled, the job I was given was not as much the “Windows job” as most would at first perceive. This wasn’t a surprise at all to me—I knew what I was getting into. This was the Windows Client team previously described. COSD remained separate as it was already.

To KevinJo and SteveB, accountability was clear, even if the organization structure and people were not. This was typical Microsoft accountability in the 2000s. I was their Windows “guy” and decidedly on the hook to figure out what comes next. Kevin had a huge amount to figure out. He was clear just how much he was hoping I could wrap my brain around with respect to “what comes after Vista?”