The Other Side of History: total quality management

Showing posts with label total quality management. Show all posts

Tuesday, August 19, 2025

Posts from a Business Class

I recently completed a course in total quality management (TQM), and here are all my writings from that class. This was only my second business class, and these classes have one thing in common: their adherence to the "happy path." By this I mean that the textbooks and course material assumed that all involved individuals are perfect angels (except for those of us who reject TQM), and that the world is adorned with sprinkles and populated by unicorns that fart Skittles. For example, advocates of TQM call for "employee engagement," but managers are not prepared for when that truly happens.

Despite this, I do not consider this class to be a waste of my time. When someone asks me "when am I going to use this?" I counter with: "when is it going to use you?" This holds even for business management classes. Plus, those classes have a perverse entertainment factor: there is enough that is correct about TQM that when it goes wrong, it is worth observing, like a slow motion car accident.

To put a bow on all this, I present this list of posts. They are grouped by topics, and are also placed in the order they were written during this eight week course. There are some new ideas, some humor, and some criticism. Mostly, though, these posts are about connecting business management topics to the concepts I find interesting.

General Criticisms of TQM

New and Interesting Concepts

Humor

Military/Militia-Related

Voice of the Customer (VOC) and when Vox Populi is not Vox Dei

Just-in-Time Manufacturing

Leadership and Management

Week 1

Getting Started with Total Quality Management

Week 2

Culture, Ethics, and Strategic Alliances

Week 3

Leadership, Customers, and Employees

Week 4

Teams, Communication, and Training

Week 5

Quality Tools and Programs

Week 6

Continual Improvement Methods

Week 7

Benchmarking and Implementation of TQM

Week 8

Application of Quality Theories

Sunday, August 17, 2025

A Sorted Tale of Pizza and Red Bull!

Introduction to Gaggle dot Com

Gaggle dot Com is a small software company founded in June 2025. The staff consists of 3 rockstar software developers, the manager/founder (also a rockstar developer), a one-man sales and advertising team, and a graphic designer that is a consultant working on an as-needed basis.

Their primary product is GaggleMail, which is not a Gmail rip-off. Pinky promise.

The first version of GaggleMail was developed by the founder in four straight 24-hour days, while he was strung out on multiple cases of Red Bull.

After this coding binge, the founder saw that it was good. He then had to be medevac'd to the closest hospital on account of heart palpitations.

Once released from the hospital, the founder decided to hire 3 buddies who were also rockstar software developers. Getting this many rockstar developers in one garage can only result in the formation of a militia or the founding of a startup company. Fortunately for everybody else, the outcome was the latter.

The founder paid his team in the universal currency of software engineers: pizza and Red Bull.

Next, the founder asked his sister to design a logo for Gaggle dot Com and to produce some screen designs that the rockstar developers could implement. The screen designs were good, but the logo looked like it was made in Microsoft Paint.

The final logo was made by a freelancer on Fivver.com. It took the freelancer twenty minutes, and it looked like it was made using AI. That's OK, though.

The rockstar developers improved GaggleMail, incorporating the screen designs made by the founder's sister and the AI-generated logo. They saw that it was good and decided to tell the world about it.

They hired a sales and marketing guy named Bob. He had two tasks: advertise GaggleMail and raise venture capital.

Bob's first marketing campaign involved TikTok videos showing three geese swimming in a pond, each carrying an envelope, taped to their beaks. Just like in the logo. He was arrested on animal cruelty charges. The founder bailed him out, and the next advertising campaign’s TikTok videos were made using AI.

For the third campaign, Bob decided to repeat the classic "Turkey Drop" from that old TV show called "WKRP in Cincinnati." Bob knew that geese could fly, so he tied them up in rubber suits as seen in “Pulp Fiction” and gagged each of them with envelopes.

He hired an airplane with a banner that read "GaggleMail by Gaggle dot Com." He loaded the bound geese into the plane and had the pilot fly at an altitude of fifty feet above a shopping mall's parking lot.

He had one of his friends recording this on an iPhone.

Bob proceeded to toss the three geese out of the airplane. Splat! Splat! Splat!

Again, Bob was arrested for animal cruelty. The founder again bailed him out and made him promise to only use AI from now on to make his TikTok videos. The video of the geese hitting the parking lot went viral! Gaggle dot Com was getting noticed!

Bob started raising venture capital and was somewhat successful, as long as he avoided the SPCA crowd.

Gaggle dot Com is now "ramen noodle profitable" and is poised to take the internet by storm. A storm of geese, but still a storm!

Problem Statement: Increase Quality!

With the boost following the "Geese Drop" video, the user base of GaggleMail grew rapidly. The GaggleMail product was performing well, until one day when the rockstar devs were inundated by emails from customers stating that GaggleMail was loading slowly and sometimes not even available!

Being only ramen noodle profitable, the manager/founder could not afford to hire customer service reps or a QA guy. Bob the sales and marketing guy was raising venture capital, and the manager/founder didn't want to take him away from that task. Besides, the manager/founder was tired of bailing him out.

So, the manager/founder led from the front! He took the following actions together with his 3-man rockstar developer team.

First, he chose one of the rockstars, the one who is a good writer, to craft emails that would be sent to the customers experiencing problems.

Second, he measured GaggleMail's response time and the percent of time that it was unavailable. The numbers looked bad: the response time was 15 seconds, and the uptime was only 75%. No wonder their customers were not happy!

Third, the manager/founder worked with the remaining rockstars to diagnose the problem.

It turned out that the problem was with the computer used to host Gaggle dot Com. That computer sat in his father's basement. He called his dad, and his dad was in a panic! "The server is melting, son!" He sounded like a goose with its head cut off.

Fourth, the manager/founder set goals for the metrics: he wanted a response time of under 1 second, and an uptime of 97%. Baby steps.

Fifth, the manager/founder worked with the 2 remaining rockstar devs (meaning, the ones not sending out apology emails) to calculate just how powerful a computer they would need to handle GaggleMail's current user base at the desired response time and uptime. They then projected how many users GaggleMail would have in a year, assuming that Bob does NOT make another viral video. They reran the calculations based on that number of people at the desired metrics.

It turned out the computer they needed was a top-of-the-line Mac Studio. The manager/founder bit his lip. "This is going to hurt!" he said. Fortunately, Bob, the sales and marketing guy, came through with some more venture capital! The manager/founder was very relieved: he didn't want his kneecaps broken by the local mob boss, again.

The manager/founder had the rockstar dev writing emails pause his work so he could join them at the Apple Store. This was going to be an experience that they would tell their children and grandchildren, and the manager/founder wanted all his friends to be there. Arriving at the Apple Store, they looked at all the computers.

There it was, the high-end Mac Studio! The four rockstars approached it, then hesitantly touched it, like those apes that touched the monolith at the start of "2001: A Space Odyssey." The Apple Store manager, concerned, approached them. Mac groupies sometimes needed a firm hand.

"Are you going to purchase that Mac Studio, or just drool on it?" the store manager asked.

The manager/founder stepped back… he was about to fulfill a lifelong dream…

He reached into his pocket. Then, in his best Cleavon Little accent, he said "excuse me while I whip this out!" He removed his wallet from his pocket and pulled out an Amex Black Card.

Half the store gasped in fear! Some of the old women even fainted!

The four rockstar devs took their shiny new Mac Studio over to the manager/founder's dad's house and replaced the old Gateway computer sitting in his basement. They transferred the Gaggle dot Com website and database to the new Mac Studio. They tested everything out, and all was well.

