When I was reading Rapid Development1 Rapid Development; McConnell; Microsoft Press; 1996., one thing that struck me was that McConnell listed individual heroics as something that makes software projects late.2 In case it’s not obvious, individual heroics refers to when a small number of team members (sometimes just one) really lean into their work and manage to complete a task within an unreasonable timeline.
Why Not Heroics?
The problem with individual heroics is that it papers over planning deficiencies. Heroics rob project managers of useful feedback. Any time heroics are relevant, it’s specifically because the project planning has failed, and blowing past that deadline is actually a very important signal the project managers need. Heroics denies them that information.3 “But what if you tell the pm heroics were required? Wouldn’t they learn then without having to miss the deadline?” In my experience, people don’t work that way. They need to suffer the consequences of their failures to really learn.
In the worst case, heroics makes the planner think they made a good plan, and plans will grow ever more unrealistic and require ever more heroics, until at some point heroics is no longer enough and the project is doomed. Along the way, people burn out and quit.
Deming had a similar story4 I don’t remember the exact details so I will make it up as I go.: doctors at some hospital filled forms very sloppily to the point where they were often unusable. The hospital solved it by having administrative staff get a new, blank form, and re-enter whatever the doctor had entered except correctly – often going back to doctor with questions, but that was not always necessary. This was deemed a good process, because doctors could spend more time with patients and less time with paperwork.
Deming convinced the hospital to try a small change: any time the administrative staff received a form that was improperly filled, they were to highlight the errors with an angry red pen and immediately send the form back to the doctor who filled it.
Initially, doctors had to spend a lot more time with forms. But as you can guess, the fraction of improperly filled forms decreased. It turns out filling the forms properly didn’t take that much longer than answering questions from administrative staff. With fewer administrative staff needed, the hospital could afford to hire more doctors, which resulted in more patient time as well.
Only then something great happened. Doctors started complaining about the forms being difficult to understand and unnecessarily complicated. The hospital was able to redesign the forms and improve the processes around them to suit the doctors’ work better – and in a few instances remove some paperwork entirely. After a few months, doctors spent less time filling in simpler and fewer forms than before. 5 As a bonus, the forms could be processed much quicker, which meant patients could get their prescriptions sooner, orders of new material arrived faster, and so on.
In other words, forcing the doctors to spend more time with paperwork initially, lead to higher quality care down the line. Totally unexpected – unless you look at the flow of information in the system.
Both of these cases highlight a more general principle: information flow in systems matter. A lot.
Many actions have not just direct consequences, but also alter the way information flows in a system: obstructing it, re-routing it, altering it, or creating it. When we choose an action, it is often more important that we choose one which affect the flow of information in a desirable way, than that the action itself has positive direct consequences.
Focusing on the flow of information will, in the long run, lead to greater improvements than looking just at short-term direct consequences of an action.