We spend a lot of time in companies discussing “process mapping,” which is — theoretically, and sometimes in reality — a way to make our processes more effective. If you’ve had a number of enterprise-type jobs, you’ve probably seen the dreaded idea of “process for the sake of process,” whereby all these rules and processes are layered on top of each other before any action can be taken. Customer-driven growth engines are nearly impossible in this context. When you have stupid rules and layers of process mapping, you have annoyed, possibly burnt-out employees. People take jobs for the salary, yes — but most people take jobs because the problem they will get to work on is appealing to them. Bad process mapping interferes with that. Stupid rules interfere with that. No one wants to spend their entire workday, be it 8 hours or 15, on process and checking boxes. People want to pursue action and problem-solving. (Well, most people that I’ve worked with.)
Here’s the easiest way to say it, as I noted in Chief Customer Officer 2.0: when you improve your employees’ lives, they work harder and ultimately improve your customers’ lives. It happens in organizations of all sizes.
So this is how we’re going to improve process mapping for the sake of customer experience: we’re going to kill a stupid rule!
Process Mapping: The kill a stupid rule process
You are going to begin by engaging employees. Ask them to find rules or elements of the company process that do one of these two things (or, sadly, both):
- Erode customer trust
- Diminish employees’ ability to do their jobs
Here’s a third category, too:
- Rules that just don’t make any sense
Employees deal with these types of rules all day, so they can be quick to ID them. Collect a list and run it through senior teams and execution-level customer-facing teams. Eliminate a healthy percentage of these rules (allow managers the ability to push back on the elimination of some, yes).
Then announce to your employees which rules have been killed, why, and how the process unfolded. I call this “marketing hope.” You are making sure that employees know they are listened to. This encourages a greater commitment back to the organization.
Process Mapping: What’s a stupid rule?
This varies by company, of course, but let me give you a couple of examples:
- “All documents must reside in X-place before they can be weighed in on:” It’s good to have a central repository and version control, of course. But a rule like this is usually process for the sake of process. Managers around a company respond to one-off documents on email all day. Someone needs to be managing versions on customer-facing documents, but having explicit rules that hold up a process is bad for business.
- Tiers and tiers of sign-offs on simple decisions: I know someone who worked on a customer-facing one-pager once. A one-pager, mind you. He shared it with his boss in Google Docs. Within about a day, 19 people had requested access to the document. This happens a lot in companies — per research from Bain, most companies with $5 billion valuations have 14 layers between the CEO and the customer. That’s a lot of layers. Having a check box at every layer may feel like you’re securing accountability, but you’re usually just removing empowerment and employees’ ability to do their jobs. It’s a stupid rule, then. To have better process mapping, remove it.
What else would you add on process mapping? And/or what stupid rules have you seen?
