Management Myth 16: "I Know How Long the Work Should Take"

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.

Previous/Next Posts

3 Comments

jim ward
on April 18, 2013 at 3:21 pm

Had you completed a defect report for each of the nine defects that you fixed, and submitted the reports to your manager, or whomever had the authority to approve the defect fix, rather than merely fixing the defects, would your conversation have been the same? The work, as defined, seems to be to implement the new feature(s).

Jim, we knew about the defects, we just hadn’t planned on fixing them at that time. But they were in my way, so I had to fix them, to implement the new feature. My boss was so sure the feature was straightforward, he had estimated the work without telling me what he had estimated. (Big Mistake!) But nothing was straightforward about that code.

Of course, the customers were thrilled. They’d wanted us to fix those defects for several years. Once I got those defects out of the way, the new feature was much easier to implement.

Except for life-and-death software, I think her more flexible approach was the right one. The authoritarian, do-nothing-without-authorization management style is okay for some military work, but regular business activity needs the make-it-better-now attitude. The amount of sand in the works of IT is beyond incredible.

I learned from bitter experience that, especially if you are right and the boss is not, you will do yourself no good by confronting her with her folly.

Subscribe to the Pragmatic Manager

Johanna’s Books

See Manage Your Job Search on Amazon, too.
See Hiring Geeks That Fit on Amazon, too.
Buy Now
See Manage Your Project Portfolio on Amazon, too.
Buy Now
See Manage It! on Amazon, too.
Buy Now
See Behind Closed Doors on Amazon, too.