“The process is the thing.”
“Give me the instructions for trouble-shooting these types of problems.”
These are a couple of quotes from others that have come up in my personal experience, and they have one thing in common: There are those who want someone or something to carry them through the easy way. Don’t’ get me wrong, I like reducing the complex into simple execution whenever possible. But there are problems inherent in the attitude present with these statements.
“The process is the thing.” No, I’m not against process; quite the opposite, in fact. If people want to share work and collaborate effectively, process becomes important, as everyone needs to be on the same page about how to approach the work. Process provides benefits like ensuring that critical steps that can cost you time and money are not inadvertently missed.
I get concerned when process becomes a singular focus – with no mention about a desired goal or outcome. Process is a means to an end, a course of action to take in achieving a goal. It’s frustrating for top performers who have a strong desire to achieve and an established track record of producing results to be pulled into dialogs centered exclusively about process by (sometimes self-appointed) “process police” whose aim is to enforce the “rules” above and beyond anything else.Delivering something that isn’t valued by the customer, despite “nailing the process,” doesn’t provide a true sense of accomplishment.
As a manager, I’ve been involved with individuals and teams who felt that process was stifling their ability to execute. Sometimes they were right and we’ve had to make adjustments. Sometimes it was our understanding and execution of the process that was really at fault. On other occasions there have been other difficulties at the heart of the matter, like an organizational roadblock. And at other times there was simply a need for a fresh perspective on how to apply our process to a new situation.
The key is to never limit the dialog about the process itself – unless the goal is to teach people about the process. When contending with real-life, day-to-day issues, talk about how the process should be applied to the work at hand, how it can help reach the goal, or where it is falling short of reaching certain objectives.
And before deciding to make changes in a process, make sure that you understand more than just what the process is. Understand why it is defined as it is and how value is derived from following the process. Then make informed decisions about process change. Like I said, process is simply a means to an end.
“Give me the instructions for trouble-shooting these types of problems.” I’ll go on a bit of a rant on this one. Ever try to get service over the phone from someone you know is following a script? Did you think that the person lacked any form of intelligence?
I’ll concede a newbie needs guidance. So train them and have someone experienced direct them at first, progressing to coaching as they improve. Then cut them loose! Scripts are for Hollywood, not for dynamic situations like technical support. They become a crutch that helps throw common sense out the window.
I’ve had more than one time-consuming phone call with technical support personnel where listening and common sense left the building. Like the time that I called to get a faulty network card that I had just purchased replaced. Because I had actually bought two identical cards, I thought this call would be a simple call.
The tech support rep began clicking away, asking the usual “Who are you?” and “What is the nature of your problem?” questions. I was able to describe my problem early on: “I bought two identical network adapters,” I explained, “and when I plug one of the adapters into my computer, I can’t get onto the network; no Internet, nothing. When I exchange this card with the other card – keeping all of the network cables and the computer the same, I get connected to the network. I can access the Internet without a problem. The only thing that I changed was the network card.”
Simple, right? I had hoped to eliminate the need for any further conversation; I expected to at least shorten the call. But this person had to follow his process – which meant following his script – and forty-five minutes later, after running test after test, I was confidently told that my network problem was with my Internet Service Provider, and that I needed to contact them.
I laughed, and replied, “I don’t know how your script got you there, but did you listen to what I told you at the beginning of the conversation?” After a little more dialog and one more phone call, I had a replacement network adapter on its way.
I don’t fault the script in this situation – I was asked to create one years ago. The problem that I ran into then is one that I’m sure continues to be true today: It takes a significant effort to capture all of the contingences and possibilities in a way that successfully navigates an unknowledgeable person to a successful conclusion. My feeling then (and it remains this way today) was that training and the expectation that people have problem-solving skills would be much more effective than trying to capture intelligence in a script.
For dynamic, difficult scenarios of today’s business world, the resourcefulness of people will always trump procedure and scripts. The message is simple: Don’t rely on a process or scripts to carry you. You won't be carried too far.
Are You Agile Enough for DevOps?
3 days ago