Management Myth 28: I Can Standardize How Other People Work

“OK, I’m really glad we can start this management meeting now. It’s time to talk about standardization. I want to create standards for our projects. I want to standardize on agile for all of our projects.” Joseph, the CIO, thought all of his directors would be pleased.

“Uh, Joseph, are you telling us you want us to go ‘all in’ on agile right now?” Cathy, the QA director, sounded concerned.

“Sure. Why not?”

“Well, we haven’t finished our pilot project, for one reason, and we don’t have enough money budgeted for training,” Dave, the development director, said. “And while I think agile is a great way to go for many projects, our business counterparts have to think so, too. We need to bring them with us. Right now, they’re still thinking in six-month chunks. You can’t standardize on agile without changing how they think.

“Why do you care how we deliver, anyway, as long as we deliver effectively? Our job is to solve problems. Your job is to make sure we are solving the right problems. If you decide which problems we solve by managing the project portfolio, we will decide how to solve the problems.

“What if we decide that we need to prototype some architecture for a while to reduce technical risk? Are you going to have my head?”

Joseph looked at Dave for a minute, then said, “No, I’m not. But I thought you liked agile.”

“I do. But the developers and I don’t quite understand refactoring to patterns at the architecture scale. We’re working at it. That’s the same way that Cathy and her team don’t always understand how to create tests and refactor to test automation all in one iteration, right?”

Cathy nodded.

“Transitioning to agile—or any one other approach—isn’t a slam dunk just because you declare it,” Dave continued. “It’s a change.

“And why should we use just one approach? Why shouldn’t we iterate on architectures or designs for a while if we want? What’s wrong with that? And what about trying kanban instead of iterations? Why can’t we do that? Why do we have to standardize on anything? Why can’t we experiment and see the results of our experiments?

“I feel as if we are finally getting out of the yoke of waterfall. I don’t want to be back in the yoke of something I don’t understand. You hired me because I can think. I hired people because they can think. So did everyone else in this room. It’s time we let them think about how they do their work, not just what they do.

“I say forget standardization. Our projects are different from each other. Why should we use the same approach on each project?

“Let’s tell people the results we want and use timeboxes to make sure we get the results in a reasonable amount of time. Why do we have to do more than that?”

Joseph leaned back in his chair. “OK, as long as you reflect on your experiments and fix them when they go wrong, you have a deal.”

Standards Provide Senior Managers a False Sense of Security
When you have a “standard” approach to projects or anything else in your organization, your managers feel as if they have a sense of security. It’s a false sense, but it is there.

They use that idea of a standard as an assumption that the work will proceed smoothly. How often does that happen? Not often enough!

You can standardize work on an assembly line and make the work safer and more efficient. But knowledge work? When you standardize knowledge work, you run the risk of making the work boring, less efficient, and not oriented to the real goal of your project.

Knowledge work is unique and encapsulates its own learning. It’s why each project should design its own approach, whether it starts off as waterfall, iterative, incremental, agile, or some combination. There is no one right way to do all projects. Each project team has to decide how and what to do for its own project.

Imposing a Standard on Someone Else’s Work Is Wrong
Except for safety or regulatory reasons, there is no reason to impose a standard on someone else’s work—especially if a manager does so.

When managers impose standards, they implicitly say, “I don’t trust you to do your jobs. Here. I will tell you how.” Would you want to do your job that way? I wouldn’t.

I don’t mind having deadlines. I don’t mind having structure of maximums or minimums, such as word counts for columns or sizes for data structures. I can live with constraints.

But when managers told me how to do my job, I didn’t live with that very well. I always thought of ways I could do it better. Always. And some of my managers didn’t appreciate those thoughts.

Standards Try to Prevent People from Thinking
Worse, many standards try to cover all of the potential problems in a process. The standard wants to prevent people from thinking. That’s how we got to big, honking binders of process.

Why do we hire people? To think and solve problems. Do we ever not want people to think? No. We want people to think. We want people to think hard. We want people to solve problems, whether it is with the process or the product.

We hired these people because we thought they were smart. They are. Let them show us how they apply their problem-solving skills to the project itself, not just the problem domain.

What If People Need Help?
If the people ask for help with standards, then you can provide local help to each team. And if the teams are part of a program where you have one business objective common to multiple projects, make sure the program understands the problem. Let the delegates to the program team solve the problem at the program level. If they need help, they will ask for it.

In my experience, organization-wide standards don’t help if management imposes them. After a while, the “way we do things here” becomes part of the culture, and you don’t need standards. People see useful things and they copy them from project to project.

But standards and standardizing, especially from management? Let the people solve problems. They are good at it. And if they aren’t, let them practice.

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 Know How Long the Work Should Take
• 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