Category Archives: Quality

Retraining Can’t Fix This

In the course of an average workday we make hundreds of decisions. Some of those decisions require engaging our conscious awareness. In my previous post I described how the quality of those decisions deteriorate as that awareness or willpower fatigues with use.

However, there are decisions where human error occurs with certainty even if our attention is totally focused on the task. Consider the Muller-Lyer[1] illusion below:

The two vertical lines are of the same length. Even after knowing this, we all continue to perceive the line on the left to be longer than the line on the right. The “fact” that the two lines are of different lengths is simply obvious to us. Because of its obviousness we don’t stop to check our judgment before acting on it. Such actions, based on erroneous perception, are likely to produce faulty outcomes.

This error in our human perception/cognition system is hard-wired into our brains. No amount of retraining or conscious effort will correct it. So corrective actions that identify retraining as the way to prevent recurrence of this type of error won’t be effective. It will only serve to demoralize the worker. What, then, is an effective corrective action for such errors?

We can develop and use tools and methods that circumvent the brain’s perception/cognition system, for example with an overlay (red lines in the figure below), or actually measuring each line and comparing those values to one another. This does add a step to the evaluation process; an after-the-fact fix to a faulty design. Ideally, though, we would want our designs to take into account human limitations and avoid creating such illusions in the first place.

Links
[1] Muller-Lyer illusion https://en.wikipedia.org/wiki/Muller-Lyer_illusion Retrieved 2017-06-22

Human Error

Often, investigators identify the root cause of a problem as human error. But what exactly is human error?

An action may be judged as an error only in relation to a reference or standard. So first a standard on how to perform the task must exist. Sometimes such a standard is defined in a documented procedure. On occasion it may also be taught by a master to an apprentice on the job. Most times we just figure it out through a combination of past experience, current observations, and some fiddling. Human error, then, is action by a human that deviates from the standard.

When we judge the root cause of a problem as human error we’re making certain assumptions: 1] that a standard exists, and 2] the standard, if it exists, is adequate to the degree that mindfully following it produces the expected outcome.

Let’s grant that both the above assumptions are true, and even grant that the root cause of a problem was the failure of the worker to follow the standard. What, then, should the corrective action be that will prevent the recurrence of the problem? In my experience it has almost always been defined as “retraining”. But such a corrective action assumes that the worker failed to follow the standard because they don’t know it. Is this true? If not, retraining is pure waste and won’t do a damn thing to prevent the recurrence of the problem.

If a proper standard exists and the worker has been trained to it, then there must be some other reason for their failure to follow it. Skill-based errors (i.e. slips and lapses) can occur when the worker is unable to pay attention to or focus on performing the task they are otherwise familiar with. So it’s not a training issue. In my previous post I wrote about how willpower, our conscious awareness, is like a muscle. It can fatigue from use. As willpower is depleted the mind resorts to mental shortcuts or habits. This is how errors creep in.

We should not rely only on our ability to remain attentive and focused to ensure that the task is performed without failure. For that we must design tasks in such a way that failure is unlikely, if not impossible, to occur. Through design thinking we can develop tools, methods, and systems that help us perform better.

Links
[1] Understanding human failure. http://www.hse.gov.uk/construction/lwit/assets/downloads/human-failure.pdf Retrieved 2017-06-15

PDCA During Product Development

I used the concept of the PDCA cycle (below) during a few new product introduction projects. The teams realized many tangible and intangible benefits from it.

Plan  The engineering concept for a part is converted into a detailed drawing. It provides a graphic representation of the part along with all its engineering requirements/specifications. Among other things, it defines the geometry, dimensions, tolerances, and material for the physical part. The drawing of the part acts as the plan for the manufacturer to follow when making the physical part.

Do  The manufacturer uses the drawing of the part (plan) to make the physical part (do).

(Note: If you outsource the manufacturing of the part, lead times could be as much as 14 weeks or 3+ months. So, it’s a good idea to involve the manufacturer in the planning phase of the part to address any foreseeable issues as early as possible.)

Check  The physical part is inspected (checked) against the drawing of the part (plan) e.g. as part of a first article inspection (FAI) or receiving inspection. Discrepancies between the physical part and its drawing are identified.

Act  Decisions are made for each discrepancy to determine whether the part must comply with the existing drawing specifications or whether the drawing specifications—typically the tolerances around an attribute—should be changed.

If it’s decided that the drawing specifications are to be changed, e.g. the tolerances for one or more attributes is to be loosened, then the drawing is revised. This results in another loop through the PDCA cycle with the new drawing or plan.

Quality People, Stop Holding Product Hostage

Any process will inevitably generate nonconforming product at some point in its operation. Companies typically define the method for handling nonconforming product in a formal procedure that is part of their quality management system. As part of such a procedure, when nonconforming product is discovered, usually during the inspection step, it is quarantined. Two separate but related questions must then be answered: 1] What do we do with the nonconforming product? and 2] How do we prevent it from recurring?

I have observed a troubling pattern across multiple companies in how their quality control professionals are managing nonconforming product. They are holding it hostage—not allowing it to flow after it has been properly dispositioned—in order to compel others to comply with the other requirements of the formal procedure for handling nonconforming product. Specifically, the requirement to determine the root cause of the nonconformity and put in place countermeasures to prevent its recurrence.

I have also identified several reasons why quality control personnel are taking this counterproductive approach. Almost all feel, with good reason, that without it they cannot comply with all the requirements of the formal procedure or the standards and regulations they are designed to meet. They don’t believe that their coworkers are intrinsically motivated to take ownership for investigating the cause of the nonconformity and putting in place the appropriate countermeasures. Nor do they believe that they are externally incentivized to do so. And, of course, there are some quality control personnel who use this tactic to assert themselves in an environment that they feel otherwise does not respect them.

The effect of such behavior though is to reinforce the perception non-quality people have that quality professionals create blocks or bureaucratic hurdles instead of working with others to support the company’s objectives by helping to improve process and product quality. I wonder whether quality control personnel are aware that nonconforming product is still counted as inventory, and holding properly dispositioned nonconforming product hostage has a myriad unintentional consequences like lost sales, inaccurate accounting of assets, using up precious storage space, wasted manpower to monitor and manage the material, etc.

When people do give in to such arm-twisting, they do it with resentment, to meet a quality function demand, and not because they see the value in fixing the process. This is a pyrrhic victory. Pressured, resentful and motivated by the wrong goal, how thorough or accurate can their root cause investigation be? Countermeasures developed in response to sloppy cause analysis will at best address the symptoms of the nonconforming product. So recurrence is all but assured! And it’s quiet possible that these countermeasures may destabilize a process and increasing its variation leading to the creation of more nonconforming product.

Holding properly dispositioned nonconforming product hostage is not the right way to improve the performance of the nonconforming product handling process. Not only are you not adding value by doing that, your actions are costing the company. So please stop doing that. There are other better ways to improve the performance of quality system processes that support the company objectives.

QSR Required Procedures

I have identified 40 procedures required by 21 CFR 820: the Quality System Regulation

  1. § 820.22 for quality audits…
  2. § 820.25(b) for identifying training needs…
  3. § 820.30(a)(1) to control the design of the device in order to ensure that specified design requirements are met
  4. § 820.30(c) to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient
  5. § 820.30(d) for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements
  6. § 820.30(e) to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device’s design development
  7. § 820.30(f) for verifying the device design
  8. § 820.30(g) for validating the device design
  9. § 820.30(h) to ensure that the device design is correctly translated into production specifications
  10. § 820.30(i) for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation
  11. § 820.40 to control all documents that are required by this part
  12. § 820.50 to ensure that all purchased or otherwise received product and services conform to specified requirements
  13. § 820.60 for identifying product during all stages of receipt, production, distribution, and installation to prevent mixups
  14. § 820.65 for identifying with a control number each unit, lot, or batch of finished devices and where appropriate components
  15. § 820.70(a) that describe any process controls necessary to ensure conformance to specifications
  16. § 820.70(b) for changes to a specification, method, process, or procedure
  17. § 820.70(c) to adequately control these environmental conditions
  18. § 820.70(e) to prevent contamination of equipment or product by substances that could reasonably be expected to have an adverse effect on product quality
  19. § 820.70(h) for the use and removal of such manufacturing material to ensure that it is removed or limited to an amount that does not adversely affect the device’s quality
  20. § 820.72(a) to ensure that equipment is routinely calibrated, inspected, checked, and maintained
  21. § 820.75(b) for monitoring and control of process parameters for validated processes to ensure that the specified requirements continue to be met
  22. § 820.80(a) for acceptance activities
  23. § 820.80(b) for acceptance of incoming product
  24. § 820.80(c) to ensure that specified requirements for in-process product are met
  25. § 820.80(d) for finished device acceptance to ensure that each production run, lot, or batch of finished devices meets acceptance criteria
  26. § 820.90(a) to control product that does not conform to specified requirements
  27. § 820.90(b)(1) that define the responsibility for review and the authority for the disposition of nonconforming product
  28. § 820.90(b)(2) for rework, to include retesting and reevaluation of the nonconforming product after rework, to ensure that the product meets its current approved specifications
  29. § 820.100(a) for implementing corrective and preventive action
  30. § 820.120 to control labeling activities
  31. § 820.140 to ensure that mixups, damage, deterioration, contamination, or other adverse effects to product do not occur during handling
  32. § 820.150(a) for the control of storage areas and stock rooms for product to prevent mixups, damage, deterioration, contamination, or other adverse effects pending use or distribution and to ensure that no obsolete, rejected, or deteriorated product is used or distributed
  33. § 820.150(b) that describe the methods for authorizing receipt from and dispatch to storage areas and stock rooms
  34. § 820.160(a) for control and distribution of finished devices to ensure that only those devices approved for release are distributed and that purchase orders are reviewed to ensure that ambiguities and errors are resolved before devices are released for distribution
  35. § 820.170(a) for ensuring proper installation so that the device will perform as intended after installation
  36. § 820.184 to ensure that DHR’s for each batch, lot, or unit are maintained to demonstrate that the device is manufactured in accordance with the DMR and the requirements of this part
  37. § 820.198(a) for receiving, reviewing, and evaluating complaints by a formally designated unit
  38. § 820.200(a) for performing and verifying that the servicing meets the specified requirements
  39. § 820.250(a) for identifying valid statistical techniques required for establishing, controlling, and verifying the acceptability of process capability and product characteristics
  40. § 820.250(b) to ensure that sampling methods are adequate for their intended use and to ensure that when changes occur the sampling plans are reviewed

Do It Well

While I have worked with hundreds of people, I can think of only a few who cared about what they did. The care they exercised showed in the superior quality of their work product. Most, however, don’t seem to show any care for the quality of what they produce. Tasks are treated as hot potatoes, to be shoved off to someone else as quickly as possible.

Doing something with care requires you to pay attention to the task and to be mindful of its context. That, in my experience, is rare. What I do know is that when the right actions are done right the outcome is most assuredly a quality product. There is a certain beauty and elegance about it.

Some pay great attention to getting the details of a task right while being oblivious to whether the task is appropriate for the context. Others may do the task appropriate for the context, but fail to pay attention to getting it right. Both of these failures generate poor quality outcomes that cause tremendous frustrations for people on the receiving end.

Caring about your work doesn’t mean you love what you do. It has more to do with the sense of pride you derive from producing something of high quality. Your workmanship is an expression of your skillfulness; your mastery of a process or craft. There is a sense of joy felt in exercising your skill.

