This is a “book club” reading of Tom DeMarco and Timothy Lister’s book “Peopleware”, 2nd edition.
Joel Spolsky, founder of Fog Creek Software and popular author / blogger, writes on this book: “The best way to describe it would be as an anti-Dilbert manifesto”.
I’m reading from the 1999 paperback second edition.
The book, originally written in 1987, had a huge success and pushed the authors to publish a second edition with eight new chapters. Written by software consultants, it focuses primarily on project management but also addresses such topics as the conflicts between individual work perspective and corporate ideology and other sociological or political problems.
It’s a great book, wonderfully written with a light touch of humor. It’s full of common sense but neglected tips and didn’t lose at all value after twenty years. Still a superb book on people management.
Part 1 – managing the human resources
In six chapters the authors go through the most important factor in every project: the people, and how the good managers don’t just make the people work but they make it possible for people to work.
Fostering an atmosphere that does not allow for error makes people defensive. The improvement gained when inhibit errors is counter-balanced by the team suffering.
The authors even suggest the opposite approach: celebrate failure. Encourage people to make some errors and therefore learning.
“When they blow it, they should be congratulated – that’s part of what they are being paid for.”
Here’s an analogy – the Roman legions used to send out scouts in different directions. If a scout didn’t return, the army didn’t head in that direction.
For many the management scope is kicking ass.
But there is nothing more discouraging to any worker than the sense that his own motivation is inadequate and has to be “supplemented” by that of the boss.
Instead most people love their work and on long-term, to make sure that everyone is doing the best job for him is the path to a successful project.
Often the only criteria to assess people in a project is only how much code they can write, a steady state measure, and not how well they fit into the effort as a whole.
But a project is dynamic, the only steady state in the life of a project is rigor mortis.
Uniqueness is what makes project chemistry vital and effective. It’s something to be cultivated.
Overtime is like sprinting: it maks sense for the last hundred meters of the marathon for those with any energy left, but if you start sprinting in the first kilometer, you’re just wasting time.
Things companies do to improve productivity:
- pressure people to put in more hours
- mechanize the process of product development
- compromise the quality of the product
- standardize procedures
Any of these measures can potentially make the work less enjoyable and less satisfying. Hence the risk of worsening turnover, which has to be always kept in mind.
A better productivity metric would be to define it as benefit divided by cost (including replacement of any workers used up by the effort).
Also, in a healthy work environment, the reasons that some people don’t perform are:
- lack of competence,
- lack of confidence
- lack of affiliation with the project goals and with others in the project.
Nothing that you can fix with means of the above four measures.
By putting regularly the development process under extreme time pressure you get poor quality products.
People under time pressure don’t work better; they just work faster.