Hacker News new | ask | show | jobs
by mjr00 1479 days ago
> Finally, the third, and most pernicious situation in which there is too much planning is when planning becomes its own end. This can happen because individuals in organizations get more reward for planning work than actually executing on it. It might be seen that the execution is the “easy part”, and can be done by anyone, whereas the grand visionary (or “architect”) is the real cause of success.

I've experienced this happening due to an influx of people into an organization who simply can't execute -- middle managers come in with impressive resumes but little understanding of the problems that need to be solved. When results aren't delivered, they default to extensive planning processes because it creates an appearance of work. There's lots of tangible outputs (market studies, reams of wiki pages and documentation that are written, fancy slide decks, plenty of presentations...) yet nothing that provides actual value to customers. They know execution is the hard part, they just can't do it, so they stay in planning mode endlessly in order to provide an illusion of productivity, and to keep their job.

1 comments

Over Planning is also an institutional response to risk. In these cases it is actually "the easy part" and so preferred by environments where any mistakes are costly. As in the "If at first you don't succeed, then Sky Diving is not for you" kind. In these cases I would not call planning an end in itself but rather a defense mechanism deployed to avoid the risk of action until absolutely necessary. Not that I justify what can become analysis-paralysis situations, but it is better to understand the beast you are dealing with if you want to navigate a path through.
> also an institutional response to risk

To further elaborate on this point, sometimes that risk is internally created. If you get negative feedback for doing something everyone agrees is valuable, negative because it's not what your manager would have chosen as the highest priority, or because the architect would have planned the implementation slightly differently, etc., then the natural response to that negative feedback is "OK, next time, let's do some more planning so that you'll be happier with the work that's being done." What makes customers happy and what makes managers happy is not always the same thing.

Great organizations embrace risk. Not reckless risk, not the kind where you say "eh, this might result in two-day downtime for all our customers, YOLO", but the kind where you say "I prefer that my workers make imperfect decisions that we can fix later if we really need to so that the whole organization can move faster". 80% of the time, the decision does not need to be fixed. 80% of the remaining 20%, you don't have time to fix it, and usually, that actually works out OK, all things considered.