People may be well-intentioned. I’ve seen many display such quotes as “Amateurs Practice Until They Get It Right; Professionals Practice Until They Can’t Get It Wrong”. Few, however, work to build mastery of a skill or develop a sense of awareness of their environment. To do that you must practice performing a task while being mindful of your context. That is hard.

Even if we don’t get to choose what we do, we can do what needs to be done with uncommon grace.

PDP — Design Verification

Design verification is the process by which we check whether what we designed (design output) matches what we asked for (design input). The concept is simple to state (Figure 1), but it can be incredibly challenging in practice, partly because of the sheer volume of checks that need to be made.

fc-Basic Verification Process

Figure 1. The basic concept of design verification: Did we get what we want?

In my experience, the design effort results in a drawing of the product which can then be used to make a physical prototype (Figure 2). So in verifying the design, we are checking whether the drawing or the prototype meet all the requirements we specified. The processes used for verifying the design range from simple visual inspection to elaborate tests.

FC--PDP

Figure 2. One possible product development process showing where design verification fits in.

Methods of Verification

Visual Inspection It is possible to confirm whether a design contains the required physical attributes through simple visual inspection. Physical attributes include:

  • Material
  • Size
    • Dimensions
      • Length
      • Radius
    • Aspect ratios
  • Shape
  • Color
  • Count of features
  • Surface finish
  • Surface coating

Table 1. The table shows one possible approach to design verification of physical characteristics. Design inputs are specified in the Engineering Requirements column. Design output in this example is the drawing titled B6-32.DWG. The evidence of the verification of a particular characteristic is given by the page number and grid location on the drawing.

t-design verification

Analysis Properties of the designed product may be calculated using physical laws (from Newtonian Mechanics)

  • Weight may be calculated using the design’s volume and material density
  • Deflection may be calculated using methods from Statics/Mechanics of Materials
  • Stress under given loads may be calculated using methods from Statics/Mechanics of Materials
    • Computational modeling such as finite element analysis (FEA) may be used, provided certain requirements are met (see the FDA’s guidance on Reporting of Computational Modeling Studies in Medical Device Submissions)
  • Tolerance Stack Analyses (TSA) may be performed for sub-assemblies and assemblies to determine whether the design conforms to the size requirements
  • TSA’s may similarly be used to determine whether the components of a sub-assembly or assembly fit together

Table 2. The table shows one possible approach to design verification of a property of the design. Design input is specified in the Engineering Requirements column. An engineering analysis report was created to show the calculation of the weight. The evidence of the verification is given by the page and section number of the report.

t-design verification 2

Testing Some aspects of the design will require testing. These include:

  • Biocompatibility
  • Package integrity

Table 3. The table shows a second possible approach to design verification of a property of the design. Design input is specified in the Engineering Requirements column. A prototype was built. The test was performed on it, and a test report was created to show the results. The evidence of the verification is given by the page and section number of the report.

t-design verification 3

Design Verification by Assembly Hierarchy

Now let’s take a step back and look at design verification from a different perspective: that of design hierarchy (Figure 3). Product design can be any combination of components, sub-assemblies, or assemblies. Verification should occur at each hierarchy of the design.

Figure 3. Overall product design can be any combination of components and sub-assemblies.

For example, in the case of an assembly made up of a bolt, a nut, and a washer, my approach to verification would be the following:

Component

Bolt

  • Perform a visual inspection of the bolt drawing to verify the bolt’s physical attributes e.g. size, material, color, etc.
  • Do the engineering calculations using the bolt’s design to demonstrate the bolt’s functional attributes e.g. torsional strength, bending strength, etc.

Nut

  • Perform a visual inspection of the nut drawing to verify the nut’s physical attributes e.g. size, material, color, etc.
  • Do the engineering calculations using the nut’s design to demonstrate the nut’s functional attributes