They returned to the manager/founder's garage then sent out a new email to the customers letting them know that all was well asking them to try the NEW! IMPROVED! GaggleMail!

Bob got that evil look in his eye. He wanted to make another banger TikTok video. "No! Don't you dare!" the manager/founder scolded.

They celebrated in the only way rockstar devs and sketchy social media influencers knew how: with pizza and Red Bull.

Ongoing Measurement

The rockstars learned a valuable lesson from all this: an ounce of prevention is worth a pound of cure. So, they needed a way to prevent this problem from recurring.

The idea foremost in the manager/founder's head was the diagnostic process they used to identify the problem and the cure they used to fix it.

The problem was that customer demand exceeded the specifications of Gaggle dot Com's computer in dad’s basement.

One solution was to lay out considerable cash - unfortunately, Apple Store employees aren't fond of pizza and Red Bull. They prefer Starbucks and avocado toast.

Could this problem be anticipated? Could Ben Franklin's adage be made actionable?

The manager/founder gave considerable thought to the problem and how to anticipate it. His first idea was to purchase more Mac Studios, but there were two problems: their cost, and the very real possibility that his dad would object to the rising electric bills.

Then he hit on a compromise, sort of. The manager/founder decided that the best solution was to continually measure the chosen metrics AND the number of customers. This would allow him to do several things:

Determine the growth curve for the size of user base
Estimate the relationship between the number of users and the chosen metrics (response time and uptime)
Predict the number of customers that will exceed even the immense power of that Mac Studio computer sitting in dad’s basement
Only purchase computers on an as-needed basis

Lessons Learned from the First Problem

This was Gaggle dot Com's first major problem, besides Bob and his TikTok videos. The leader/founder wanted to record his thoughts. Here’s what he came up with:

Pay attention to customer complaints and be prepared to address them
Be proactive so the complaints were limited
Choose appropriate metrics that are relevant to customers
Determine the baseline and set goals for improvement of those metrics
Continually measure these metrics with the goal of improving them
Automate the measurement process
Make predictions based on those measurements
Pay your rockstar devs well: pizza and Red Bull are the coin of the realm

Quality Philosophy Used

Should the manager/founder's actions count as a "quality philosophy?" Yes and no: he concerned himself with customer satisfaction and continual improvements, but those two factors do not count as a complete total quality management (TQM) implementation. Let's go through the "8 Principles of TQM" as listed in Isolocity (2024):

Customer focus – yes, customer satisfaction was the driving factor
Leadership involvement – the manager/founder led from the front
Employee involvement – they live for this stuff!
Process approach – heck no
Systematic management approach – heck no
Continual improvement – yes, the manager/founder took actions to improve the relevant metrics and is considering how to continue the process
Factual decision-making – how else could it be?
Mutually beneficial supplier relationships – Gaggle dot Com maintains excellent relations with the local pizza shops and Red Bull suppliers.

So, the quality philosophy used was not full TQM – it included modifications appropriate to our scrappy software company. It allows Gaggle dot Com to retain its innovative nature required by all startup companies while preventing the (malignant) growth of bureaucracy that paralyzes and destroys such companies.

Quality Tool Used: Log Analysis

The quality tool used by Gaggle dot Com wasn’t one the usual quality tools, but it is certainly common and valuable in the software development industry: log analysis!

All computers running software like GaggleMail record some of the events taking place in that shiny new Mac Studio sitting in dad’s basement. The information recorded includes customers interacting with GaggleMail, database access, potential security concerns, system crashes, and so on. This is an incredible amount of information that not even our rockstar developers could make sense of it (really, they could, they just have better things to do).

Mundane events like customer login attempts, interaction with databases, and so on usually do not require immediate analysis. However, the data recorded is still valuable and is the foundation of relevant statistical process controls (described next).

However, a log analysis tool can immediately spot security problems and system crashes. How to act on that information? Usually, the log analyzer sends a text message to one of the rockstar developers who is “on call” so that he can diagnose it and fix it.

Something our manager/founder must consider is that for many rockstars, there is not enough pizza and Red Bull in the world to be on on call. So, the duty would fall on the manager/founder.

Statistical Process Control Used

One of the best statistical process control methods for a company like Gaggle dot Com to use are histograms of the hourly web traffic GaggleMail receives. This feature is usually part of system monitoring or logging tools and can be easily added to dashboards for use by all the employees at the Gaggle dot Com.

As a concrete example, consider a histogram that shows the number of GaggleMail users in each hour of the day. There would have to be adjustments for different time zones, of course.

The rockstar devs would look at the histogram to figure out when extra computers would be needed to handle the extra traffic. In the case of GaggleMail and their brand-new computer, the Mac Studio would have to be more fully committed to making sure GaggleMail customers are serviced during peak hours. An “edgy” application of hourly web traffic is to enable or disable features in GaggleMail based on traffic volume – expensive (computer intensive) features could be disabled during peak hours. This would lower service quality, so must be considered as a last resort.

The manager/founder will look at the chart to figure out if it makes sense to continue to host the site on a single Mac Studio computer or move to a system like Amazon Web Services which includes "load scaling" – automatically making more computers available during peak hours and taking away those computers when not needed during off hours.

Bob, the sales and marketing guy, would use this chart to determine the peak hours that GaggleMail users check their mail. If Gaggle dot Com decides to sell advertisements on the site, Bob would use the histogram to set the prices the advertisers would have to pay. Ads shown during peak hours would cost the advertiser more than ads shown during off hours.

Conclusion

The manager/founder was happy with the way things worked out:

He implemented a system used to measure the quality of GaggleMail
He extracts usable information from that system
He uses the information to predict growth and to financially plan for upcoming expenses
This allows him to continually improve the metrics
He performs competitor analysis to add desirable features

All of this is great: the customers are happy with existing quality of service, and the quality of service is always improving. In essence, he has moved from merely reacting to being aggressive, as all good rockstar developers should be.

Our manager/founder has no illusions about the future, however.

He and his team of rockstars will soon no longer work for pizza and Red Bull. Their standards are evolving! Soon, they'll want higher quality pizza (Nico's or Papa Johns) instead of that horrible Domino's. Also, their tastes will change from ordinary Red Bull to Fresh Squeezed Red Bull, then to Tropical Red Bull Margaritas, and maybe even all the way to Vodka Red Bulls!

That means that Bob the sales and marketing guy must continue raising venture capital, or worse, return to his shady past of abusing geese, all for the engagement. You can see it in his eyes - he wants those clicks!

The manager/founder knows that these events are on the horizon and must plan accordingly – again, he must not only be proactive but aggressive.

Bob could establish multiple revenue streams for Gaggle dot Com, like advertising, or somehow "gamifying" GaggleMail.

Gaggle dot Com's team is small, but this is made up for by the incredible power of rockstar developers! Archimedes once supposedly said “give me enough pizza and Red Bull, and some rockstar developers, and I will move the world.” This proves that rockstar devs have been around since about 230 BC.

It may seem that GaggleMail depends on having only rockstar programmers. It doesn't: non-rockstars are welcome and are valuable, so long as they fully understand their own strengths and weaknesses.

One event that would require the addition of more developers is if Gaggle dot Com adds more software products to their lineup besides GaggleMail. The manager/founder has been hearing complaints about Google Maps, and he has considered making something called Gaggle Maps (totally not a copy of Google Maps, really).

How to pull this off?

A single team of rockstar developers rightfully scoff at the whole agile development and scrum processes with its daily standup meetings and sprints and other bureaucratic bloat. But what about two teams?

