With the rise of the software-enabled business, we are faced with a language challenge that requires everyone to be “bilingual”
As well as being able to communicate effectively with other people, we all now need to be able to communicate effectively with technology. Limitations in how humans “talk to” technology ultimately reduce the value of desired outcomes, and are a key issue for organizations trying to leverage “digital” to transform their companies.
Common challenge areas
We have identified four aspects of human-to-technology communication where we see common pitfalls and challenges. In combination, these factors drive businesses to waste precious resources, time and investment, as well as organizational commitment.
User requirements
Organizations need languages that capture the richness of demand, yet use ones that are prescriptive and artificially limited by the constraints of supply. By completing the processes set out in enterprise solutions, organizations fool themselves into thinking that success will follow. Yet, once configured, the resulting solution does not meet business expectations, burdening the organization with software that does not deliver the intended benefits.
Technology requirements
At one time it was thought that the richer and more complex the language descriptor, the more one could accomplish. However, Representational State Transfer (REST), the technology architecture pattern that helped the internet become what it is today, has proven otherwise. Its language is based on just four verbs: GET, POST, PUT and DELETE. By contrast, the complexity of Simple Object Access Protocol (SOAP) – another computing language originally defined in 1998 that allows web services to “talk to” computer systems on the internet – has a much richer descriptive framework, which is also more complex, and therefore restrictive.
Coding
Coding today has a fundamental limitation – the number of people that can code. This scarcity of resources pushes up salaries and therefore means that organizations face budget issues when it comes to employing programmers. To allow more people to create software so that it becomes a process, rather than requiring them to learn to code, we need a language that removes the barriers between ideas and execution as working code. Yet, we have a human-to-technology language taxonomy that, despite best efforts, has multiple barriers to entry. The end result is that we limit the number of people with great ideas who can quickly create business value.
Software product and adoption
Adoption of new technologies within organizations is often met with passive resistance, or “tissue rejection”. A recent ADL article identified some common pitfalls, which are compounded by the issues described above. For example, many organizations underestimate behavioral issues – failing to adequately plan how employees will adopt the tool – and mismanaging communication, which impact adoption. We need a language that provides meaning by reflecting real-world complexity, and is simple to understand.
How we “talk-to” technology
Jobs To Be Done
Enterprise software processes can limit the innovation potential of organizations. Therefore, when selecting or building new tools, it is important to deploy design-thinking concepts to help capture requirements that can test outcomes in a meaningful way:
- User stories – this captures actor, action and benefit, and is always expressed in a specific format (“as an <actor>, I can do <action>, so that I get <benefit>”). Through workshops, this tool helps business users define what they want.
- Personas – this captures examples of users and their “pain” and “gain” points – i.e., what makes their lives difficult today, and what would remedy their issues. Personas also capture how a user may use a technology (e.g., frequency, location, device), which impacts overall technology requirements.
- Jobs To Be Done – a key component of personas and user stories is to define the ultimate desired outcome. These are expressed as “Jobs To Be Done” (JTBD), as explained by the JTBD framework developed by Clayton Christensen and Anthony Ulwick. This is the core desired action and outcome – and removes the impediment of how people have worked before to open up new ways to tackle old problems.
What Would the Web Do (WWWD)
The ultimate purpose of developments such as REST is to deliver technology architecture patterns that are open and flexible, which do not limit desired outcomes. Using these digital design principles helps deliver robust, performant and highly extensible solutions to meet business needs. User stories and Jobs To Be Done are useful to help test these requirements.
Smart-stitching
Best practice among technology innovators and software-driven businesses has opened up a third approach – an alternative to the traditional options of “build” or “buy” – that we describe as “smart-stitching”. In this pattern, an end-to-end business capability can be split into elements that can be delivered using standard software platforms, which are increasingly open source, cloud based and delivered as services. When the analysis of what is needed is carried out, the elements that are truly bespoke to a solution or organization are typically a small percentage of the total footprint, and custom development of these components becomes a manageable and time-efficient exercise. The commodity and custom elements can then be “stitched” together into an end-to-end solution.
Memes for adoption
Memes act by delivering simple messages. The purpose of a message can be two-fold: to deliver a quantum of information to explain and enact a change or desired outcome, and/or to help embed adoption of that desired outcome into the DNA of an organization’s ways of working and culture. The first must happen very quickly, almost intuitively, to the receiver of the message. The second happens over time, as a feature/by-product of the ways of working and culture, through peer-effect. Both require a meme to have similar characteristics: simple, short, and salient.
Conclusion
Increasingly, companies will win or lose based on the value they can generate in the software layer. This requires executives to help their organizations improve their ability to “talk to” technology. However, traditional approaches are constrained by restrictive language and frameworks, closed technology architecture patterns, or the organization not thoroughly considering adoption. The language we use to talk to machines, to conceive and codify software, is a type of technology itself. We therefore recommend that executives look at how their organizations can understand and get better at the technology of language, if they want to drive success
About the Author
Mandeep Dhillon is Principal, Leader of Phase 0 at Arthur D. Little. For over a century, ADL has been driven by our clients’ most pressing challenges, as they seek to turn the previously unimagined into commercial reality. Today, the global Digital Problem Solving team at Arthur D Little are both inspired by and embody our founding principle, as established by Arthur D. Little in 1886. Find out more at www.adlittle.co.uk