Washer

  • Perform a visual inspection of the washer drawing to verify the washer’s physical functional attributes
  • Do the engineering calculations using the washer’s design to demonstrate the washer’s performance attributes

Assembly

Nut-Washer-Bolt

  • Perform a visual inspection of the assembly drawing to verify the assembly’s physical attributes:
    • Are the correct bolt, nut, and washers specified?
    • Does the drawing specify the number of each component to be used in a single assembly?
    • Does it show how these components are to be assembled?
  • Perform a tolerance stack analysis of the components to show components will fit together, or build prototypes of each component and perform a test of assembly.

Different aspects of the design are verified at each level of the assembly hierarchy.

The Value of Experience

Experience by itself teaches nothing… Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.

― W. Edwards Deming, The New Economics for Industry, Government, Education

fAnd yet I routinely hear people declare “I’ve been doing this for 30 years!” Experience is particular; shaped by chance causes; unique to an individual. It by itself cannot be generalized. To do that you need theory.

Theory links “what” (experience) to “how” (process). It can be tested in diverse circumstances. If it produces expected outcomes, it is useful. It can be shared and used with confidence. Theory builds understanding. Shared understanding, not shared experience, leads to individual empowerment, personal responsibility and accountability, and cooperation.

Declarations like that above are nothing more than chest-thumping meant to discourage inquiry and end debate. Instead of building faith they further mistrust. They ask obedience not understanding. They are an exercise of power and authority. Territorial. Protectionist.

It shouldn’t come as a surprise that people who appeal to experience alone have no credibility with me. I view them as ignorant and hold them in the lowest possible regard.

Discovering Quality – A Personal Journey

I have been asked many times, where do you see yourself in five or ten years? Usually it has been in the context of a job interview or a performance appraisal. Early on when my career was getting started I had no idea, so I answered in vague tentative terms. “I see myself doing what the company needs me to do.” “I see myself in a more responsible role,” whatever that meant. Truth be told, I did not give the future much thought. I was more concerned about the present. I need to start earning a living. Would I get this job? Would they sponsor me for a work visa? Don’t mess up.

One word sums up my early career: naive. For my first job, I was hired as an applications engineer by a semiconductor equipment manufacturer. The company made machines that chip makers used. It had nothing to do with my background in mechanical engineering. I did not know anything about the semiconductor industry, its technology or the company’s products. I did not know how the company was organized. I did not know what my role was about. How did I fit in? What was my function? Who was I supporting? In hindsight, I did not know what it is I even ought to know so I did not know what questions to ask or that I should ask any at all.

The way I dealt with my naiveté and feeling lost was to put my trust in management. Do what I was told. They, of course, had experience that informed their judgment, and good motives, too, didn’t they? On one occasion, I remember clearly, the general manager of my unit saying to me “This isn’t college where someone has mapped a curriculum for you to follow. Figure it out.” I did my best with right intentions, but best efforts and right intentions are not enough when you do not know what to do. For my efforts to be meaningful, for me to be productive, I needed to understand my context. I needed help, and I got lucky.

I was introduced to quality at the midpoint in my career by Samsung. When the company hired me as a quality assurance engineer I had no clue what it was about. But they sent me to their main facility to get training—a huge and impressive campus near Seoul, South Korea. The trip was for five full weeks; every day was spent on training. Part of each day was spent in the classroom being taught quality concepts like viewing work as a process where the next step is the customer, and performing root cause analysis by repeatedly asking “Why?” The rest of the day was spent learning how these concepts were used in practice with basic quality tools like process flow charts, checklists and Pareto charts. I was asked to “walk” and map various processes to understand what was happening and to compare what I found with what was supposed to happen. While I cannot recall my first impressions anymore, I do remember feeling engaged and curious.

