Management Advice: Predictability over Productivity

About a year and a half ago, I found myself in the position of being a manager---evaluating people and evaluating the success of projects. I've learned two important lessons. First, it is possible to succeed. I've sort of done this myself. But I've watched from a reasonably great distance mrw42 succeed on a much more impressive level. That's reassuring; it is all too easy watching most of the software projects I'm involved in to conclude that project management is a cruel joke. The second lesson is one I keep learning over and over again. It's more important to be able to know where you are on a project and to accurately predict when you'll be done than to be fast, or to exceed your estimates. We all have an desire to challenge ourselves and to show how good we are by setting aggressive deadlines. Another common problem is that we roughly know what the deadline has to be and we decide that we'll get done by then regardless of how long it will actually take. Then of course we miss the deadlines.

Missing the deadlines isn't horrible. Open loop control is all about precision components and carefully controlled conditions. Humans working on projects they have never done before are not precision components, and if your software project can be described as carefully controlled conditions, you work on different software than I do. So, it's no wonder that we need negative feedback loops to make it all come together. However that requires that people admit when they are behind as soon as they are behind. Needing to readjust deadlines either by changing the task, time or resources is nothing something that you either as an individual contributor or as a manager should be penalized for or feel bad about if it happens incrementally or when problems are discovered.

All too often though, it works like this. "How is your deadline for Friday coming," the manager asks. "Fine," the programmer says, thinking to himself that while he hasn't gotten started he can work extra hard and get it to come all together. Friday rolls around and the programmer says, "it will be done real soon; a bit to finish up," as he starts coding madly. Two weeks later, this project that was on-time two days before it was due is mostly done. Adjusting deadlines is fine but 600% over-budget is not an adjustment, it's a major failure. Yet 600% is not uncommon for the sorts of problems I've seen within MIT or especially on volunteer projects. If the manager had known it would be two weeks then the project could have been reassigned, additional help given, or the feature set changed. But if the deadline is always just around the corner the only thing the manager learns is that they have an unreliable contributor.

One factor that significantly contributes to the problem is that a lot of people are very interrupt driven. They may well be only two days behind assuming they could find a two day time slice. That might happen next month. I haven't yet figured out a solution to the interrupt driven person problem that works well. I guess if you could estimate time slices and how often they happen or estimate what fraction you'll actually spend on a given project, you'd be able to do something useful. That doesn't always seem possible. I've mostly had to write myself off for anything directly related to Kerberos other than management: I just don't have predictable enough availability that I can count on anything assigned to me getting done.

The take home lesson here is simple. Give your manager as up-to-date information about how well you are doing on your projects as you can. Honesty and accuracy is so much more important than telling someone what they want to hear or being optimistic. Yes, you want to be a team player: you want to say that you will meet that deadline and help the team get in those extra features. However reality will tell and in the long run unjustified optimism hurts the whole team as well as hurting your evaluation.