![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
"
nerds want the problem to be technological, but it never is.
people tend to lump this stuff under the word "politics", but usually it's not actually political, it's sociological. calling it "politics" gives the impression that you can't do anything about it.
if you were running a staff making cheeseburgers at a fast-food restaurant, you'd want to:
in a development project, you want to do almost the opposite of these things:
iterative development -- encourage people to try things out and then throw them away if they aren't working
you can't go the The People Store and say, "send me new George Gardenhyer, but make him a little less uppity"
spend time brainstorming, investigating new methods, planning, estimating, budgeting, scheduling, allocating personnell, figuring out how to avoid doing some of the subtasks, reading books, training, goofing off. spend less time doing and more time asking, "should we be doing this at all?"
"people under time pressure don't work better; they just work faster"
also, even if you get slightly more productivy out of people for one project, you'll increase turnover in the long term, which is a net loss
(except in bureacracies) where's the evidence for it? on the contrary, a 1985 Jeffery-Lawrence study showed that projects with no estimated times were the most productive (this doesn't disprove parkinson's law, but it makes you wonder).
you may have seen some workers who seems to avoid work, or who seems to have no standard of quality, or who just can't get the job done. this doesn't confirm Parkinson's Law; the person probably lacks competence, confidence, affiliation with others on the project, or identification with the project's goals. in any of these cases, schedule pressure isn't the answer.
proposed variant that they think is true: "organizational busy work tends to expand to fill the working day"
the market isn't willing to pay enough of a premium for high quality to make quality the most profitable choice (directly). but you should make high-quality stuff anyways, because people are more motivated when they are making something of high quality (b/c they can be proud of it -- they can tie their self-esteem, a primitive drive, to their work). the resulting productivity gains outweigh the costs of the higher quality standard.
let the project team veto the release of any product until they think it is of high quality.
see the Notes
don't let anyone but the person measuring the productivity data see an individual's productivity data -- especially, the data on an individual's productivity must never get back to their boss (but the boss can see the team stats)
as a manager, you have to deal with interruptions, so you may have a tendancy to be unsympathetic to others who get interrupted. but programmers work best in a state of flow, so the productivity cost of dealing with interruptions for them is high. so, allow them to turn off their phones and provide a way to indicate "do not disturb" to prevent coworkers from walking in and talking to them all the time (and to prevent you from doing so). don't have a noisy environment. don't have a paging system (bayle: seriously, some places do that?!?).
record the ratio of uninterrupted hours to total hours (for programmers). your target for this metric is about 40%; if it's much lower, you need to fix the environment.
if you use timesheets for anything besides payroll (i.e. the track hours spent on projects, and in that way the progress towards project completion), then augment timesheets with a timesheet that logs only uninterrupted hours, and consider using this as the basis for other metrics.
rely on non-replicable (non-modular) patterns of organization. replicable patterns based on repitition of identical modular components lead to huge awesome uniform edifices. but working in one of the uniform spots in such an edifice makes you feel like a tiny cog in a big machine, which is unmotivating
Christopher Alexander's prescription: "
if you are in a big organization with a uniform space, take the most important projects (or your project), and move it to a different space
plusses of a space: