Inflection Points

In order for you to thrive in the digital environment, you need to understand the implications of the changing technology landscape on your organization. This is the second article in our Technology Radar Echoes, a series where authors share their insights and experience on the technology problems and solutions driving business differentiation for enterprise leaders.   

According to Klaus Schwab, executive chairman of the World Economic Forum, the Fourth Industrial Revolution is underway and driven by technology. Executives in every company, in every corner of the globe, are concerned about how to derive value from this onslaught of technologies—which ones to invest in, which ones to experiment with, which ones impact their business, which ones to ignore. As a technology leader, a portion of your analysis should revolve around determining inflection points, the critical phases of transitions along a technology’s journey from an abstract idea to maturity.
 
Inflection points are the points at which a product becomes a trend (something that will be used by a critical mass and therefore likely to drive value) instead of a fad (something that will fizzle out). It is vital for leaders to determine whether a particular technology is one or the other. Getting in too early may end in costly mistakes, whereas getting in too late may end in competitive disaster.

This article explores inflection points, how companies have fallen into traps in the past, and how to avoid missing your inflection points for product adoption and expansion.

Inflection Point Pitfalls

Cloud is only the latest in a long series of transformative shifts. In the early 1990s, companies that were aggressive about automating previously manual processes reaped big benefits. Companies that adopted technologies like CORBA, Java, Ruby on Rails, or Map/Reduce at just the correct time profited. And it’s not just hard technology: techniques and practices such as Continuous Delivery, DevOps, or the application of Data Science to unlock new value also seem to reach a tipping point. But what defines the correct time to adopt a new technology? When does a technology move from niche to Next Big Thing status?

Finding those points is hard because they vary by technology and how companies consume it. However, it is easy (in hindsight) to find companies that missed important inflection points. Some are about timing, whereas others about trends.

Too Early

Moving too early is a common anti-pattern befalling companies overly aggressive about technology. As an extreme case, Neal once worked with a client who had been on the cutting edge of technology. They built their own application server, web framework in Java, and just about every other bit of infrastructure. At one point, Neal asked if they had built their own operating system, and when they said “No,” he asked, “Why not?!? You built everything else from scratch!”
 
Upon reflection, the company needed capabilities that weren't available, either commercially or via open source, so they built their own, which conferred an advantage—at the time. The problem: when freely available tools became available, they already owned their lovingly hand-crafted infrastructure. Rather than cut over to the more standard stack, they opted to keep their own because of minor differences in approach that seemed, at the time, to be a significant advantage. A decade later, their best developers worked in full-time maintenance mode, fixing their application server, adding features to their web framework, and other mundane chores – slaving away on plumbing, in other words. But the better route for the organization would have been for the best developers to apply their talents toward building better applications, which provide growth opportunities.
 
Today, private clouds are the next technology soon approaching an inflection point. Until now, most private clouds have been built on Infrastructure-as-a-Service. IaaS removed some of the red tape from server provisioning but left development teams with a heavy operational burden. Many of these existing IaaS-based private clouds are held together with custom scripting , but that could be about to change. In the April 2016 Thoughtworks Technology Radar, we noted that many companies are focused on cloud platform initiatives:
 
[...] We suspect that any PaaS built today will not be an end state but rather part of an evolutionary path. Enterprise migration to Cloud and PaaS, while bringing many benefits, has difficulties and challenges…Consumers of these technologies should seek the inflection point that indicates “ready for prime time” for their context and should avoid coupling too tightly to the implementation details of their PaaS.
 
PaaS exhibits all the classic characteristics of a transformative, pervasive technology (a trend, not a fad), but moving too early to has left many companies with expensive, hand-crafted custom solutions instead of powerful platforms.

Too Late

Fred Brooks describes the Second System Syndrome as the tendency of small, elegant, and successful systems to “evolve into elephantine, feature-laden monstrosities” due to inflated expectations of what technology can accomplish. It additionally manifests as analysis paralysis: companies that have lived with the limited Version 1 keep imagining the possibilities of Version 2 – without actually getting around to building Version 2.
 
Neal worked with a company in the late 1990s that had built a booming business printing car maintenance reminders for dealerships. The first system was written in in a proprietary language on a single manufacturer’s hardware. When Neal encountered them, they were on their third ground-up rewrite attempt. For the past decade, they had been building requirements and had failed twice in new technologies, and what they wanted to build was indeed impressive: modernized technology stack, cutting edge workflow management, and other pie in the sky requirements. The problem was that the hardware vendor was out of business and no longer made hardware. Thus, part of operation’s job was to scan eBay for used hard drives and other replacement parts. Eventually, the last computer died before they built the new system, and they closed the company.
 
