The price of dignity at work: one company says $20

  1. Monitoring employees’ time in the restroom is not okay.
  2. If you believe monitoring employees’ time in the restroom will materially improve your company’s bottom line, refer to item #1, and please keep reading.

Item 1 should go without saying. It’s like telling colleagues to stop chasing the bats in the office – seriously – I’ve done that. Or telling kids to stop eating liver and onions. But at least one company, which we will refer to Company W, has proven me wrong once again. Some years ago, W’s management saw fit to expand the purview of “performance management” to include employees’ personal business:  employees spending more than 6 minutes a day in the restroom risk being written up. This. Really. Happened.

“The company’s human resources department described “excessive use of the bathroom as…60 minutes or more over the last 10 working days…do the math and it works out to 6 minutes a day,” the article stated.

I suspect this stroke of timesaving brilliance was born out of a not-so-unusual concern about productivity or output. I get that. There’s a problem – let’s jump right to problem solving because that’s the way of the traditional method of management – leading unsuspecting management teams down a bad path. So very reasonably, hypothetical solution in hand, management rightfully pursues a data-driven approach to said productivity problem. Enter technological ease – management implements the swipe in /swipe out approach to restroom breaks – thus confirming productivity is in the toilet. Sticking a pin in confirmation bias for now.

Imagine the unintended consequences of operation “haste makes waste:” trashed restrooms and unwashed hands. If there were any productivity gains (from the few who might have abused restroom time), they were probably lost on sick leave (remember – unwashed hands). I doubt going faster and trying harder did much for W’s bottom line.

The imposition of workplace policy on one’s basic human functions is just plain wrong. And limiting restroom breaks for the sake of productivity is dumb.

If this wayward management team knew Dr. W. Edwards Deming and his System of Profound Knowledge, they would know it’s they, not their workers, who are responsible for improving productivity. Dr. Deming fought against the supposition that problems in production were the result of workers not doing their jobs the way they were taught. Rather, it’s management’s job to understand their business as a system, make processes visible, and give their workers the tools and knowledge needed to improve the capability of the system instead of assigning arbitrary productivity targets.

You see, management achieves a high-quality product by improving the manufacturing process, not by offering $20 gift cards (one dollar a day) to workers who don’t use the bathroom at all during work time.  Company W did that too….  As I was saying, when the process is ‘in control’ – management is able to transfer resources from the production of defective units to the production of good product.

If W’s management embraced Dr. Deming’s theory of management, restroom time management, like chasing bats, would fall into the realm of the absurd.







“Nailed it.” A lesson in overcoming project complexity


When your project shows signs of trouble, go basic first.

It was Benjamin Franklin and not 70’s musician Todd Rundgren who first admonished us to pay attention to the basics or be willing to accept unpleasant consequences.

 “For the want of a nail the shoe was lost,
For the want of a shoe the horse was lost,
For the want of a horse the rider was lost,
For the want of a rider the battle was lost,
For the want of a battle the kingdom was lost,
And all for the want of a horseshoe-nail.”

Are you singing yet?

“HOWs” and nails have something in common:
they’re pointed and effective for building strong foundations.

Much of my work focuses on involving people in activities and decisions about their work and how it will change as the technology they use changes.  Having been a consultant/leader with a Big 4 firm, my project experience is extensive and varied. Project work sometimes got complicated, and we’d have to resort to heroic measures to finish. Sometimes people got burned out, but we delivered.  Looking back, I can’t help but wonder….when the going got tough, why weren’t we looking more closely at the basics first – the foundations of team effectiveness?

I used to believe the secret sauce of strong project teams –and their effectiveness– was chemistry. Harkening back to a “Camelot” project – we had all the right capabilities and expertise, we were aligned on scope and approach, collaborative, and delivered a great project.  Those characteristics are all easily seen. Yet, as I’ve continued to explore the essence of organizational culture I’ve come to realize that a team’s respect for [and engagement in] structure, visible processes, and clear governance, although perhaps more difficult to see, were the foundation, the secret sauce, of what made all the other characteristics work well –and ultimately are what made us successful.

How did I figure this out?  Contrast.