Our manager/founder has read works about something called "scrum of scrums," a technique for combining and synchronizing multiple teams (Spanner, n/d). The problem our manager/founder has with this is that the basic frameworks of agile and scrum are flawed, and making a pile of them (as required by scrum of scrums) does not fix those flaws and, indeed, magnifies them!

Our manager/founder understands that forcing all available people into an organizational or team model should not be done. It is better to devise an organizational or team model that works for the people already there.

Then scrum and scrum of scrum advocates call for something called "work-life balance." Our manager/founder understands that work-life balance is a myth (Pontefract, 2024), and it is a reason for companies to not demand the best from its employees.

In fact, whenever he reads about scrums or scrum of scrums, our manager/founder wants to find a rope and a wobbly stool!

Still, the problem remains. All our manager/founder understands is that it is inappropriate to share expertise across different teams except in very specific ways: doing weekly "brown bag lunches" is great for sharing knowledge, but sharing a QA person or a project manager across multiple teams are causes of failure.

This is shaped by his experience: small teams work great but combining them by treating the team members as "human resources" is vile, disgusting, and downright repulsive. Unfortunately, our manager/founder has no practical experience in combining teams in a way that eliminates bureaucracy, maintains creativity and autonomy, and preserves dignity.

This failure to understand how to combine multiple teams must not be taken as a reason to stop asking questions. The future is wide open, and there must be ways for Gaggle dot Com to stay scrappy and not turn into another IBM!

Thus ends our story of pizza and Red Bull!

References

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Isolocity. (2024). What are the 8 principles of TQM? https://isolocity.com/what-are-the-8-principles-of-tqm

Pontefract, D. (2024, 2 June). The fallacy of work-life balance. Forbes. https://www.forbes.com/sites/danpontefract/2024/06/02/the-fallacy-of-work-life-balance/

Spanner, C. (n/d). Scrum of scrums. Atlassian. https://www.atlassian.com/agile/scrum/scrum-of-scrums

Management Paralysis and the Good Idea Fairy

Because both total quality management (TQM) and the Malcolm Baldrige approach both require that companies and organizations use a “fact-based” or “evidence-based” or “data driven” approach to setting strategy and making decisions, some type of integrated performance measurement system (El Mola and Parsaei, 2010) seems like a requirement for ongoing operations. [By the way, there apparently is something called “evidence-based medicine.” Going on those words alone, one must shudder at the opposite. But, if anything is true, it is that when words are used to obscure, one must wait for the truth and real intentions to be revealed.]

An integrated performance measurement system must be action-oriented, meaning that not only can it be used to track performance but can also be used to identify slow-downs, excessive costs, and other areas that require improvement.

In addition, an integrated performance measurement system must be able to measure performance based on processes that span across an entire company or organization and not be relegated to single departments. That’s called a process-oriented metric. It is not clear whether an integrated performance measurement system can propose a restructuring of an organization or company so that these cross-department processes do not cross so many departments, and whether such a restructuring is eventually worth it.

The voice of the customer (VOC) and market forces must be considered in any quality management system such as TQM and Malcolm Baldrige approach. Parast et al. (2024) imply that some companies or organizations have a difficult time converting those into actionable items. Instead of a customer-satisfaction loop or a market-analysis loop, companies get stuck in what engineers call “analysis paralysis” – they never make it pass the data collection stage.

Something similar to this is what I call “management paralysis.” This is when management hasn’t developed strategy for some product, or when old management leaves the company and takes their strategies with them. Goetsch & Davis (2021, p. 295) use the phrase “voice of the company,” and with management paralysis, the voice of the company is mute.

Here is a good example: in October 2021, Apple introduced a “notch” in the screen of their MacBook and MacBook Pro products. The idea is that this notch would be a place to hold higher resolution cameras, as well as face tracking and face detection technology. Here we are in August 2025 and none of that has happened. One must conclude that the Good Idea Fairy paid a visit to some mid-level manager and gave him the "vision" of putting the notch into otherwise outstanding computers, and either there was a change in management or an underbaked strategy. Or, the Good Idea Fairy is paid by the hour!

References

El Mola, K. & Parsaei, H. (2010). Integrated performance measurement systems: A review and analysis. The 40th International Conference on Computers & Industrial Engineering, Awaji, Japan, 2010, pp. 1-6. https://doi.org/10.1109/ICCIE.2010.5668237

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Parast, M. M., Safari, A., & Golgeci, I. (2024). A comparative assessment of quality management practices in manufacturing firms and service firms: A repeated cross-sectional analysis. IEEE Transactions on Engineering Management, 71, 4676-4691. https://doi.org/10.1109/TEM.2022.3221851

Change Management Strategy for Converting to Total Quality Management

Introduction

This post follows the steps needed for a company to transition in a total quality management (TQM) operation as outlined in Goetsch & Davis (2021). We begin by listing some of the factors that determine the success of a TQM conversion, and some alternative implementation plans. Next, the implementation process recommended by Goetsch & Davis – the Goetsch-Davis 20-Step Total Quality Implementation Process – is described. The paper concludes by describing situations and alternatives when management is lacking commitment to TQM.

Success of Implementing TQM

No two implementations of TQM are the same, and the success depends on several factors. Mann & Kehoe (1993) list several factors besides management buy-in. These factors include the employees’ age distribution, their education level, whether the management uses long term planning, and so on. There are also different approaches to implementing TQM, as described in (Yusof & Aspinwall, 2000, p. 642), which range from companies not implementing TQM all at once, to implementing it on a department-by-department basis. The Goetsch-Davis 20-Step Total Quality Implementation Process described next requires a top-down commitment to TQM throughout the entire company. There is room for adjusting the pace of adopting TQM (determined with the choice of projects deemed fit for “TQM-ization”), but the process is meant to be total.

Implementation According to the Goetsch-Davis 20-Step Process

Goetsch & Davis (2021) utilize a three-phase process for implementing TQM. These phases are preparation, planning, and implementation. The details of these phases follow the Goetsch-Davis 20-Step Total Quality Implementation Process (Goetsch & Davis, p. 419-423).

Preparation

As the implementation of TQM is a top-down process, preparation begins with the top executive (CEO for example) becoming committed to TQM. He then forms a Total Quality Steering Committee consisting of the CEO’s direct reports and with the CEO chairing the committee. If a union is involved, the senior union member is also included in the steering committee. This committee is a permanent entity and replaces the former executive staff organization. With the help of a consultant, they engage in team building and get training in TQM’s philosophy, tools, and techniques.

Control then moves to the total quality steering committee. They begin by creating statements of “vision” and guiding principles. Based on those documents they set broad strategic objectives. Next, they communicate and publicize the statements and their plans, and this communication is an ongoing activity by the steering committee.

The steering committee then identifies organizational strengths and weaknesses – why wasn’t that done earlier? As part of this, they identify TQM advocates and TQM resisters. One of these groups of employees could be added to project teams created during the planning phase (guess which one?)

The steering committee will then establish baselines for employee satisfaction and attitudes (performed by the HR department), as well as baseline customer satisfaction. For large customer bases, satisfaction can be determined by using sampling. Customer feedback must include both extremal and internal customers.

Planning

At this point, the steering committee can enter the planning phase! The approach they should use follows the PDCA (Plan-Do-Check-Adjust) cycle, so it may be necessary to return to this step based on the results of what follows. For reference, this is step 12.