Many different teachers were pulled in. These were men and women who had been performing the related functions for a long time. Training with them was intense. Not only was I asked to practice the lessons I was taught, but they would quiz me about what I learned. Sometimes they would know the answers and ask leading questions. Other times they would work with me to find the answers. I returned from my trip with a solid foundation and a context for my work. This was unlike anything in my previous jobs where I did stuff assigned to me without understanding. I had found purpose for my work—why I was doing what I was doing—and with it the joy of doing it.

The trip to South Korea was just the beginning of my education in quality. My manager, a veteran of the Samsung way, insisted on careful observation and deep thinking in my work. For example, in dealing with nonconforming product I was asked to check whether it was a process issue or a measurement issue, whether it was a recurrence of an issue, whether other attributes were also affected, and so on. I was asked to step through the consequences of my observations to determine how such an issue would manifest itself in the final product. My colleagues, short-term expatriates from South Korea, provided daily examples of how to do this through their own practice. It was one of them, as he was studying to take ASQ’s Certified Quality Engineer (CQE) exam, who introduced me to ASQ. In my time with the company, I went through further training that included an eight week course for Six Sigma Green Belt, and a week long course for lead auditor in ISO 16949. The people at Samsung made a heavy investment in my development for which I will forever be grateful.

There is no doubt luck played a crucial part in how I came to discover my context. And that discovery had to be enabled by an outside factor. But much of what has come about since has been through hard work and religious practice. Since my time with Samsung I went on to earn my CQE and CQA through self-study. In studying for those exams I discovered the breadth of scope of quality. It caused me to reframe my context, enlarging it beyond an individual company and traditional boundaries. I learned to view production as a system in Dr. Deming’s Out of the Crisis [1]. This systems view was developed further by Dr. Ackoff’s Redesigning the Future [2], and Peter Senge’s The Fifth Discipline [3]. Dr. Shewhart’s book, Economic Control of Quality of Manufactured Product [4], and Dr. Wheeler’s Understanding Statistical Process Control [5] taught me the ubiquity and nature of variation and how to differentiate between the two fundamental types: common cause variation and special cause variation. I developed a functional understanding of the psychology of human motivation through Daniel Kahneman’s Thinking, Fast and Slow [6], and the Buddha’s “Dhammapada.” And Karl Popper in his The Logic of Scientific Discovery [7] and Thomas Kuhn in his The Structure of Scientific Revolutions [8] showed me how knowledge grows.

I continue to read on the history of the field, the fashions and fads that came and went, its development, its successes and failures, and its challenges. My studying has been non-stop. So has practicing what I have learned. It is now second nature for me to plot the data when I am confronted with a problem; to understand it in its context, and whether it represents a potential signal or just noise. I use checklists as memory supplements everywhere—as daily to-do lists, as lists to define and meet the requirements of an operation or process, and as data collection lists to track frequency. I doodle process maps to understand what is happening or being described.

Quality has had a profound impact on me. It touches every aspect of my life. The ideas that make up the field of quality have helped me develop my observation skills, taught me how to reflect on the observations and understand them, and to then respond to them appropriately. While I am still subject to the vagaries of life, conscious practice of these learned skills has reduced the chaos I introduce to life through my actions. This in turn has improved the outcomes of those actions. And that, I hope, has made some small difference in the lives of those I touch. A trivial example of this is my daily commute to work. I observed that it made no meaningful difference in the time it took whether I actively changed lanes or stayed in the same lane. But the repeated lane changes significantly increased the risk of getting into or causing an accident. It increased everyone’s degree of frustration. It increased my driving effort, and reduced my fuel economy. So I no longer change lanes unless absolutely necessary. I get to work in just the same time, safe and sound, and hopefully so do others.

It will be ten years in 2016 since my fortunate introduction to quality. I could not have seen this is where I would be all those years ago. In the zigzag path my career has taken I have had a chance to work with many different companies in several different industries. I have taken advantage of each opportunity to observe how a company operated, particularly as it related to its employees. When I have come across coworkers, new or experienced, who reminded me of my naive self, I have tried to help them to understand their context and how they fit within it—something my management never did for me. I believe it has helped them to orient themselves, discover their purpose, and labor in a way that bore fruit instead of frustration. That has been most satisfying.