Many years after the curtain came down on my Camelot project, I was asked to lead the process / organization side of a large technology project.  Starting a project is like building a house – the quality of the foundation defines the remainder of the effort.  The project had been operational for a few months when I joined so the foundation had already been poured.  I dismissed the occasional hiccups I noticed as “the team getting started on a new project” –for as long as I could.  At one point I suggested that we revisit our project governance – the operational guide, how it was implemented, and whether the team followed it – but this was a mature team and the general consensus was that everyone knew what to do.

And so I relented. I was the new person and thought it best to heed the advice of Edward Baker “A large percent of the time it is best to just stand there rather than to do something.” Baker was a protégé of Dr. W. Edwards Deming, and is the author of the recent book, THE SYMPONY OF PROFOUND KNOWLEDGE: W. EDWARDS DEMING’S SCORE FOR LEADING, PERFORMING, AND LIVING IN CONCERT. And so instead of just doing something, I observed and took lots of notes.

To be honest, there were so many things happening at once, it was impossible to identify clearly any specific, superficial cause for the hiccups.  Have you ever been sitting at your desk on a Monday morning and experienced the subtle fragrance that tells you your office trash can wasn’t emptied over the weekend?  You know you’d better take care of it – because it’s not subtle for long.  Intermittent disruptions quickly turn into a steady stream of issues blockers, miscommunications, and disagreements about how the work should get done.

The “ask” from the team arrived in a one-line email:
“Can you help us figure this out?”
Now they were ready for me, and I was ready for them.

I had been thinking a lot about what I’d observed, but I was hard-pressed to know where to start.  You know how in the movies the sound of a needle scraping across a vinyl record album silences a roomful of people?  The thought of my mentor’s reaction to my lizard-brain urge to jump straight to solutions has the same effect.  “How’s that working out?” he’d ask in his irritated-but-amused tone.  Then, he’d remind me that “faster is often slower.”

One of the things Dr. W. Edwards Deming taught us through the System of Profound Knowledge is the importance of understanding our organization as system. When we do this, we can study it and understand how it performs, and develop and test theories on how we can improve it.  When we attempt to “fix” the system without first understanding it – there is a high likelihood that we will make things worse.    So, as I slowly backed away from the fire with the still-full gas can in hand, I pondered what my mentor would say and remembered the advice of Tim Timmons, a Major League Umpire who presented at a function I attended.  On the subject of expanding our capabilities – and what to do when we’re just short of knowing what to do next – he reminded us to “return back to center” – the place where you know what you know.

So that’s what I did.  Using Dr. Deming’s diagram of how a system operates, I worked with the team to put together the picture of our project as a system – starting with the Aim (the importance of this project in the larger scope of the organization).

Capture (1)

After we defined the Aim and value chain (the activities that contribute directly to achieving the Aim), we looked at inputs and influences – starting with the obvious – software, knowledge, development tools and the like. As the list of inputs waned – we crossed over to outputs and outcomes. Again – obvious ones like requirements and designs were mentioned. Then I prompted a little – asking the team to consider some of the outcomes we saw that we didn’t want: strain, and delays…. Light bulbs coming on.  For 45 minutes, I shuffled between two sides of the white board -adding some inputs – but more influences; and some outputs – but more outcomes.

When we finished, we had a picture.

That picture helped us develop some themes – which showed us that while the situation seemed complex, it wasn’t overwhelming.  In the next session, we did some root cause analysis and looked for low-hanging fruit – the solutions you can test fairly quickly.  After three working sessions, we had a plan in place. Everyone was clear on what to do, by when, and by what method.

If you’re wondering, yes, governance (or the team’s lack of clarity with respect to governance) was a root cause.  We revisited roles and responsibilities, reinforced processes for communicating across the team, and engaged the entire team in the development of RACIs – articulating what Roles are Accountable, Responsible, Consulted, and Informed – for every operational process.  We also clarified the project methodology and trained everyone on it.   All of the governance resources and tools became living documents that could be easily accessed by anyone on the team.

You see, it’s one thing to know, in general, WHAT a “role” does on a project. When we don’t take the time to clearly define the HOW, it’s like using too few nails to build a foundation.  Before you know it, you’ll be fixing problems instead of marching toward your Aim.