[ This is part II, you can find the part I here ]

Enough about problems, let's assume they are properly identified and you know how to address them - in a way that will truly add value. The problem appears when you want to do everything at once, in the same time.

Why people do that?

There are various reasons of different backgrounds:

  1. Ambition

    If you see options & there's a potential to do something breathtaking that can make a really meaningul change, sometimes you fool yourself about the effort needed - it almost feels like it's already done, you treat it like it's already done, because you went through all the building process in your mind already. The real problem appears when you find such improvements in many products / areas you deal with - each of them seems to be a "piece of cake", each of them is important, each of them will make the difference - so why not to make them all! It will take just few days, week maybe...

    And you should already know how it ends.

  2. Sealing the ownership

    You live in a very competitive organisation - people fight about their position: the more applications / modules / packages are in my team - the better. And the more critical these are, the more important I become. That's why you won't never ever give up on anything you touched - you seal your ownership and to do that you keep touching every application / module / package, just to make sure that everyone sees it's alive and you're able to keep it rolling. So no-one will claim his rights to YOUR property.

    Congratulations, you've achieved a lot. First, you've made yourself (& your team) a true bottleneck - your toys' development & improvement is effectively blocked: depending on the bussiness criticality of the component on the long-term it may cramp whole organisation.

  3. Obligations

    You just take too much crap on you, because you're a "yeasayer". Your problems with assertiveness throw you down into the pit of crunchtime: you chaotically try to delivery X things at once, sacrificing anything you can (quality always goes first, then people morale, transparency, etc.) just to meet (or rather cross as little as possible) the deadline.

    All of that because you have no balls to stand up & raise the void of reason: "what we're doing here is a madness - harmful in every aspect".

  4. Just-in-case-ism

    This one is really bad: you don't understand the real meaning & value of the stuff you do. It's either that unclear or there's no value, but only politics - anyway, you just want to do a lot of stuff, just because something from that sack may appear important & meaningful in future. Because something may "click in", something may reveal the potential, may get a good press - so let's do it just-in-case.

    What does it mean? It means that you don't believe in what you're doing. You don't find it making much sense. You didn't thing about the way it's supposed to improve the organisation - or the organisation effectively prevents you from that by being helplessly driven by political maneuverings.

  5. Pride & arrogance

    Noone else can do it. The A-Team? They would just break the whole stuff! Fellowship of the Ring? You better cancel the project right away... The Magnificent Seven? Face it - those guys are idiots unable to write a single straight line of code. I am your Obi-Wan Kenobi and there's no hope aside from me.

    The more experienced I get, the more respect I get, the more I hate the idea of elite teams: "this task is for SEAL Team and you crowd stand aside & don't touch it, so you don't break it". There are very, very few things more deteriorating that that. Make sure that if you introduce such a clear distinction between teams in your organization you really know what you're doing and you're ready to face the consequences.

  6. Poor scope management

    Sometimes you're going "too wide" not because you steer things that way, but because your organization is chaotic & so-called scope management proceses are immature & shaky:

    • before you manage to end (ship!) anything, there's a change in priorities & you have to switch the context completely
    • the ownership & transparency are illusive - it's unclear who you should get your work errands, so you ... take it from everyone who's talking to you. And as these may be some really important people, you can't reject / withdraw
    • you suffer from the long release cycle - scope may be finalized & "carved in stone", but then there's a business opportunity / law regulation that has to be addressed in this release cycle ...

So what?

We've went through the 'why' part, but what are the actual consequences? This should be quite clear TBH:

  1. The changes / improvements that are spread too thin are barely noticeable - the chance to actually make something meaningful is more limited (because you have less time for each topic) - this leads to more so-called rotten compromises & postponing important decisions until some-day-one-day...

  2. People who jump myriads of topics just to scratch them (introduce a fast modification here & there) have much more limited sense of ownership over the product. Everything seems temporary. They don't think about product's roadmap, because:

    • they know it's one of many
    • they know they'll be working with something else in next few weeks
  3. If you modify too many important (for the organisation!) products, it's very easy to make yourself a bottleneck - everyone will be waiting for your changes, but you're involved in something else for next few weeks ... Keeping all the critical products under the supervision of one team has one more con: the knowledge about the products is concentrated within one team: what if these people leave the company, have to go AWOL or have some private issues?

My suggestion is ...


  1. Keep the ownership over the number of product you're able to effectively maintain.
  2. Distribute the critical products between teams.
  3. Don't keep the best people within one team, make sure such people (I call them "inspiring technical leaders") are in every team you have, so they can effectively coach people, spread the knowledge & evangelize less experienced team members.
  4. If you have a topic that has a sponsor, can add meaningful value to the organization - hit it with the largest freaking hammer you have. And hit it hard. And keep smashing it until you rock the house like there's no tomorrow. Make it meaningful, make it visible. make the difference.
Share this post