The steering committee identifies projects that are amenable (or vulnerable) to adopting TQM. One of the determining factors for the initial choice of projects is the likelihood of success. Teams for each project are appointed. These teams can be cross-departmental, and it is handy to know who the TQM advocates are (Goetsch & Davis, p. 422). The project teams are then trained on TQM principles by members of the steering committee. Finally, teams’ direction is set, and they are activated, each starting their own PDCA cycle.

Implementation or Execution

The project teams then lead the implementation or execution phase. They gather feedback from the team members, the customers, and the employees and report their findings back to the steering committee, perhaps on a monthly basis. (Goetsch & Davis, p. 422) This is the “check” stage of the PDCA loop, and the steering committee makes appropriate adjustments, returning to step 12.

The steering committee modifies organizational structure, procedures, and processes, as necessary. They also implement reward or recognition systems. Finally, union rules are considered.

Conclusion

By following these steps, it should be possible to have a company or organization adopt TQM. If there is no commitment from top management on total quality, then it may be possible to “sell” TQM to them, but…

If enlightenment does not work, it may be time to consider moving on to different employment. That is not always a reasonable option, but long-term prospects for your current employment are not bright either, given top management’s attitude toward total quality. (Goetsch & Davis, p. 423)

Yup, enlightenment.

It also may be possible to implement TQM within a single department. Department total quality is a contradiction since TQM requires commitment from every aspect of the company, but Goetsch & Davis (p. 424) note that this is better than nothing.

For companies with management not committed to adopting TQM, there are other courses of action that can get a company close to using TQM: pursuing ISO 9000 certification and competing for the so-called Baldrige Award.

References

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Mann, R., & Kehoe, D. (1995). Factors affecting the implementation and success of TQM. International Journal of Quality & Reliability Management, 12(1), 11-23. https://coer.org.nz/wp-content/uploads/2011/09/D22_Factors_affecting_the_implementation_and_success_of_TQM.pdf

Yusof, S. R. M., & Aspinwall, E. (2000). TQM implementation issues: review and case study. International Journal of Operations & Production Management, 20(6), 634-655. https://coer.org.nz/wp-content/uploads/2011/09/D22_Factors_affecting_the_implementation_and_success_of_TQM.pdf

Just-In-Time and Lean Strategies

Introduction

This post discusses the relationship between Just-In-Time (JIT) manufacturing and Lean strategies. We begin by (trying to) define each of these separately, then examine how they work together as JIT/Lean. Next, the relationship between JIT/Lean and total quality management (TQM) is discussed. We conclude by noting that while JIT/Lean strategies seek to advance the goals of TQM, it does not advance all the goals of TQM.

Just-In-Time Manufacturing

Just-In-Time (JIT) manufacturing is a production strategy that minimizes waste by ordering and producing goods on an as-needed basis, directly in response to customer demand. JIT manufacturing is a pull system, so there is no need to rely on forecasts (which is a push system). There is little or no inventory holding costs since production is triggered only when the customer demands it. Besides low inventory holding costs, one of the other advantages to requesting parts only as needed, there is reduced risk of waste in the forms of spoilage (in the case of perishable goods) or obsolescence (for manufactured goods).

Lean Manufacturing

Like JIT, Lean manufacturing is also concerned with reducing waste, but on a broader scale. Goetsch & Davis (2021, p. 377) state that there are seven types of waste that Lean manufacturing seeks to minimize:

Overproduction
Wait time
Transportation costs
Processing
Inventory
Unnecessary motion
Product defects.

These include wastes not strictly covered by JIT, in particular transportation costs and unnecessary motion.

Comparing the Strategies

It makes sense to combine these two manufacturing philosophies, as they were both invented by Taiichi Ohno (1912 - 1990). As Ohno was employed at Toyota Motor Corporation, the system was initially called the Toyota Production System (TPS) and was seen as an alternative (or refinement) of Henry Ford’s mass production system. As it spread to other industries, it gained the name Lean manufacturing.

Goetsch & Davis do indeed combine JIT and Lean manufacturing, calling it JIT/Lean, which they roughly define as follows:

Just-in-time/Lean is producing only what is needed, when it is needed, and in the quantity that is needed. (p. 376)

This definition doesn’t include the full scope of Lean manufacturing, however.

Combining JIT/Lean with Total Quality Management

JIT/Lean manufacturing integrates well with total quality management (TQM) manufacturing. In particular, by minimizing the production of defective goods, companies following JIT/Lean are concerned with increasing the quality of their goods. Since the system operates only in response to customer demand, product defects are identified early and corrected. Finally, since the JIT/Lean operates as a pull system, it is inherently concerned with customer satisfaction.

This is essentially the conclusion of Cua, McKone & Schroeder, (2001). They combine TQM and JIT together and find that they are compatible with each other as well as with something called Total Productive Maintenance (TPM).

Tesfaye & Kitaw (2017) claim that integrating TQM and JIT are insufficient to guarantee organizational success and requires “interaction between the core company and the external stakeholders (such as governmental organizations, universities, banks, research institutions, and others)” as well as what they call “technological capability accumulation.” This latter refers to transferring and adopting knowledge into the company instead of being “just passive receivers and users of foreign technologies.” (Tesfaye & Kitaw, 2017, p. 22).

The research by Tesfaye & Kitaw (2017) focused exclusively on Ethiopian leather and leather manufacturing companies, but the lack of technological capability accumulation occurs in other industries, even in software companies. Software and IT companies “burn through” technologies at an incredible rate, caused by employee turnover as well as the idea of rejecting older technologies in favor of adopting “the new hotness.”

Conclusion

JIT and Lean are both strategies that improve manufacturing processes. Both are concerned with eliminating waste in such processes, with JIT concerned with minimizing inventory holding costs and minimizing costs that result from spoilage and obsolescence. Lean improves on this by minimizing additional types of waste such as wait times and transportation costs.

JIT/Lean brings the benefits of TQM – improved quality and focus on customer satisfaction – but only to production departments. Companies practicing TQM require continual improvement and customer focus of all departments of a company, whereas JIT/Lean is applicable to production departments. As such, JIT/Lean works well with TQM, but it is distinct from TQM.

References

Cua, K., McKone, K., & Schroeder, R. (2001). Relationships between implementation of TQM, JIT, and TPM and manufacturing performance. Journal of Operations Management 19(6), 675-694. https://doi.org/10.1016/S0272-6963(01)00066-3

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Tesfaye, G. & Kitaw, D. (2017). A TQM and JIT integrated continuous improvement model for organizational success: An innovative framework. Journal of Optimization in Industrial Engineering 22,15-23. https://doi.org/10.22094/joie.2017.265

ISO 9000 Standards

Introduction

Why would a company choose to implement ISO 9000 standards versus a quality management concept? This post attempts to answer that question, We start by first describing the ISO 9000 family of standards. Next, ISO-9000 standards will be compared and contrasted with the total quality management (TQM) philosophy. One of the differences between ISO 9000 and TQM is that the former has costs associated with certification, and the costs are (roughly) described. Finally, the question is answered considering this information.

What are the ISO 9000 Standards?

The International Standard Organization (ISO) maintains numerous formalized standards of which ISO 9000 is meant to standardize the approach organizations use to manage and improve processes. Some of these are industry-specific whereas others, like the ISO-9000 family of standards are quality related, but are limited to internal measures of quality. Indeed, “ISO 9000 does not specify a level of quality or performance for any product or service provided by an organization. That is left to the organization to determine with its customers” (Goetsch & Davis, p. 226). This latter part is a good thing, otherwise every single change or improvement in a product or service will have to be evaluated by a committee external to the organization.