References and Notes

1. Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT CAES. 1991. Print. ISBN 0-911379-01-0

2. Ackoff, Russell L. Redesigning the Future: a Systems Approach to Societal Problems. New York: Wiley, 1974. Print. ISBN 0-471002-96-8

3. Senge, Peter M. The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday/Currency, 1990. Print. ISBN 0-385260-94-6

4. Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York: D. Van Nostrand Company, Inc, 1931. Print.

5. Wheeler, Donald J, and David S. Chambers. Understanding Statistical Process Control. Knoxville, Tenn: SPC Press, 1992. Print. ISBN 0-945320-13-2

6. Kahneman, Daniel. Thinking, Fast and Slow. New York : Farrar, Straus and Giroux , 2011. Print. ISBN 978-0-374275-63-1

7. Popper, Karl R. The Logic of Scientific Discovery. New York : Basic Books, Inc., 1959. Print.

8. Kuhn, Thomas S. The Structure of Scientific Revolutions. Chicago: University of Chicago Press, 1970. Print. ISBN 0-226458-04-0

The Weekly Meeting

Monday afternoons at two-thirty. That was the time for our weekly staff meeting. When I joined the company everyone was required to attend it: engineers, technicians and operators. The head of our department, the Director of Quality, led it.

It was a rare week when the meeting started on time. Mondays were also when we had our one-on-one meetings with the Director and he had one of those exchanges going on right before our staff meeting. It always went over. So several of us would gather and wait outside of the meeting room until we were noticed and motioned to come in.

Even with this routine delay I don’t remember a single week when everyone was present before the meeting started. There was frequently at least one person who creeped in late. It wasn’t always the same person either. Some late comers might put on an apologetic face at times, but a few were shamelessly indifferent of their indiscretion.

Just as the meeting never started on time, it didn’t end on time either. I recall a few occasions when I wondered whether the meeting actually ended.

The Director got our meeting going by sharing a subset of the highlights and lowlights of the previous week that he gets in an email from the corporate overlords. We cheered the highlights and bemoaned the lowlights even though none of us could draw a connection to any them with the specific work we did. They did not prompt any actions for our department. They were also divorced from similar points shared in the previous week; presented as stand-alone bits of information. On those occasions when someone did make a tentative connection, it unleashed pent up frustrations with people feeding off of each other to blame some nonpresent “they.” So what purpose did this update serve? I couldn’t tell you.

Following the update, the Director shared his schedule for the current week. It always showed back-to-back meetings, sometimes overlapping, from the start of the workday to its end, for the whole week. So when did he have time to think and plan, to draw up an agenda for his meetings, to follow-up on assignments, to analyze, understand, and guide the performance of the system he was charged to direct? At first I had felt sympathy. What sort of monstrous organization drives its people like this? But it didn’t last long. I recognized much of it was self imposed and not a demand of the organization. It was his way of showing others how busy and engaged he was, how hard he was working, how committed he was to the company. It was all light and no heat. Perhaps I’m being harsh, but I don’t think so.

After he finished his update he would ask each staff member if they had anything to share. Most did not. Some, though, shared information on what they were doing in excruciating detail. Usually it was about “unexpected” hurdles, blocks, or breakdowns. They were the same from week to week. This was another opportunity to vent about those others who didn’t follow procedures, the unreasonable surge in demand for our services, or how the system is broken and needs fixing. Who is going to fix it? How should it be fixed? What resources are needed for the fix? That requires a plan. But when is there time and space for that?

Once a month the Director would remind everyone to calculate and report metrics they were responsible for. It shouldn’t come as a surprise that at least one was delayed. Not always the same one, but it came with all the usual excuses.

That was the ritual.