Agile

Leadership Tip #13: For Innovation, Remove at Least One Policy or Procedure a Week

Some managers wanted to prevent Bad Things from happening in the organization, so they added policies or procedures. Now, these same managers want business agility. However, the policies and procedures increase friction and make it harder to get the Right Things done. It’s time to start removing some of those policies and procedures. The more we remove, the more agility or improvement we might see.

Here’s how an environment of Big Honking Binders starts:

  • Someone makes a mistake, or a leader sees a potential risk.
  • Instead of dealing with the actual mistake or mitigating the risk, the leaders create policies and procedures.
  • As the organization changes (both products and tooling), people might not make those mistakes again. Or have those same risks. Yet, the policies and procedures remain. Worse, sometimes, managers add more policies and procedures.

Too often, the policies and procedures mean the leaders don’t trust anyone else to finish their work.

The more policies and procedures (those Big Honking Binders), the less initiative and thinking you might see. I saw that in an organization that had management signoff for changes the technical people made.

A Signoff Policy to Reduce Risks

About a decade ago, an organization suffered three consecutive bad deployments to production. So the managers created a signoff procedure and a deployment team to reduce those risks.

Over those 10 years, the technical teams created more robust testing and deployment scripts. However, the teams were still dependent on the deployment team—they were not allowed to deploy independently. And the deployment team had to wait for management signoff.

As the teams used agile approaches, they requested more and more frequent deployments. However, the managers still wanted to sign off on all changes.

Because there were so many requests for the changes and the managers were so busy, the managers wanted to batch their decisions. The managers met biweekly to learn and decide about each change. The effects of that batching:

  • Every change requires several days of delay because the managers need to review the changes.
  • Most changes required a week or more of delay.
  • Because of the delays, the teams stopped creating small requests. They bundled most of the requests into larger changes. That meant there was more risk from each change.

Finally, one large change broke the production server. During the three-day outage, they learned:

  • Because the deployment team felt pressure to deploy, they didn’t read the documentation carefully enough. They added the changes in reverse order.
  • Because they added the changes in the wrong order, rollback didn’t work.

The managers and their delays caused the very risks the managers were supposed to avoid.

After the inevitable blame game, the company started to experiment with one change a day. Then two. Then three. Now, the company uses a specific time of day to deploy all the changes. Yes, that’s still a policy, but no one signs off, and, so far, the teams can deploy during that time.

The managers created friction, which resulted in problems. Now, the teams have a reasonable constraint.

What about guidelines?

Money Policies to Manage Cash Flow

I see lots of policies around money, especially who can spend how much. The consequences of those policies tend to be:

  • The person who needs to spend money needs to get permission, often from some number of managers.
  • Or, the person must adhere to onerous policies, especially for travel, to get reimbursed.

The result: it takes time to get approval, even for reasonable, small spending. And people don’t get reimbursed in a reasonable amount of time.

I’ve worked with clients who wanted me to itemize every penny I spent so that they could reimburse me. Instead, I offered them a deal—I would estimate the airfare and hotel and not charge them a cent more. No charge for meals, rental car or taxi, or anything else. One client said they couldn’t do that. I had to itemize everything.

I said I would increase the entire fee by 10% because that was a lot of work. They were willing for me to raise the rate on the entire engagement rather than change their policy.

That’s a lot of friction and expense to micromanage my expenses.

Too often, policies and procedures create friction to finishing work. A lot of the friction we see is anti-agility.

Consider removing policies and procedures and create guidelines and constraints instead.

What Might You Consider Removing?

When I think about policies and procedures we might want to remove, here are some possibilities:

  • Anything that requires a team to seek approval from managers to finish their work.
  • Paperwork-intensive outputs, not outcomes.
  • Anything to do with performance “management.”

One of my clients decided on a new policy: they would remove a policy or procedure for every new one they added.

One clever first-line manager, Trina, asked, “What will you remove because you added this one?”

The senior managers said, “Everything around vacation. You and the teams figure it out yourselves.”

Trina asked, “You don’t care how much vacation people take?”

“No.”

“You don’t care when people take vacation? For example, do you plan to have a shutdown for the Christmas period?”

“We hadn’t, but that’s a great idea.”

Trina’s questions prompted the senior managers to consider those guidelines and constraints. They decided to have a summer shutdown around July 4 and a winter shutdown around Christmas-New Year. (Their business allowed them to do so.) And if people wanted to work then, that was fine.

The company did have a specific guideline: they wanted everyone to take at least two weeks of vacation a year. If not, the manager needed a direct conversation with the person. (At every level.)

Maybe you like this idea, but remove something once a week?

Remove One Policy or Procedure a Week? Really?

I clean my office in two modes:

  • A cleaning marathon, where I take an entire day and clean up.
  • A few minutes every day to eliminate the messiness I’ve accumulated.

The longer I wait between cleanings, the more I need the marathon. If you’ve been accumulating policies and procedures, you might also need a marathon of significant management attention. What culture do you want? What friction do you have?

Consider these questions:

  • What creates friction for people doing the work? What would they need to work better? You might look at cycle time for teams and decision-making cycle time for managers.
  • Where do we impose processes and procedures where guidelines and constraints might work better? If people have to ask for books or training, could you offer everyone a book allowance or a training allowance? Maybe even create a team or department-based training allowance so that teams can learn together.
  • What can you remove from all the performance reviews and management efforts? We have data that says performance reviews don’t work. And I see too much waste when managers write reviews or allocate raises.

Yes, this is one of the Modern Management Made Easy principles: Encourage experiments and learning.

One possible experiment: Instead of trying to prove how good a new guideline or constraint might be, consider assessing the value of what you have now.

You might address all the processes and procedures about how you fund projects, teams, or people.

If you want more innovation, remove the friction that prevents people from doing a great job.

This tip is mostly from Practical Ways to Lead an Innovative Organization.

This is a part of the series of intermittent leadership tips.

Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Leadership Tip #13: For Innovation, Remove at Least One Policy or Procedure a Week

Opinions expressed by Java Code Geeks contributors are their own.

Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button