This is an extreme case of “too late”—they knew for years that their technology was increasingly out of date and they were moving, just not as fast as their technology rusted away beneath them.
 
Back in 2015, the number of mobile-only users exceeded desktop-only users in the US for the first time, so it’s not surprising to hear that “mobile-first” as a web and application development strategy has become mainstream. With mobile-first, the smallest screen is catered for first, with larger screens and desktops receiving an upgraded version of that small screen experience.
 
But if you look at the majority of mainstream enterprises, many have moved too late to adopt the mobile-first mindset. Many websites simply load as-is onto a phone, giving tiny text and a “pinch and zoom” user experience. Some organizations have a separate mobile version, which may or may not work adequately, and in some cases the mobile version may be light years ahead of the (now old and outdated) desktop version!
 
Many organizations have simply reacted too late to the mobile trend and are playing catch-up today.

Picking the Wrong Horse

Sometimes, you pick the correct technology for all the correct reasons at the correct time – but it becomes wrong because of uncontrollable external forces.
 
For example, Smalltalk was the first system to really do object-oriented programming in a serious way in the early 1990s, but languages like C++ and Java ended up dominating the language landscape.
 
As another example, Google Wave was radical new interaction paradigm, allowing people to communicate both in real time and in persistent conversations and included integration to maps, web sites, and so on. Thoughtworks was an early participant in the Wave ecosystem, building a Wave connector for Mingle, our Agile project management tool. Google eventually shuttered Wave due to a lack of traction in the marketplace, leaving early adopters to migrate back to traditional email. Despite Wave’s failure, it may have been a beacon for others—currently Slack is the darling of the “social enterprise” movement, and another technology to evaluate for an inflection point.
 
Often the best technology doesn’t win in the market place. Thus, expertise in choosing technology is only part of the decision process. You must also understand market forces to ensure the horse you’ve chosen can make it to the finish line.

Finding (or Avoiding) Inflection Point Dangers

Inflection points vary by company, market, technology choices, and a wide variety of other factors. For example, investigating advanced concurrency libraries is strategic for a company that does high-volume commodities trading. But it is a distraction for big-data centric insurance companies. How do you identify the inflection points important to your company?

Analyzing Inflection Points 

Your inflection point analysis should provide a framework for making decisions about technology direction in general and specific decisions related to products, architectures, or projects. Ultimately, your goal is to determine: are they fads (so not necessary to chase) or trends (which will gain traction and so should be incorporated)? This decision-making framework includes the following:  a technical maturity assessment, using a tool like the Technology Radar; a market maturity, using a Technology Adoption Model; and an internal assessment of your organization’s goals and initiatives (the preferred adoption model is probably Geoffrey Moore’s revised model described in Crossing the Chasm).
 
Returning to our earlier example, on a technology radar Smalltalk might have earned an “adopt” from a technical perspective. However, from an Adoption Curve perspective Smalltalk hovered over the chasm between Early Adopters and Early Majority. One reason Geoffrey Moore calls this space the Chasm is that many companies (and technologies) fall in, and never get out. Such was the case with Smalltalk.
 
Decisions about what to do at inflection points depend on an organization’s unique goals and initiatives in its market. For instance, you might have several technology experiments going on that are approaching a decision point about incorporating them into a large software development initiative. Incorporating both a technology initiative and a market maturity perspective into that decision process will help. You might even develop guidelines that will focus the team’s decision. For instance, one could be to say that for new digital business initiatives, your company prefers technologies that have reached at least the Trial or Adopt stages on our technology radar and the early majority stage on the technology adoption curve.

Managing Inflection Points

Once you’ve identified your inflection points, you can manage them more effectively with the following strategies:

Be Proactive and Intentional

Constantly reacting to what’s on fire this week is a recipe for poor IT performance. We suggest having a clear roadmap and strategy in place for each of your systems and technologies, clearly articulating the state of that asset and its anticipated life cycle. The roadmap should include your full systems estate—legacy, modern and experimental—and articulate whether you’re continuing to invest in that old system, just keeping the lights on, or actively trying to retire it. 

