Back Again, Thinking about Work
An interesting thing happened today that reminded me of my recurring business philosophy interests. I attended a meeting where a new manager brought forth a diagram of a business process we were to discuss and refine.
This process was the kind that had evolved organically over time, not one of the premeditated kind that look neat on paper but are often not followed. There were several different shapes, reminiscent of a flowchart, joined with solid lines in some places and dotted lines in others. The discussion was aimed at giving the group a shared understanding of the complexity of the process that most understood fairly well. Getting the new manager up to speed was naturally an unstated but obvious aim as well.
Several aspects of the discussion were particularly interesting. Most of us in the room seemed uncomfortable seeing their work activity represented on a diagram, associated with similar representations of co-workers' tasks. Some even stated that the tasks they performed in conjunction with the process were not appropriate for the chart. One said "it's just something I do for myself, and it doesn't have anything to do with anybody else". Another, " I do this but it doesn't really belong here because it's not a recognized process." Nobody challenged the general assumptions about analyzing the process, likely not because they agreed, but more likely because they were waiting to see what might result from the exercise. To me the whole exercise seemed kind of weird, and somewhat misguided. The manager stated that the point was to consider whether the process could be automated, so "all you'd have to do was hit a button and all the work would be done".
We are a small company, more oriented toward people than toward processes in my opinion. In the area where I work people operate autonomously and, I think, in a constant state of mild fear. The company and its business are fairly healthy, and I can't think of any reason to be unhappy working there, but on a day-to-day basis for many people the misery output exceeds the amount of work they get done. We self-impose pressure to stay out of trouble and out of sight, to be busy on tasks that ideally are not of strategic importance to the business, so as to be doubly secure against the risks of extra work and, worse, of added responsibility. Why this is constantly baffles me, although I have some suspicions. Offering to do away with people's work, therefore, is an unwise stance for a new manager to take.
It struck me as foreign and totally unrealistic that we would automate even a minor business process like the one we examined. Automation would require a lot of up-front work, both planning and actual execution, before it could produce any results. The process under consideration could no doubt benefit from some evaluation and possible "process improvement", but the "just push a button and it all happens instantaneously" scenario falls somewhere between foolish and dangerous.
The virtues of a process-oriented view of business, as I've heard it described, are that such a view provides a conceptual framework through which nearly any activity can be considered. The cleaning crew has a process for doing their jobs, the accountants have processes they follow, customer service has processes, manufacturing is all about process. You get the idea.
This way of thinking seemed absurd in today's meeting because it does not apply very well to our people's views of how they interact with one another. Our workplace culture is simply not that process-oriented, or seen another way, processes are too abstract and too rigid to sum up most of what goes on in a person's day. Maybe this is different on the production lines, but in our arena nobody ever seems to want to follow a process.
What we are instead is what I call people-oriented. We know how to do our jobs. Those activities are taken for granted and fall out of focus. What we think about and direct our attention to are the unique, un-process-definable aspects: which job am I working on now? who needs their report first? Should I call this person back before I start reading e-mails? How do I get these important things done today before I get distracted? Can I get this one task done before the 1:00 meeting? I wonder if there's any coffee left upstairs.
All of these concerns center around a personal sense of organization that take precedence over participation in a business process. There lies the problem of process-oriented thinking for non-process-oriented people. The world appears to us in a non-linear fashion, and whether or not we'd function best or be happier doing one thing at a time, seeing it through to completion, reality forces us to manage several streams of information at a time, adjusting our participation so as to give our attention where it is needed, then switching to something else when attention wanes or distractions appear.
As I tried to imagine the functional diagram from today's meeting in a non-process-oriented way, the differences started to become more clear between a linear process-oriented approach to human activity and some other kind of approach. Keeping with my hypothesis that our company is "people-oriented", some points became particularly apparent.
- In a process-oriented world, events follow other events in linear fashion. People are generally interchangeable and serve only to perform the functions described as parts of a process.
- In a people-oriented world, people exist autonomously but also are members of one or more groups. Events can be performed by groups or by individuals, and do not necessarily depend on other events preceding them.
- Roles in a process-oriented world are dependent on functions. Having the "punch press operator" role is identical to performing the "operate the punch press" function. People and roles are thought of as a one-to-one relationship.
- Roles in a people-oriented world are a type of rule permitting a person to perform one or more actions, or prohibiting a person from other actions. A person can have a role without ever performing a function permitted by it. People can have several roles.
- Rules in a process-oriented world are embodied in processes.
- Rules in a person-oriented world are both contained (i.e. understood) by individuals and shared in groups.
Trying to map the process diagram out in a people-oriented way did not turn out as expected. In view of the differences I'd noticed already I figured the people-oriented diagram would be much more complicated than the simple linear process-oriented view. That is, instead of "function-in-a-box, arrow, next function" I expected the diagram would turn into a map of people tagged with various roles, contained in Venn-diagram-like bubbles to indicate group membership, rules off in space who knows where, then annotations with the various actions associated with the roles assigned to each person, with no clear way of tying them together. What happened instead surprised me: I set down the event that had been described on the process diagram as a single rectangular box in the center of the page. Then I located around it all the different groups who had been assigned functions on the other diagram. Under each group I listed the actions they performed. Then I stopped and looked at the new diagram. Every needed action was there, and the page looked a lot simpler than the process diagram.
"This can't be it," I thought. "What about the dependencies?" I wondered. Don't some things need to be done before others? Of course they do, but on the new diagram this is not assumed in every case. I realized that the linearity of the process diagram was creating an assumption for me that every event required a preceding dependency, existing more in the idea of the process than in the events themselves.
In the "people-oriented" model, the autonomy and intelligence of people (an assumption that probably threatens the model in numerous unforeseen ways) takes care of the dependent events in a way the mechanistic process model cannot conceive. If conditions are insufficient for an event to be performed, conscious human agents simply either wait, or else go and do something else. Rules can set priorities based on existential conditions, such as availability of a particular resource, or the intervention of another person.
In a process-oriented outlook prioritization is a separate event that takes time from the overall process. Prioritizing between a multitude of conditions requires that every possibility be taken into account explicitly. This can be staggering in its complexity and require a crippling amount of processing. Person-oriented thinking, on the other hand, can abbreviate prioritization because the rules employed are not embedded in processes. This is not to say that people always prioritize independently as an external designer might want, but if one is willing to abandon a process-oriented approach the greater agility of complex prioritization might far outweigh the risks.
So how would our manager new improve his process-automation goal to achieve beneficial results for those he invited to his meeting? If he asked me I'd suggest what I've laid out so far as a start. To really help us work better together would take a lot more effort on his part -- there are no easy answers dealing with people.
