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

Sally, the project manager, strode confidently into her meeting with John, the CIO. She’d reviewed the roadmap with the product owner and had discussed the risks with the project team. She was sure, based on the first few iterations, that the project was off to a good start. Sure, she knew that projects rarely stayed on course, but this project had a chance of making the dates. The product owner knew how to work the backlog, the team knew how to get to done each iteration, the architect was embedded into the team—this project was cooking! She was happy. As much as she could project into the future—which wasn’t far—this project was going well.

“Hi John. What did you want?” Sally said as she sat down in John’s visitor chair.

“I want you to cut 20 percent off the date for this project.” John replied as he pointed to the final release in the roadmap.

“Well, that’s no problem. We’re agile. You won’t get the last 20 percent of the iterations, so you won’t get the last x percent of the features, but that’s okay.”

“No, you don’t understand. Things shouldn’t take this long to do.”

Sally frowned and said, “I don’t understand. What do you mean, ‘Things shouldn’t take this long to do.’ Do you think people are slacking off? Do you think we are not working hard? What problem are you trying to solve?”

John sighed. “When I was a developer on this system, it didn’t take two months to add a feature like this,” he said as he pointed to the roadmap and to a specific feature. “It shouldn’t take that long. In fact, I added something like that back in the day.”

Sally almost swallowed her tongue. She didn’t want to try to explain that the team had spent almost a week and pulled all of John’s code out for just that feature, because it didn’t work and was unmaintainable.

He continued, “I wrote that code overnight. I know what it takes to write code for this system. It doesn’t take two weeks!”

“John, when we write code now, we write unit tests along with the code. In fact, we write the tests first. We find that when we do that, it helps our design.”

John interrupted Sally. “Well, it makes everything take too long. Stop doing that.”

“No,” countered Sally.

“What do you mean, ‘No.’ I’m your boss,” John said. “What I say goes.”

“Not when you say something that doesn’t get you what you really want,” said Sally. “Look, what you want is to finish this project faster, so you can start the next project, right?”

“Right,” John replied.

“Okay, so you can stop an agile project whenever you want, because we always get to done at the end of an iteration. No problem,” Sally explained. “We have tests so we know the code works. We have releases on the roadmap, and if you want to release before or after a ‘real’ release, we can do that, too. But my job as an agile project manager is to ensure that the team gets to practice their professionalism. I serve the team. I also serve you, but the way I serve you is by facilitating the team. So, no, I’m not going to help you get something you don’t really want. Remember when we tried to make waterfall work, and you used to try to cut 20 percent off the end of every project schedule?”

John leaned back and smiled. “Yes, that worked.”

Sally grinned. “Well, it worked for you the first time. But it killed the team. So, I learned what you did. Since I used deliverable-based planning and incremental approaches with rolling-wave planning, I just gave you an estimate that is 20-30 percent larger after the first time you cut my schedule by 20 percent. I’m not an idiot. I refuse to let the team suffer because you don’t know what it really takes anymore for what the code needs.”

“You inflated your estimates?” John asked. “How dare you!”

“It worked, didn’t it?” Sally retorted.

“Well, it did,” said John. “I liked the releases. But I don’t like it when you pull the wool over my eyes.”

“Well, that’s why we went to agile. You and I both have a lot more transparency. That’s why I say you can stop the project at any time.”

John thought for a few seconds and then said, “How dare you say I don’t know anymore what the code needs!”

“John, when was the last time you really looked in the code? I mean, really looked in the code? You are a CIO. You don’t write code for a living. You don’t. You don’t know what it needs. You cannot possibly estimate what it takes.”

“You are looking at a roadmap, not even an estimate, making a judgment about where we will be in six months, and deciding we are taking too long? You are not being rational. So many things can happen on this project.

“You tell me what you want to have happen, and I will do my best to make it happen. You want to finish this project by a certain date? Great. Make sure you explain to the product owner what features you think are most important. The product owner will work with you. We will work together to deliver the most important features by the date you want. But I will not tell the technical team to stop being professional. That is the quickest way to get a product we cannot ship. And then we cannot go on to the next project.

“So don’t tell me you know how long things should take. We are the project team. We know how long things take. You tell us what project you want us to work on. We will. We will work on the features in order from the product owner. We will be professional. We will not goldplate anything. But don’t tell us how long anything should take. We will tell you how long things will take. Okay?”

“Well, okay,” said John.

How long will the work take?
If you are not familiar with a task, it always seems as if it should take less time to complete than it does, especially if the work is conceptually easy to explain. It’s even worse if a manager has done work similar to that work in the past. But what managers forget is that when they performed that work before, the system was less complex. Or, the environment was easier to work in. Or the language was easier to learn. Something was easier.

The longer the manager has been away from the technical work, the less the manager still knows the technical details. And—as we all know—for software, the details matter.

Does your manager still know what to do?
At one point, maybe that manager did. But the more senior the manager, the less likely that manager knows how to perform the work anymore. Do not allow managers who don’t know the technical work to influence the project schedule or the technical environment. People who don’t perform technical work should not change the project schedule or buy technical tools. It’s fine if those people provide a monetary ceiling—fiduciary responsibility makes sense. But making the final decision? That’s up to the people who do the work.

The more you allow the manager to influence your work, the worse your work environment may become.

Managers don’t always ask for what they want.
If you have a manager who insinuates himself into your work, ask that manager what he wants. In this case, John wants this project to be done faster so the next project can be started earlier. Sometimes, managers want to release earlier, especially if they are not using agile approaches. Whatever the case, the project team always has options.

It’s okay for a manager to want a project to end early. Managers can want anything. It’s how they act on those wishes that might be a problem. As long as managers trust in their project teams, and as long as those project teams work to earn trust, both sides can work together.

Read more of Johanna's management myth columns here:

• The Myth of 100% Utilization
• Only the 'Expert' Can Perform This Work
• We Must Treat Everyone the Same Way
• I Don't Need One-on-ones
• We Must Have an Objective Ranking System
• I Can Save Everyone
• I Am Too Valuable to Take a Vacation
• I Can Still Do Significant Technical Work
• We Have No Time for Training
• I Can Measure the Work by the Time People Spend at Work
• The Team Needs a Cheerleader!
• I Must Promote the Best Technical Person to Be a Manager
• I Must Never Admit My Mistakes
• I Must Always Have a Solution to the Problem
• I Must Solve the Team’s Problem for Them
• I Can Move People Like Chess Pieces
• Management Doesn’t Look Difficult From the Outside, So It Must Be Easy
• I Can Compare Teams (and It’s Valuable to Do So)
• It’s Always Cheaper to Hire People Where the Wages Are Less Expensive
• If You’re Not Typing, You’re Not Working
• You Can Manage Any Number of People as a Manager
• People Don’t Need External Credit
• Performance Reviews Are Usefult
• It's Fine to Micromanage
• We Can Take Hiring Shortcuts
• I Can Standardize How Other People Work 
• I Can Concentrate on the Run 
• I Am More Valuable than Other People 
• I Don’t Have to Make the Difficult Choices 
• I Can Treat People as Interchangeable Resources 
• We Need a Quick Fix or a Silver Bullet
• You're Empowered Because I Say You Are
• Friendly Competition Is Constructive
• You Have an Indispensable Employee