As an additional note, the “we can’t buy Wang hard drives any more” problem has been significantly reduced by virtualization, only to be replaced with the “what happens when Bob retires?” problem. All three authors have met clients where the primary risk to the business was key employees retiring, and in many cases those employees did retire only to be re-hired on an expensive hourly basis! A better solution would be to incorporate better training and onboarding of new employees as part of the business plan.

Experiment

Plan on making mistakes. However, try to make small mistakes and large successes. Build engineering practices like feature toggles that allow you to be more aggressive with A/B testing, dark launching, canary releasing, and other modern DevOps practices. Remember, you can’t plan away uncertainty—you must experiment with a range of potentially useful technologies. However, since there are so many possibilities, use the market maturity and technical maturity analyses to help determine which experiments to run.

Build a Technologist Infrastructure

Jim once visited a large software company in India that had achieved CMM Level 5. The organization had a comprehensive technical review process that included extensive documentation. However, they had just experienced a disastrous project using technology that was new for them. During the retrospective period, we determined that they had a wonderful technical review process, but none of the reviewers knew anything about the new technology!
 
To be successful at navigating technology inflection points, you must have and nurture a group of technologists who are knowledgeable, adaptable, and have a passion for learning. At Thoughtworks, to put our semi-annual Technology Radar together, an opinionated group of people get together for a week to hash out what goes into the Radar, what comes out, and determine each item’s classification. These are front-line technology experts who get their hands dirty with the nitty gritty of building software every day. The group also needs business analysts who are technology literate and can analyze the market maturity of the technologies, so as to determine how new technologies might impact their organization’s goals and initiatives. The infrastructure also needs to have a collaborative decision making process and feedback mechanisms that address successes and misses.

Move with the Tide

It makes sense for companies to build their own software when a viable alternative doesn't exist and it provides an advantage. However, once a robust, standard, open source alternative is available to solve the same problem, move to it. While it will take time and other resources to make the transition, in the long run it frees your best developers to work on your hardest new problems. Awareness of the inventory of available open source software takes time and effort, but ignoring that resource costs a lot when you must build (and—the real cost—maintain) your own.

Budget for Change

Even with the best people and processes, the uncertainty of the rapid-paced technology environment will lead to mistakes. Budgets need to allow for refactoring and revising. Allocating budgets for revamping technology that is in place and “working” has always been a difficult issue. Unfortunately, the decision has often been presented to business partners as “Do you want new features or higher quality?”—a business outcome versus a technical outcome. You know the typical the answer.
 
The better question is really “Do you want new features or decreased cycle time (defined as the continuous delivery measure of engineering efficiency)?” Business partners push for quicker and quicker response time, but they often don’t realize their feature-oriented decisions push development times in the other direction. Old cranky technology and old cranky code can decimate cycle time. Refactoring and revising should emphasize reducing cycle time, not esoteric improvements in technical quality.

Prefer Adaptability over Predictability

The software development ecosystem exists in a state of constant dynamic equilibrium. Each new innovation or practice may disrupt the status quo, forcing the establishment of a new equilibrium, making predictions impossible. Instead, try to build architectures and applications that respond to change: if change isn’t costly, it becomes easier and more palatable.
 
[Neal, Rebecca Parsons, Thoughtworks CTO, and Patrick Kua, Agile Coach and Senior Developer, are working on a book about Evolutionary Architectures to address adaptability at the architectural level, trying to add evolvability as a common “-ility”.]

Build Your Own Technology Radar

At Thoughtworks, we publish our Technology Radar twice a year, advising readers of our assessment (both good and bad) of the current development landscape. But we also encourage our clients to build their own internal radar, to help understand and assess the efficacy of current technologies and collaboratively build a road map for near-term technology choices. Neal has written a blog about this process, located here. 
 
Your own Technology Radar should reflect the technologies in use in your enterprise, as well as those creating buzz in your industry segment. You’ll need to keep an eye on industry-specific publications as well as mainstream “general tech” press, as input to your Radar. In addition it’s worth attending industry conferences to get a feel for what vendors (and competitors!) are doing with technology.

Going Forward

New technologies arrive at an accelerating pace, but companies must still make hard decisions about adaptation, resource allocation, market forces, and a host of other issues before picking the latest new, shiny tool. The myriad of issues to consider can be daunting, but as you become better at identifying and acting on the inflection points that impact your ecosystem, you make better decisions. These are real forces, with real business and technology outcomes; awareness and intelligent reaction to these inflection points adds clarity to your technology decision processes.