ISO 9000 has gone through several versions, with varying amounts of bureaucracy in each version (Goetsch & Davis, p. 235). Besides reducing bureaucracy, the advancing iterations brought ISO 9000 (specifically ISO 9001:2000) standards closer to TQM (Goetsch & Davis, p. 235). Seddon (2000) claims that ISO 9000:2000 represents “an admission of failure – failure of the Standard to make a positive contribution to economic performance” (Seddon, p. vii).

The ISO 9000 series uses seven quality management principles: customer focus, leadership, personnel engagement, process approach, improvement, evidence-based decision making, and relationship management (Goetsch & Davis, p. 227).

The operating principle of the ISO 9000 management system is described as “Plan-Do-Check-Act.” “Plan” involves setting objectives and determining plans to achieve them. “Do” means setting those plans in motion. “Check” means to verify whether the objectives are achieved using those plans. Finally, “Act” (or “Adjust”) means that the organization makes necessary changes to the plans to correct any shortfalls, then wash-rinse-repeat. (p. 227). The text states that repeating these steps results in “continual improvement for products/services, processes, and systems of processes.” (Goetsch & Davis, p. 227). The ongoing improvement of products or services is (supposedly) a byproduct of the Plan-Do-Check-Act cycle.

Part of obtaining ISO 9000 certification involves creating and using a quality management system (QMS). This is not necessarily a software system but it certainly a process designed to maintain quality and customer satisfaction. The certification and annual verification can be thought of as a check that the QMS is used and is well-functioning.

Comparing ISO 9000 with TQM

Both TQM and ISO 9000 aim to enhance the quality of the products and services an organization offers to meet or exceed customer expectations. Both emphasize customer satisfaction by ensuring consistent quality and meeting their requirements.

Both require commitment from management and employees to implement the quality practices, and both encourage ongoing efforts to refine processes and enhance quality over time.

Contrasting ISO 9000 and TQM

TQM is a management philosophy that integrates quality into all processes within an organization. It emphasizes continual improvement and customer satisfaction and requires cultural change. Meanwhile, ISO 9000 is a family of international standards for quality management systems (QMS) that focus on documented processes and certification.

As mentioned above, TQM is concerned with continually improving the quality of an organization’s products or services. ISO 9000 focuses on the quality of internal processes.

One of the differences between ISO 9000 and TQM is that ISO’s process approach involves risk-based thinking, and tools like the Plan-Do-Check-Act cycle are meant to reveal such risks.

TQM is broader than ISO 9000 and it covers all aspects of an organization including culture, employee engagement, and leadership. ISO 9000 focuses on establishing a standard QMS to ensure consistency in processes.

There is no timeframe of implementing TQM in an organization because its mandates are not only process-related but also cultural. There is no fixed endpoint since continual improvement is a never-ending process. In contrast, ISO 9000 has some sort of deadline since the organization is seeking certification.

TQM are informal standards, so the cost of adopting it within an organization usually involves training and process redesign costs, but there are no formal certification expenses. With ISO 9000, there are costs for certification, audits, and recertification. These are discussed in the next section.

Cost of ISO 9000 Certification

A quick review of the ISO 9000 family website (International Standard Organization, n/d) does not list prices for the certification processes. Indeed, ISO charges for much of its documentation.

The phases of ISO 9000 or 9001 certification are as follows: initial certification, annual surveillance audits, and re-certification audits performed every three years. There are numerous ISO consultants or, as one consultant website (BRP Hub, n/d) calls them, “accredited certification bodies” and presumably their prices vary.

For small businesses, BPR Hub quotes prices for certification body fees for small businesses in the range from $3,000 to $6,000. Consultant fees are from $300 to $1,000 per hour. The annual audit costs are at $500 to $1300 per day. For the annual surveillance audit, the price is from $1,000 to $2,500 per year. For the re-certification process that occurs every three years, no prices are given. Another consultant site (9000 Store, n/d) also doesn’t list re-certification costs; that website does have similar quotes broken-down by company size as well as the current state of the organization’s QMS.

Conclusion

TQM and ISO 9000 are not mutually exclusive, and ISO 9000 is a formalization of some parts of TQM standards. TQM is focused on maintaining and improving the quality of products and services a company provides, whereas ISO 9000 is concerned with standardizing internal processes.

They are both bureaucratic layers, and one of the differences between them is that companies seeking ISO certification pay money for their own bureaucratic self-strangulation. It makes sense for a company to achieve ISO 9000 certification if and only if its customers or potential customers (such as government bodies) require that certification. The decision to seek ISO 9000 certification comes down to a cost-benefit analysis, and the annual surveillance audits are a good opportunity to reconsider that decision.

References

9000 Store. (n/d). Cost of ISO 9001 certification. https://the9000store.com/articles/iso-9000-cost/

BRP Hub. (n/d). ISO 9001 certification cost for small businesses. https://www.bprhub.com/blogs/iso-9001-certification-cost-for-small-businesses

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

International Standard Organization. (n/d). ISO 9000 family. https://www.iso.org/standards/popular/iso-9000-family

Seddon, J. (2000). The case against ISO 9000. Oak Tree Press. https://archive.org/details/caseagainstiso900000sedd

Hierarchy of Communication Channels

Effective communication is a requirement in a total quality management (TQM) organization. Fundamentally, communication is necessary to maintain the delivery of quality products and services as well as continually improving those products and services (Goetsch & Davis, 2021, p. 163-166).

In a team context, effective communication is necessary to set clearly defined objectives and expectations. Like Albuali (2021) states, “[r]unning a successful project needs various effective strategies for managing communication between upper and lower level employees.”

Albuali (2021) goes on to divide a hierarchy of communication channels: high-level, low-level, and moderate-level. High-level channels are basically in-person or by phone: face-to-face, department meetings, or phone conversations. A low-level channel is a quarterly meeting or a written memo. Moderate-level communication channels include email and intranet chat, and this provides a level of effective communication that is needed in many situations.

It is crucial for project managers and team leaders to choose the appropriate channel: using a high-level channel for each and every communication results in the message becoming noise; using low-level communication for important information can result in that information being missed.

This is not to say moderate-level communication channels are best: email can be sent to the “spam” folder after all. Being a written form of communication, the sender can inadvertently send ambiguous information. There is one value to emails that is not frequently mentioned: emails can be used for business process discovery.

In a 2012 paper, Stuit and Wortmann hit upon the idea of mining the data contained in emails so as to find patterns in human collaboration. These patterns can be interpreted as evidence for business processes. The method Stuit and Wortmann (2012) used involves not only looking for common sender-recipient pairs and dates, but also considers email threads and “boilerplate” messages. This information is collected by a tool called “E-mail Interaction Miner” (EIM) which discovers collaboration patterns.

Stuit and Wortmann evaluated this on the operator of the national gas transmission grid in the Netherlands, Gasunie Transport Services Inc. (GTS). In 2008, GTS allowed them to run EIM on a subset of their email messages relevant to a delayed IT project at GTS. Stuit and Wortmann were able to trace the history of this project, amd they were able to provide “GTS with actionable managerial insights that can initiate improvements in the interaction structure and resource planning of future infrastructural projects.”

GTS knew that their IT project was delayed, but they did not know why it was delayed. EIM was able to identify the sources of the delays, which can be used to improve the next IT project. Software, in this case EIM, thus participated in achieving one of the goals of TQM: continuous process improvement.

References

