Management Myth 16: “I Know How Long the Work Should Take”
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Long ago, when I was a young developer at an anonymous company, one of my managers was disappointed with my progress. “I know how long the work should take. If I was doing the work, it would be done by now,” he huffed at me.
“Really?” I could have stopped there. I didn’t. “If you had done the work right the first time, I wouldn’t be in here mucking around with this, trying to fix everything. I pull something here, and something pops out over there. Of course, I’ve fixed nine defects by now, nine defects I hadn’t planned on fixing. Our customers are thrilled, because I’ve released the already-fixed defects. I just haven’t released this feature yet. But you would be done. Good to know. I wonder what else I have to clean up.”
Have I told you yet that I am the Queen of the Career-Limiting Conversation?
My boss didn’t fire me. At least not that week :-) It was a complex piece of code. I could have been more politic in my answer. But I was tired of pushing, pulling, and the puzzles. I wanted some straightforward puzzles to solve, not those roundabout problems. And then when he said he knew how long the work should take? That was insulting. As if I was taking my own sweet time with this. Ha! I was working hard. I was thinking hard.
This management myth is based on the belief that if the work is simple to describe, it’s easy and fast to do. Uh uh. Do not fall for that one.
Managers, architects, technical leads—anyone who has done work similar to this—can fall into this trap. This myth exposes several problems:
- Does the manager understand the work as it stands, now?
- Does the technical person understand the work now?
- Do each of them agree on what done means for the work?
Having a snarky conversation as I did is not helpful. That’s why you should read my newly posted Management Myth 16: I Know How Long the Work Should Take. In that column, I provide you a useful example of how to have the conversation with your boss, as opposed to my example above.
If you are a manager and you don’t want to fall prey to these or other traps/myths, you should make it a point to participate in the Better Software/Agile Development conference in Las Vegas this year. I will be giving a talk, called Exploding Management Myths. I’m also leading a Management Lab. I hope you decide to join me there.