Truth, Quality, and Bullshit
An exploration into the relationship between truth and Quality and the existence of bullshit in project timelines.
Author and clinical psychologist, Jordan Peterson, said once on a podcast that, “Quality is the building into an object of truth.” He probably wouldn’t even remember saying it, as he was discussing an unrelated topic, but I haven’t been able to get it out of my head since. Given the context of his statement, he was likely referring to product quality; however, I find it useful to apply this concept to more than just physical objects. For example, “[Product] quality is the building into a [product] of truth” or “[Organizational] quality is the building into an [organization] of truth.”
In my experience, organizations don’t seem to have an appreciation for the relationship between truth and Quality. They often have an “ends justify the means” mentality or sometimes just an “ends” mentality where the “means” aren’t even considered. Nothing highlights this lack of appreciation more than how organizations approach the creation and maintenance of project timelines.
I am told that it is status quo for timelines to be “optimistic,” but it has always been perplexing to me that the individuals in charge of creating them can be so comfortable with lying. I have recently come across a term that I think is a better description of what is occurring, and it has helped me better understand the problem. That term is “bullshit,” coined by Henry G. Frankfurt in his essay, On Bullshit. He explains that “[the bullshitter] does not reject the authority of the truth, as the liar does, and oppose himself to it. He pays no attention to it at all. By virtue of this, bullshit is a greater enemy of the truth than lies are.” Understanding bullshit and how it differentiates itself from lying, with relation to the truth, is instrumental to understanding Quality and how to improve it. I have seen first-hand it’s negative impact on Quality and if I had known then what I know now, I may have been able to do more about it.
To illustrate the impact of bullshit on Quality, let me take you through an example of the development of a “High Risk” timeline that I experienced while working for a large organization. This project included the outsourcing of both the product development and manufacturing. During project kickoff, the supplier presented us with a projected schedule. The completion date presented was several months after the date leadership had told us they wanted the project completed by. Obviously, unacceptable. There was buffer room put into the schedule to help mitigate risk caused from uncertainty, so we got to work pairing it down. For example, if they had to procure material from an outside source that quoted a lead time of 4-6 weeks, they would include six weeks in the schedule. Material lead times that were listed as six weeks became four weeks. Amazing! Two weeks saved already. Why didn’t the supplier think of that? We did this for nearly a week until we had a schedule that met our leadership’s expectations. We called this the “High Risk” schedule. There is always risk in business, so “High Risk” doesn’t sound that bad, but “High Risk” is really a misnomer. A better name would be “Best Case” because it will only end up being true if everything goes perfectly.
A project timeline is a series of interdependencies. If the timeline says that material for testing will be available in four weeks, testing may be scheduled at a third-party lab for that time. If it ends up taking six weeks for the material to be available, the testing lab may only be able to reschedule for eight or ten weeks out. If the lead time risk was integrated into the timeline, testing would be able to be completed in six weeks. Since it was removed to improve the initial projected completion date, the same task now has taken eight or ten weeks. This is exactly what occurred with this “High Risk” timeline.
To show that the existence of bullshit is universal regardless of organizational size and complexity, let me take you through another example. This organization was mostly focused on one project, and it was significantly behind when leadership originally told investors it would be completed. For this project, there were two major risks: resourcing constraints and global supply chain disruptions. Both risks were discussed, but neither were integrated into the timeline. Because of this, every time a risk was realized, the project had significant delays. This again, was a “Best Case” timeline, but it allowed leadership to present investors with a favorable completion date, so they were satisfied. The timeline was created assuming resources and material would be available as needed, but resources were always assigned to conflicting priorities, and material was consistently being received late. As the communicated completion date approached, the timeline was reassessed and pushed back. This occurred several times throughout the year that I was on the project and the risks were never built in.
Compromises are often made to accommodate a “Best Case” timeline. At one point on this project, a decision was made to change the material of a component to reduce the lead time on prototypes needed to start testing. Inevitably, other delays occurred, pushing the need for the prototypes back several months, but the parts had already been made. In order to accommodate the new material, capital equipment had to be purchased for the downstream supplier, and a unique manufacturing process had to be developed. Even with the accommodations, the supplier still had difficultly making good parts, causing additional delays when fulfilling orders. The attempt to accommodate the “Best Case” timeline ended up decreasing Quality in a variety of ways: unnecessary capital investment, increased yield loss, increased lead time, and damage to the supplier relationship. If the timeline was not “Best Case,” it would have been clear that the few weeks savings were not going to matter. The delays that occurred would have been expected and planned for and the change that ended up decreasing Quality would never have been a consideration.
In my experience, people understand that lying is wrong and generally understand that it will decrease Quality. They do not, however, have that same understanding of bullshit. Often the individuals responsible will spend a substantial amount of time and energy crafting a timeline that meets the expectations of their superiors. In most cases, when this is accomplished, there is a feeling of gratification and pride. Whatever the feeling is, it certainly is not the guilt that one feels when knowingly lying. I have approached the issue of dishonest timelines in the past by claiming that they were lies, but my criticisms never seemed to resonate. The individuals creating them were not opposing the truth, they were simply not paying attention to it. They may not have been comfortable with lying, but the project timelines they created were bullshit.
Frankfurt goes on to say, “Since bullshit need not be false, it differs from lies in its misrepresentational intent. The bullshitter may not deceive us, or even intend to do so, either about the facts or about what he takes the facts to be. What he does necessarily attempt to deceive us about is his enterprise. His only indispensably distinctive characteristic is that in a certain way he misrepresents what he is up to.” The individuals creating the timelines above did not intend to create false timelines, however they did misrepresent what they were up to. Their goal was not to develop a timeline that would ensure the project was completed as quickly as possible. Their goal was to develop a timeline that made their bosses happy. There are many reasons for this, and they were likely just following the incentives put in front of them, but this article isn’t about that, it is about the existence of bullshit, in a technical sense, and its relationship to Quality.
If Quality is synonymous with truth, as Peterson suggests, it will be obvious to most people that lies “oppose [Quality]” and they will typically agree that you should not lie. However, most people think that if they are not lying, they are telling the truth, unaware that they could be doing neither. Bullshit, or when someone “pays no attention to [Quality] at all,” is an even “greater enemy” to Quality. If your goal is to create a high-Quality environment, it is important to prioritize the truth. To do this, you need to be able distinguish between lies and bullshit. Project timelines are just one example of how bullshit can create a low-Quality environment, but there are many others. I recommend if you are in a low-Quality situation, ask yourself: Is it because people are opposing Quality or because they are paying no attention to it at all?