Unpacking Disagreement over New Ideas
”Why is it a problem to have stops? Stops are common. We should be able to add them to a live load.” He was insisting. This made no sense to me.
”You mean a shipment, right? The load becomes a shipment once matched.” I waited for his confirmation. It wasn’t happening.
This got me thinking about what it means to add stops for loads too. What was this about live loads? We’d have to change how matching algorithms work. This already took months to research, design, redesign, and have everyone align on. My next meeting with design, engineering, and quality teams will be fun. We cannot keep revising the short-term roadmap, nothing will get done.
”That’s what I meant. Was it truckload only? We did say LTL too?” He was one of the founders, and an important investor.
”No. We said truckload, and we agreed at the time that this was full truckload only. LTL is a different business altogether. You know it. You built a business in FTL before, and I don’t remember you saying it was LTL. Different customer needs, suppliers, service, technology. We’d have to do new research. Do you want to wait for another year to get another prototype? The differentiators are different. Everything is different.”
I was Head of Product at the time, which meant that I was responsible for aligning everyone on what the product is, what it could be, and getting everyone to agree what it should be. In this venture, the initial ideas came from investors, what one might call a ”product vision”. It was also on me to make sure the product satisfies everyone, from customers to engineers who make, release, maintain, and improve it.
”Can we stick to truckload only for now? We know it’s a big opportunity, we’re early, and it’s complicated enough.” I hoped this would stop him, or at least postpone this.
He was silent. I continued. ”So, there’s no such thing as ’live load’. I know someone may be calling freight that’s moving a ’live load’, but we don’t. Remember, the load is what the customer asks us to move, and it stays a load until it’s matched to a carrier; at that point, it becomes a shipment. Loads and shipments are described in a different way, the information about the load is only some of the information we then need to have and keep a record of, about a shipment.”
The above is part of a longer conversation I recall having in a booth of one of the Lufthansa business lounges at Frankfurt Airport, sometime in 2016. These are small, poorly soundproofed booths, claustrophobic, but lined with material that is supposed to make you feel less bad. Sure, it’s better than the waiting areas, but after hundreds of times, no good emotion can be associated with the experience; indifference on the best of days. That time, I recall being cold as I got off the plane; it was also late at night; I was very likely teaching students in the morning, and was flying home the same day, switching planes at FRA. A wonderful moment to have that conversation.
What’s interesting about this conversation is that it is quite typical. This is of course anecdotal evidence, and I’m certainly biased in all sorts of ways in my recollection. But I used to have such conversations for at least twenty years, having been involved in various ways in the design of many services that customers access via the Internet.
How is it typical? What is typical about it? The specific thing that was typical is that this is a conversation between people who are together trying to design something that does not exist yet, is not tangible, and who know different things. We are making new ideas, new concepts together, and since they are new, they do not refer to something that is there, exists, can be touched, seen, and thus help us resolve our differences. It was also typical that we both had significant decision authority: not everyone involved in innovation of this kind has the same authority to make decisions that affect the design – I did, as did he, but while he was more of an expert in the domain of application of the service/product (service and product tend to be blurred on the Internet) he hired the company I was a partner in at the time, and so my expertise was conceptual design, his was the domain. It follows that our disagreement cannot be resolved in some simple way, say, by having one of us simply choose to ignore the position of the other. By conceptual design, I mean the choices of what the service does and for whom, how that happens, what the business model is (i.e., how it generates value, and of what kind), and so on; those decisions then get transformed by other people into a working prototype and then software that customers end up using.
Now, here’s the fascinating part of all such conversations I can recall: although both them and I spoke English, we didn’t really understand each other, and the reason we didn’t – that’s at least my explanation – is that the words we were using were referring to things we were designing, so not to things which existed, and which him and I could touch, see, or read some precise description of. We were not talking about, say, the Frankfurt Airport, which is a precise enough of a thing, one you can go and visit, that disagreement can be resolved relatively easily (google it, go there, etc.). No, the thing we were making was getting a shape through these conversations; it existed in written descriptions, specifications, contract annexes, all of which we were creating, reviewing, approving, not someone else. We had to navigate these unstable reference-free ideas, change them as we go, until we reached rare moments of agreement, at which point our decisions led others, engineers, designers, etc., to actually make something that customers could try and buy.
What did we disagree about?
At some times, we used the same names for different new ideas, and at others, we used different names for similar new ideas. We disagreed frequently. Even when we might have agreed quickly, we couldn’t. If the same words stand for different ideas, and if these ideas are new (and therefore, do not come with an established definition), you are never sure if you agree or not.
Disagreements we had over the terms ”load”, ”shipment”, ”truckload” and ”LTL” were an insignificantly small sample of confrontations we had over four years that I was involved in the venture he invested in.
Innovation there was never-ending. As our customers changed their minds about what worked best for them, as we acquired new customers with new expectations conventions, constraints, practices, we kept coming up with new ideas internally for how to change our organization, products, services, systems, in response. In such an environment, it is more useful to develop an appreciation for disagreement, than to prefer stability. This is not only to accept it as a frequent phenomenon, but also to learn to analyze it, so you can then better decide how to address it.
Part of the problem with ”load” and ”shipment” was that we used same words for different new ideas. The cure for polysemy is obvious if we could pick one of a few available definitions for ”load” and ”shipment”: we should review available ones and agree on one for each word. Disagreement over new concepts is more subtle, of course, for three reasons. Firstly, it is naïve to expect to reach the agreement easily – disagreement is not simply over which definition we will pick among a few, it is over the scope of the system, product, service to design, build, run, manage, and improve. There are significant ramifications of adopting a definition of a new concept; the definition affects where we want to go, how we will get there, and what resources we will need. If we defined ”load” as being anything fitting in a dry van, this would not remove the possibility of shipping smaller loads for different customers on the same truck (the same trailer), and would lead us to LTL.
Secondly, disagreement over ”load” may not be local to the definition of ”load”. What we agree for ”load” may lead us to have to change our definition of ”shipment”, ”customer”, and others. New concepts depend on each other, in that the meaning of one will be tied to the meaning of others. If definitions ought to represent some of that meaning, then changing the definition of one new concepts will affect definitions of other concepts, where the former is mentioned. If the definition of X mentions Y, then changing the definition of Y may require us to change the definition of X.
Thirdly, we were creating new ideas, and the first version of a new idea is rarely the best. It wasn’t that we disagreed over general-purpose or even established specialized definitions of ”load” and ”shipment” – we used these words in new ways, specific to inventions we were coming up with, within the local context of the innovation process we were involved in. Even if he had a specialized, industry-standard definition in mind for ”load”, it didn’t matter, since I was looking for an idea of load which was new, and which fitted our aims and our constraints and the innovation we wanted to get to. The problem that the novelty of an idea introduces, is that disagreement we have now is not going to be the only disagreement we will have: the new idea will go through many changes, which will be motivated by various disagreements over time.
My experience is that disagreement over new ideas is a problem that intensifies over time and with more people. The more successful the venture became, the more this problem became pronounced, and cost more to solve. If communication leads to disagreement over meaning of words, how can you tell that the teams are in sync? How could you possibly assess and manage the risk of planning one thing, then being delivered another?
Disagreement about who meant what, while working on new ideas, may seem a straightforward issue to solve. Let’s get together and talk it through. But you first need to detect disagreement, then spend time solving it. You might detect it late, after damage is done. Handling it means more communication, not less. Could you have avoided this?
When you know that there is a risk for this kind of disagreement to occur, how do you detect it? Moreover, how do you detect it early, when it involves fewer people, before more is invested, and may only have affected inconsequential decisions? How can you make detection and correction part of a routine, instead of just hoping it will all go well?
The problem with disagreement about new concepts is quite different from disagreement about established concepts. When we disagree on established concepts, there is a reference that we can look up, to settle our differences and reach a common understanding. This could be a dictionary, an encyclopedia, a terminology accepted in a domain – something that we can both accept, along with others, as an authoritative source.
However, when we disagree on new concepts, then there will be no authoritative source, someone other than the two of us, or a passive source – a book, database, knowledge base, or otherwise – which we can both go to.
Instead, we have to create and define the new concept. This is exactly what was done in the logistics venture, where we had a new and our own ”load” and ”shipment” concepts, among many others.
The same happened in other businesses I was involved in during the last two decades: I was in teams which were tasked with inventing, creating, testing, delivering, and running new products, services, systems which targeted specific opportunities and problems in various industries. We were coming up with new concepts, and had to make specific definitions for them – part of it was so that we can agree internally on what to do with and about them, the other part being that we have to be clear how our innovation differed from what was already available.
Disagreement over established concepts and disagreement over new concepts are two different kinds of anomalies. The former signals the need to point everyone to the authoritative reference, which provides the agreed-upon concept. The latter begs a different question: Is disagreement a signal that the concept in question should change? And if so, how do we change it so as to avoid disagreement later?
The key point is that disagreement over established concepts signals an anomaly, something to detect and correct without changing the concept, while disagreement over new concepts is part of their formation, that is, is a step in the creation of such concepts, and in their maturing up to the moment when they become accepted by, and thereby established in a community. At that point, there is an authoritative source, an accepted definition, and disagreement is an anomaly. This is why I believe Plastic Definitions and Define/Destroy are interesting: they are a tool for the formation of new concepts, to make them stable enough that we can move to make things that these concepts refer to, and get it into the hands of those we do this for.