Delay Bad News
A management AntiPattern, practiced by developers and managers alike, where bad news is withheld from higher management for as long as possible (until it cannot be hidden any more). This is done for the following reasons:
- The hope/desire that the problem will go away (sometimes it does, usually it doesn't). Sometimes the problem can be handled internally (if your task is slipping; maybe you can work weekends and thus still meet schedule); other times, it cannot.
- Fear of an inappropriate reaction by management -- whether punishing of the individual, MicroManagement ("give me daily status reports"), etc.
- Fear of an appropriate (but undesirable/embarrassing for the responsible party) reaction by management, such as re-assigning the work to another developer; deletion of a feature, etc.
- Wanting to save face -- if the problem goes away (see above), maybe I can avoid admitting the problem; if I admit it, now I look bad (even if everything turns out all right).
Common examples:
- Many developers, when a task is slipping, report being "on progress" until the deadline occurs - even if they know well in advance that they are slipping and extra time will be required to complete the task. (See AlmostDone).
- ProjectManagers, likewise, often will delay reporting slips in the schedule to his/her boss, hoping that the team can cover the slip without additional help. (If it is definite that the team can, this isn't really an AntiPattern).
Consequences:
- A bad problem frequently becomes worse; a slip that may have been manageable if known early becomes intractable or more difficult to manage.
- Both managers and subordinates start to distrust each other--management views schedule estimates as suspicious (inviting more MicroManagement); subordinates work even harder to DelayBadNews because the last time management heard bad news there was a TurdFanCollision.
- If things get really bad, people do get punished.