Albuali, M. (2021). Effective Strategies for Managing Communication in a Project. International Journal of Applied Industrial Engineering (IJAIE), 8(1), 1-6. https://doi.org/10.4018/IJAIE.20210101.oa1

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Stuit, M. & Wortmann, H. (2012). Discovery and analysis of e-mail-driven business processes. Information Systems, 37(2), p. 142-168. https://doi.org/10.1016/j.is.2011.09.008

Trust and Team Dynamics

Creating a well-functioning team is an exceedingly difficult endeavor that requires common purpose, leadership, organization, clearly delineated roles, communication, and, most importantly, trust (Goetsch & Davis, 2021, p. 147-151). Sometimes, something can go wrong along the way.

When a team was well-functioning at one point and then later fell apart, there was definitely a failure of leadership. One of the things a good leader does is to keep his team members engaged in the project. If a team member disappears or otherwise “checks out,” the leader must figure out why this happened and pull the team member back in. This is not only for that wayward team member’s benefit but also for the overall success of the project (mission).

Pulling a team member back into a project is not an easy task! At some point, trust was broken, and it must be rebuilt.

The importance of trust cannot be underestimated. Soderberg and Romney (2022) state that trust is “the glue that holds human associations together.” This applies not only to single teams, but organizations, communities, and indeed whole societies. Wike & Holzwart (2008) note that “[h]igh levels of social capital and social trust have been linked to any number of positive social outcomes, including low crime rates.” Wike and Holzwart were analyzing a major political event – the fall of communism – but the same principles apply at all levels, including small teams.

Soderberg and Romney (2022) are concerned with establishing trust. They find that authentic and proactive behavior are crucial characteristics of leaders. They also find that they must “demonstrate humility in their communication” and that they should exhibit “compassion in their behavior.” Their findings are based on research at assisted-living care facilities, however.

So, how to rebuild trust once it has been lost? Schniter, Sheremeta, and Sznycer (2012) conducted research on this topic, and they identify three remedial strategies. First, the “offender” (Schniter et al’s word) should recognize that trust has indeed been broken, and then apologize. Second, the offender should persuade and assure “victims” (again, their word) that they are valued and promise to act trustworthy in the future. Finally, the offender must be willing to pay a cost, somehow.

Schniter et al’s work was conducted through what they call “trust games.” In these games, “trustees made non-binding promises of investment-contingent returns, then investors decided whether to invest, and finally trustees decided how much to return. After an unexpected second game was announced, but before it commenced, trustees could send a one-way message.” Their conclusions were based on the contents of that one-way message along with the actions the investors took after receipt of that message.

Schniter et al do consider the value of the harm caused by the offender. Their experiments involved playing two rounds of this game, and it was found that repeated trust-breaking resulted in a considerably less chance in reestablishing trust (Schniter et al, p. 28).

It's not clear whether this economic model is applicable to team dynamics. It is interesting how far apologies and promises go to rebuilding trust, however.

References

Goetsch, D. L., & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Schniter, E., Sheremeta, R., & Sznycer, D. (2012). Building and rebuilding trust with promises and responsibilities. Economic Science Institute Working Paper. https://digitalcommons.chapman.edu/cgi/viewcontent.cgi?article=1069&context=esi_working_papers

Soderberg, A. & Romney, A. (2022). Building trust: How leaders can engender feelings of trust among followers. Business Horizons 65(2), 173-182. https://doi.org/10.1016/j.bushor.2021.02.031

Wike, R. & Holzwart, K. (2008, 15 April). Where trust is high, crime and corruption are low. Pew Research Center. https://www.pewresearch.org/global/2008/04/15/where-trust-is-high-crime-and-corruption-are-low/

Training Needs Analysis

Introduction

Training is the transfer of job-specific knowledge that is or will be crucial for an employee’s current or upcoming position at the company. As Goetsch & Davis state, “[T]raining is an organized, systematic series of activities designed to enhance an individual’s work-related knowledge, skills, and understanding or motivation. (p. 180)” Training is different from education in that the former should have immediate relevancy to an employee, whereas education is more general. All training is education, but not vise-versa.

For a company that practices total quality management (TQM), it is necessary that employees have the knowledge to perform the required skills at a world-class level. Further, because total quality companies will frequently redesign their processes and workflows to become more efficient, frequent retraining will be necessary.

For this post, we will consider a situation that frequently arises at software companies of all sizes: recent computer science graduates who lack experience with the tools of their profession. We will identify the needs, devise a quick training program, discuss delivery methods, and evaluate the results.

Needs Analysis

A training needs analysis is necessary in three circumstances: a new employee is hired, an existing employee moves to another position, or there is a change in process or workflow to improve the quality of some product or service. The hiring of a new employee is considered in this post.

Training needs are determined by comparing the knowledge and skills required for a job with the knowledge and skills an individual possesses. The knowledge and skills requirements for a job should be well known to managers or team members, so to determine training needs, we must determine the employee’s actual knowledge and skills.

Reviewing an employee’s CV to determine this gap is insufficient, since there may be “padding.” Goetsch & Davis list several alternatives of finding the missing skills. One way is to simply ask the employee – the perceived need to “pad” is reduced since the person is already an employee. A more bureaucratic approach is to perform a “job task analysis survey” (p. 186).

In software companies regardless of size, it is sufficient to just ask the employee. With larger companies, depending on organization, multiple training events may be scheduled. These would be better than one large training event because the employees will have a chance to practice their skills on the software their team is developing.

Specific Training

A frequent problem managers will encounter with recent computer science graduates is that they do not know how to use fundamental software tools used in the profession.

Computer science (CS) degrees (either undergraduate or graduate) tend to be extremely theoretical and math heavy. Many important tools used by professional developers, such as those for remote computer control, for saving different versions of code, for running other people’s code in a secure manner, etc., are simply not taught to recipients of CS degrees.

Fortunately, there are numerous online tutorials explaining how to use all those tools. The best learning material comes from an MIT class called “The missing semester of your CS education.” Developed by Anish Athalye, Jose Javier, and Jon Gjengset of MIT, it includes videos, presentations, and worksheets that are perfect for closing this skills gap (Athalye et al, 2020).

Delivering the Training

Goetsch & Davis give three options for delivering the training: internal, external, and partnership (p. 188). Each has advantages and disadvantages, but one approach has considerable strengths that the other two lack.

External training requires hiring a separate company that provides training. For the skills gap under consideration, this will be overkill, especially if the number of trainees is small.

Partnerships involve the company joining forces with a university or community college to provide the training. The advantages to this approach are that they have experienced instructors, prepared training materials, and classrooms or computer labs already set up. This arrangement is also overkill for small groups of employees.

One situation where either partnerships or external trainers would not be overkill is when, say due to restructuring, an entire team is lost without adequate time to transfer knowledge to the new employees. In that case, a whole new team must be trained, and there would not necessarily be a clear internal trainer.

One major disadvantage to partnerships and external agencies is that they would have access to the company’s intellectual property. Non-disclosure agreements (NDAs) would have to be signed, but it is easy for external agencies or university partnerships to skirt the NDAs.

For these reasons, internal training would usually be best, especially if the number of employees requiring training is small, say under six. The training can be provided either by a team lead or a developer on that team. There are several advantages to doing internal training. First, such training is mentorship, thereby a team-building event. Also, no NDAs would have to be signed. Finally, the new employees can be practicing their skills on the projects for which they will be responsible after training is complete.

Steinmacher et al (2021) note that in large open-source projects, one of the problems of mentoring is that the mentor has difficulty in identifying appropriate tasks for the newcomer. This problem should not occur in the situation where the mentoring is done by a member of the same team to which the newcomer will belong.

