Log in

No account? Create an account

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.


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.

the problem, as always, is that managers are often not trusted by employees not to punish the employees if things are not as up-to-date as the manager wants. many people especially resent interference by managers in tasks they know how to accomplish; often managers do not have enough knowledge (or in the worst case, skill) to direct the task, but start thinking it's their job to as soon as the thing gets "behind".
yes, that's my own experience -- either that, or in the cases where the line manager can be trusted, it is the people above who can't be (those are also usually the people who came up with the "deadlines", without sufficient input from the people who actually have to do the work).

that doesn't account for volunteer projects, but i think that most people garner their early experiences in that sort of environment, and it sets the tone. considering that most people also receive no training whatsoever on project estimation, it's not surprising that it's all a bit pavlovian.

i worked as a free-lance consultant for years, and i can't remember the last time somebody actually involved me before creating project milestones and deadlines. no, the conversation always goes "this is what we want your help with" and "we have a deadline of may 31st", and then people want to see estimates from me. at that moment i know several things:

- the project is in trouble
- there is no realistic plan for the project
- management has no idea how to run a well-planned project
- we won't meet the deadline, unless we all work overtime or cut corners on specs or can actually get the scope of the project reduced or more qualified people assigned (rare). oh, or we shortcut testing! that's the ticket.

of course what can you really expect when people don't even know the difference between a deadline and a target date, and when they have no idea of how to assign priorities. oh man, i could rant for hours about bad management.

and i'd include myself there. i've taught myself some project estimation skills, but they're not solid, and really, that's always my least favourite part of the job. i just estimate from past experiences, double or triple what i come up with depending on perceived difficulties, and that'll be in the general ballpark, sorta, kinda. that's incredibly sloppy. but again, it's largely bound up with having to work with other people who don't even write specifications for the tasks they want me to do. it all feels like "what's the use" even if i theoretically know better. and since i don't manage other people i don't have enough incentive to learn more.
When I was a program manager, I figured out how to translate each developer and manager's estimates into something closer to reality. Some would just be off by a day or two, some you'd have to double, and some actually would give you a too long estimate because they were just overly conservative. (Ok, that last one was super, super rare.) The program managers I worked with all did the same thing and we all knew what everyone's adjustment factor was. n
I understand the importance of getting an adjustment factor for each person.
But that only helps improve the open-loop aspects. You still need the negative feedback. If my adjustment factor is so-non-linear that I interpret "all is well" as "all is broken," the data is useless.
I completely agree.


Project Estimates

Remember that study from Peopleware that showed productivity was highest with no schedule whatsoever? The only schedules I have are either for coordination of external resources ("you show up here and do this at this time") or to give to customers/internal resources simply because they demand them and "it will be done when it is done" makes them upset.

As Eisenhower said, planning is vital but plans are useless.


September 2019

Powered by LiveJournal.com