Employee Empowerment and How I Became a Contextualist

Back when I was in college, I had an instructor who was a big fan of Total Quality Management (TQM). TQM was quite popular, but in our business school setting, it wasn’t taught that much. We learned about Juran, Feigenbaum and Total Quality Control, Deming and a lot of Quality theory. We learned about kaizen, quality circles, flat organizations and employee empowerment. When our instructor had us memorize W. Edwards Deming’s 14 Points, I was hooked. Most of the Quality theory just made sense to me. Why do business any other way?

I particularly liked the idea of flat organizations with empowered employees who were in charge of their own destiny. I had worked part-time with various organizations for several years, and already saw how much waste can occur while executing business tasks. Often, the people doing the work had a much better idea on how to be more efficient, but layers of management seemed to get in the way. I often thought about Quality theory, and in these cases, about using employee empowerment. It seemed to be the answer to inefficiency issues I was seeing, and might help employee morale.

Later on, I learned an effective heuristic for business school case studies:

If I use Quality theory with a good dose of Deming as a solution for any problem, I’ll get a good grade.

So I often used Quality theory for case study assignments. It worked quite well. It seemed that few of my classmates used these kinds of ideas, so I probably got marks for being unique. Then I had Dr. John Rutland as a professor, and things changed. I found out that the heuristic didn’t always work, and that it was a poor one at that. Dr. Rutland figured out quite quickly that Quality theory was my silver-bullet, and deftly pricked the balloon of my pomposity.

After working on a business case study, he asked me for my ideas. I began reciting my typical answer:

  1. empower the employees.
  2. flatten the hierarchy.
  3. form Quality Circles to work on solutions to problems.
  4. etc.

I had barely uttered something about “empowering employees” when he cut me off.

“Jonathan. Have you talked to the individual employees yet?”

“No.” I answered.

“Do you know what makes them tick? Do you know what their motivations are? What their likes and dislikes are? Do you know not only their frustrations but their sources of pleasure?”

“No.” I stammered. “Why did you suggest it then?” I choked out something about having better job satisfaction if employees feel they have a say.

“You mean to tell me that you think an employee who works in the auto industry whose job is to turn a bolt on an engine block a quarter turn all day, five days a week doesn’t have job satisfaction? You may not enjoy that job, but other people might. They may be happy with the way things are, and miserable if they are ’empowered’. How can you be so arrogant to think that without finding out what the problems are, or what the motivations of your employees are, you can just go ahead and impose a system without taking them into account?”

Wow. I was shocked. He was right. I wasn’t empowering anyone, I was doing what Jerry Weinberg describes as “inflicting help.” I felt ashamed at my ignorance. Dr. Rutland went on: “Jonathan, people are cognitive beings. They are all unique. It’s your job as a manager to find out what makes them tick. It’s your job to help them reach their goals and remove obstacles from their way. The right solution is the one what works in their environment, taking their needs and talents into account. You can’t just impose the way you think is the best way for all environments.” I was stunned, but after I swallowed my pride, I decided I should learn everything I could from him. The lesson that day (thanks to me), turned out to be on context, and to not settle on one solution, and then always use that one solution for every problem. That was at best naive, at worst lazy, and negligently incompetent. “Use the solutions that work right now, given the team, environment and culture you have.” Dr. Rutland said. “You can learn a lot of different techniques, but in the real world, things have a habit of not going according to plan. A good manager will learn as much about these tools as possible, but will adapt and adjust accordingly, using the tools that work for each unique situation.

Furthermore, there are cases where Quality theory has failed spectacularly, in real, live organizations. The real world has a habit of yanking the rug out from under us.”

I have never forgotten that lesson on how the context for what we do is extremely important. Years later, some people echoed similar wisdom, calling themselves the Context-Driven Testing School. Their ideas resonated with me, thanks in no small part to what I learned from Dr. Rutland, who had first taught me to be a contextualist.

Furthermore, I’ve been in situations where a flat, employee-empowered organizational structure was a complete disaster. Sadly, despite being prepared for it, I was shocked. I worked for an organization that had several business school case studies that holding it up as a model for an employee-driven organization. Once I was inside, I found it was a terrible place to work. I’d never before seen such bitter political infighting, deliberate project sabotage, posturing projects, coup attempts, inefficiency, waste and poor morale. When I moved on, I was so relieved to get out of that organization with its confusing reporting structure, paralyzing indecision (from so many competing employee committees), and general toxicity. It was a breath of fresh air to go into an organization that many would decry as being “Taylorist” or “Command and Control”. At least most of the decision making was in fact decisive, and I knew who had the decision making power based on the organizational chart.

I told Brian Lawrence a bit about this experience, and he simply said: “The hierarchy went underground.” I was pleasantly surprised by this bit of wisdom. In a top-down organization, at least you know the hierarchy more or less. The unpleasant “Taylorist” and “command and control” behavior did not really go away, even in a company that was founded with a flat hierarchy and text-book employee empowerment programs. It just went underground, and it got very ugly, having the opposite effect that the founders intended. I was reminded of Weinberg’s “Rule of Three”, which goes something like this: if you can’t think of three ways a potential solution can fail, you don’t completely understand the problem space.

I’ve learned from wise teachers, and I’ve been fortunate to learn from people like Dr. Rutland and Brian Lawrence. My learning has shown me that any kind of process, structure or tool has the potential to fail. The context is important, and it is foolhardy to charge ahead with a potential solution without fully exploring the problem space. Life is full of tradeoffs: any potential solution we suggest in an organization has the potential to fail. It’s okay to still go forward with a potential solution even if we can imagine it might fail. (I don’t even care if it is the “right” one, as long as we are prepared to adapt when needed.) To believe a practice, tool, process or organizational structure is unquestioningly right, in any context, will eventually lead to disappointment. When I read back over some of my TQM notes, I find that there are some great ideas there, but I don’t treat them as my hammer and every problem I see as a nail anymore. I hope I manage to continue doing that with other processes and tools.

So what do I do now that I’ve learned something? I:

  • resist jumping to a solution too quickly;
  • learn about the context;
  • talk to the people doing the work, and do a lot of listening;
  • do careful analysis before suggesting solutions; and
  • use Rule of Three to do contingency planning and raise awareness of the potential for problems to come up in the future.

In my line of work, it is common for people to immediately ask me if I’m going to do test automation once they learn I’ll be on a project. My answer tends to be something like this:

If, after careful analysis, we find that test automation is a good fit to solve the problem we need to solve, we’ll explore test automation.

That answer seems to surprise people, but I’ve learned my “test automation as problem solution” lesson several times over. I have seen so many test automation efforts fail because “test automation” was thought of as a solution to all testing woes. I’ve seen enough failures to know that test automation is a tool that requires careful thought and planning. As Tim Beck would say, “Are we solving the real problem?” My job is to work with a team to find out what the problem is, and work with them on a solution to that problem. Test automation, like employee empowerment may or may not help us solve that problem. In some cases it may just compound our existing problems with new and exotic ones.