Dear Bob ...What do you think of weekly status reports for developers?As an IT manager with a number of direct reports, I find it hard to keep track of work being done so I know when to assist some developers. More to the point, some developers tend to spin their wheels on work and need direction from time-to-time to keep moving.I want to avoid micromanaging but I also need to make sure I can keep the projects m Dear Bob …What do you think of weekly status reports for developers?As an IT manager with a number of direct reports, I find it hard to keep track of work being done so I know when to assist some developers. More to the point, some developers tend to spin their wheels on work and need direction from time-to-time to keep moving. I want to avoid micromanaging but I also need to make sure I can keep the projects moving and mentor those that need help.Note that I do have one-on-one meetings with everyone on the development team but cannot meet with all of them every week.– Macro-manager Dear Macro …Weekly status reports are, I think, like timesheets. Some managers insist on them, others don’t. Sometimes they provide valuable information, sometimes employees more or less invent the data just before they’re due. Generally, developers like neither, viewing both as bureaucratic wastes of time.The difference between the two is that managers eventually discover inaccuracies in the weekly status reports. I think the big challenge with weekly status reports is that they are something employees do to help managers, not something employees perceive as creating value for them. They don’t pass the WIIFM (What’s In It For Me) test.One possibility (not something I’ve tried) is to divide the status report in two. Monday morning, developers would be responsible for delivering their plan for the week – ideally, not more than half a page of expected deliveries, each with a space next to it to enter the date delivered. Friday afternoon they are responsible for delivering the same document with delivery dates filled in.Add to the Friday document comments on issues, barriers and so on, and it might be painless enough that it will make sense to everyone as being a planning exercise as opposed to a reporting exercise. The most important factors for deciding whether to do this, and then on making it work, are:Being clear about what you’re looking for (including providing a template, so it’s a fill-in-the-blanks exercise, not a blank-sheet-of-paper essay).Keeping it as minimalist as possible so it doesn’t become burdensome.Communicating why it’s important, so everyone understands and it doesn’t become “just paperwork.”If at all possible, finding a way for it to be useful for the developers, for the reasons outlined above.Saying the same thing a different way: There are two models of management. In the first, companies bring in employees to act as a “force multiplier” for managers. In the other, companies bring in managers to make sure employees are as effective and productive as possible.When you interact with employees, the second version is far more effective, for a simple reason: You’re talking with them about their work as what matters, not about their obligations to you as what matters. – Bob Technology Industry