How Definitions Influence Future Choices
How can definitions make it easy to do some things, and hard to do others? How do they impose constraints on future choices?
If you commit to a definition, meaning you choose one definition of a term over others, then you also take additional commitments. It is a case of getting more than you bargained for. How much of this more do you know when you make the definition? Do you want this additional baggage? These are the two central questions below.
Law is an interesting domain when thinking about definitions. This is for two reasons: one, it insists on using terms in a precise and consistent way, and two, how these terms are used has substantial effects on people’s lives. Consider the very hard case of the term ”terrorism”. How would you define it?
Here is how terrorism is defined in the United Kingdom Terrorism Act. The version below is from 2018. Most text is the original definition, and it was included in law in 2000; text labeled [A] was added to the original definition in 2006, and the updated definition was published in the Terrorism Act 2006; text labeled [B] was added in 2008, and published in Counter-Terrorism Act 2008.
”Terrorism: interpretation. (1) In this Act ’terrorism’ means the use or threat of action where (a) the action falls within subsection (2), (b) the use or threat is designed to influence the government [A: or an international governmental organisation] or to intimidate the public or a section of the public, and (c) the use or threat is made for the purpose of advancing a political, religious [B:, racial] or ideological cause. (2) Action falls within this subsection if it (a) involves serious violence against a person, (b) involves serious damage to property, (c) endangers a person’s life, other than that of the person committing the action, (d) creates a serious risk to the health or safety of the public or a section of the public, or (e) is designed seriously to interfere with or seriously to disrupt an electronic system. (3) The use or threat of action falling within subsection (2) which involves the use of firearms or explosives is terrorism whether or not subsection (1)(b) is satisfied. (4)In this section (a) ’action’ includes action outside the United Kingdom, (b) a reference to any person or to property is a reference to any person, or to property, wherever situated, (c) a reference to the public includes a reference to the public of a country other than the United Kingdom, and (d) ’the government’ means the government of the United Kingdom, of a Part of the United Kingdom or of a country other than the United Kingdom. (5) In this Act a reference to action taken for the purposes of terrorism includes a reference to action taken for the benefit of a proscribed organisation.” [1/13]
This is a complicated, but carefully made definition of a complex and important phenomenon. It is also a poorly understood phenomenon. Any definition, therefore, however attentively made, will have limitations.
One of the possible consequences of applying this definition is that some acts, which normally do not look like cases of terrorism, still could be categorized as terrorism.
“Civil disobedience, public protest and industrial action are among the activities that could fall within the definition. These types of activities should be excluded from any definition of terrorism. […] Unlike the definition in the Australian Criminal Code (and its State equivalents), the New Zealand Terrorism Suppression Act, the Canadian Criminal Code and the 2003 South African Anti-Terrorism Bill, the United Kingdom definition does not contain an exception in favour of advocacy, protest or industrial action. The legislation simply requires the purported terrorist to have committed an act (such as endangering a person’s life, or seriously damaging property), and to have committed that act in furtherance of a political, religious or ideological cause with the aim of influencing the government or intimidating the public (or a section thereof). This encompasses groups whose methods are generally non-violent and who do not aim to intimidate or to coerce the government or the public. For example, a long-running nurse’s industrial dispute where staffing levels in public hospitals have been seriously reduced could ’create a serious risk to the health or safety of the public’, within the meaning of s 1(2)(d) (as could the industrial actions of other essential services, such as fire officers, police, and so forth). If the strike were directed towards convincing the government to increase pay and conditions in public hospitals then this could also satisfy both the ’political cause’ and the ’influencing government’ requirements, in s1. Similarly, a mass student protest against the deregulation of university fees by the British Government could also fall within the definition of terrorism.” [6]
These are interesting potential consequences, regardless of intentions that led to the definition. Going back to less complicated topics, the point is that your choice of one definition over another has consequences on the structure of the problem space, of the solution space, and on the innovation process.
This means that how you define something has an impact on what problem you are going to be solving – that is the problem space part – the potential ways you will be looking at to solve it – the solution space part – and on how you go through the formulation of the problem and its resolution – the innovation process part. In other words, it can affect really all that goes on during innovation.
In another text, I introduced the case where I was in a team that was designing a business services marketplace. One of the issues that was highlighted early on, was that contract negotiation between the party providing the service and the customer tends to take an unpredictable amount of time. Negotiations can last long, and if they last too long, they may simply not lead to the contract at all. So one of the aims that was taken for granted, was that the process should shorten the time to contract, or more broadly, to the decision to sign or not.
How do these early assumptions shape the problem space? Consider these three potential definitions for the contract negotiation process.
Contract Negotiation 1: Process in which parties agree on terms of collaboration.
Contract Negotiation 2: Process in which a party that needs to have assignments performed communicates with potential parties that can execute these assignments, until she has either agreed with one on terms for collaboration towards the execution of these assignments, or has agreed with none of the considered parties.
Contract Negotiation 3: Process in which parties agree on terms of collaboration within two calendar weeks from the time the asking party requested a proposal from the supplying party.
The first definition is the least constraining. It leaves a lot open. Nothing is said about how many parties can be involved, how much time they can take, what they can collaborate on. The second definition is clear about the number of parties that can be involved, and how the process ends. Only the third definition mentions the duration of the process, and is precise about it, but is open regarding the number of participants.
If the innovation team adopts the third definition, they still need to decide on the number of participants, among others. But can they allow any number of participants? Does allowing fewer participants make two weeks a long time for negotiations? Is two weeks too short, when there are many participants? Does the number of participants influence duration? Is it the other way around, does the duration limit the number of participants? Should the process differ in maximal duration if it has many participants? Which numbers would require which durations?
If the team does indeed adopt the third definition, and makes it immutable, then this affects substantially the possible designs of the negotiation process. And it does so in ways which may not be easy to see as early on in the innovation process. We did, in fact adopt a definition which included a time limit. Because of this, we had to restrict communication between the parties. If we left it open, letting them freely communicate, we believed that they would not converge to a go/no go decision quickly enough. This, in turn, required that we provide template contracts, where it was clear which exact parameters could be negotiated. And that, then, required that we restrict communication between parties only to the negotiation of values of those parameters. Yet another unanticipated consequence of this, is that it can work only for highly structured contracts, where these negotiable parameters are few and well known. For example, a monthly retainer amount and a price per hour, together with the list of tasks. That is a far reaching consequence, because it affects the size of the potential market for the process, and the software that was to be made to support that process.
This does not mean that a more open definition (one with fewer constraints) is better. If the team takes seriously the first definition instead, then it may ignore the relationship of duration to outcome, and more specifically that the duration of negotiations influences negotiation success.
All these issues seem obvious as you read this text, but they are hard to see and analyze when you are involved in the innovation process. It is often only in retrospect that their merits and drawbacks become clear.
In respect, you can see a definition as a bundle of predictions. In the case I mentioned, these are that two weeks are a good duration for contract negotiation, that the number of participants needs to be two or more, and so on. These are predictions about what will make the outcomes of innovation useful.
An analysis to do, that helps understand the implications of a definition on the problem and solution spaces, is to identify choices in the definition, and identify at least one other option for each. I did it below on the three definitions.
Contract Negotiation 1: Process in which (one, two, more parties) (agree, disagree, cancel negotiations) on terms of (delegation, collaboration).
I identified three choices in the first definition. One is the number of parties, with four options (either one of the three, and all three as the fourth). The second is the outcome of negotiations, with four options as well. The final is the object of negotiations, with two options. You could have gotten other choices and other options for each. What the analysis highlights is that the first definition commits to one out of 4x4x3 possible combinations; the problem space is restricted to the chosen options in each choice, and any solution will have to solve a problem in that part of the problem space.
Consider now the second definition.
Contract Negotiation 2: Process in which a party that needs to have (one, more assignments) performed communicates with (one, more than one potential parties) that can execute (all, subset of these assignments), until she has either agreed with (none, one, more than one party) on terms for collaboration towards the execution of (all, subset of these assignments).
Above, I highlighted five choices, and a problem space of 3x3x3x3x3 combinations. You could easily enlarge this problem space, by allowing participants to make their own decisions. That would look like this.
Contract Negotiation 4: Process in which a party that needs to have (one, more assignments, party’s own choice of number of assignments) performed communicates with (one, more than one potential parties, the number of parties decided for that contract) that can execute (all, subset of these assignments, a minimum set by the asking party), until she has either agreed with (none, one, more than one party, number chosen by the asking party) on terms for collaboration towards the execution of (all, subset of these assignments, minimal set required for the asking party to accept the contract).
And this is only for a rough definition of a single term. You can imagine how this becomes complicated to think about, if we start looking at choices in two, three, or more realistically, glossaries with a few dozen, and sometimes hundreds of terms. Even if you dedicated effort to the analysis of this kind, to each definition alone, you would still have to do this for interactions of choices which are in definitions of different terms, but depend on each other.
Same analysis is now applied to the third definition.
Contract Negotiation 3: Process in which (two, more than two, number set by asking party) parties agree on terms of collaboration within (one, two, custom number chosen by asking party) calendar weeks (from the time the asking party requested a proposal from the supplying party, from the time the first supplying party responded to the request for proposal, either of these as requested by asking party).
Again, notice how a seemingly simple definition can cause headache, as the number of choices and options in each start to multiply.
Let’s take a step back. What goes on in this analysis? I said I was identifying choices. In abstract terms, these are assignments of values to variables. I took easy examples in these definitions, because it is straightforward to think about, e.g., the number of participants as a variable that can take different numerical values, positive integers. But this is less apparent in the third definition, for the choice of trigger that starts the negotiation timer, where I had the choice “two calendar weeks from the time the asking party requested a proposal from the supplying party”.
In simple terms, choices are all items in a definition that you could change. A choice in a definition is something that can or could be different.
A choice is not necessarily easy to identify in the definition. It could be straightforward, like in the cases I had above, or much harder, as in the following example.
Shippable: A Shippable Unit (a.k.a. “Shippable” only) satisfies all the following conditions: It involves one or more software functionality; It is represented, in the release management process, by exactly one User Story; It is released to UAT Environment; Prior to its release to UAT Environment, it has been tested to ensure that this software functionality operates in accordance to its Product Specification; Its Product Specification has been approved, prior to the commitment of development resources to its implementation, i.e., prior to its User Story being introduced for the first time in a Sprint.
This comes from a terminology made by a software engineering team that was adopting for its own work style a general purpose development method. You might recognize that they were adopting and adapting for themselves, a variant of the Scrum method for software development. A first choice, which is hard to see in this definition, is that a shippable should involve pieces of functionality; it was only when the team started dedicating more resources to analysis tasks, which do not produce functionality, but do produce designs of future functionality, that they recognized that outcomes of these analyses cannot be presented as shippables, which skewed data on team’s performance, and caused problems when performance assessments started being done by a third party. This was, in fact, not a conscious choice, because the team was already – when the definition was made and approved – involved for months in developing functionality which was well specified up front, and there was no analysis effort to do. That option was not considered, and when no options are considered, this part of the Shippable definition seems, at that time, as immutable, it is not a choice at all, even if this turned out to be a mistake.
Another issue is the last item, where the Product Specification needs to be approved up front. This turned out to be a problem, because if we had to follow it rigorously, it would delay a number of decisions to change minor aspects of the product, decisions which we ended up taking anyway, without having the approved specification. However, when the definition was being made and approved, it seemed like the only option.
It can, in short, be hard to see that something in a definition is a choice in the first place. But even in the hard example above, choices were still items, parts of the definition.
It can be harder still, as when the definition itself is a choice, and taking another option would lead you to throw away that definition altogether.
In the Shippables example above, the notion of a shippable is associated, as are the notions of User Stories, Sprints, and so on, with the Scrum method for software development. The choice of going along with that method, of aligning to it, is in fact a choice like any other. If we wanted a different method, there may not be a notion of Shippable there at all.
This highlights the fact that you need to worry about choices that led to the need to introduce the term in the glossary, then about choices captured in the definition of the term itself, and the choices that are implicit, which you only learn through experience.
Troubles do not end there. I have a rather different understanding of options and choices when I am analyzing definitions that I create, as opposed to those that others made. Indeed, a term’s definition is simply an outcome of the thinking and communication that led to it (including one’s specific experience and expertise accumulated up to that point). If you did not participate in, or do that thinking, then your analysis of choices in a definition will be based only on the definition itself, and the rest of the glossary.
But even if I had to make a definition of Shippable, I can still know little about Scrum, or software development altogether. Your analysis, in other words, inevitably leans on the knowledge you have.
And even if I knew a lot about software engineering methods, it would be more appropriate to know specifics of that team, who will be using the definition, than if my knowledge was generic.
The bottom line is that the less you know and the more indirect that knowledge is, the more difficult it is to anticipate the effects of choices in the definitions you make, or are handed over.
I mentioned three parameters so far, which play into your ability to predict the effects of choices in a definition. They are:
- If your knowledge is direct or indirect; it is direct if you have expertise and experience on phenomena at hand; it is not if they are new to you, and much of what you can think of these phenomena is, thus, speculation based on, for example, analogy;
- How extensive your knowledge on the phenomenon is. The less extensive it is, the more likely it is that many choices in the definition will remain implicit to you;
- If you are an author of the definition, or only its recipient, in which case you did not participate in whichever explicit choices were made when that definition was designed.
These three dimensions are orthogonal. Your level on one has no relationship to your level on another. With this in mind, your worst case is being a recipient of a definition, while having low indirect knowledge of the phenomenon that the definition is about.
References
- UK Terrorism Act. 2000. url: https://www.legislation.gov.uk/ukpga/2000/11/section/1
- Ben Golder and Williams George. “What is Terrorism-Problems of Legal Definition”. In: UNSWLJ 27 (2004), p. 270.
