What technology strategies will you adopt as you redesign work?
Part 6 of a 7-Part Series on Using Collaborative Intelligence (CI) to Improve Company Performance
As I wrote previously, when speaking with company executives regarding how best to use Collaborative Intelligence (CI) to improve their company’s performance, I ask seven clarifying questions, the sixth of which is: “Now that you’ve analyzed the work, what technology strategies will you use to support the redesigns?”
I ask this question to describe a process for selecting technologies to support the redesign and determining how best to acquire and implement them. Explicitly contemplating this question helps organizations identify the best ways to use CI technologies to achieve performance improvement goals.
I am using the term “technology strategy” rather loosely. I am referring to the company's choices regarding how best to identify, acquire, and operationalize the technologies required to support the envisioned redesigns.
Future articles will cover the following topics:
Developing/Augmenting a technology strategy to support organization-wide adoption of internally-developed CI (includes infrastructure, data management, human resources, etc.)
Developing/Augmenting product/service strategies to support the incorporation of CI
Developing/Augmenting a business strategy to provide CI products/services
Making Sound CI Technology Decisions
Figure 1 depicts the high-level process for making sound CI technology decisions. For each prospective CI technology:
Figure out what type of technology is needed,
Estimate its capacity requirements (based on expected breadth and depth of use within the organization),
Make an initial decision on whether to build, buy, or rent the technology (this decision may change based on experimental results),
Test whether it works as expected and works with humans as well as expected.
If so, develop and execute a more complete acquisition and deployment plan. If not, move back as many steps as required and repeat.
Identifying Needs
If the organization has limited awareness of prospective CI technologies, this step should begin with an initial search for prospective solutions.
In all cases, the required technological capability may not yet exist or may be under development. In the first case, the organization must continue using what is in place today or find an alternative. In the second case, an executive decision on whether to be on “the bleeding edge” is required. Depending on the organizational value of the technology and the learning advantage that may accrue, being on the bleeding edge may be warranted.
The type of CI technology required depends on the characteristics of the work assigned. It can be identified through a cascading decision process based on these characteristics, posed as a series of questions, with each answer refining the scope of prospective solutions. Typically, 0-2 prospective technologies remain when all questions have been answered. (The examples below include a representative rather than a complete list of prospective technologies.)
Example 1
Labor Type? Physical – Robot or other intelligent machine.
Work Type? Variable – Need more information (see following characteristic), but variable work requirement excludes several categories of physical machines.
Output Type? Structured (known variances within a fixed structure/process) – Collaborative robot, an easily programmable robot, or a computational model that controls an industrial robot.
Style/Location/Timing Types? Interactive/Co-Located/Synchronous – Collaborative robot.
Example 2
Labor Type? Mental – Software-based intelligence.
Work Type? Variable – Need more information (see following characteristic).
Output Type? Unique – Either prompt-based generative AI or an ML workflow with human oversight and human-in-the-loop feedback.
Style/Location/Timing Types? Independent/Virtual/Asynchronous – ML workflow with human oversight and human-in-the-loop feedback.
Estimating Required Capacity
The unit of work being analyzed can be specific to a single business process (such as managing flow in a mixed-model assembly line) or applicable to many different business processes (such as generating text).
Although the required capacity for the prospective technology could be estimated mathematically (and give a false sense of precision), at this stage, it is better, faster, and easier to make a qualitative judgment using two factors: expected usage per deployment and breadth of deployment (aka, Distribution – see Figure 2).
Selecting Acquisition Strategy
Estimating the future organizational demand for any CI technology informs the decision of whether to build it (and operate it), buy it (and operate it), or rent it (usually via a SaaS provider). But cost is not the only consideration. Others include:
The ease of adoption.
The expected degree to which the CI will contribute to a competitive advantage (this is often related to ease of adoption).
The estimated risks associated with CI adoption and use.
The expected rate of change in the CI technology and its estimated performance curve.
Each of these considerations will be examined in more detail in future articles. Costs are the most important because they determine whether something is worth doing (risk-adjusted economic value calculations) and affect many technology architecture decisions (public/private/hybrid cloud, APIs, microservices, etc.).
Validating via Experimentation
CI technologies are relatively new; they are changing quickly, and their full potential is unknown. These things combine to create a high degree of strategic and operational uncertainty.
One of the best tools for dealing with such uncertainty is strategic experimentation, wherein organizations design and execute a series of quick, inexpensive experiments to reduce the uncertainty around key questions.
The most important questions/uncertainties regarding CI include the following:
Will we be able to get it to work correctly?
Will it work as expected?
Will it provide the expected benefits?
Will the approach scale (relatively) easily and profitably?
Will people like it? (Remember, CI is designed to work with humans. If humans don’t like it, the expected benefits will not accrue or will be limited.)
Will the technology be stable enough to support continuing operations?
Designing and executing one or more effective business experiments provides the organization with data to help answer each of these questions. If outcomes are uncertain, another experiment (or a round of experiments) can be executed to clarify initial results.
If you’d like more information on how to do strategic experimentation, let me know in the comments section. I taught an Executive MBA course on this topic and have done executive briefings for several clients, so I have a lot of material. I could do a webinar or video podcast.
Assessing Outcomes
If the experimental results are favorable, the organization can design and execute an acquisition and deployment strategy. If they are not, depending on the outcomes, the organization may have to experiment with other prospective technologies, reduce the scope of the redesign, or modify its initial acquisition strategy.