James Lewis, David Peterson and others have asked if I'm going to follow-up my programming in the small articles with some "project management in the small" articles, because these days I am mostly doing project management; so I'll have a go. I have less experience as a project manager than as a developer, so it might be presumptuous of me to write these articles, but I will anyway. My experience of project management is both on teams with someone else as the project manager, and being a project manager myself, over many years and dozens of projects.
Some project managers seem to think that it's important that they work hard and their team works hard. However, (as Steve Freeman has said recently in conversation too), what is really important are the outputs of the team not it's inputs. That is, what's important is the value the team is delivering (output) rather than how hard they are working (input). Note I say "the value that the team delivers" and not "the amount of software they deliver" - at times the difference can be huge.
In some cases, working longer hours increases the output, but not always. Don't confuse the two things. In my experience, a bit of slack* actually increases output, and working too hard decreases output over the long term. You can increase output for a short time by working longer hours, but it doesn't last.
[* - I haven't read this book yet, I will do. From reading the reviews it sounds like the sort of stuff I'm talking about]
If developers get tired, they can also get sloppy, demotivated and stop thinking. Just grinding away hour after hour does nothing for productivity. Furthermore, the most mobile developers will eventually quit and get a job elsewhere if they are working long hours all the time.
The biggest gains in productivity often come from doing a lot less work, rather than doing more work. That is, working out a creative way in which you can do something much simpler or using some software that someone has already written to solve the problem.
The biggest gains in value can come from developers having some slack time to think of new ways of using software for the benefit of the business. At connextra, we introduced gold cards which was a structured way of giving developers some time away from planned stories, and some of the work that came out of these "gold cards" turned out to be enourmously valuable to the company; much more than the cost.
It's much easier to work hard and to bully or bribe a team into working harder (or at least longer) than it is to help them work more effectively. Therefore, some project managers take this option - knowing that the hard work of themselves and their team will be noticed by the people they report to, and so they think they might look good. However, what looks better is actually delivering stuff.
As a project manager you will often have meetings scattered throughout the day, with half an hour here, and hour there, between meetings. You don't have to feel bad if you aren't busy all the time. You need to have unplanned time in your schedule to be available for helping with things that come up. Being available is more important than being busy. Some project managers seem to book and attend lots of pointless meetings and rush around the office being busy. It's more important to be available to sort out that seemingly minor issue there and then, because what seems like a minor issue can get in the way of the developers' flow. Remember it's the effectiveness of the whole team that matters rather than how busy any particular individual is.
No. That's not what I'm saying. You shouldn't be a slacker, but a bit of slack is good.