Throw Away Your 5 Year Plans


I don’t want any part of them.  They result in over-engineering, wasted documentation, never-ending discussion as everyone takes the opportunity to put their chef hat on, employees that get stuck going down a path while the world changes around them, and promises to customers you won’t be able to keep. 

Planning is not bad and having a clear vision a necessity, but don’t get caught up in the details of your roadmaps. Instead of a huge roadmap have a customer scenario end-state that you can use to comunicate what needs to be enabled, made simpler, or exposes an opportunity. 

Another way to think about it is that your goal should not be to pretend you are a writer on Alias that keeps trying to build up to a dramatic “end game” that takes five years and will likely disappoint.  Make sure everyone knows about your end game and try to keep it achievable in 2-3 years or less. 

The more you accomplish down a path quickly the more people will learn about and have your “end game” come into focus for them with a bunch of “aha” moments as the see the pieces fall into place.  If you can’t communicate your desired end state and a roadmap for getting there in less then one slide… I don’t want to be a part of it.  There’s just so much low hanging fruit out there that your time will be better spent picking them off to get short term wins that start to make your desired end state more visible to folks.

What you need is smart people to identify the low hanging fruit, prioritize the fruit in order of how much closer each piece gets you to your desired end sate, and start picking them off one at a time. 

Another problem with the “5 year” thinking that’s rampant here at Microsoft is when people say “Yeah, that would be cool, but what we should be thinking about is…” and the … is usually filled in with the most overengineered solution you can think of that’s designed to handle every edge case and adjacent problem you could imagine. 

We’re hired and paid to constantly be thinking in line with big pictures that we frequently miss the little things that, when done en-mass, would have a much bigger effect on customer satisfaction than the overengineered solution would.. because you’d be 5 years late. 

Again, I don’t have a problem with big solutions to big issues, but at Microsoft we often grab that big hammer too frequently when what you had was a pushpin of a scenario.

I guess, in the end, what I’d suggest is to question your choice of weapons used to solve problems.  Only break out hammers when necessary, don’t believe that every problem needs a 5 year plan, and start accomplishing the little things that will have a huge customer impact… just make sure that you do have an “end game” in mind that your building towards.  And remember that an “end game” shouldn’t take you 5 years.

Comments (7)

  1. RogerH says:

    I’m certainly no expert, but I’ve definitely seen problems with both over-engineering and under-engineering.

    I’ve personally got caught over-engineering many times and ended up developing half-thought out features that were eventually cut or not used.

    But, when you let every problem "come to you", sometimes you can have solutions which seem like a "bubble-gum" fix.

    After working on a "bubble-gum" project long enough, the code becomes horrid and the only thing on people’s minds is a re-write!

    The one thing I’m definately trying to master is the art of re-factoring. If you can take the vision of the "5 year plan" and execute it incrementally while correcting any "bubble gum" solutions that occur along the way, you would eliminate the spaghetti code and the desire for starting over.

    Definately easier said than done! But it’s a fascinating problem for a developer, especially once who’s been around a while and seen the same things happening time and time again. Good article!

    – Roger

  2. MSDNArchive says:

    Thanks for the feedback!

  3. Lauren Smith says:

    Are you kidding? 5 year plans are critical to the correct functioning of the Au Skyfall Management Process. You need to keep the outlook long so that you have enough time to implement the grand scheme. The more money to pour into the up front design, the better. Sometimes it pays to bring in consultants to help with this part (for historic reasons I use the term "Wife’s Brother" or WB to refer to this type of consultant).

    Then, after 6 months of hard engineering and documentation work, the process can be streamlined by replacing the initial implementing manager who can then go on to implement the same sort of business re-alignment in another company.

    Nothing says "Success" and "Willing to take risks" better than "unmitigated disaster"!

  4. PatriotB says:

    If it weren’t for 5-year plans, we probably wouldn’t have seen .NET.  Or, maybe it would’ve been the simpler "COM+ Runtime" that it originally started off as.

    Another problem is that people mis-estimate… deciding on working on something that would normally be a, say, 2-year plan, when the project is in reality a 5-year plan.  Avalon seems to fall into this category: it’s something that has been under development for at least 5 years and is still not released.  Obviously MS didn’t intend on it taking this long.