Hardcore Software by Steven Sinofsky

Share this post

084. How Many On the Team, Exactly?

hardcoresoftware.learningbyshipping.com

084. How Many On the Team, Exactly?

If you want to know what an organization is doing, then just count where the developers are and what they are working on. — Me

Steven Sinofsky
Jun 5, 2022
8
7
Share this post

084. How Many On the Team, Exactly?

hardcoresoftware.learningbyshipping.com

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.

Why a Lessons Learned Program? Why does an organization need a lessons learned (LL) capability? Before we discuss that, it is important to understand what is a lesson" and what is a "lesson learned." A lesson is knowledge or understanding gained by experience. The experience may be positive (a best practice), as in a successful test, mission, exercise, or workshop, or negative, as in a mishap or failure. Successes and failures are both considered sources of lessons. A lesson must be significant in that it has a real or assumed impact on everyday operations. It must be valid in that it is factually and technically correct; applicable in that it identifies a specific design, process, or decision; and it reduces or eliminates the potential for failures and mishaps or reinforces a positive result. Basically, it is the knowledge acquired from an observation or an adverse experience that causes a worker or an organization to improve. A lesson is an LL when you can measure a change in behavior. Obviously, this change in behavior needs to be of a positive nature that improves performance. The U.S. Army, with over 25 years of focused LL experience and one of the world's leaders in experiential learning, still struggles with actually "learning" lessons once identified. Even though there are many understandable reasons for this, you cannot give up. Other organizations complain that once you identify a lesson, it ends up in some database and you quickly forget it. The irritation of every LL specialist is seeing important lessons collected and never being shared or resolved. This takes time and effort and, in most instances, money. Often there is no obvious "owner" of the lesson identified, and there is rarely a system set up to resolve the issue and implement corrective actions.
I’ve always been a big fan of the US military principle of knowing the difference between a lesson and a lesson learned. This is taken from the military paper “Establishing a Lessons Learned Program.” (Source: https://usacac.army.mil/sites/default/files/publications/11-33.pdf)

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?”

This post is for paid subscribers

Already a paid subscriber? Sign in
Previous
Next
© 2023 Steven Sinofsky, All Rights Reserved
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing