00:19 Introduction
02:17 Omit needless words
04:26 Supply Chains
08:12 The story so far
09:20 F-Shaped Pattern For Reading Web Content (2006)
15:15 Inverted pyramid writing form
20:35 Writing for Supply Chains - Situations
21:10 Problem
24:48 Data
28:56 Product
34:18 Process
39:32 The Manual
44:26 Writing for Supply Chains - Antipatterns
45:37 Happy Talk
50:07 Arcane Naming
54:53 Hell’s bullets
59:13 Droning
01:02:10 Conclusion
01:04:30 Upcoming lecture and audience questions
Description
Supply chains involve the coordination of large teams. Thus, written materials are king. Modern supply chains are simply not compatible with oral tradition. Yet, supply chain practitioners often fare terribly as far as their written communication skills are concerned. Let’s review what usability studies, and some notable experts, have to say on these matters. Also, supply chain initiatives, executed through the experimental optimization approach, must be thoroughly documented. The formulas and the source code answer the what and how questions, but they do not answer the why. The documentation must ensure that the supply chain scientists understand the problem they are facing. Over time, this documentation becomes the key to ensure a smooth transition from one supply chain scientist to the next.
Full transcript
Hi everyone, welcome to this series of supply chain lectures. I’m Joannes Vermorel, and today I will be presenting “Writing for Supply Chains.” For those of you who are attending the lecture live, you can ask questions at any point in time via the YouTube chat. However, during the lecture, I will not be reading the chat nor answering the questions. I will be getting back to the chat at the very end of the lecture and answer the questions at that time.
Supply chains have become very complex, large, and international, way beyond the point where oral tradition alone is sufficient. A better form of communication is needed, and this is simply put, a written tradition. Yet, when we look at the quality of the written materials found in most supply chains, it turns out that these documents tend to be lacking, to say the least. This problem, while not strictly specific to supply chains, tends to be very harmful to supply chain operations due to the scale and complexity involved. The intent of today’s lecture is to outline a series of principles that can help your companies have better writing practices, with the specific intent of improving their supply chain practices.
A fair share of these principles are not strictly specific to supply chains. However, they happen to be of prime interest to supply chain operations precisely because supply chain management is inherently complex.
Better writing starts with better English writing, and here I’m afraid that I might not be the most competent person to carry out such a lecture, as I am not a native English speaker myself. Nonetheless, I will do my best.
In this area, I would like to present a very short book, “The Elements of Style” by William Strunk, which is an all-time classic. Probably a fair share of the North American audience of these lectures is already familiar with this book. Being a non-native English speaker, I would recommend this book to my entire audience. It is a fantastic read and is probably one of those books that have served me the most from a professional perspective during the last two decades.
In this book, the author outlines a series of very simple rules, such as “Omit needless words in sentences,” “Omit needless phrases in paragraphs,” and “Omit needless paragraphs in texts.” These rules, although simple, are also very frequently overlooked. When you overlook the sort of rules outlined in this book, you invariably end up with written materials of very low quality.
By the way, for a book that puts a lot of emphasis on simplicity, I can’t help but notice that from one edition to the next, the book itself has not gotten any simpler. In fact, the last edition, published almost 50 years after the passing of the original author, is twice as large as the original edition. In this situation, I would recommend the very first edition, which I believe to be the best.
Complexity is at the core of supply chain management. As we defined in the very first lecture of this series, supply chain management is the mastery of optionality in the flows of physical goods. Supply chain management, by design, intersects with a wide range of parties, from clients, suppliers, sales, production, procurement, transport, logistics, and more. A line of dialogue needs to be maintained with all of these parties at all times, at least on a daily or weekly basis. In this regard, oral tradition tends to be quite weak. From my perspective, email and chat are also part of the oral tradition, if only because with email and chat, it’s basically “write once, read once, and dispose.” This is very different from a written tradition where a piece of text is written with a great amount of care, with the intent of having this text read by many parties multiple times over time.
We have a line of dialogue to maintain with numerous parties, and there are many elements that need to be routinely discussed. One more problem is the evolution of the job market itself. Over the last two decades, the job market has evolved. As an element of anecdotal evidence, the median tenure at Amazon and Google is nowadays only a little more than one year. This figure is not inconsistent with other parts of the job market. For example, in France, for employees under 30 years old with an engineering degree, the median tenure is only one and a half years.
We are now in a very different world from the second part of the 20th century, where people were joining a company with the intention of spending their entire career in that one company. Nowadays, people rotate in and out of their job positions fairly rapidly, with a median duration of two years or less for the sort of jobs that are of interest from a supply chain perspective. The problem is that we have a line of dialogue that needs to be maintained, and both the people inside the supply chain and those outside will rotate in and out of their job positions every two years. This further weakens the oral tradition, and that’s why having a written tradition is of prime importance. It is necessary for a supply chain that operates smoothly at scale and can improve upon itself, even though most of the people working in a given supply chain at any point in time will only be a minority five years from now, as most of them would have gone elsewhere in the marketplace.
Establishing the principles for a powerful, efficient written tradition is the topic of today’s lecture.
This lecture is the fifth in a long series of lectures, and it is part of the second chapter in my series on supply chain management. In the first chapter, I presented my views on supply chain as a field of study and as a practice. In particular, I outlined the fact that supply chain management is essentially a collection of wicked problems, as opposed to tame problems. We have adversarial behaviors all over the place.
In today’s lecture, we will see that supply chain management is played with a team, but it’s a very large team that can include hundreds or even thousands of teammates. This is why the oral tradition is so weak when dealing with so many people at the same time. Having a written form of communication, especially superior forms of written communication, is crucial. This is exactly the topic of the present lecture.
First, it is of interest, as usual, to have a look at what science has to say on the matter. To understand what it means to have a superior form of writing, it is important to first understand what it means to read. There is a very interesting usability study conducted by Jakob Nielsen in 2006. This study was based on eye-tracking 232 users who read through several thousands of pages. The resulting heatmaps, displayed on the screen, are from their eye movements on the webpages.
Eye-tracking on web pages is highly relevant because, nowadays, most of what people read professionally is read on a computer screen, with the majority of content being read inside a web page. Emails and social networks might be apps, but fundamentally, they operate in web browsers as web apps, making it very much like reading on a web page.
Jakob Nielsen, in this usability study, provided a series of interesting insights. Among these insights, he shows that although reading patterns depend on the specific page of interest, eye movements are calibrated by default according to the average page on the web. It means that the way people read any given page on a computer depends not only on the page in front of the user but on the average of other pages that people are used to reading on their computers. Nielsen also shows that when a document does not have a layout aligned with the average layout of other pages, readers become confused and fail at basic tasks of looking for information. The first finding is that the optimal layout depends on what other companies are doing in terms of web layout.
Nielsen outlined a very characteristic pattern of how people read on computers, which is of prime interest from a professional perspective. The pattern is that people essentially read with the first eye movement being a brief horizontal scan from left to right, followed by a brief vertical scan from top to bottom, followed by a series of secondary horizontal scans from left to right. This creates an F-shaped reading pattern.
What is interesting here is that people are not so much reading as scanning. Indeed, Nielsen observes that people are looking for what he calls the “informational scent.” The idea is that there is so much content to read that a sequential reading of a document is very inefficient. You do not want to read on a computer just like the way you read a book, from the first page to the last page, in a completely sequential manner. Instead, people actually scan pages, identify a few nuggets of information, click a link, and jump to the next document. They only engage in sequential reading once they are convinced that the material presented is relevant to the task at hand. People are not only reading for enjoyment; there is typically a purpose or a task involved, which is of prime relevance from a professional perspective, especially in the context of supply chain.
When we look at the F-shaped pattern, we see that if important words are not present in the title or at the beginning of each paragraph, users will miss the information. Jakob Nielsen, in his study, shows that websites presenting written material that do not follow this rule extensively confuse users, who in turn fail at accomplishing even basic tasks on the website. This principle is very important and relevant for all written materials that support a written tradition for supply chain.
Interestingly, science arrived about a century after the practice. The practice called the “inverted pyramid” became popular and dominant in news writing at the turn of the 20th century. The inverted pyramid is the embodiment of the F-shaped reading pattern, and it assumes that people will read with this scanning pattern. The technique has been used in various industries and was already an established practice in many large companies by the second half of the 20th century, particularly those with sizable supply chains.
The inverted pyramid follows two principles. The first one is that the most important element must come first. For example, in the headline of The New York Times, the first four words are “Men walk on Moon.” If we just read the first four words, we already have the essence of what the page is going to discuss. The idea is to put what matters most at the very top.
As you progress through the text, you will go through information of lesser importance. The idea is to start with the most important information, then move to almost top important information, and continue down the gradient from most important to least important. So, the first cardinal rule of the inverted pyramid style is to start with the most important information. For example, if the conclusion is the most important part, it should be at the very beginning of the document, not at the end. This pattern goes against much of what is taught in many schools and universities when it comes to writing.
The second rule is that the text should be self-sufficient whenever the reader stops reading. If the reader only reads the title, it should be sufficient. If they read the title and the first paragraph, it should be sufficient, and so on. This allows the reader to decide when they want to stop reading, knowing that they have already covered the most important information. This approach follows the idea of a professional use of documentation, where readers jump from one document to another, seeking information relevant to the task at hand. This is the idea embodied in the inverted pyramid writing form, which goes against the writing styles taught in schools and universities, such as essays with an introduction, development, and conclusion, which are deeply inappropriate for professional communication.
In this lecture, I will present a series of guidelines for transitioning your supply chain from an oral tradition to a written tradition, addressing various situations and elements encountered in a supply chain. I will also review a series of unfortunate bad practices that happen to be very popular.
The first thing that needs to be put in writing in a supply chain is the problem itself. There is a mindset that is extensively taught in universities and schools: the problem is a given. As a student, you are supposed to provide the answer and receive good grades if you have the correct answer. Obviously, the problem itself is given by the person, and you don’t question the validity of the problem itself. You think that the correctness of the answer to the problem is what matters. However, from a real-world perspective, this is complete nonsense.
Usually, the most difficult part of putting anything in business in writing is to decide what actually constitutes a problem. The problem is not a given; it is something very subtle and nuanced. For most supply chains, the starting point of having a written tradition is to put in writing what the supply chain is about and focusing on the “why.” Using the Toyota-style recursive “why,” you document the problem by asking all the whys and going down the rabbit hole to challenge all preconceptions.
Defining a problem is not going to please everybody. Supply chain is at the intersection of a lot of people and parties. When you start touching the very definition of the problem, it has a political element to it and defines the very structure of the company you’re operating in. However, there is a silver lining: when you start putting your supply chain problems in writing, what you do not understand about your company and all the other parties involved (procurement, production, marketing, sales, etc.) will become much more apparent to everybody. This is a good thing because it means that if you start putting all those elements in writing, the things you’re already doing wrong will become apparent, and other people will have the opportunity to challenge you for the greater interest of the company.
The second point is that most modern optimization techniques for supply chain, such as predictive optimization, are extensively dependent on data. As we have seen in the previous lecture, data in a supply chain doesn’t fall from the sky. There is no such thing as a data set that could be ready-made for data science. The data that exists comes from pieces of enterprise software that have not been engineered with the idea of doing data science. The ERP (Enterprise Resource Management) has not been designed to do data science; it has been designed to operate the company more efficiently, with a higher degree of productivity and reliability. The sort of data that you get is not necessarily bad; very frequently, it is just what it is and may be poorly documented. The second stage of establishing a written tradition for your supply chain starts by documenting and writing all the data. The biggest challenge is often to establish the semantics of the data and its purpose from a supply chain perspective.
Enterprise systems may contain hundreds of tables, and in every table, there may be dozens or potentially hundreds of fields. Every single field in every single table, which is basically a column in a relational system, needs to be documented. Establishing the semantics is crucial. For example, the semantics of an order date can be very ambiguous. It can be the date when the order was created in the system, the date the entry was last modified by a user, the date the order was approved by someone in the company, the date the payment was made, the date the supplier acknowledged receiving the order, and so on. There might be multiple interpretations, so fields like “order date” are deeply ambiguous. The semantics lie in what people are doing with this column, not what is documented by the software vendor.
As discussed in one of the previous lectures about experimental optimization, semantics are essentially theories about the nature of the data. The only way to know whether your theory is correct is to test it through experimentation. A fallacy when it comes to documentation of supply chain data is to think that this can be done in isolation with regard to the decision-making process of the supply chain. It’s only by building a set of numerical recipes that generate supply chain decisions that you can test your theories, which are the semantics you believe to be true for your data.
The next thing that needs to be documented is the product. In a previous lecture titled “Product-Oriented Delivery for Supply Chain,” we discussed that modern supply chain practices involve building a set of numerical recipes that automatically generate all the mundane decisions your supply chain needs to make daily. Supply chain is defined as the mastery of optionality, and the supply chain product is the piece of software that leverages all the options to make the right decisions every day. Most supply chain decisions are repetitive, like replenishing stock, producing inventory, and steering prices up or down.
The product is essentially the piece of software that collects all the numerical recipes that generate all these decisions, and this product needs to be documented. In a written form, the big problem here is that there is a big temptation to paraphrase the code. The software is implemented with a programming language, and it’s very tempting, because it’s actually easy to do, to paraphrase the code when documenting software. However, paraphrasing the code is completely useless. If you want to know what the code is doing, you can just read the code. It’s not because you translate the code in English, in ways that are much more ambiguous and harder to comprehend, that you’re making the life of anybody easier.
The purpose of documenting a software product is not about paraphrasing the code; it is about explaining the “why.” Why did we implement these numerical recipes in the first place, and what are the hidden problems that we have to face? If you do not document the “why,” people may be inclined to change the numerical recipes in ways that are not going to work because they don’t understand why it was made this way in the first place. Maybe there is a twist in terms of numerical formulas where you think a formula is kind of weird, but there is a much easier form to write what appears to be pretty much the same thing. However, maybe the easier form has a problem of numerical stability. It’s very important to document the “why.”
It is also essential to document all the failed attempts because software products are developed typically in highly iterative ways. Most of the attempts fail for diverse reasons, and you move on. What you see is just the result of a long evolutionary path where many dead branches have been cut over time. If you do not document the branches that were cut, you’re going to repeat the same mistakes over and over again. Remember that we live in a world where the median tenure of people in companies, especially those with an engineering degree, is going to be something like two years. It’s crucial to document why you chose this option for numerical recipes and why seemingly good options were dismissed because they were failing in ways that may be very counterintuitive.
As a final word, it is also important to document the known weaknesses in the numerical recipes because they are of prime interest for the continued improvement of the software product driving the supply chain.
We also have the process to document, which is what people are expected to do on a routine basis. Due to the way I am approaching supply chain, the process should be approached with great care. In the ideal world, there is no process whatsoever because everything repetitive should be implemented in the software and thus automated away. Essentially, processes are the things that cannot be automated away or that resist automation one way or another.
Nonetheless, supply chains operate in less-than-ideal world conditions, which is what a real-world perspective implies. So, even if we try to have a very high degree of automation, there is always a degree of human-driven processes still involved. The problem I have with processes is that the mindset emphasized by the ISO 9000 perspective is very toxic. The ISO 9000 series places too much focus on the “what,” and this tends to be toxic in the sense that very quickly, the process establishes itself, and people start questioning the adherence to the process rather than the process itself.
When you document the “what,” doing a good job becomes about how compliant you are with regard to the process. As anecdotal evidence, one of the banks used by Lokad, a large international bank, kept using fax machines for two decades past the point where the entire world had moved on. They were still using fax machines until recently because they had to be compliant with their process. This example shows the problem with processes: when you establish a process, it tends to have a bureaucratic core and outlast its usefulness.
So when I say documenting a process, I emphasize the importance of paying attention to the “why” and understanding the key reasons that drive the establishment of this process in the first place. It’s crucial to remember the “why” because when the reason for the process evaporates, which can happen when technology evolves or when certain problems or needs no longer present themselves in the same form, the process should cease. The “why” should be the primary focus in the documentation of the process, to ensure that the process is discontinued when it ceases to be relevant. This is a matter of efficiency, and with supply chains being large, complex, and to a large extent bureaucratic, we need to pay close attention to these elements.
To sum it up, when we think of moving a supply chain from an oral tradition to a written tradition, the compilation of all these materials should be put together in what is typically referred to as the manual, or the “big book of the supply chain.” This big book will consolidate the problem, the data, the product, and the process. In the case of large clients who operate extensive supply chains, this manual may be several hundred pages long. Supply chains are highly complex, with various industry-specific challenges, making the problem definition intricate. The data can also be very complex, with potentially dozens of ERPs in large companies. The numerical recipes can be quite complicated, and the product driving the supply chain decisions should be made as simple as possible, but no simpler. The processes can involve dozens of parties, making them extensive.
As a result, we can end up with a massive manual, which is why it is essential for this manual to adhere to the inverted pyramid writing form. The introduction of the manual should be written in the inverted pyramid style, presenting the most crucial elements right at the beginning. Each chapter should also follow the inverted pyramid style, starting with the most important elements and gradually moving towards less relevant or important aspects. This principle of the inverted pyramid should be applied to the sections within the chapters as well. The inverted pyramid form is intended to help people navigate sizable documents efficiently.
Perhaps the manual would be read sequentially when a new employee joins the company, spending a few days going through the entire supply chain manual from start to end. However, most of the time, people will jump in and out of the manual to directly find the information that is most relevant and then continue with the task at hand. That’s why the inverted pyramid is so important as a writing form when you want to consolidate a large amount of written materials in a way that is highly productive to leverage in your daily operations. It’s not something that is intended to be read linearly, except maybe at the very beginning when you join the company.
At Lokad, it is part of our established practice when we carry out a supply chain initiative for a client to compile all of the documentation into what is referred to as a Joint Procedure Manual. The reason for the “joint procedure” prefix is because Lokad is a company that is outside the company of interest, so it’s a manual that is shared about the supply chain with a third-party company that happens to be Lokad. One of the primary interests and values of having such a manual is when you need to transition from one supply chain scientist to the next.
In the very second lecture of the first chapter, where I presented the vision for the quantitative supply chain, I introduced the role of the supply chain scientist, the person who takes ownership of the generation and numerical recipes that generate supply chain decisions. Like most other companies, Lokad is not immune to turnover, so it is crucial that the manual ensures a smooth transition from one supply chain scientist to the next. The manual is the embodiment of all the business thinking that went into the establishment of the product and the processes that are associated and layered on top of the product.
When it comes to written materials, there is plenty of leeway to produce low-quality content, and there are certain anti-patterns that I would like to point out. Anti-patterns are things that are done by a lot of people but are actually harmful for the company and need to be avoided. Let’s review the bad practices or anti-patterns that are most harmful to supply chain, in my experience.
The first one is “happy talk,” which is characterized by a form of corporate speech that is almost entirely devoid of information. It’s a piece of corporate writing that is almost pure noise and no information whatsoever. I believe that happy talk is the natural consequence of seeking consensus. When people, as social beings, try not to antagonize the people they work with, they naturally want to play it nice with others. The specific problem of supply chain is that it is at the intersection of so many parties, such as production, sales, marketing, procurement, and purchasing. You are at the intersection of so many parties that if you seek complete consensus across all those parties, you end up with the smallest common denominator, which happens to be almost virtually nothing. This is the big problem here. It’s very tempting to say nothing because whatever you say is going to antagonize somebody somewhere. When people start to realize that, happy talk takes on another form that is even worse than just saying nothing. People realize that if they say anything, it will go badly for them, or they will antagonize people that they don’t want to antagonize. The next stage consists of actually saying what you can say without antagonizing anybody, which is just to say positive things about yourself and your team. Then, it becomes a sort of virtue signaling exercise where essentially corporate communication becomes pieces of advertising that just promotes whoever is actually writing the copy. Obviously, all of that is completely not aligned with the corporate interest of actually improving and doing anything good for the supply chain itself.
As a litmus test to detect happy talk, whenever you see a piece of corporate writing, just ask yourself the simple question: could I take this piece of text, put it in another division, or even another company, and would this piece of text be equally relevant in this other division or in this other company? If you find a piece of text that, when moved to another division or another company, would be equally relevant, the odds are super high that it’s pure happy talk and that it’s actually relevant to another company just due to the fact that it doesn’t say anything.
The solution is essentially courage. You need to stand for something. Supply chain can’t please everybody. Supply chain is essentially an art of trade-offs. If you please sales to the utmost with sky-high service levels, you have an excellent quality of service but will not please finance because you generate so much waste and dead inventory in the process. If you want to please production to the extreme, it may not be aligned with what gets traction on the market, so it’s not going to fit what people are selling and what marketing is pushing. Supply chain is essentially a trade-off between all those parties, so you can’t please everyone. You have to establish the fact that it’s a balance, and to some degree, you will antagonize all the parties involved, although the point is not to antagonize those parties but to reach a trade-off that is as profitable as possible for the company.
Arcane naming and arcane knowledge are time-tested practices to hold bureaucratic power in an organization. This is a very ancient technique, probably thousands of years old. Supply chain, being what it is, the mastery of optionality is fundamentally a practice that is established at the management level. I really differentiate supply chain and logistics, and I define supply chain as a mastery of optionality. It is essentially a management layer, and thus, at its core, there is a bureaucratic element that is unavoidable. It’s a bit like the glue that holds the company together; it cannot be avoided. It is important to recognize that at the core of the supply chain, there is a core of bureaucracy.
It is very tempting and easy to fall into the trap of arcane naming. You don’t need a grand plan for that; you just have to be lazy. This laziness will only reinforce the elements of arcane naming because if you’re careless when it comes to naming, you will end up with names that are badly chosen and opaque. Interestingly, this opacity, although not the prime intent, will grant an extra layer of power to these elements of the organization.
As a litmus test, you can check how many acronyms are used in your organization. The propensity of using acronyms goes hand in hand with the amount of arcane power wielded inside the company by bureaucratic parties. Companies that try to stay away from bureaucratic power try to minimize these opaque acronyms that are reserved for the initiated.
These arcane names are not just a problem due to political issues; they create an ongoing amount of opacity that leads to lost efficiency. The productivity of everything you try to do in the company will be degraded due to this ongoing friction. Whenever an employee tackles a problem, they will face half a dozen acronyms and will have to constantly refer back to the glossary section of a manual to figure out what those acronyms mean. This creates confusion and reduces operational efficiency.
Moreover, as I pointed out in the first series of guidelines about establishing a written tradition, the most difficult question that needs to be answered is “why.” Any degree of confusion, such as having improper names, makes the question even harder to answer. Having proper names is essential to reduce the amount of ambient confusion in a space, like the supply chain, that is already very complex by design.
The solution is good names, and there is no mystery. It’s a lot of work. There is a saying in computer science that there are only two exceedingly difficult problems: cache invalidation and variable naming. Finding good names is very difficult and takes effort. It’s not unreasonable to spend a full hour to find a good name for something. This is not a waste of time; it’s very important.
Hell’s Bullet is another problem, and the issue here lies with slides, as found in PowerPoint presentations. These slides very rarely have the qualities that you would expect from a piece of text. This is not a problem of format, but rather the crux of the problem lies in what I would refer to as “graphic writing,” which is typically characterized by heavy usage of bullet points. These bullet points replace all the logical connectors in the text, such as “and,” “or,” “then,” “yet,” “however,” and “furthermore.” What you end up with is a text that is deeply ambiguous.
For the person writing the text on the slide, this is typically not the prime intent. However, writing a piece of text that is ambiguous through bullet points is much easier than writing an actual text with logical connectors where you have to write something that makes sense. As a litmus test, a very simple way to decide whether what you’re reading is some sort of Hell’s Bullet or graphic writing is to try reading it aloud. If it doesn’t make sense when you read it aloud, then it is not proper writing. You should be able to read a piece of text aloud, and it should make sense.
There are other forms and variants of graphic writing, such as two-by-two diagrams or SWOT diagrams, which are also easy to produce, deeply ambiguous, and convey very little information. The solution here is simple: write phrases.
By the way, there are very successful companies, like Amazon, who have a massive distrust of slides. One practice that has been established at Amazon for probably more than two decades is the idea of the memo. Whenever there is a meeting to be started with many people involved, a memo will be written prior to the meeting. It should be plain text, with maybe an illustration if you have a graph, but that’s it. The meeting will start with about 10 minutes of silent reading, where all parties involved will read the memo. Then the rest of the meeting will discuss what is written. I believe this technique to be very efficient, and it’s a technique I’ve been using with key management at Lokad for a long time.
My final anti-pattern is “droning.” Droning is when people in a company operate as corporate drones, pretending to be corporate drones instead of actually being humans. I believe this emerges naturally from a misguided intent of wanting to play the act of being part of a large corporation. Many people take being part of a corporation too seriously, and this can result in communications that look like they were written by robots to be read by robots.
Let’s be honest, supply chains can be boring at times, and not all aspects are exceedingly interesting. A lot of stuff, like documenting hundreds of fields in enterprise software, is not particularly engaging. The job itself can be very mundane and boring, and that’s fine. However, if you double down on the boring aspect by having a piece of text written as if you were a complete drone, you end up with something incredibly tedious, causing the reader’s mind to switch off.
The problem is: can you consider a piece of text well-written if someone attempting to read the document falls asleep intellectually halfway through because it’s so incredibly tedious? Obviously, these are corporate materials, and we are not going to crack jokes. However, it’s not a corporate crime to have a tidbit of humor or present elements in ways that pique the interest of your readers. Doing so can make the text better in terms of efficiently conveying your intended message. This is particularly important in supply chain because these matters can be quite extensive.
The default status is often “Why didn’t you read the documentation?” and the response might be “I couldn’t be bothered; it was just too tedious.” The solution is to act as humans and write for humans in your supply chain documents.
In conclusion, transitioning your supply chain from an oral tradition to a written tradition is a matter of efficiency at scale. There are enormous productivity benefits that can be reaped by making this transition. One frequent objection is that writing text is incredibly difficult. Yes, it is difficult, but text makes all the challenges bubble up, surfacing all the difficulties. Slides, especially with bullet points, are easier to produce because you’re circumventing the difficulty in the first place instead of tackling the problem head-on.
Text is beneficial because it forces you to confront the challenges, and it may take an entire day to write half a page about a problem statement for your supply chain. If that’s what it takes to have a well-established, solid half-page that firmly lays the foundation of what you’re trying to solve for your supply chain, then so be it. Fundamentally, I would say better text is a superior alternative in most situations. By text, I mean text from a written tradition, where it is written with care and the intent of being maintained over time and re-read a great number of times. Many companies pride themselves on having people think outside the box, but in many companies, people are not even capable of describing the box in the first place, especially not in writing. The first stage, if you want to think outside the box, is to be able to describe the box in writing in the first place, and that would be the starting point.
Now, I will jump to the questions. The next lecture will take place two weeks from now. It will be another persona. Remember, personas are essentially extensive descriptions of the problems alone; we don’t want to jump to the solution. It will be an aerospace persona, where we explore the very specific world of aerospace supply chains that are very unlike most other supply chains. Let’s have a look at the questions.
Question: How could, if at all, semantics apply to a data lake? Is it truly a data lake if it feels defined?
For me, a data lake has several ingredients, and some of them are of a purely technological nature. The first thing is that enterprise software operates on relational databases. 99% of the enterprise software out there operates on traditional relational databases like SQL Server from Microsoft, Oracle, PostgreSQL, or MySQL. These systems are designed for a balanced amount of reads and writes. They are tuned for very small reads and writes, like modifying one stock position and reading one stock position at a time.
However, when it comes to data crunching, you have a problem. This is precisely the problem that data lakes try to solve. When you want to crunch data, you want to read all the data at once in batch, and relational systems are not designed for this. They are not efficient at dumping all the data they contain, especially if they need to do so for multiple parties simultaneously.
I believe that a data lake is fundamentally a layer and a technological layer where you create a copy, without any transformation, of all the data that lies in various systems in one place and maintain synchronization. The key added value of the data lake is to ensure that agents (it doesn’t have to be human) who want to read all the data in bulk can do so without interfering with production. The data lake also prevents crashes in production due to system overload when reading data in bulk. That’s the first key value.
The second value is that the applicative landscape of your company might be very heterogeneous. You might have tons of different systems, like an Oracle database, a Sybase database, a Microsoft database, a PostgreSQL database, and so on. All of these are many systems with different interfaces and software components to access the databases. The data lake provides a unified way to simply query all of the data. That’s the key value. However, when it comes to a good data lake and its semantics, beware that the semantics for a field of data depend on what you’re trying to do with the data. There is a kind of illusion, and there can be a bureaucratic element to it, where an extensive data lake team tries to document everything, even though they are lacking the key mechanism of experimental optimization to challenge whether the semantics they are writing down for each field are actually correct.
My suggestion when you have a data lake is to keep this team super lean and super reduced. The team that operates the data lake has only one task: to provide a synchronized view of the production data in the data lake in ways that are technically unified, but not to take care of the documentation. Documentation will be produced by the teams that are doing something with the data.
Question: Sometimes, simple diagrams designed with automated solutions like Microsoft Visio could make our life easier and remove a huge part of data discovery workload. Do you agree?
Yes and no. If you go back to one of my previous slides, you would see that, yes, you can generate diagrams, and they can help to a limited extent. I’m not saying you shouldn’t use visualization tools to represent the relationships between tables with keys and whatnot. These elements are fine, and you can even print a few diagrams into your supply chain manual. I think it’s relevant. However, they cannot replace plain text documentation. Remember that most of what you want to document is why. The table diagram that shows the relationships between tables and keys only tells you the what. The what is trivial to document, so yes, diagrams can make it easier to document the what, but that was already the easiest part of the challenge. Keep in mind, it’s the why that is very difficult to document, and this is where the vast majority of your time, effort, and energy should be focused.
Question: What would be your first best move to start establishing good practices for companies that start at zero?
Well, I would start by writing down the problem statement of the supply chain. It’s not supposed to be a very long document. If you don’t operate in a company that does something fantastically complicated like aerospace and you have a company that does something conceptually simple, start with a clean problem statement about what the supply chain of this company is about. It should not be more than a couple of pages. Have those pages circulate around so that people have a chance to object, and then by addressing those objections, you will make the document better and stronger. This will give you a strong starting point. It’s not necessarily time-consuming. If you want to start a written tradition, begin by writing the first page that describes the problem in a way that makes sense. The upper hierarchy might find it useful to gain an understanding of what their own company is about. My starting point would be to start with a modest document and focus on the problem statement.
Question: If you found a “crappy” document, let’s say a forecasting procedure, how would you approach upper management to suggest changes or a complete rewrite, as it is even easier to correct the existing one politely?
Well, I believe that this is a sensitive matter. I wouldn’t attack the document directly, as people may take it personally. In good companies, you should be tough on problems and soft on people, but it’s very difficult, and very few companies can achieve that. Usually, companies are tough on people and soft on problems. My suggestion would be to approach upper management with examples of good practices and rules that qualify for a good document, like the inverted pyramid form of writing. Emphasize that this superior form of writing was already established in the 70s at Procter & Gamble. These practices are not new or cutting edge; they have been established knowledge for a long time. You can lead your upper management to a gradual understanding of these practices, and they will probably come to their own conclusion when it comes to assessing the quality of the material they might have produced themselves. Many people can journey through a similar path if they are exposed to the correct ideas; they will realize that maybe the document they produced needs improvement, and they may ask other employees for help.
Thank you very much for attending this lecture. I hope that for all of you who do not live in companies that are firmly grounded in written tradition, you can start transitioning from oral traditions. See you two weeks from now; it will be the same time, same day of the week, Wednesday, and the same time of the day, 3 pm Paris time. See you next time, thank you.
References
- The Elements of Style (First Edition), William Strunk Jr, 1918
- F-Shaped Pattern For Reading Web Content, Jakob Nielsen, 2006
