Are your skilled innovators not performing as quickly as you thought they would? I think I know why.
In a previous role, I was a developer and led teams developing part of a dynamic geosciences (reservoir) simulator. Most of the code was in C#, but the heavy math was in C++. While the former made up about 85% of the code, CPU time was overwhelmingly in the latter. In the C# code, we considered security, parameter integrity, class vs. namespace complexity tradeoffs, etc.—the typical considerations of modern coding. Since the C++ code was ―performance sensitive, the primary consideration there was performance. If you made it down there, that code would assume that the caller knew what they were doing and it would perform the function as quickly as possible, throwing an exception if things went awry. The caller had to handle that. The contrast between the two areas was built in by design, to enable performance.
In a previous article, I posited that sustainable innovation can be more efficiently driven by those doing the work and through continuous work flow evolution (as opposed to risky, revolutionary changes that require long iterations to develop, test, and mature). In this column, I extend my earlier comments to suggest how larger organizations can accelerate the benefits from small scale innovators by treating them as performance sensitive.
Challenges, Real Threats
We can acknowledge from the start the risks that may increase as we innovate. Within the energy industry, we have safety critical systems that must not be compromised. We have business sensitive and (highly) confidential information that drives key decisions. Companies within our sector have increasingly become targets of malevolent actors, which could compromise or exploit these systems and information.
Migration to the cloud changes the landscape. Ironically, the move from secure, on-premises computing to the cloud can bring significantly improved security. However, that desired outcome is not ensured merely by moving. Thankfully, with improved cloud services and often by using specialty services, migrations patterns are becoming easier to execute with confidence.
Turning Inward and Friction
Our on-premises approach built in confidence from the hardware, through the operating systems, to various aspects of IT services. Companies using that approach have used expertise to assure secure, reliable service delivery, and, through the years, standardization and optimization have brought efficiencies to the enterprise. Our intent with regard to risk was to understand threats, to minimize customization, and to manage change rigorously through controls, processes, and governance. Like in the castles of the medieval period, valuables were guarded and vulnerabilities were explicitly mitigated.
Good luck on that now. The needed interdependencies with the rest of the world are too many to explicitly know dangers, and, even if such knowledge were available, it would quickly become stale. Your company may prevent you from using USB drives or accessing your private email account on your work device; those actions might mitigate the understood threat, but they certainly will increase friction. When your company’s cloud service or software provides (or is perceived to provide) inadequate cost controls or fails to prevent developers or users from doing risky things, it will be tempting to increase the friction in those processes to prevent undesirable outcomes. But what is certainly true is that a culture of increasing friction on innovators can have a compounding, negative effect on their productivity.
“But Can’t Friction Be Good?”
In auto racing, friction is essential. It enables acceleration. It keeps the car on the track in tight turns. The driver clearly needs brakes. The common theme in all this friction is that it comes into play to help the driver perform. In competitive racing, friction without such a noble purpose is meticulously eliminated.
Is that the culture in your company? Are your innovators given control of a fast car? Are they trained to compete safely so that they can perform in such a car?
A Better Way
The better way is to enable “yes” to two questions for your innovators: Can they use the tools? And do they know the rules?
Enable In-Context Innovation
Recognizing that the fastest and most effective innovation will happen in the actual place where the work is done, have you provided the tools, training, and expectations that those doing the work will drive improvements of the work? This begins with a culture of continuous improvement but will only be realized if your team can access diverse skills, including Lean skills (e.g., value stream mapping, measurements, controls) and whatever will be needed to improve the efficiency and value delivery of the work in their context. The people with these skills may not be dedicated to the team, but they need to be embedded in the team processes if they are to have the depth of insights and interactions required for rapid iteration of the solution.
In my work context, we use a variety of geosciences related technical software, which afford varying levels of automation/innovation capabilities. The best ones offer a variety of approaches, like intuitive work-flow automation requiring very little in what might be considered software development skills, in-application and external-to-application scripting (such as Python, which might be considered in this context a moderately sophisticated software skill), as well as extensibility frameworks or APIs (geared more toward professional
developers). Supporting such a spectrum of approaches can prove advantageous on a broad range of opportunities where the innovation and solution approaches can be tailored to match the need and the team’s skills.
Clear the Path to Sustainability
Once the team has practical innovation capabilities and the culture of innovation is driving continuous improvement, do the innovators know how to achieve sustainability? Often what got you here (rapid prototyping and maturation iterations using in-context innovation) won’t get you there (e.g., standardization, affordability, and supportability). Consider, for example, a case where we use external-to-application Python to automate a work flow. This approach can lead to rapid innovation cycles and quick maturation, but the result may be the modern equivalent of a complex Excel notebook with VBA scripting. How does that Python code become sustainable? It may be that the code gets picked up as a part of a managed library or that it becomes the basis for a redevelopment using an extensibility framework or other managed code. Other considerations, such as data management and support integration, may be necessary to enable the innovation to be scalable, supportable, and sustainable more broadly. Usually, this consolidation phase of innovation requires skills not found in the working teams, but the teams need to be skilled at passing the baton on to those who can provide an enterprise product. Otherwise, the innovation may fail to be profitable at all, as often the initial profitability comes only in replication and standard use.
Focus the Enterprise on Enabling and Sustaining Efficiency and Proven Innovations
Far from “doing” innovation on or to the working teams, the role of the enterprise is to enable and sustain proven innovations that have been matured and derisked in the working teams. The most common problems are easily diagnosed. For example,
- In policy (e.g., licensing, controls), in technology (e.g., software and service selection), and in practice (e.g., standardization, data management, work flows), explicitly consider impacts on efficiency and value delivery as measured in the working teams. If you see decreases in efficiency and value delivery across the organization, it’s a good bet that this is driven by enterprise decisions.
- For measuring innovation success, the key concern is the how well you have sustained and replicated the innovation 6–18 months after introduction. Rather than the number of innovations sustained, a better focus is on the gains in efficiency and value delivery attributed to the systemic innovation that you have sustained. After all, it’s not about the technologies, it’s about a culture that systemically drives improvements in the actual work.
- When considering your opportunity funnel, ideas may (even frequently) fail to progress early in the pipeline, but a properly running factory should consistently be delivering scalable innovations after the improvements have been proven locally and have a predictable path to sustainability. If you fail to see sustained and significant improvements over time, this is likely because of poor (or ineffective) innovation capabilities or an inability to deliver or sustain the innovations, perhaps because of the wrong focus at the enterprise.
Conclusion
Innovators in the working teams are a special class who should not be burdened with the general rules of the enterprise. They are often already the bottleneck to innovation, because they must be concerned with the normal delivery work of the team, but they are also critical to innovation, given their deep insights with the actual work and its potential improvements. When unburdened and given the right tools and training, these local innovators can rapidly prove and mature efficiency and value delivery opportunities, efficiently derisking the innovation path for the enterprise. The work of the enterprise is also essential, but complementary; its focus is to enable the local innovators and to scale and sustain what they have proven.
This column originally appeared in Digital Energy Review, the newsletter of SPE’s Digital Energy Technical Section.