Evaluating the Training

There is no quick and reliable way of evaluating the success of the training because those software developer tools, in a sense, rely on “muscle memory.” The proper way of determining the success of the training is simply to observe the new employee and watch how he uses the tools. Once the employee has learned the tools, his increasing proficiency should become obvious.

Conclusion

Using an internal mentor approach to enable recent computer science graduates to use the tools of their profession offers the opportunity to build camaraderie and teamwork while ensuring that the new employee can fulfill his responsibilities. Intellectual property will be protected because the training is done internally. By relying on internal training, the new employee can practice learning his skills on the very projects he will be tasked with maintaining. This doubles the training, for the new developer will become familiar not only with the appropriate tools but also the projects that will become his responsibility.

References

Athalye, A. et al. (2020). The missing semester of your CS education. MIT. https://missing.csail.mit.edu/

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Steinmacher, I. et al. (2021). Being a Mentor in open source projects. Journal of Internet Services and Applications 12(7). https://doi.org/10.1186/s13174-021-00140-z

Successful Communication in a Quality Project

Introduction

This post covers the range of factors required for successful communication of a quality project. The discussion here mostly follows Goetsch & Davis (2021) except for the last section.

Communication and Effective Communication

Goetsch & Davis defines communication as follows: “Communication is the transfer of a message (information, idea, emotion, intent, feeling, or something else) that is both received and understood” (p. 162). This covers verbal, nonverbal, written, and other forms of communication.

According to the text, receiving and understanding a message is not sufficient for effective communication. The message must then be acted upon by the recipient in the desired manner, thus effective communication may require persuasion, motivation, monitoring, and leadership on the part of managers.

Effective communication is essential in a total quality environment, as focusing on customer needs requires communication of those needs. Other aspects of total quality management (TQM) that depend on effective communication include leadership, teamwork, conflict resolution, and employee empowerment. “The role it plays is facilitation.” (Goetsch & Davis, p. 164).

Traditional Forms of Communication

The text covers aspects of medium-specific communications such as verbal and written communication.

Written communication is best for when a permanent record is needed, and when the message needs to be clear and concise. For communicating in writing, the text recommends that the message should be (Goetsch & Davis, p. 172-174) well-planned, brief, direct, accurate, and should be edited for spelling, grammar, and clarity. Another reason for using the written medium is for situations when a list of requirements or instructions must be transmitted; this is done not only for accuracy but also as a courtesy to the recipient.

According to Goetsch & Davis, during verbal communication, either face-to-face or via telephone, the manager should show interest, be friendly, flexible, tactful, and courteous (p. 171). It is also important for managers to ask questions effectively (p. 172), which involves dropping defenses, stating your purpose, using open-ended questions, phrase questions carefully, and acknowledging emotions. These last two recommendations are questionable, however. Being overly sensitive or emotionally fragile has no place in any organization, whether it practices TQM or not.

There are also nonverbal communication factors ranging from posture, tone, facial expressions, and even the color of the room or the environment (Goetsch & Davis, p. 170). These nonverbal factors can carry information such as the relative importance of specific thoughts or sentences.

Video Conferencing

A form of communication not mentioned in Goetsch & Davis is video conferencing, which is common in companies with remote workers or with globally dispersed organizations. Video conferencing has many of the advantages of face-to-face communication, but it lacks many nonverbal communication factors.

The 1988 paper by Edigo notes that videoconferencing dates to the 1960s, but describes it as a failure, stating that it is not a substitute for face-to-face meetings, and there is a lack of real utility for a video capability. A more recent paper by Karis et al (2016) shows the increased popularity that video conferencing has gained in various industries including Google, Inc. The main weakness of this form of communication, according to that paper, is the early state of tools enabling collaboration. The tools they explicitly mention as promising are Google Docs, e-mail, and instant messaging. Of course, the rise in globalism and COVID-19 has made video conferencing a very practical option.

Conclusion

Effective communication is essential in a total quality environment, as it facilitates the clear transfer of messages and fosters collaboration. Traditional forms of communication, such as written and verbal methods, remain vital for their clarity, permanence, and ability to convey nuanced information through nonverbal cues. In response to globalization and COVID-19, video conferencing is now indispensable in modern organizations. By using these communication methods, managers can ensure that customer needs are met, teamwork is enhanced, and quality products and services are delivered.

References

Egido, C. (1988). Videoconferencing as a technology to support group work: A review of its failure. In Proceedings of the 1988 ACM conference on Computer-supported cooperative work, 13-24. https://dl.acm.org/doi/pdf/10.1145/62266.62268

Goetsch, D. L., & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Karis, D. (2016, 1 January). Improving remote collaboration with video conferencing and video portals. Human-Computer Interaction, 31(1), 1-58. https://doi.org/10.1080/07370024.2014.921506

Authority and Leadership

Authority is a necessary part of leadership, but there are many shades to that latter word! “Authority” can mean technical expertise, or it can be a general moral trait, or a position determined by one’s place within a hierarchy. These three aspects can come into conflict.

Take for example technical expertise vs hierarchical position. Say you have a highly skilled engineer (technical expert) who has innovative ideas to solve a critical problem. But a manager higher in the organization, who lacks the same level of technical knowledge, may override the engineer’s recommendations due to his positional authority. Hierarchical authority is often tied to decision-making power, while technical expertise is based on specialized knowledge. When positional authority disregards expertise, it can lead to inefficiency or errors, as decisions may not reflect the best technical judgment.

For technical expertise vs moral authority, suppose you have a person with deep technical knowledge who proposes a solution that is effective but ethically questionable, clashing with someone whose authority stems from moral integrity. The conflict arises because technical expertise focuses on what is possible, while moral authority emphasizes what is right. These priorities diverge when technical goals overlook ethical implications.

For moral authority vs hierarchical position, consider a leader in a high-ranking position who issues directives that conflict with the convictions of someone seen as a moral authority within the organization. This situation describes the situation that whistle blowers find themselves in. Hierarchical authority implies a chain of command, while moral authority stems from trust and ethical reputation. When the person with moral authority challenges the leader in a high-ranking position, this is seen as a challenge which undermines the chain of command.

It is easy to imagine a situation where all three come into conflict. For example, imagine a highly skilled surgeon (technical authority) recommends a risky procedure to save a comatose patient. A hospital administrator (hierarchical authority) is opposed to the procedure for reasons of liability, and an ethics committee member (moral authority) argues against the procedure on grounds of patient consent. The options in this case are either to negotiate or to seek a compromise.

In military situations, the moral vs hierarchy authority conflict is almost always resolved because morally, everybody is in agreement on the rightness of the mission (Hlad, 2013). If not, there are options for one who has moral reservations about the correctness of the mission (Kilner, 2023). When technical authority comes into conflict with hierarchy-based authority (rank), the person with rank evaluates the technical authority’s recommendation against the mission and usually says “go ahead and cook.”

In Total Quality Management (TQM), where continuous improvement, collaboration, and ethical decision-making are paramount, moral authority emerges as a critical pillar of effective leadership. TQM emphasizes not only technical excellence and structured processes but also a commitment to ethical principles that foster trust, integrity, and long-term organizational success (Goetsch & Davis, 2021, p. 53).

The resolution of conflicts among these forms of authority—whether through negotiation, compromise, or ethical prioritization—requires leaders to recognize the unique value of moral authority. In business settings, where competing priorities and stakeholder interests often complicate decision-making, moral authority provides a unifying framework that aligns technical and hierarchical efforts with ethical standards.

