Share via

Good at process.

  • Article

If you work for Microsoft or maybe in the software industry more generally and you hear someone described as being "good at process," you'll understand that what this really ends up meaning most of the time is more like "good at applying procedure," or less charitably and in not very secret code, "not good at anything else." As we in Windows are going to be spending a lot of time over the next few months working on our core engineering systems, trying to become "good at process," it's important to understand what this should really mean.

This good at process thing has been on my mind for a while. Because to me, being good at process is almost completely orthogonal to being good at applying procedures. Being good at process should mean being able to look at existing processes critically to make them faster, more efficient, more effective, or otherwise better. It may mean introducing processes that bring order where there was previously mess, or it may mean removing processes that bring red tape without any real upside. Someone who is good at process can take a bird's eye view of how a system is working to identify patterns and see which mechanisms could be changed in order to make the system better.

This is often the opposite of what it means to be good at applying procedures. Someone who is good at applying procedures is most often detail-oriented, which is not only not the same as being good at process, it may even be antithetic to it. A good release PM is good at applying procedures; a great release PM is able to apply procedures but unwilling to where those procedures don't make sense on a larger scale. A great release PM is good at process. And since there's no guarantee that people who are genuinely good at process are also detail-oriented enough to follow through on established procedures, it turns out that it's pretty tough to find a really great release PM (but easy to find so-so release PMs).

The MQ exercise that Windows is currently undertaking -- a quality milestone in which we're supposed to think critically about our processes and build tools that will bolster our core engineering infrastructure to make us more efficient in the future -- really highlights the diference between being good at process Microsoft-stereotype-style and being really good at process. Understanding this distinction seems like a crucial foundation for making any real improvements to process.

Comments