Be That Someone...

I came across the following post on one of the MSDN blogs I regularly visit.

On one of the mailing lists in the Windows project, somebody spotted some behavior that seemed pretty bad and filed a bug on it. The project was winding down, with fewer and fewer bugs being accepted by the release management team each day, so it was not entirely surprising that this particular bug was also rejected. News of this smackdown threw the mailing list into an fit of apoplexy.

Don't they realize how bad this bug is? Somebody should reactivate this bug.

Yeah, this is really serious. I don't think they understood the scope of the problem. Somebody should mark the bug for reconsideration.

Definitely. Someone should reactivate the bug and reassert the issue.

After about a half dozen of messages like this, I couldn't take it any longer.

I can't believe I'm reading this.
I decided to Be Someone. I reactivated the bug and included a justification.

Don't just stand around saying somebody should do something. Be that someone.

For those who are really curious, the name of the blog is "The Old New Thing". It is written by Raymond Chen, who is one of the veterans on the Windows project team.

Non-Goals

Some time back, I read an informative book titled “One Strategy”, written by Steven Sinofsky of Microsoft and Marco Iansiti of Harvard Business School. Apart from some fascinating insights into how the Windows Team came together to pull off a mega-project like Windows 7, the book also taught me some thought-provoking concepts. 

One of such concepts was “Non-Goals”. A non-goal is a scope-limiting attribute that explicitly states some objectives which will not be fulfilled.

Wikipedia has an entry for Non-Goal.

non-goal (plural non-goals)

1. A potential goal or requirement which is explicitly excluded from the scope of a project.

That's a hard problem, but it's a non-goal for us here.

We always talk about having definite goals, things that we will or should do. It seems counterintuitive to have a list of things we won’t do, but it makes a lot of sense when you think about the complex nature of most of the projects and communication issues between geographically-distributed teams.

In a scope-definition exercise at the start of any project, we usually focus on the things we are required to do. Having a section for non-goals helps to set the expectations of project team (and also of the client)!

For example, consider a scenario: Your project team is working on product planning.  After some consideration, you decide to develop the UI only in English language in the first release, and to localize the product in the subsequent releases. So, in this case, for the first release:

• Goal is delivery of English UI
•  Non-goal is localization support

This clears the scope of work, and avoids doubts in minds of the project team.

Non- Goals are directly related to strategy. It is easy to get carried away and vigorously nod “Yes, Yes, of course!” to everything that’s being asked of us, but it takes a certain amount to courage to say “No”!

Furthermore, defining the things you are not going to do enables you to focus on the ones that you are, and to ensure that you deliver these features with the best possible quality.

Steve Jobs, one of the best entrepreneurs of our times, famously remarked that “Secret to innovation comes from saying no to 1000 things.”

At the beginning of a new year, when many of us are usually excited about planning for the year ahead,  this concept brings a clarity to our thoughts, and reminds us that while we may have almost infinite things to do,  distinctiveness  (and hence success) often comes from doing less, and doing it better.