Fred took rounds on the office corridors during the evenings to take a feel of who was busy versus who was reading an online newspaper or playing a video game. If you happened to have anything other than work running on your screen when this gentleman took his rounds every evening, the least you could expect is an email with a list of tasks that you need to immediately start working on. The most you could expect was a taunting sarcastic remark.
I see a young and budding manager somewhere knitting his eyebrows , folding his hands and taking a defensive stance already. Somewhere, in some corner of the world, there is a young and budding manager reading this, talking to himself and saying this: What is this idiot talking about now? I mean resource management and utilization is all about making sure that your resources are utilized at an optimum level. Isn't it? Huh? Huh? Huh?
Actually, you know what, if you have heard this 'resource utilization' line or if you were that young and budding manager who was thinking this, chances are that you have picked it up from one of the two places. One is through your underpaid teacher at a B-Grade management school. The other is through your previous manager who you looked up to.
Now here is the newsflash: Chances are also high that your underpaid management teacher never actually managed a single live project in his entire life. And as far as that previous manager that you looked up to is concerned, well he might just have been a regular old jerk who was managed by other jerks when he was young which is where he picked up the thought process without questioning it.
When you take a team of kick ass programmers and put them on a kick ass project, you form a self sustaining eco-system. Assuming that you have hired correctly, if you leave a bunch of builders free for sometime, good things happen.
Every programmer has "TODOs" in their code comments. Things that they tell themselves they will come back to later. Every designer has design changes that he would like to refractor if he had more time. These are exactly the things which differentiate a remarkable product from a lousy mediocre one. When you leave a kickass team alone chances are they get sick and tired of reading the news in about and hour.
Then they often tend to come back to these changes and they tend to start working on them. Silently. Quietly.
If you have a product that has been running for more than a year now and a passionate team that loves working on the product, try telling them nothing to do for a couple of weeks and see how they react. Chances are that they might either give you a product with a stronger, faster and much more stable foundation or they might come out with features and really small changes that might pleasantly surprise you.
Stop those stupid status meetings. Stop monitoring every hour of your programmers. Stop giving them new assignments as soon as the last assignment on their list is marked as done. If you have hired the right guys and have left them alone, chances are that they are working on stuff that needs attention. Stuff that you might not even be aware of. Stuff that might usually come back to bite you two years from now. If they are free, they won't sit quietly for long.
If you have the right people, they will be much more worried than you are about having nothing to do.
Now go cancel that status meeting. See how it goes.
I wish you good luck.