What is Leadership?

Everywhere we look, we see organizations with leaders. In worldwide bodies and the local PTA, in politics and the workplace, from kings and presidents to Yertle the Turtle—leaders seem to be universal. From time to time, at reliable intervals, someone will suggest that society try to get along without leaders; but the effort never lasts long. 

Leadership is so familiar that it's no surprise to find it a Quality Management Principle. But why is it so familiar? What is leadership, and why does it seem so hard to get along without it? Answering that raises another question: if leadership is indeed inescapable, what can it do for us? How can we use the phe­nom­enon of leadership to advance our Quality goals?

So many questions. Let's start at the beginning.

What it is and why we need it

In any work, there are two components: first you need a picture in your mind of what to do (or you have to decide among competing alternatives), and then you have to do it. When I write this article I start by deciding what to say, and then my fingers type the words out on my keyboard. But if I don't start by making decisions about what to say, I won't get anywhere. My fingers can't type this post by themselves until I tell them what to type.*

We all know this. It's almost too obvious to have to spell it out. But the same thing applies when we work in groups. In order to work together, we have to agree what we are working on; we have to agree who does which part; and we have to agree to common decisions along the way. Do we steer left or right? Do we paint it red or green? Who will be out front pulling, and who will be in back pushing? And so on. For simple jobs and small groups we can often agree by discussing it among ourselves. But that approach cannot scale: when the group is large enough or the job is complex enough, we have to delegate someone to make these decisions for the rest of us. And that person is by definition the "leader."

Therefore leadership is an unavoidable part of working together in large (or mid-sized) groups on big (or complex) jobs. As long as we live in a complex society, where organizations of all sizes tackle a bewildering number of jobs, we will continue to see leaders everywhere.

The paradox of empowerment

Ironically, just as the complexity of our work requires leaders, it also undermines them. 

As we have seen, complex work requires leaders because somebody has to decide all the questions that come up in the course of getting the job done. 

But complex work undermines leaders because nobody can be an expert in everything. The CEO might have gotten his position because of his flair for marketing, say, or for finance. But that skill does not equip him to define an Internet security policy for the office, or a preventive maintenance schedule for the factory. Like it or not, he has to ask other experts to decide those questions, and mostly he has to believe what they tell him. As a result, large and even mid-sized organizations have no choice but to adopt "employee empowerment"—not as a management fad, but as a way of life. When the work is even a little complex, it becomes essential to distribute responsibilities and authorities throughout the organization in line with individual expertise, rather than concentrating all decisions at the top.**      

How can leaders support Quality?

So our organization has leaders—probably several of them, at different levels. What can they do to support Quality?

There are a lot of straightforward steps that leaders can take, stemming from their role as decision-makers and from their position—especially at the higher levels—overseeing multiple areas at once.

• They can ensure that workers have the tools that they need to do the job: equipment, training, procedures, and any other needed resources.
• They can ensure that the organization's departments are working together, and not at cross-purposes. 
• They can ensure that relevant communications get all the way through the organization undistorted, so that workers have the information they need.

All of these responsibilities flow pretty directly from the basic job description of "leaders."

The personality of the organization

But there's another role for leaders beyond all that, and it's harder to put into words. Maybe I can start by pointing out that every organization—every department, every group, every team—reflects the personality of its leader. It's not always a perfect reflection. Sometimes you might think it's more like a funhouse mirror. But the effect is real.

I was surprised to discover this in my first managerial role. My predecessor in that position had been good at some things and less good at others. And the department's overall reputation in the company aligned pretty well with his strengths and weaknesses. When he left the company for another opportunity, I took his place. And over time I began to realize that people treated the department differently. After a while, our collective strengths and weaknesses aligned more to my personality and less to his. I won't dive into the details, because it might sound like disrespecting my predecessor, when in fact I learned a lot from him. I will always be grateful for what he taught me. But our personalities were very different, and the department reflected them—first his, and later mine.

As an aside, there's nothing supernatural or exotic in this effect. The manager of a department hires and fires people, rewards and punishes them, promotes or fails to promote. It's only natural that behaviors which the manager thinks are important will come to predominate.

This "manager effect" on the personality of an organization puts enormous responsibility on the shoulders of leadership. 

• Do you want to instill a Quality culture? That's easy: just make sure all of your leaders care passionately about Quality. 
• Do you want to encourage an ethical business culture? Nothing could be simpler: just make sure your leadership are utterly incorruptible and intolerant of corruption. 
• Do you want a culture of innovation and risk-taking? Let workers see their leaders take risks—including risks that fail—and get away with it.
• Do you want all of the above, all at once? That may be harder. But again, you have to start with leadership.

Just remember that all eyes are on your leaders, all the time. So if you are a leader, you cannot allow yourself to slack off. Maybe you relax when you get home—that's none of my business, and I don't need to know. But while you are at work you have to be a living, breathing example of what you want from your people. Every minute, every day. The reason is that they are going to imitate you whether you like it or not—but they will imitate the real You, the one they actually see, not the cardboard cutout you wish they saw instead. So whatever behavior you want to get from them, that's the way you have to live.***

__________

* Compare Aristotle's remarks on work in Pol., I, 2, §2, 1252a-b.  

** It is a commonplace of political theory that centralized autocracies are less efficient, less resilient, and more fragile than decentralized free societies, because all decisions have to be approved by the autocrat. This means that important matters are delayed until he has time to attend to them. It also means that these decisions, when finally taken, are frequently wrong. In the same way it is no accident that ISO 9001:2015 requires the organization to implement employee empowerment at appropriate levels. Clause 5.1.1(j) requires top management to "[support] other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility." (In other words, top management has to empower other roles to step up and take control of their areas.) And clause 5.3 requires top management to "ensure that the responsibilities and authorities for relevant roles are assigned, communicated and understood within the organization."   

*** This sounds like the advice often given to the parents of young children, for good reason. Obviously your adult employees are not children! But this specific dynamic—I mean the "manager effect," where a department takes on the personality of the manager—just happens to work the same way at home or on the job.       

What is Customer focus?

The first Quality Management Principle supporting any quality management system is Customer Focus. And in many ways, it is the most important. As we saw last week, the other basic principles establish a management system as suitable for a sustainable organization: that is, a social organism which uses rational self-reflection to adapt to its environment. But Customer Focus is what points that management system (and that organization) towards Quality. Quality means that your customers get what they want; and you can't get there without focus. For this reason, ISO 9000:2015 defines that:

The primary focus of quality management is to meet customer requirements and to strive to exceed customer expectations.* [2.3.1.1]

But why does it really matter? How do you do this? And who counts as your customer?

Why does customer focus matter? 

Of course at the most basic level, customer focus matters because if you treat your customers badly they will take their business elsewhere. And if they go to your competitors, you'll go out of business. 

But there is more than that. Customers are the whole purpose for an organization. Peter Drucker famously observed, "There is only one valid definition of business purpose: to create a customer." And logically, this makes sense. The only valid purpose for a nursery is to support gardeners. The only valid purpose for a hospital is to treat and cure sick people. The only valid purpose for a car dealership is to enable people to drive cars. And so on. Customer focus means paying attention to the one thing that gives all our work meaning.

How do you focus on customers?

There are as many ways to focus on customer needs as there are customers or needs. But a few simple ideas are basic.

First, you have to know what your customers really need (or want), and what you are able to provide. If those line up, that's great; if they don't, you might want to do something to correct the mismatch.

What is more, if you work as part of an organization (and not as a sole proprietor), you have to make sure that everyone in the organization is working on the same thing, or at least pulling in the same direction. This is trickier than it sounds, because sometimes organizations end up serving the demands of their own procedures rather than acting in a way that benefits their actual customers.

We discussed this risk in a blog post a couple of years ago, when I described the work of John Seddon. Seddon has made a career out of prodding executives to see their businesses from the outside, the way a customer does. His first step when working with a new client is to send top management out to the front office to watch a single order come in, and then to track that order through its whole life-cycle. Invariably, the order winds its way through a dozen departments; the whole path is so complicated that it takes way longer than it would have taken if one person had handled the job from start to finish. Also, with every additional step there's another chance for error. This kind of work cycle, which is all too common in the largest organizations, is a direct consequence of forgetting to focus on the customer's perspective.

Again, customer focus can take thousands of forms depending on the specific details of what work you do and who your customers are. But start by seeing things from their perspective.

For that matter, … who exactly are your customers, anyway? 

Who is your customer?

We can start with a definition, but we won't end there. ISO 9000:2015 defines a customer as a:

person or organization that could or does receive a product or a service that is intended for or required by this person or organization. [3.2.4]

So far, so good. But who else do you have to consider?

Direct and indirect customers

Some customers are indirect; that is, they don't walk into your store or pay you directly, but they buy your goods from one of your customers, or from a distributor. I have a friend who makes custom light fixtures by hand, and many of his sales go through a distributor for practical reasons—so he can focus on creating the works instead of marketing them.

Then there are people who look like customers but don't end up buying from you. Another friend works in retail, in a niche that requires a lot of customer consultation. Her store is recognized as the best local source for expertise in their line of work. Of course most people who get their information there also shop there; but once in a while people will come in and learn everything they can from the sales staff … only to spend their money somewhere a few dollars cheaper. Are these people "customers"? In a sense perhaps they are. More to the point, the store has to understand that these people exist, and to advise the sales staff how best to work with them.

Other interested parties

The most recent edition of the ISO quality management system standards generalized the concept of customer by introducing that of interested party. ISO 9000:2015 defines an interested party as a:

stakeholder; [a] person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity [3.2.3] 

As we saw a few years ago while discussing the case of universities (see this post and this one), the concept of "interested party" is in many ways simpler than the concept of "customer." And it shouldn't be hard for most organizations to list the interested parties that care about the outcome of their operations. For example, your state may require you to apply for a business license in order to operate. Strictly speaking the state government isn't a customer, but everyone understands the need to obtain all the appropriate licenses before you open your doors. So naturally the state's "needs and expectations" have to be taken into account.  

Unusual interested parties

Sometimes you might have "interested parties" that aren't so obvious. 

Let's consider an unpleasant example—and one that I hope will never happen to you in real life! Suppose a representative of the Corleone Family comes into your shop one day, looks around, and says, "This is a nice place you got here. It'd be a shame if something happened to it." Then he offers to "sell you insurance" to protect your shop. Does this thug count as an "interested party"?

According to ISO, he might. It depends on how credible a threat he poses. If you are confident that the police can protect you, naturally you'll prefer to ignore him. But ISO 9000:2015 clarifies the concept of interested party by explaining:

The relevant interested parties are those that provide significant risk to organizational sustainability if their needs and expectations are not met. [2.2.4, para. 2]

So if the Corleone Family truly poses a "significant risk," then it is fair to classify them as "relevant interested parties." And ISO 9000:2015's advice on customer focus suggests that one way to address such focus is to:

determine and take action on relevant interested parties’ needs and appropriate expectations that can affect customer satisfaction. [2.3.1.4]

Only you—or your organization—can determine whether "protection insurance" counts as an "appropriate expectation" from local criminals; but if you choose to pay it, ISO 9000 will back you up.

All our work is for the sake of something, which means that it is all—implicitly, at least—in the service of somebody. As long as we can remember that, we're well on our way towards sustainable Quality. 

__________

* There is room to discuss whether it is always right to exceed customer expectations. (See this post, for example.) But the standard says only "strive," so we can afford not to emphasize this point when it does not apply.  

    

Seven principles

Euclid, By Jusepe de Ribera - J. Paul
Getty Museum, Public Domain.

In day to day work, we often take for granted our basic understanding of Quality as a discipline. This is as it should be. Normally we're busy, we've got problems to solve, and we know that the Quality tools will help us solve them. There's no need to go all the way back to Euclid every time we have to measure a right angle.

But suppose we wanted to go back? What foundations does the Quality discipline actually stand on? Are there any, or is it just something we cooked up among ourselves because it sounded good?

Of course the answer depends on what part of the Quality discipline you ask about. The field's statistical tools are all based (obviously!) on statistics, which is a well-understood branch of mathematics. Problem-solving methods like PDCA are basically an application of the scientific method to industrial or business problems.

What about management systems? Are those based on anything?

Yes, actually they are.

The standard ISO 9000:2015 enumerates seven basic Quality Management Principles, on which rests the whole structure of the ISO quality management system standards, as well as any particular quality management system you or I might implement for our own companies. Because these principles are so fundamental, I thought it could be useful if I take a few weeks to analyze them one at a time, in order to unpack what each principle means and why it is there. That's my plan for the next seven weeks, unless it gets interrupted by something urgent.

But there's a question I'd like to address right at the beginning: Why these principles in particular? Is there really something that makes them more fundamental than any others?

The seven quality management principles are these:

• Customer focus
• Leadership
• Engagement of people
• Process approach
• Improvement
• Evidence-based decision making
• Relationship management    

Clearly they are all important. Clearly they are all good things to do. But what makes them any more fundamental than any other principles you might think of?

The point is that quality management systems are designed for use by organizations. 

• An organization is a social organism. 
• In order to continue to exist (to survive, or especially to prosper), an organization must use rational self-reflection in order to adapt to its environment.
• And in order to pursue Quality, an organization must (by definition) focus on the needs and wants of its customers and interested parties.

All of this follows more or less from the definition of quality management systems, and from basic observations about the nature of organizations. But look at the consequence.

• Customer focus means that the organization has to focus on the needs and wants of its customers and interested parties.
• Leadership and Engagement of people are fundamental to the definition of an organization as a social organism. Without Leadership, there is no unity or common purpose, and therefore no organism. Without Engagement of people there is no organism in another sense, because the people will just wander away.
• The Process approach and a commitment to Improvement give the organization the tools for rational self-reflection.
• Evidence-based decision making and Relationship management both mean that the organization adapts to its environment. Evidence-based decision making is how the organization adapts to the facts in its environment. And Relationship management is how the organization adapts to the other entities (persons, interested parties, or other organizations) in its environment. 

That's what makes these principles so fundamental.

In the coming weeks, we'll unpack them in detail.

Carrots and sticks

A couple weeks ago, a reader wrote in to ask me about document control. Specifically, he asked me:

Question: How do you standardize document file structures in an office where there are many different and competing structures currently in place? And how do you accomplish this in a work culture which is highly resistant to change?

Background: [My company] is behind the times when it comes to using organizational software like SharePoint, Microsoft OneNote, etc. Instead, we have opted for the tried and true method where "each person comes up with what works for him"; and we have repeated this model several hundred times. As a result, our file structure is an absolute mess and is heavily reliant on personal experience. 

Secondly, like in many similar companies, we have filing cabinets full of paper copies. These are often reports from projects completed in 1985, and client studies that were delivered in 1997. Most of them are obsolete, but nobody knows which are and which aren't. So it's easier to keep them there "just in case". 

What ends up happening is that employees becomes very familiar with a small section of the file structure (their own) but are completely lost anywhere else. Usually this means they have to email someone asking, "Do you know where File X is?" Over and over.

So how do we deal with this? The value of uniform organization is clear: less time wasted tracking down files, greater transparency when we get audited (frequently), easier knowledge transfer between employees and new hires, etc. I don't see any clear solution, except to have someone send out a memo describing the new file paths they want (which people might or might not follow).

Here's what I told him.

Excellent question! The short answer is that it's not easy. And it involves both carrots and sticks.

The sticks have to come first. Someone in authority has to announce "Here is the new folder structure for all your records, and every department will adopt it as of the first of next month. There will be unannounced audits to check if you are really doing it." Then follow through with the unannounced audits, and some kind of disincentive for people or departments found out of compliance.

But this will get only superficial compliance. People will do just enough not to get punished, and no more. Or rather, a few innovative and early-adopter types will take one afternoon to reorganize all their files in the new way. Some others will copy five files into the new format and then store the 500 files they have traditionally maintained into a single folder called "Other," which is where they will do all their real work. (The five files they copied—not moved—will never be edited nor maintained, but will sit in the new structure as Potemkin files in the hopes that it's enough to save their owners from punishment.) And then there will be people who waffle inconsistently in between these two extremes.

The carrots take longer. But what will happen … slowly, maybe over years … is that the people who have adopted the new format find they are more efficient. Everyone starts to get used to the new layout (slowly, incrementally) and so after a while even the dyed-in-the-wool opponents will start putting new files in the approved folder structure, even while keeping their archives a trackless warren. Then one day you will hear one of the staunch opponents of the new system looking for a file he "just knows" is around here somewhere. After he has searched in vain for half an hour he will exclaim with exasperation, "Things would be so much easier around here if people would just follow the darned process!" At that point you know that you have crested the hill, and you are on the downward slope on the other side.

But it takes a lot of frustration to get there.

Incidentally, if this describes your organization, the effort to get it straightened up will always be worth it. Good luck!

     

Who needs process, anyway?

Over the last couple weeks I've written about different ways that process-development can go wrong: either by piling too many procedures atop each other, or by imposing ungainly external constraints. But who really cares? Wouldn't it be easier to do without formal processes altogether? Think of all the trouble we'd save!

Do we really need processes? Of course it depends. It doesn't take much of a process to play Tag with your kids at the park (so long as you all understand the rules of Tag). But you absolutely need a clear process in order to bake a cake. Let's break down the difference. When do you need a defined process?

We can start with baking a cake. You need a process there because there are fundamental dependencies between the steps. For example, you have to mix the ingredients together into a batter before you put in all in the oven: if you try to bake the ingredients separately—the milk, the eggs, the flour, and the baking powder—you'll get a mess that can't be mixed together afterwards. Then again, you have to let the cake cool before putting on the frosting, or the frosting is likely to melt and smear. So any activity whose steps involve internal dependencies is implicitly a process, and should be understood as such.

Process-definition is also useful when you have an explicit list of requirements that have to be met, because when you specify a mandatory sequence of steps you can check that each requirement in turn is addressed somewhere. The procedures that I described as examples in my two most recent posts—the permitting procedure to build along the California coast, and the jury service reimbursement procedure—are both examples of this type of process. In both cases, there are legal requirements that have to be met. And so the government* defined explicit procedures to follow, to ensure that no requirement is missed.

You need processes when working with machines, for several reasons. Most basically, machines require uniform inputs in order to work correctly, and they deliver uniform outputs. In fact, you can almost say that a machine is a process—nothing else—worked out in steel and wire. But for that reason, the human activities around the machine—feeding it, tending it, and the like—have to be deterministic, and therefore procedural. Beyond that, working with machines means watching for safety issues and performing regular maintenance. Each of these tasks has its own list of requirements. And we have already seen that the best way to meet a list of requirements is to define a procedure. So in addition to operational processes around machines, we have to define safety processes and maintenance processes as well. 

One critical use-case is often overlooked: you need processes when several functions have to work together. (This is also called the division of labor.**) This is because each role is focused on its own work: Engineering is designing new widgets; Production is building them; Logistics is shipping them; Sales is selling them. For the most part, everybody understand his own work but has only the foggiest clue what anyone else is really doing. And yet everyone depends on the work of everyone else. So as soon as a work package has to be handed off from one person to the next, there are only two choices: either the two workers stop everything to discuss the hand-off in detail, or else each work package is proceduralized so that the hand-offs are always the same. Obviously the first approach is impossible, because it would bring all work to a halt. But that means the introduction of defined processes is necessary to support the division of labor. 

Let me mention two other use-cases briefly. Defining a process is helpful when training someone to do a job. As I have remarked before, there have been any number of times I've taken over a job from someone else who "just knew" how to do it, and the first thing I always do is to write a checklist (even if only for myself). And finally, defining a system of interlocking business processes is a useful tool for understanding the scope of your business as a whole—for example, if you are preparing an improvement initiative.

Is there anything that process can't do? Of course. Process can't make you smarter. It can't make you creative. And it can't make you successful. Processes are necessary in all the use-cases I've just described, to avoid the confusions and failures that would be inevitable without them. But by themselves, processes are never sufficient.

Steve Jobs talks about this in a brief clip available on YouTube. (This clip is extracted from a longer interview that you can find here.)

__________

* In both of these examples, this was the State of California. 

** See Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations (1776, 1784, etc.), Book 1, chapter 1.   

       

Constraints can spoil processes

Last week I wrote about one of the ways that process definition can go wrong: namely, when you layer one process atop another without rethinking the whole activity in an integrated way. But there are more ways besides that one.

Another common failure mode is when external constraints prevent you from working in a convenient way. In a sense it sounds too easy just to blame external constraints, because we'd like to think that if we were only clever enough we could overcome them. But that's not always easy to do.

Jury service procedure

The Los Angeles Federal Courthouse, by Daniel L. Lu
(user:dllu) Own work, CC BY-SA 4.0, LINK.

A couple of months ago, I got a summons in the mail to appear for jury duty in Federal District Court in downtown Los Angeles. That's more than 90 miles from where I live. The summons included a phone number which I was to call the day before—any time after 2:00pm—to confirm whether I was really required to appear. And as a concession because I lived so far away, they were prepared to reimburse me for a hotel room.

Here's the procedure for securing reimbursement:

1. Call the day before (after 2:00pm) to confirm that I am required to report. (Assume "Yes.")
2. Call a nearby hotel to book a room. Ask for the "government rate." (The Court supplied a list of nearby hotels with government rates.)
3. Drive to the hotel.
4. On the morning of the first day of service, check out of my room and advise the hotel that I am on jury service so I might be back.
5. When I come back from the first day, ask for my room back again.
6. Repeat steps 4 and 5 every single day of jury service until I am released.
7. Pay the bill with my own funds, and then submit the defined paperwork to get reimbursed.

What's wrong with it?

I read this procedure, and right away I wondered, "Did the people who wrote this procedure ever actually try to book a hotel room in downtown Los Angeles?" As a procedure, it seems to reflect no awareness of the procedures of the hospitality industry. I see two critical gaps at the very least:*

• Hotels in prime locations often book far into the future, but I can't book my room until after 2:00pm on the day before my service starts—because the Court might not need me. And the letter was clear that the Court will not reimburse cancellation fees.
• If I check out of my room every single day, what is the likelihood that it—or any other room—will still be waiting for me when I get back at the end of the day? Probably greater than zero but less than certain. So I might find myself suddenly room-less. But if I keep my room and the contending parties come to an agreement in the hallway, the Court will dismiss me from jury service and won't pay for the following night. 

In the end it all worked out. I have family in the area, so my need for a hotel was not critical. And the Court dismissed me without asking me to appear. But the process issue stuck in my head.

Why is it like this?

When we run into difficult processes like this one, it's always tempting to blame the people who designed them. But in this case I think that the real blame has to lie with the external constraints that the system has to obey. And those constraints are not so easy to wave away.

• Most of the problem stems from the Court's unwillingness to plan more than a day ahead. But they can't. There is always the possibility that the litigating parties might come to a last-minute agreement, or that the case might be dismissed for some other reason. So the Court really doesn't know more than a day in advance whether a given pool of jurors will be needed.
• Of course it would be nice if the Court were willing to be a little flexible on this point, granting jurors a day's leeway before or after to allow them to make their plans in advance. But some jurors would be sure to abuse such leeway.
• In the same way it might be nice if the Court summoned only people who already live locally, so that the need for a hotel never arose. But that's hardly fair. Serving on juries is one of the basic duties of citizenship, along with voting. If only locals had to serve on juries, then people who happen to live near a Courthouse would carry an extra burden that never fell on those of us who live far away.
• Alternatively, we could multiply the Federal District Courts until everyone in the country lived near enough to one to count as "local." But that would mean a lot more courts! Do we need that many? Do we (as taxpayers) want to pay for that many? Maybe not.

Maybe there are clever solutions that I can't think of. But it's not an easy problem. The constraints are imposed by the unpredictability of the legal process, and by topics (like fairness and cost) governed by the political process. So changing the constraints means reworking one or both of those processes, neither of which is likely to be easy.** 

In developing your own procedures, try hard to avoid the situation where you are squeezed between such implacable constraints.

__________

* One additional topic is that if I call the Court at 2:00pm and only afterwards call a hotel, I'm likely to get on the road by about 3:00pm. This means arriving in Los Angeles at the peak of the afternoon traffic. That outcome may not—strictly speaking—count as a failure mode of the procedure. But it would certainly be a nuisance.

** As I have observed before, when the Quality process conflicts with the political process, the political process usually wins.

    

It doesn't take a conspiracy!

Last month, Southern California was hit by a battery of wildfires. Los Angeles County alone was struck by at least nine (two of them crossing the border to Ventura County as well), of which three—the Hughes Fire, the Eaton Fire, and the Palisades Fire—each burned over 10,000 acres. The Eaton and Palisades Fires each started on January 7, and were still burning three weeks later (though by then they were mostly contained).

There may be more to say about these fires from the perspective of problem-solving and preventive action, once there has been time for more of the analysis to be done. But for the moment I want to address a different kind of discussion, one that broke out almost as soon as the fires did.

Social media conspiracy theories

Pretty much as soon as the first homes went up in smoke, people on social media blamed it all on a wicked conspiracy. The gist of the argument seemed to be that:

• if you take too long to rebuild your home (some posts said the limit was two years, while others said it was three) then you lose the protection of Proposition 13 to keep your property tax rates low; 
• and for people whose net worth is all tied up in their home, higher property taxes could force them to sell at ruinous prices; 
• but the number of permits required by the State of California to build in these exclusive areas is so great that building is sure to take too long; 
• and therefore the fires must have been set by Bad Guys who wanted to scoop up a lot of prime real estate at bargain prices.

Maybe I don't need to say this, but the social media posters who jumped on this bandwagon didn't get all of their facts quite right. 

• Yes, it's true that there are some restrictions on what kind of a replacement structure you can build while keeping your old tax base—if you replace a doghouse with a mansion, you can expect a reassessment—and some of those restrictions also take account of how fast the rebuilding happens. 
• But the formulas are more complex than the doomsayers claimed, and more generous. (The current rules were implemented by Proposition 19, passed in 2020, and you can find more information at this website here.)
• 
  And yes, it's true that the State of California normally requires a lot of permits to build in some of these areas, specifically so that you don't ruin a neighborhood that's already there (inhabited by people who moved there before you did) by putting up something that doesn't fit the natural or social environment.
• But when everything has burned to the ground, those considerations aren't as relevant. As a result, California Governor Gavin Newsom issued an executive order on January 27 suspending permit requirements under the California Coastal Act and directing the Coastal Commission not to interfere. (Although in fairness to the social media warriors, this executive order came more than two weeks after they started alleging conspiracies. So maybe that delay played a part in motivating them.)   

January 27 was also the day that evacuees from the Palisades Fire were allowed to return to their homes, just three days after President Trump visited Los Angeles to urge expeditious rebuilding and to promise federal aid. So on the whole, the government's response has been a little better than the doomsayers feared.  

Bad Guys are no smarter than the rest of us

But suppose they had been right. Suppose the rules were as bad as they said, and pretend for the moment that nobody had lifted a finger to invoke emergency powers or to speed these processes along. In that case, could we have legitimately inferred a conspiracy?

No such luck. Even in that case, we might well be looking at no more than bad process management.

Where conspiracy theories go astray is to assume the Bad Guys are smarter in carrying out their Evil Deeds than we are in handling normal problems at work or at home. Product development in the technology sphere routinely faces unplanned delays and sudden changes in the scope of work. And yet somehow we hear that the Bad Guys pull off their plans without clumsy mistakes or slipping schedule. Really? Where can we find these guys? I guarantee they'd make more money from legitimate jobs!

On the other hand, if you accept that even the Bad Guys are just normal humans, then they make the same mistakes the rest of us make. And what that means is that when things go wrong, the problems are more likely to result from normal human ineptitude or bad luck than from malice.*

Better process management

Fine, if it wasn't the work of Bad Guys, then how exactly did it get so hard to acquire the permits to build a house along the California coast? I don't know the real answer, and won't without doing some research into the history of the California Coastal Commission. But I assume that this situation is just the result of bad process management.

Once upon a time, someone must have noticed a risk that something bad could happen if a person tried to build a house without checking for some condition first: maybe it meant checking that the ground was solid enough to build on. So the state implemented a procedure that you have to check the ground before you build. Later, someone else noticed a risk that something else bad could happen if you didn't check for another condition first: maybe this time it had to do with making your house out of flammable materials. So sure enough, the state implemented another procedure to check your materials before you start. That meant two checks before you start building, and two permits to prove that you did the checking. 

And so on. 

This is the lesson for process management. Let's say you have defined a process to do something, and it's working well enough, but then a new situation comes along. The easiest thing in the world is to write a new process and overlay it on top of the first, to deal with the new circumstance. Now someone has to follow them both. Then another new situation comes along, and another, and another. Are you going to keep writing new processes, and force people to follow one after another after another? Too many people do just that, and it can grind your operations to a halt.** 

The real answer is, Don't do this! Instead, rethink your whole system from the beginning. Start over from scratch and work out a single process that accommodates all the subtleties and special cases that you are now aware of. Anything else will bog your people down and immobilize them. But the point of a process is to get things done. 

The State of California may have created a situation where the only way to build a house expeditiously in certain areas is through executive orders and emergency action. When it comes to your own work, learn from that example instead of imitating it. 

__________

* Hanlon's Razor encodes this insight as: "Never attribute to malice that which is adequately explained by stupidity."

** This is part of why I have argued before that "Procedures which are easy to write, are hard to implement."