References

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Hlad, M. (2013, 16 April). Moral fitness: Ethical education for Marines. Marine Corps University. https://apps.dtic.mil/sti/pdfs/ADA603799.pdf

Kilner, P. (2023). Mitigating moral injuries through proactive, ethical leadership. Military Review. https://www.armyupress.army.mil/Journals/Military-Review/Online-Exclusive/2023-OLE/Kilner/

A Note on Culture and Leadership Style

The U.S. Army is empowering its soldiers with mission command: by requiring and rewarding initiative, trust and loyalty is engendered, just as it is in organizations practicing Total Quality Management (TQM) (Goetsch & Davis, 2021, p. 52). Obviously, bureaucracy is still present and it is now clear how initiative and bureaucracy can coexist.

It is interesting to compare this organizational culture with other military cultures that result in two diametrically opposed leadership styles: centralized control and Auftragstaktik, which is practiced by the German military as well as various self-defense forces.

Russia still clings to rigid, a top-down command style rooted in centralized control. As explained in (Bowen, 2024), "the Russian military continues to operate with a Soviet-style centralized command. This command style at the tactical level often has contributed to the types of inflexible operations that contributed to previous failures and casualties."

Former USSR satellites such as Ukraine maintain a similar approach. Oleksandr Syrskyi, the current Commander-in-Chief of the Armed Forces of Ukraine, has a "preference for a tightly controlled leadership structure that favors loyalty and personal closeness over purely professional criteria" (n.a., 2024).

The consequences of this centralized command were demonstrated in Russia’s annexation of Crimea in 2014: interviews (VICE News, March 22, 2014) with Ukrainian sailors (VICE News, March 16, 2014) showed them to be demoralized and directionless when one of their commanders defected to Russia and the government in Ukraine was in disarray.

The opposite of this is mission command or what the Germans call Auftragstaktik (Widder, 2002). These two styles of command are not the same, but in both, the commander specifies the mission and timeframe, and the way to accomplish this is left to the individual troop's initiative. Vandergriff (2018) gives a more comprehensive description of Auftragstaktik – instead of focusing on command and control, he describes it primarily as a form of professionalism and cultural philosophy expected of all members of the German Army: “subordinates could be trusted to take the action he thought appropriate, rather than stopping and waiting until contact could be re-established. This aggressive attitude allowed units to take advantage of fleeting opportunities and local successes.”

Vandergriff (2018) goes on to identify three virtues that German officers required: “knowledge, independence, and the joy of taking responsibility.” These virtues are expressed in Innere Führung, which the German Major General Werner Widder (2002) describes as leadership and civic education and is the foundation of the relationship between the individual soldier and society.

Thus, Vandergriff’s virtues not only describe the character of German officers but makes Auftragstaktik a natural corollary instead of a forced doctrine: German professionalism implies mission command, but not necessarily the reverse.

Self-defense forces have adopted Auftragstaktik out of necessity: their members are not professional warfighters, and they sometimes operate out of contact with their leaders for extended periods of time. In the absence of orders, the individual knows what to do: locate, close with, and destroy the enemy, and break his stuff. This is the exact opposite of what the Ukrainian sailors were doing.

The relation of culture and supporting leadership style in corporations parallels that in military or semi-military organizations: cultures of trust imply certain types of leadership styles, and when there is no trust, another leadership style is needed. The major difference between the corporations and the military organizations is the price for getting the culture and consequent leadership style wrong, and the speed at which that price is paid.

References

Bowen, A. (2024). "Russian Military Performance and Outlook." Congressional Research Service. https://crsreports.congress.gov/product/pdf/IF/IF12606

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

n.a. (2024). "Oleksandr Syrskyi shifts Ukrainian military leadership to vertical approach." New Voice of Ukraine. https://english.nv.ua/nation/new-ukraine-s-armed-forces-chief-changed-the-command-process-of-the-army-50431480.html

Vandergriff, D. E. (21 June 2018). “How the Germans defined Auftragstaktik: What mission command is – and – is not” Small Wars Journal. https://archive.smallwarsjournal.com/index.php/jrnl/art/how-germans-defined-auftragstaktik-what-mission-command-and-not

VICE News. (2014, March 16). Ukrainian Troops Speak Out: Russian Roulette in Ukraine [Video]. YouTube. https://www.youtube.com/watch?v=GH3HGvZlhhk

VICE News. (2014, March 22). Taking over a Ukrainian Base: Russian Roulette in Ukraine [Video]. YouTube. https://www.youtube.com/watch?v=tBLs_AsBtjg

Widder, W. (2002). “Auftragstaktik and Innere Führung: Trademarks of German leadership” Military Review, September-October 2002. https://www.armyupress.army.mil/Portals/7/Hot-Spots/docs/MC/MR-Sep-Oct-2002-Widder.pdf

TQM and the Four Olds

Leadership in Total Quality Management (TQM) involves inspiring individuals to pursue excellence within a motivating environment that fosters trust, commitment, and shared values (Goetsch & Davis, 2021). Followership is cultivated through voluntary engagement, requiring leaders to demonstrate authenticity, clear communication, and accountability to build an environment that encourages initiative and teamwork.

TQM can be extended in several ways. One, advocated by Dean and Bowen (1994) involves integrating technical systems (statistical process control, quality verification, etc.) with social systems (people, relationships, and culture). Dean and Bowen seem to imply informal means of developing employees and building trust such as through coaching, mentoring, and employee recognition. This fosters loyalty and effort – in other words, it builds followership. Dean and Bowen also assert that leadership must be theory-based and value-driven, rooted in principles like customer focus and teamwork. This makes expected organizational norms parallel the requirements of total quality norms.

Another way of extending TQM is to emphasize the importance of creating an organizational culture open to change, innovation, and learning. This critical dimension was advocated by McNabb and Sepic (1995) as another way of building a loyal following. The environment that McNabb and Sepic conducted their study, the public sector, is not exactly known for change and innovation, but there is a culture of learning.

All this may seem like a good thing, until McNabb and Sepic pull back the curtain:

Western managers have a model of thing based on individual-oriented motivation, conflict and competition with one’s peers, and autocratic controls for containing costs. Consequently, TQM cannot take root in the culture of an organization of until old values are changed and new values are built into the underlying structure. (McNabb & Sepic, p. 381)

Failures when adopting TQM are not failures of management but “they may be attributed to deeper, more critical sources: the fundamental, persuasive culture of the organization and the operating climate the culture the instills in its employees.” (McNabb & Sepic, p. 369)

In many ways, this is reminiscent of the “Four Olds,” the cultural elements to be destroyed during the Chinese Cultural Revolution – old ideas, old culture, old customs, and old habits (Durdin, 1971).

One must then ask McNabb and Sepic just how far they are willing to go to achieve total quality goals in environments resistant to change?

References

Dean, J. W. & Bowen, D. E. (1994). Management theory and total quality: Improving research and practice through theory development. The Academy of Management Review, 19(3), 392–418. https://doi.org/10.2307/258933

Durdin, T. (1971, 19 May). China transformed by elimination of the ‘four olds.’ New York Times. https://www.nytimes.com/1971/05/19/archives/china-transformed-by-elimination-of-four-olds.html

Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

McNabb, D. E. & Sepic, F. T. (1995). Culture, climate, and total quality management: Measuring readiness for change. Public Productivity & Management Review, 18(4), 369–385. http://www.jstor.org/stable/3663059