Job-Killing Processes

I’ve been wrestling with a thought lately - if organizations are complex systems, and complex systems are continuously self-organizing, then why do we believe formal processes make these complex systems more efficient? Worse, when an organization is in need, why do we engage in process improvement - when what may be needed is process reduction or elimination? This is not the first paragraph to question process improvement, this is not some original Eureka moment.  This is a personal journey, and the enormity of the mistake is beyond what I had considered previously. Friends, more erudite than I, have used similar words before - but for some reason I’m realizing, only recently, a simple truth: the implications for the baseless faith in the machine-based approach to management and the firm are global and profound.

A process-heavy enterprise isn’t cold and impersonal - because humans are still warm and social.  Instead, a process-heavy enterprise creates the need for larger social networks.  Formal processes do not capture the natural evolving paths people take to confront their tasks.  In response, people do what is natural, they use their social network to navigate the workplace - looking inward to find others who have succeeded despite the process.  We know that excessive time spent focused inward leads to burned-out employees, who must work the “second eight” to comply with organizational reporting and the like.  On a larger scale, this wasted effort presents - at the limit - an opportunity cost for the enterprise as a whole.  Perhaps the path to efficiency is to set the conditions for processes to emerge at the point of need, rather than Six Sigma-ing the (majority of) tasks that require creativity and agility.

In the famous early mistakes in business process re-engineering, managers believed once their processes were “streamlined” and “documented” (and embedded in enterprise software tools), they could realize savings by reducing the number of humans.  For routinized tasks, this may be a reasonable assumption - however, what percentage of your workday is routine?  Look to your own environment - do you rely on your social network to find the informal work-arounds for corporate process?  When faced with a challenging problem, do you find solace in the documented process?

Work to Rule. In labor relations, there is a term called “work to rule.”  Simply stated, this means that union workers have a negotiating tool that enables them to paralyze an enterprise - by merely doing only what is considered ‘by the book.’  No creativity, no work-arounds, no focus on task accomplishment - just fealty to the process.  Consider this message:  the way to crash some enterprises is to do what is expected by procedure manuals and process charts.

Business Development. In one company, I observed a set process for preparing contract proposals:  with clear roles, authorities, assignments, formats, and process steps.  Chokepoints were established along the way, when “pencils” down would precede a murder board review to assess the quality of the proposal against the procurement specifications.  These comments were returned to the writing team, who would tackle their task anew. The information technology consisted of shared folders, and the writers laboring over each section would be required to post their documents in the appropriate folder at the required hour.  The work was intense and draining, writers were often unaware of each other’s work, and the review team invariably excoriated the team for the lack of a “single voice” or “storyline.”

In another company, the proposal response was visible at all times to the entire proposal team.  In a shared online space, the sections were worked in parallel, each writer able to observe the other’s ongoing work.  The team met daily to talk through issues, but kept in touch throughout the process through instant messaging and email. There were roles and authorities, assignments and formats here as well - but the process was determined by the writing team, and emerged and adapted based on the demands of the work and the schedule.  As the storyline evolved transparently, there were fewer surprises, people were able to lend value across the work throughout - and the end product was coherent and compelling.  This without a review team’s intervention.

Software Development. In software development, Agile methods are triumphing over waterfall or other linear methods - users are happier because their approach to their work changes as they learn what is possible from the technology solution.  The human and the software evolve together.  The old approach was to gather what people thought they needed, build the software according to specifications, and then train the humans to operate the solution.  There may be a correlation between how much training is needed and how disconnected the solution is from how people work.  When software methods allow the humans and technology to co-evolve, when humans are co-designing the solution during “development” - we seem to have happier humans.

The thoughts bouncing in my head now are:  what needs to be in place to allow for emergent processes? Formal process has a small place - compliance processes dictated by, for example, government regulation come to mind.  However, value-creating processes must emerge from the interaction of the work and the humans.  They cannot be formalized absent the humans or the situational context - if they are, then humans will circumvent them, creating a more inefficient enterprise... or follow them to the letter, and destroy value.  In a real sense, process improvement should be replaced by process enablement.  Let the approach to work emerge from the situational context.