Guidelines for Keeping Pace with Innovation and Tech Adoption pdf pdf
Business
Guidelines for Keeping Pace
with Innovation and Tech
Adoption
How to Respond When Competition, Your Customers, and Automation
Come Knocking
Esther Schindler
Guidelines for Keeping Pace with Innovation and Tech Adoption
by Esther Schindler
Copyright © 2017 O’Reilly Media, Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North,
Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales
promotional use. Online editions are also available for most titles
(http://oreilly.com/safari). For more information, contact our
corporate/institutional sales department: 800-998-9938 or
corporate@oreilly.com.
Editor: Laurel Ruma
Production Editor: Nicholas Adams
Copyeditor: Rachel Monaghan
Interior Designer: David Futato
Cover Designer: Randy Comer
December 2016: First Edition
Revision History for the First Edition
2016-11-18: First Release
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc.
Guidelines for Keeping Pace with Innovation and Tech Adoption, the cover
image, and related trade dress are trademarks of O’Reilly Media, Inc.
While the publisher and the author have used good faith efforts to ensure that
the information and instructions contained in this work are accurate, the
publisher and the author disclaim all responsibility for errors or omissions,
including without limitation responsibility for damages resulting from the use
of or reliance on this work. Use of the information and instructions contained
in this work is at your own risk. If any code samples or other technology this
work contains or describes is subject to open source licenses or the
intellectual property rights of others, it is your responsibility to ensure that
your use thereof complies with such licenses and/or rights.
978-1-491-97412-4
[LSI]
Guidelines for Keeping Pace
with Innovation and Tech
Adoption: Don’t Just Fail Fast —
Learn Fast
There are two kinds of fool. One says, “This is old, and therefore good.”
And one says, “This is new, and therefore better.”
Dean Inge
New products, services, and methodologies clamor for our attention. All of
them promise to make our lives easier, to help our teams become more
productive, and to give our companies more opportunity to make money.
Some might even be telling the truth.
We all have guessed about when to climb on board with a new technology,
hot product, lauded programming language, or other hyped item touted as the
latest-and-greatest innovation. Even when the item truly is exciting, adopting
it is a risk no matter what size of business you run or where you stand on the
corporate ladder. If you commit too soon, you may discover that the
innovation doesn’t measure up to its promises, and its failures screw things
up for your own projects. If you jump on board too late, after your
competitors adopt the innovation and work out all the kinks, your
organization may find itself playing catch-up.
This is an age-old problem. A hundred years ago, businesspeople argued
about whether it was the right time to get rid of horse-drawn conveyances and
invest in those newfangled delivery trucks. But they had more time to
contemplate the options. These days, the pace of change is so fast that it’s
hard to learn what an innovation is, much less make a sensible decision about
the right time to adopt it.
It’s not like you have a choice, really. Things are changing all around us, and
we (as individuals and businesses) have to respond, one way or another.
“All organizations change, regardless of whether employees are ‘prepared
and ready,’” says Kirsten Osolind, senior VP at strategy and innovation
consulting firm Reinvention Consulting. “You need to be on a constant quest
to wrestle new efficiencies from existing assets. You need to surf waves of
opportunity. You need to run at the right speed, in the right direction.”
Fortunately, useful guidelines can help us make the “right item, right time”
decisions, and assist in the integration of the new technology into existing
business processes. These suggestions may aid you in recognizing when and
how to implement a technology change.
You Say “Disruptive” As If It’s a Good Thing
In the late 1980s, I was president of a tiny computer user group in rural
Maine. We decided to put on a computer faire — the techie equivalent of
“My dad has a barn; let’s put on a show!” — which ultimately drew about
1,000 people. For a rural coastal community with a traffic light every 40
miles, that’s a lot.
I asked Pete Petersen, the vice president of WordPerfect Corporation, to be
our keynote speaker, in hopes that the guy running the business for the
market-leading word processor would be willing to talk to us. To my delight,
Petersen said yes, even accepting my oh-so-naïve topic suggestion of
prognosticating the future of computers. I remember his predictions to this
day.
“I can’t tell you what future computers are going to look like,” Petersen said.
“But I can tell you this: they’ll be smaller, cheaper, faster, quieter, and more
powerful.”
And he was right. Nearly every technology change in the past 30 years has
fallen into one of those categories. We appreciate anything that’s “smaller,
cheaper, faster, quieter, and more powerful,” whether those qualities apply to
a speedier personal computer, a more efficient software development process,
an RFID chip that communicates useful data across a network, or a SaaS
application inexpensive enough for a small business to afford.
When changes are gradual, they’re easy to weave into “business as usual”
methodologies. It doesn’t cause much stress to replace an aging computer
with a faster model, and you get little corporate pushback if you suggest a
tweak to “the old way of doing things.”
But when we talk of innovation, often we refer to something really new.
The Technology Adoption Curve
Human improvement isn’t always a single moment of discovery in which an
entire worldview changes. Those who study the creative process of
innovation distinguish between incremental enhancements and true game
changers. Clayton Christensen’s The Innovator’s Dilemma (Harvard Business
Review Press, new edition 2016) — which has a terrific four-minute video
summary — calls these sustaining innovations, improvements to “the way
we’ve always done it” and disruptions, unexpected changes to existing
systems that redefine a problem as well as the solution. Everyone was
looking for a better iron lung; instead, Jonas Salk invented the polio vaccine.
Steve Jobs cited Henry Ford as saying, “If I had asked people what they
wanted, they would have said faster horses”; even if the attribution is
inaccurate, the sentiment is not.
Not every disruption is a technology disruption, the way that a new CPU or
medical breakthrough might be. Sometimes the change is a business model or
a methodology. MP3 music players were around for a while, as an expensive
lackluster wannabe product category, a problem looking for a solution. Then
the iPod got it right. With a different business model, Apple integrated
hardware, software, and services; it created both happy consumers and a
technological, musical, and social juggernaut.
Disruption sounds like a marvelous thing when you’re the entrepreneur doing
the disrupting. It means your business is doing something truly unique (and,
one hopes, profitable) to which other organizations must attempt to measure
up. That’s been true for ecommerce, Uber, phone cameras, Software as a
Service (SaaS), social media, and dozens of other revelatory technology and
business model changes.
If you run a business, though, disruption is a bad word. It means shaking up
the status quo, often with an uncertain outcome. Not everyone wants to be
disrupted; most leaders are content to be boringly productive, profitable, and
business-as-usual. Disruptions are time-consuming distractions, at best.
This topic was deeply explored by Everett Rogers, a professor of
communication studies, in his book Diffusion of Innovations (Free Press,
1962), and later cited at length by Geoffrey A. Moore in Crossing the Chasm
(HarperCollins, 1991). They summarized the technology adoption life cycle
by identifying several classes of buyers and users (that would be you):
Innovators (2.5% of the population, according to Rogers)
The first to adopt an innovation, these people often pursue new products
aggressively, while the products are still in development. Technology is
a central interest in their lives, and their endorsement means a lot to
those who follow. These people take risks, they are willing to put up
with fewer product features because of the promise of more to come,
and they accept that some bright ideas fail.
Early adopters (13.5%)
Early adopters adopt the innovation when it’s still new, but no longer
raw. They are tech-literate influencers whose opinions shape others’
decisions. They can imagine, understand, and appreciate a new
technology’s benefits and relate them to other concerns. But, as with the
innovators, early adopters are willing to accept imperfections in the
short term because they see where the innovation is heading.
Early majority (34%)
The entry point to the mainstream, these people share some of the early
adopter’s ability to relate to technology. But, cautions Moore, ultimately
they are driven by a strong sense of practicality. “They want to see wellestablished references before investing substantially,” he wrote.
“Because there are so many people in this segment — roughly one-third
of the whole adoption life cycle — winning their business is key to any
substantial profits and growth.”
Late majority (34%)
This group approaches change with a high degree of skepticism, usually
after the innovation has been accepted in their society. “They wait until
something has become an established standard,” writes Moore, and they
tend to buy from large, well-established companies. (Or, as my mom
used to say, “If it’s so great, why isn’t everybody doing it?”)
Laggards (16%)
Laggards are change averse, and prefer familiarity and tradition. (Get off
my lawn!)
Moore’s chasm theory was mind-blowing when it was first expounded
because he emphasized the wide gulf — that chasm — between the early
adopters and mainstream buyers. In guiding entrepreneurs on how to cross
the divide, Moore went into detail about identifying target markets, product
positioning, building a marketing strategy for each type of adopter, and
choosing the most appropriate distribution channel and pricing.
Christensen, Moore, and Rogers spoke primarily to and for the entrepreneurs,
venture capitalists, and technology early adopters — the people who shape so
much of what the future looks like. For example, “Characteristics of
disruptive businesses, at least in their initial stages, can include: lower gross
margins, smaller target markets, and simpler products and services that may
not appear as attractive as existing solutions when compared against
traditional performance metrics,” wrote Christensen. “Because these lower
tiers of the market offer lower gross margins, they are unattractive to other
firms moving upward in the market, creating space at the bottom of the
market for new disruptive competitors to emerge.”
They and others offer plenty of inspirational material for how inventors can
attract our interest, and I’m happy to leave them to it.
But visionaries and pragmatists have very different expectations — and here
we focus on the practical issues in technology adoption.
The Chasm in Your Company
The point I want to stress is that it is important to recognize that there are
several categories of users and purchasers. Because if you are considering
adopting a new technology, you’re somewhere on that scale.
If you yourself are an early adopter by nature — you taught yourself how to
program in a brand-new programming language, you built your own personal
computer and giggled while you did so, you started a computer user group in
rural Maine — then the “laggard” viewpoint is unfathomable and the
mainstream users seem ridiculously hidebound. Don’t they realize how much
they’re missing?!
Yet your organization — or different departments within it — may have a
different attitude, and you need to take their concerns into account. Whatever
you think of these people individually, you can’t sell them on a major change
without addressing their goals and fears.
Also, these are not hard-and-fast personality traits. You can be an early
adopter in one realm and a laggard in others, even in business terms. For
example, you may be willing to take a bet on a new social media plan, but be
loath to move your customer relationship management system to the cloud.
The consequences of failure are minor in the former case, but could be
devastating in the latter.
In fact, it’s wise to limit the number of innovations you adopt. If nothing else,
changing too many variables at once makes it impossible to discern which
one made the difference.
“There’s a steady stream of ‘cool and new’ things, and if you tried to adopt
every one that came along, you’d be overwhelmed,” says Otto Berkes, CTO
of CA Technologies. “It’s tempting to chase the latest shiny object, and while
doing so may seem like progress, it will ultimately take you off track. It’s just
as important to decide what new things not to adopt as the things you decide
are worth the effort.”
Failure Is Dangerous
Technologies ebb and flow. What was once new and exciting becomes hohum boring and mainstream — in fact, that’s what its inventors hope for —
and eventually it is displaced by the newer and even more exciting.
Case in point: BlackBerry. When the RIM 950 Wireless Handheld came out,
sporting a patented keyboard design that made it easy to type with your
thumbs, owning one was super-cool. A BlackBerry email service followed in
1999, leading some businesses to adopt the technology, since the stepbeyond-pagers demonstrated real productivity benefits. If you owned one (a
friend did), people (by which I mean I) would ask to see it, and would quiz
you about how it worked. By 2006, BlackBerrys had become so mainstream
that users were criticized for their “CrackBerry” addiction.
But RIM couldn’t keep up with iPhone and Android, and it was slow to
deliver on the new versions it promised. And now, BlackBerry says it’s done
designing and building its own phones.
Obviously, BlackBerry’s decline and fall is meaningful to the company
shareholders. But it also illustrates the adoption curve for any business
decision maker. In 2000, suggesting that your company adopt BlackBerry
would make you a forward-thinking iconoclast, and might earn you a raise
and promotion. Ten years later, the same recommendation would mark you as
a hidebound laggard who wasn’t keeping up with the times.
It’s even more dangerous to fall behind on technology when the adoption
curve involves a lot of moving parts and application integration, or the
technology otherwise becomes hard to extract afterward. Bringing in a new
programming language, office productivity software, or network
infrastructure are the easy examples, since each requires ongoing support,
including employees who know how the system works. Replacing a
company’s mobile phones is relatively simple and inexpensive, compared to
rewriting custom applications for a new operating system.
This makes the decision process even more stressful. At what point should a
mobile app developer decide to create a version for a new mobile platform?
Maybe JQuery’s time is done; should a development team adopt TypeScript
instead? On whose say-so? What should they consider before they make the
decision — beyond the techie feature catnip issues?
Nobody wants to bet the house on a new platform that doesn’t take off. I
knew OS/2 developers who realized too late that the market didn’t grow
enough to justify their investment in building applications for IBM’s
operating system. Corporations that did commit to OS/2 (often for the best of
technical reasons — did I mention OS/2 was wonderful?) were forced to
replace it. They also had to buy new Windows or Linux applications, not to
mention the cost of rewriting the custom software they built on top of OS/2,
and then they had to explain all that to the company management to whom
they’d successfully argued that this was the right direction.
This happens at a personal level as well. If you’re a mobile developer of any
experience, you remember when it was obvious that you had to write
software for iPhones, but less clear if you should write a version for
BlackBerry or Android or Windows Phone. In the early stages of a
technology adoption life cycle, it’s nearly impossible to tell which one is
going to take off, and practical limitations (such as developers having only 24
hours in a day during which to write software) sometimes mean you can’t
support every option.
Conservatism Is Okay
Business projects fail regularly even when the technology is understood and
well established. Management mistakes, unreliable suppliers, poorly trained
workers, taken-for-granted assumptions, inadequate budgets, and many other
factors can play havoc with even the best-laid plans, without including,
“Let’s take a chance on that newfangled thing.”
Newfangled things have a long history of failure. The vendor may go out of
business due to lack of funding, often because too few organizations were
ready to invest in something unproven or the pricing model was out of
whack. Their promised technology advantage may not pan out. The
groundbreaking innovation may go against industry standards in an
environment where standards win out.
As a result, it’s easy to make the argument that businesses should adopt wellestablished technologies that offer proven reliability, easy availability,
volume pricing, and adequate useful life — all factors in a CEO’s goal of
reducing the total cost of ownership. It’s a lot easier to sell management on
the “expected” answer.
Being an effective early adopter is a tremendous amount of work. It’s one
thing to buy a consumer item for yourself. For businesses, early adoption
involves a major commitment and can put an organization at more risk.
Really, you can understand why some companies hang back and continue to
rely on “business as usual,” no matter how frustrating it might be to the
people who want to try the latest innovation. “If it ain’t broke, don’t fix it”
often is a wise viewpoint…to a point.
“The company I currently work for has been around for about 30 years,”
explains Jim, its receptionist. “While they do use QuickBooks, they still also
use handwritten time cards. Only a quarter of their work records they have is
backed up in any way.” The company owners have always worked that way.
But, Jim opines, the old-fashioned workflow weakens the infrastructure of
the company, because employee training takes longer, the records are
susceptible to loss or damage, and it’s more difficult to locate files on paper.
“People stopped using handwritten time cards decades ago,” says Jim. “There
have been no major consequences yet, but I think it’s only a matter of time.”
Evaluating the Options
When I asked people for their advice about when to jump on board with a
new technology, the most common response was laughter. “Good luck with
that,” said one friend. “Nobody ever knows.”
Yet we each make these decisions sometimes. We commit to a major shift in
tools, technology, or process, and make those choices using some kind of
criteria, consciously or unconsciously. You might change the core
programming language the team uses, adopt a new environment (such as a
move to the cloud), replace a legacy tool with a more modern one, or start a
project with an unproven gadget (such as seeking a business model using the
Internet of Things). We like to apply some kind of logic to the process, even
if we ultimately go with our guts.
This seems to be the process we each use:
1. Identify the business goals and today’s limitations in addressing
them.
2. Measure the new thing against those goals.
3. Evaluate the impact of the change, for good and ill.
4. What happens if you wait?
5. Make your decision.
6. Implement the change.
We go through this process even when we don’t deliberately identify each
step. Sometimes we use emotional shortcuts that cut to the chase. We can
review a new restaurant in a single sentence (“The food’s good, but it’s not
worth the money.”) or with 2,000 words of in-depth analysis discussing each
item on the menu (particularly its chocolate dessert).
But, ultimately, the decision-making process takes each of these issues into
account.
The many questions I raise below may make it sound as though you should
never adopt anything new. Certainly, these seem critical to my ear. But I raise
these objections because other people in your organization are sure to do so
— and it’s a good idea to have an answer ready. Also, when you realize that
you can honestly respond (to yourself if no one else), “Hey, we’re set with
that; no problem!” you can begin the adoption process with far more
confidence.
A jargon note: by now you understand that the whiz-bang item adoption
might be new hardware, a cloud-based application, a new Agile development
methodology — really almost anything. That’d get unwieldy if I needed to
describe each of these options repetitively. So let’s just refer to the attractive
new technology as the Turbo Ninja Plus, as a generic name for the item
you’re swooning over. Got that? Groovy.
Determine What You Want: Introducing the Turbo Ninja
Plus
“Oh cool!” you might shout, when you first learn about the new opportunity.
“I want me one of those!”
But before you even consider adopting a Turbo Ninja Plus, you have to
determine if it solves any kind of problem you currently experience or that
you expect to experience. And that sends you back to square one of any
business plan: contemplating your goals.
Whether you run a multimillion-dollar enterprise, volunteer with a
community organization, or lead a tiny development team, there is a shared
purpose. It might be, “Create software that makes architects shout with joy”
or “Give homeowners peace of mind” or “Enable payroll professionals to
pass their certification exams” or “Have fun with N-scale model trains” or a
thousand other things. Sometimes people give this a formal label, such as “a
mission statement,” but ultimately you provide something of value, usually
something that people are willing to pay for.
And nearly everything you do is in service to that goal, whether or not you lie
awake at 2:00 am agonizing over it. Which means that the Turbo Ninja Plus
must either contribute to you achieving your goal, or reduce the obstacles that
prevent you from achieving that goal.
The goals and obstacles may present themselves in several ways. For
example, the Turbo Ninja Plus may give customers a new feature they care
about (oh look, more blinking lights — they love blinking lights!). It might
make it easier for you to create those new features (oh look, an application
interface that makes it faster to create brighter blinking lights!). Or it may
remove a barrier that slows or prevents your ability to deliver on the goal
(finally, accounting software that automates our ability to charge customers
for those blinking lights!).
Alexis Davis, founder of H.K. Productions, has a four-step process when the
company contemplates a major tech shift:
1. We revisit our mission.
2. We ask, “How can we best utilize this new technology to better
serve our audience, customers, users?”
3. We research — learning from the best as well as learning from
others’ failures.
4. We put the pieces together to create a plan of execution.
That’s not a bad plan.
Document your process! Take the time to write down your goals — and the
problems that are preventing you from reaching them. Otherwise, you might
buy a solution that’s a great answer — to the wrong question. In addition, the
act of writing down the goals and problems helps you ensure that your team
shares the same perceptions.
Plus, in the long term, you can learn from your own mistakes. Let’s say your
company does adopt the new technology. Two years down the road, look at
this documentation to judge how well you estimated the goals, identified the
problems, and predicted the issues.
For example, Praveen Puri, management consultant and president of Puri
Consulting, listens to his clients describe what they want to do. “I ask them
questions such as, ‘Why do you want to make the change?’ and ‘How is the
customer affected?’ Usually, this is a multistep process, where I have to keep
asking the questions to get the next level of answer.”
The conversation might go something like this:
Client: We want to change the website.
Puri: Why do you want to change the website?
Client: Because it uses an old design.
Puri: How would the change affect the customer?
Client: It will look more modern.
Puri: Do the customers complain about the appearance?
Client: No.
Puri: Will the customer be affected any other way?
Client: Yes, the system will be more secure, so their information is more
secure.
Puri: OK, then it is innovation worth doing.
Measure the Promise Against Your Goals
Sometimes, the situation is obvious: you’re in danger. The existing hardware
keeps crashing, and it’s more expensive to fix than to purchase a new system.
You see a competitor gaining ground and taking business away from you. A
vendor has become unreliable. You recognize that employees are wasting
time (and thus money and energy) because they use different software whose
data is perpetually out of sync.
When you know something has to change, you’re already one step ahead,
because you’re working in service to the team’s goals.
Spreadshirt is an ecommerce platform for on-demand printing of clothing and
accessories. Its platform evolved over more than 10 years, says its CTO,
Guido Laures, beginning as a PHP monolith back in 2003. But, says Laures,
the system reached the “point of no more innovation” in 2013. “Any
improvements or even small new features required major development
efforts,” he says. “Every change had become risky because of the many
interdependencies from rather unrelated parts of the platform. Changing
something at one place caused multiple issues at other places of the
architecture.”
Obviously, something had to change. Even if the existing system generated
significant revenue for Spreadshirt, its fragility was evident. “But how do you
get rid of a system that is unmaintainable but generates millions in revenue?”
Laures asks.
If you have never owned a database before and you see a need to adopt one,
the only issue is, “Which one?” You can make a choice based on your feature
wish list, your budget, and your heart’s desire.
It’s more complex when fixing one problem raises new ones, as Spreadshirt
discovered. Sure, the Turbo Ninja Plus (hypothetically) promises to help your
development team create its products faster, which certainly would make
happier customers and stuff more cash into the company’s coffers. But
adopting it means that staff have to be trained to use the new tool, you have
to upgrade the company’s servers, and you may need to argue with another
department about changing the workflow. Sure, the Turbo Ninja Plus is better
than what you have now — but is it better enough? It might bring in more
money — but are the profits more than the costs?
In either case, you need to investigate the opportunities and measure them
against the team’s mission. It’s a good idea to make a list of the criteria to use
in deciding to jump on board. Whether the Turbo Ninja Plus’s promises
originate with a vendor, from the tech community, or via a fad, often we can
be distracted by features that sound appealing, but can’t demonstrate that they
support the team’s goals.
“The question to ask about anything new is whether it adds real customer
value,” Puri says. “It must either allow customers to do something new that
they want or need, or it must make core functions better, faster, or easier.”
“Remember that innovation is applied creativity,” Puri adds. “Cleverness
which does not add value to the underlying business needs is throwing good
money after bad.”
Sometimes, familiarity rightfully wins out over coolness. “We tried to
implement a new instant messaging solution to address email overload
problems,” says Sushil Kumar, CMO of Robin Systems, a small but growing
company. “There are lots of discussions under way at any given time, which
can form the basis for critical business decisions.” Traditionally these
conversations happen in email threads, which can be difficult to archive and
to share with new employees. Kumar decided to test-drive the newest, coolest
messaging application. “However, we could not get people to use it,” Kumar
says, “partly because of the product issues and partly because of the cultural
issues.” Most users stuck to email, which meant more complexity — since
employees now were having conversations in two places instead of one. “We
therefore decided to abandon the messaging app implementation until we
were ready for it,” Kumar concluded.
That’s why it’s important to understand the value creation process in your
business, says CA Technologies’ Berkes. He suggests answering these
questions:
What specific value will it bring to your customers and your business?
What are the risks? What are the opportunity costs for adoption?
Is it something that you can try to adopt incrementally, or will it require
a “big dig”?
Consider the Consequences of Adoption — and Failure
Many people ask, “How well does it solve the problem or improve our ability
to deliver on our promises?” But there are at least two additional issues to
consider, as you analyze the Turbo Ninja Plus’s suitability to the task.
What consequences would you encounter if you implemented it?
What would happen if you didn’t?
As much as we’re drawn toward new and better solutions, implementing
them affects the way we do business. (If they didn’t, why bother?) We like to
think about the positive effects, such as improved efficiency or faster delivery
time. But what else might happen? How likely is it to occur? What could you
do to ensure the best outcome? What would have to change in order for the
adoption to be a success?
The earlier the innovation appears on the technology adoption curve, the
more often your answer is, “I have no idea,” and the more you should assume
the associated costs are relatively high — at least in the short term.
For example, imagine you are considering adopting a new programming
language that is optimized for part of your knowledge or technology domain.
Only a handful of developers have any level of expertise programming in that
language, so they’re harder to find and they command a higher salary than
the average programmer on your staff. Training resources are difficult too;
nobody’s written a book about the language yet, much less created a track for
it at your favorite programming conference.
Those concerns are balanced, presumably, by the advantages of being first to
market and getting a head start on the learning curve, and by the actual
benefits of the new language. Plus, you don’t want to adopt the technology
too late and miss out on its competitive advantage.
But those advantages are difficult to prove. And what happens if your
assumptions are wrong?
Almost by definition, you are proposing a major change. How comfortable
are the players and stakeholders with the disruption caused by the tech
adoption?
Don’t think only in terms of the managers and other people who have to sign
off, who may never actually touch the new system. Consider the line-ofbusiness worker. For instance, your chief financial officer may decide that
it’s time to replace the expense reporting system. Until now, every employee
has had to email a spreadsheet and PDFs of receipts; that’s a pain for the
accounting staff, especially as it has no useful reporting procedure and they
need to construct their analysis manually. But if you consult only the CFO
and accounting staff about what’s needed in a new SaaS expense-reporting
application, you won’t learn about the features most valued by the employees
who have to use the software.
Unless you meet with each group of people affected by the proposed change,
you also won’t learn about their fears and desires, which absolutely reflects
their willingness to make a change.
The following questions may help you evaluate the consequences.
Technology consequences
Does the Turbo Ninja Plus require you to change infrastructure? What
depends on the current and proposed technology, and what does it
depend on? What do the changes cost, in dollars, time, and complexity?
Will those downstream changes turn into a yak shaving experience?
What’s the reliability of the Turbo Ninja Plus? Based on what metrics,
measured by whom? How does that compare to the current system?
What’s the performance like? How does that affect what happens at a
later stage in the process?
How can you measure its value? How long will it continue to provide
value?
Do you need to provide training? How available is it, at what cost? How
much staff time needs to be budgeted for the training? What work won’t
get done while they’re learning the Turbo Ninja Plus’s intricacies?
How do you judge your team’s ability to implement the change, based
on existing in-house knowledge?
People and team consequences
How much support do you have from company leadership? How much
has the boss bought in to the proposed innovation?
What will it take to convince management of the suggested path? How
do you keep them up to date during the transition? What happens to the
company, project, and your reputation if it fails?
What needs to happen to ensure user acceptance? Especially given that
“new and different” is jarring? How can you overcome resistance to
learning the new technology?
Do you have time to make changes and adjustments?
Process adjustment consequences
How does the innovation affect current processes or procedures? For
whom?
Does this have social implications? Does it mean changes
in collaboration or communication styles?
What are the direct and indirect costs? How does this interweave with
other budgetary priorities?
What is the effect for the development or implementation teams? How
does this affect their existing workload and work stress?
In each case, also ask yourself: what would happen if we waited?
Many of those questions may yield heartening results. For example, if the
Turbo Ninja Plus really is as fast as the vendor promises, your answers
largely may be positive: customers get their products faster, employees aren’t
frustrated by having to respond to downtime problems, and you can break
into new markets.
These questions should raise opportunities, not just challenges.
For example, Puri worked with a major bank that acquired a smaller bank.
“The original plan was to shut down the smaller bank’s banking systems and
switch their customers to the acquiring bank’s system,” Puri says. “They
found, however, that the smaller bank’s software was rated higher on user
surveys. We ended up combining the systems. Now, all their customers use
the smaller bank’s frontend software, while the older bank’s backend
software handles the combined customer volume.”
Even after you resolve all those questions, you still won’t think of everything.
In fact, it’s the problems you didn’t consider that are apt to hurt you the most,
because you put nothing in place to address those issues.
Sell the Change
Let’s say that you personally have concluded that the Turbo Ninja Plus is a
good option. Now you need to convince other people of that direction —
even if the decision is yours to make.
“Successful organizational change requires a shift in perspective,” says
Reinvention Consulting’s Osolind. “Employees become an integral
component of the entire change equation.”
Remember the technology adoption cycle? You might see the opportunity of
the Turbo Ninja Plus, but it is unlikely to be equally evident to everyone in
the company. When you discuss the new option’s advantages and
disadvantages with managers, users, and other stakeholders, consider their
worldviews too.
For example, when you talk with an early adopter about the Turbo Ninja
Plus, you can bring up its technical specifications, its likelihood to give the
company a serious competitive advantage, and the irritation of putting up
with its growing pains. To a technology enthusiast, it’s often worth taking a
chance on something new, and such supporters are happy to invest in at least
a pilot project.
But if you aim to insert something truly new into a corporate environment,
acknowledge your listeners’ mainstream attitudes. The same sales pitch you
gave to the early adopters can turn off conservative decision makers. Buyers
in the early majority can understand practical value, but they want to be
reassured that they aren’t the very first to encounter problems. Stress the
business references and metrics collected by other reputable organizations.
You can comfort these people by citing the Turbo Ninja Plus’s conformance
to industry standards and its sustainable improvements.
Not every person says no because he is a technology laggard. Among the
reasons people prefer to wait before adoption are:
Their needs are latent
While they suffer the same effects as those who are excited about the
proposed improvement, they haven’t actively identified that a solution
exists, let alone considered a product or service. A trusted comrade can
speak to the situation (“We never realized how much time we spent
doing that!”), and hopefully you’re the person with that reputation, but
in general these folks are immune to any marketing beyond word of
mouth. Help them see that they have a problem worth solving, and they
will be ready to consider a solution without friction or interference.
They perceive a high cost of change
That can be monetary: surely the budget can be spent on something with
a safer and predictable outcome? Or we know the product price will
come down when the technology is more established? These people also
may view the cost in terms of the difficulty of moving data and
procedures from one system to another, such as a database transfer or
rewriting code. Consider how your implementation answers each of
these concerns.
They are wary of losing competence
Even minor changes affect employee routines and rituals, such as adding
yet another social media client or recreating an invoicing process. Even
when a dusty old tool is substandard, it’s familiar, and you know how to
work around its foibles. A new system means discovering the new
weaknesses (usually the hard way) without any idea of how to fix the
problems. Yet again, education can make a difference; so can creating
documentation that guides users from the “old way” to the “new way.”
For example, when Microsoft worked (successfully) to displace
WordPerfect with Word in business environments, it emphasized how
easy it was to import WordPerfect files.
“It’s important to address each challenge head on, while making sure
everyone is comfortable with the change,” says Kumar. In practical terms,
you need to build safeguards against unexpected roadblocks or failures.
“Education and realistic expectation setting is key to making sure adoption
happens at a pace that is acceptable,” Kumar says.
“Selling a change impacts the entire ecosystem of an organization, from
employees and customers to strategic partners, vendors, the supply chain, and
processes/procedures,” says Osolind. “Change leadership works best when
you invite the entire ecosystem to help you rewrite the storyline. When folks
make decisions and feel like they are choosing for themselves, they’re more
likely to be committed to the outcome.”
“Beyond communicating a clear vision, allocating the right resources, and
aligning performance management systems, the key to successful
organizational change is removing barriers and creating circumstances in
which employees’ inherent motivation and drive is freed and channeled
toward achievable goals,” says Osolind. “Doing so requires that
aforementioned shift in perspective, where employees at all levels are not
merely informed about change or trained to manage and handle change but
rather deemed to be an integral active component of the entire change
equation. Start a small groundswell. Create a grassroots movement. Train the
trainer. Consider perks for ideas and usage adoption at various levels.”
Some organizations are more open to change than others. For H.K.
Productions’ Davis, opinions are welcomed when backed with proactive
suggestions. “We listen, apply what’s useful, and move forward,” says Davis.
“And as progress is made so are the minds of those who were hesitant in the
beginning.”
Ideally, you’d like to work for a company with a culture of innovation, where
it’s okay to experiment and fail. But that doesn’t have to mean, “Be the
company that takes big chances.”
“Any company has a culture that it should look at as an asset when it’s
contemplating change,” says Dave Gray, management consultant and author
of The Connected Company (O’Reilly, 2014). Those aspects shape decisions,
including the choices you reject.
For example, says Gray, both Nokia and Samsung had similar strengths in
manufacturing. Nokia saw the digital culture on the horizon, so it sold off
everything that wasn’t related to mobile phones, and invested heavily in
software. “They took major risks that were (in retrospect) obvious mistakes,”
says Gray, because the culture of software and manufacturing directs
different kinds of risks.
But instead of repeating Nokia’s mistakes, Samsung recognized its culture
and its capabilities, and chose a different path, says Gray. Samsung’s attitude:
smartphones are coming, and we don’t know who will win — but whoever
wins, they use Samsung hardware, whether it’s a Samsung phone or screen
components that form part of Apple’s supply chain.
“The culture is the huge center of gravity you can use to accelerate on your
path, like spacecraft going around Jupiter,” says Gray. “But often, companies
disregard their greatest asset.”
Consider a Slow-but-Sure Approach
In general, the smoothest solution is to change as little as possible. Try the
Turbo Ninja Plus in only one department, for instance. Use it on only one
product line.
It’s important to discover if the advantages outweigh any costs before you
roll out to the entire company, says Wowza Media Systems’s VP of
engineering, Barry Owen. “Better yet, do a pilot project on one team and
verify if the benefits are real,” he says.
This approach minimizes the disruption by keeping explosions small.
Problems are dealt with locally so that they don’t ripple across the entire
project. It also gives the company an opportunity to identify “Oh, I didn’t
think of that effect” problems and to solve them early, before implementing
across the organization.
Incremental adoption helps avoid several types of risks. Among them are
testing the solution for actual readiness and discovering the transition’s
unanticipated social and environmental issues.
To mitigate the risk of adopting too early, consider:
Performing benchmarking and quality evaluation of the technology
itself.
Measuring the upward compatibility of existing systems to become
informed about the impact of the change.
Creating alternatives, so that a project’s success does not depend on the
new technology being adopted. (For example, create a plan for the
project to still be accomplished with the previous technology, even if the
old technology increases the budget or schedule.)
Measuring and monitoring pilot projects so that project estimation tools
can be refined to reflect early experiences.
Coordinating the new technology’s impact with support tools so that the
entire set continues to work together.
Here’s how Spreadshirt’s Laures went about the process with his ecommerce
upgrade. His situation may include technical decisions and processes that
don’t apply to your own Turbo Ninja Plus, but most of the steps have rough
equivalents.
Define the order of migration
Once Laures and his team committed to modernizing the company’s
technology stack, they defined the order of migration. “We analyzed those
areas of the business that suffered most from the inability to change,” he says.
For example, most of their online marketing directed traffic to the website
frontend. The company’s user experience experts had concepts sitting on the
shelf that could never be implemented because of missing flexibility in the
old, monolithic system.
Migrate only what needs to be touched
“Tech people sometimes tend to work in an all-or-nothing approach,” says
Laures. In their desire to avoid complexity, developers may conclude, “Let’s
start from scratch on a greenfield and switch everything to the new platform
once it is finished.”
If you can swing it, great. But at Spreadshirt that was not the case. “The
monolith consisted of a couple of million code lines covering three different
business models, ERP, and production processes,” explains Laures. A project
to start again from scratch would have taken years, during which the old
system would continue to suffer.
Plus, there are no real guarantees with that methodology. Laures has never
seen a successful Big Bang migration in his career. “Touching only those
components that will be modernized next is a better approach to reduce
complexity, stick to the things that work, and still innovate in certain areas,”
he says.
Minimize synchronization
Once Spreadshirt identified the first component to update, they faced the next
decision. “Besides the Big Bang approach, there are actually two additional
paths to modernization,” Laures points out: duplicate and sync and rip and
integrate.
With “duplicate and sync,” you start from scratch (only for the single
component) and duplicate the business logic within the (in their case) new
microservice. New components can use the new services, without being tied
to the monolith. “To ensure that the service has access to the required data,
database synchronization between the legacy and the new system is set up,”
Laures says. “After that, new frontends can easily integrate with the new
service using modern frontend technologies.”
The alternative approach, “rip and integrate,” tries to avoid error-prone and
expensive data synchronizations by switching off the legacy component after
the new microservice is available and reroutes all clients into the new service.
This approach could also be seen as the last step of a component’s legacy
migration, says Laures.
Assign one team per business concern
Don’t ask the entire company or department to be involved in the change.
One team should own the entire business process. Advises Laures, slicing
team responsibilities along technical layers (the frontend team, service team,
database team) might lead to unintended friction points. And, when problems
arise, it could result in some finger pointing between the dependent teams.
Organize the Transition
Don’t throw a ton of resources at something that seems like it might be a
good idea without concrete evidence of value or customer need, suggests CA
Technology’s Berkes. Start small, and evaluate progress at each stage.
“Accelerate the development of new ideas that are proving their value;
chances are that you’re not the first one with the idea,” he says. “And just as
importantly, stop development of ideas that aren’t working out as hoped to
make room for more promising ones with your limited resources.”
Owen followed this process well when Wowza migrated from one software
development tool to another. The team began with a clear goal: “Modernize
our version control infrastructure and get all teams on the same tool.” It
articulated Git’s benefits to the organization: “Most new hires are much more
familiar with Git than any other tool. And lots of new tools and source
repositories only support Git.”
And then the migration got under way, with these guidelines and activities:
Any new project is started in Git instead of SVN.
Teams using Git help train the teams using SVN on best practices.
Develop a migration strategy and use tools to migrate existing SVN
codebases to Git without any history loss. For example, one product
used sequential build numbers instead of commit hashes; a way to
replicate that in Git was needed.
Make necessary changes to the automated build system.
Practice migration. Fix and repeat as necessary.
Rip off the Band-Aid: “As of Monday we are using Git.”
Note that training came first, so that the developers familiar with SVN didn’t
feel lost with the new tool. Owen’s team also tried to contain the change in a
small group and to ensure the bugs were worked out before, as he puts it, the
Band-Aid was ripped off.
Coping with Change
When we individually grasp the promise of a Turbo Ninja Plus — which
surely is smaller, faster, cheaper, quieter, and more powerful than the
previous technology — quite often we’re tempted to drop everything and
move to the new tool immediately.
But
Guidelines for Keeping Pace
with Innovation and Tech
Adoption
How to Respond When Competition, Your Customers, and Automation
Come Knocking
Esther Schindler
Guidelines for Keeping Pace with Innovation and Tech Adoption
by Esther Schindler
Copyright © 2017 O’Reilly Media, Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North,
Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales
promotional use. Online editions are also available for most titles
(http://oreilly.com/safari). For more information, contact our
corporate/institutional sales department: 800-998-9938 or
corporate@oreilly.com.
Editor: Laurel Ruma
Production Editor: Nicholas Adams
Copyeditor: Rachel Monaghan
Interior Designer: David Futato
Cover Designer: Randy Comer
December 2016: First Edition
Revision History for the First Edition
2016-11-18: First Release
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc.
Guidelines for Keeping Pace with Innovation and Tech Adoption, the cover
image, and related trade dress are trademarks of O’Reilly Media, Inc.
While the publisher and the author have used good faith efforts to ensure that
the information and instructions contained in this work are accurate, the
publisher and the author disclaim all responsibility for errors or omissions,
including without limitation responsibility for damages resulting from the use
of or reliance on this work. Use of the information and instructions contained
in this work is at your own risk. If any code samples or other technology this
work contains or describes is subject to open source licenses or the
intellectual property rights of others, it is your responsibility to ensure that
your use thereof complies with such licenses and/or rights.
978-1-491-97412-4
[LSI]
Guidelines for Keeping Pace
with Innovation and Tech
Adoption: Don’t Just Fail Fast —
Learn Fast
There are two kinds of fool. One says, “This is old, and therefore good.”
And one says, “This is new, and therefore better.”
Dean Inge
New products, services, and methodologies clamor for our attention. All of
them promise to make our lives easier, to help our teams become more
productive, and to give our companies more opportunity to make money.
Some might even be telling the truth.
We all have guessed about when to climb on board with a new technology,
hot product, lauded programming language, or other hyped item touted as the
latest-and-greatest innovation. Even when the item truly is exciting, adopting
it is a risk no matter what size of business you run or where you stand on the
corporate ladder. If you commit too soon, you may discover that the
innovation doesn’t measure up to its promises, and its failures screw things
up for your own projects. If you jump on board too late, after your
competitors adopt the innovation and work out all the kinks, your
organization may find itself playing catch-up.
This is an age-old problem. A hundred years ago, businesspeople argued
about whether it was the right time to get rid of horse-drawn conveyances and
invest in those newfangled delivery trucks. But they had more time to
contemplate the options. These days, the pace of change is so fast that it’s
hard to learn what an innovation is, much less make a sensible decision about
the right time to adopt it.
It’s not like you have a choice, really. Things are changing all around us, and
we (as individuals and businesses) have to respond, one way or another.
“All organizations change, regardless of whether employees are ‘prepared
and ready,’” says Kirsten Osolind, senior VP at strategy and innovation
consulting firm Reinvention Consulting. “You need to be on a constant quest
to wrestle new efficiencies from existing assets. You need to surf waves of
opportunity. You need to run at the right speed, in the right direction.”
Fortunately, useful guidelines can help us make the “right item, right time”
decisions, and assist in the integration of the new technology into existing
business processes. These suggestions may aid you in recognizing when and
how to implement a technology change.
You Say “Disruptive” As If It’s a Good Thing
In the late 1980s, I was president of a tiny computer user group in rural
Maine. We decided to put on a computer faire — the techie equivalent of
“My dad has a barn; let’s put on a show!” — which ultimately drew about
1,000 people. For a rural coastal community with a traffic light every 40
miles, that’s a lot.
I asked Pete Petersen, the vice president of WordPerfect Corporation, to be
our keynote speaker, in hopes that the guy running the business for the
market-leading word processor would be willing to talk to us. To my delight,
Petersen said yes, even accepting my oh-so-naïve topic suggestion of
prognosticating the future of computers. I remember his predictions to this
day.
“I can’t tell you what future computers are going to look like,” Petersen said.
“But I can tell you this: they’ll be smaller, cheaper, faster, quieter, and more
powerful.”
And he was right. Nearly every technology change in the past 30 years has
fallen into one of those categories. We appreciate anything that’s “smaller,
cheaper, faster, quieter, and more powerful,” whether those qualities apply to
a speedier personal computer, a more efficient software development process,
an RFID chip that communicates useful data across a network, or a SaaS
application inexpensive enough for a small business to afford.
When changes are gradual, they’re easy to weave into “business as usual”
methodologies. It doesn’t cause much stress to replace an aging computer
with a faster model, and you get little corporate pushback if you suggest a
tweak to “the old way of doing things.”
But when we talk of innovation, often we refer to something really new.
The Technology Adoption Curve
Human improvement isn’t always a single moment of discovery in which an
entire worldview changes. Those who study the creative process of
innovation distinguish between incremental enhancements and true game
changers. Clayton Christensen’s The Innovator’s Dilemma (Harvard Business
Review Press, new edition 2016) — which has a terrific four-minute video
summary — calls these sustaining innovations, improvements to “the way
we’ve always done it” and disruptions, unexpected changes to existing
systems that redefine a problem as well as the solution. Everyone was
looking for a better iron lung; instead, Jonas Salk invented the polio vaccine.
Steve Jobs cited Henry Ford as saying, “If I had asked people what they
wanted, they would have said faster horses”; even if the attribution is
inaccurate, the sentiment is not.
Not every disruption is a technology disruption, the way that a new CPU or
medical breakthrough might be. Sometimes the change is a business model or
a methodology. MP3 music players were around for a while, as an expensive
lackluster wannabe product category, a problem looking for a solution. Then
the iPod got it right. With a different business model, Apple integrated
hardware, software, and services; it created both happy consumers and a
technological, musical, and social juggernaut.
Disruption sounds like a marvelous thing when you’re the entrepreneur doing
the disrupting. It means your business is doing something truly unique (and,
one hopes, profitable) to which other organizations must attempt to measure
up. That’s been true for ecommerce, Uber, phone cameras, Software as a
Service (SaaS), social media, and dozens of other revelatory technology and
business model changes.
If you run a business, though, disruption is a bad word. It means shaking up
the status quo, often with an uncertain outcome. Not everyone wants to be
disrupted; most leaders are content to be boringly productive, profitable, and
business-as-usual. Disruptions are time-consuming distractions, at best.
This topic was deeply explored by Everett Rogers, a professor of
communication studies, in his book Diffusion of Innovations (Free Press,
1962), and later cited at length by Geoffrey A. Moore in Crossing the Chasm
(HarperCollins, 1991). They summarized the technology adoption life cycle
by identifying several classes of buyers and users (that would be you):
Innovators (2.5% of the population, according to Rogers)
The first to adopt an innovation, these people often pursue new products
aggressively, while the products are still in development. Technology is
a central interest in their lives, and their endorsement means a lot to
those who follow. These people take risks, they are willing to put up
with fewer product features because of the promise of more to come,
and they accept that some bright ideas fail.
Early adopters (13.5%)
Early adopters adopt the innovation when it’s still new, but no longer
raw. They are tech-literate influencers whose opinions shape others’
decisions. They can imagine, understand, and appreciate a new
technology’s benefits and relate them to other concerns. But, as with the
innovators, early adopters are willing to accept imperfections in the
short term because they see where the innovation is heading.
Early majority (34%)
The entry point to the mainstream, these people share some of the early
adopter’s ability to relate to technology. But, cautions Moore, ultimately
they are driven by a strong sense of practicality. “They want to see wellestablished references before investing substantially,” he wrote.
“Because there are so many people in this segment — roughly one-third
of the whole adoption life cycle — winning their business is key to any
substantial profits and growth.”
Late majority (34%)
This group approaches change with a high degree of skepticism, usually
after the innovation has been accepted in their society. “They wait until
something has become an established standard,” writes Moore, and they
tend to buy from large, well-established companies. (Or, as my mom
used to say, “If it’s so great, why isn’t everybody doing it?”)
Laggards (16%)
Laggards are change averse, and prefer familiarity and tradition. (Get off
my lawn!)
Moore’s chasm theory was mind-blowing when it was first expounded
because he emphasized the wide gulf — that chasm — between the early
adopters and mainstream buyers. In guiding entrepreneurs on how to cross
the divide, Moore went into detail about identifying target markets, product
positioning, building a marketing strategy for each type of adopter, and
choosing the most appropriate distribution channel and pricing.
Christensen, Moore, and Rogers spoke primarily to and for the entrepreneurs,
venture capitalists, and technology early adopters — the people who shape so
much of what the future looks like. For example, “Characteristics of
disruptive businesses, at least in their initial stages, can include: lower gross
margins, smaller target markets, and simpler products and services that may
not appear as attractive as existing solutions when compared against
traditional performance metrics,” wrote Christensen. “Because these lower
tiers of the market offer lower gross margins, they are unattractive to other
firms moving upward in the market, creating space at the bottom of the
market for new disruptive competitors to emerge.”
They and others offer plenty of inspirational material for how inventors can
attract our interest, and I’m happy to leave them to it.
But visionaries and pragmatists have very different expectations — and here
we focus on the practical issues in technology adoption.
The Chasm in Your Company
The point I want to stress is that it is important to recognize that there are
several categories of users and purchasers. Because if you are considering
adopting a new technology, you’re somewhere on that scale.
If you yourself are an early adopter by nature — you taught yourself how to
program in a brand-new programming language, you built your own personal
computer and giggled while you did so, you started a computer user group in
rural Maine — then the “laggard” viewpoint is unfathomable and the
mainstream users seem ridiculously hidebound. Don’t they realize how much
they’re missing?!
Yet your organization — or different departments within it — may have a
different attitude, and you need to take their concerns into account. Whatever
you think of these people individually, you can’t sell them on a major change
without addressing their goals and fears.
Also, these are not hard-and-fast personality traits. You can be an early
adopter in one realm and a laggard in others, even in business terms. For
example, you may be willing to take a bet on a new social media plan, but be
loath to move your customer relationship management system to the cloud.
The consequences of failure are minor in the former case, but could be
devastating in the latter.
In fact, it’s wise to limit the number of innovations you adopt. If nothing else,
changing too many variables at once makes it impossible to discern which
one made the difference.
“There’s a steady stream of ‘cool and new’ things, and if you tried to adopt
every one that came along, you’d be overwhelmed,” says Otto Berkes, CTO
of CA Technologies. “It’s tempting to chase the latest shiny object, and while
doing so may seem like progress, it will ultimately take you off track. It’s just
as important to decide what new things not to adopt as the things you decide
are worth the effort.”
Failure Is Dangerous
Technologies ebb and flow. What was once new and exciting becomes hohum boring and mainstream — in fact, that’s what its inventors hope for —
and eventually it is displaced by the newer and even more exciting.
Case in point: BlackBerry. When the RIM 950 Wireless Handheld came out,
sporting a patented keyboard design that made it easy to type with your
thumbs, owning one was super-cool. A BlackBerry email service followed in
1999, leading some businesses to adopt the technology, since the stepbeyond-pagers demonstrated real productivity benefits. If you owned one (a
friend did), people (by which I mean I) would ask to see it, and would quiz
you about how it worked. By 2006, BlackBerrys had become so mainstream
that users were criticized for their “CrackBerry” addiction.
But RIM couldn’t keep up with iPhone and Android, and it was slow to
deliver on the new versions it promised. And now, BlackBerry says it’s done
designing and building its own phones.
Obviously, BlackBerry’s decline and fall is meaningful to the company
shareholders. But it also illustrates the adoption curve for any business
decision maker. In 2000, suggesting that your company adopt BlackBerry
would make you a forward-thinking iconoclast, and might earn you a raise
and promotion. Ten years later, the same recommendation would mark you as
a hidebound laggard who wasn’t keeping up with the times.
It’s even more dangerous to fall behind on technology when the adoption
curve involves a lot of moving parts and application integration, or the
technology otherwise becomes hard to extract afterward. Bringing in a new
programming language, office productivity software, or network
infrastructure are the easy examples, since each requires ongoing support,
including employees who know how the system works. Replacing a
company’s mobile phones is relatively simple and inexpensive, compared to
rewriting custom applications for a new operating system.
This makes the decision process even more stressful. At what point should a
mobile app developer decide to create a version for a new mobile platform?
Maybe JQuery’s time is done; should a development team adopt TypeScript
instead? On whose say-so? What should they consider before they make the
decision — beyond the techie feature catnip issues?
Nobody wants to bet the house on a new platform that doesn’t take off. I
knew OS/2 developers who realized too late that the market didn’t grow
enough to justify their investment in building applications for IBM’s
operating system. Corporations that did commit to OS/2 (often for the best of
technical reasons — did I mention OS/2 was wonderful?) were forced to
replace it. They also had to buy new Windows or Linux applications, not to
mention the cost of rewriting the custom software they built on top of OS/2,
and then they had to explain all that to the company management to whom
they’d successfully argued that this was the right direction.
This happens at a personal level as well. If you’re a mobile developer of any
experience, you remember when it was obvious that you had to write
software for iPhones, but less clear if you should write a version for
BlackBerry or Android or Windows Phone. In the early stages of a
technology adoption life cycle, it’s nearly impossible to tell which one is
going to take off, and practical limitations (such as developers having only 24
hours in a day during which to write software) sometimes mean you can’t
support every option.
Conservatism Is Okay
Business projects fail regularly even when the technology is understood and
well established. Management mistakes, unreliable suppliers, poorly trained
workers, taken-for-granted assumptions, inadequate budgets, and many other
factors can play havoc with even the best-laid plans, without including,
“Let’s take a chance on that newfangled thing.”
Newfangled things have a long history of failure. The vendor may go out of
business due to lack of funding, often because too few organizations were
ready to invest in something unproven or the pricing model was out of
whack. Their promised technology advantage may not pan out. The
groundbreaking innovation may go against industry standards in an
environment where standards win out.
As a result, it’s easy to make the argument that businesses should adopt wellestablished technologies that offer proven reliability, easy availability,
volume pricing, and adequate useful life — all factors in a CEO’s goal of
reducing the total cost of ownership. It’s a lot easier to sell management on
the “expected” answer.
Being an effective early adopter is a tremendous amount of work. It’s one
thing to buy a consumer item for yourself. For businesses, early adoption
involves a major commitment and can put an organization at more risk.
Really, you can understand why some companies hang back and continue to
rely on “business as usual,” no matter how frustrating it might be to the
people who want to try the latest innovation. “If it ain’t broke, don’t fix it”
often is a wise viewpoint…to a point.
“The company I currently work for has been around for about 30 years,”
explains Jim, its receptionist. “While they do use QuickBooks, they still also
use handwritten time cards. Only a quarter of their work records they have is
backed up in any way.” The company owners have always worked that way.
But, Jim opines, the old-fashioned workflow weakens the infrastructure of
the company, because employee training takes longer, the records are
susceptible to loss or damage, and it’s more difficult to locate files on paper.
“People stopped using handwritten time cards decades ago,” says Jim. “There
have been no major consequences yet, but I think it’s only a matter of time.”
Evaluating the Options
When I asked people for their advice about when to jump on board with a
new technology, the most common response was laughter. “Good luck with
that,” said one friend. “Nobody ever knows.”
Yet we each make these decisions sometimes. We commit to a major shift in
tools, technology, or process, and make those choices using some kind of
criteria, consciously or unconsciously. You might change the core
programming language the team uses, adopt a new environment (such as a
move to the cloud), replace a legacy tool with a more modern one, or start a
project with an unproven gadget (such as seeking a business model using the
Internet of Things). We like to apply some kind of logic to the process, even
if we ultimately go with our guts.
This seems to be the process we each use:
1. Identify the business goals and today’s limitations in addressing
them.
2. Measure the new thing against those goals.
3. Evaluate the impact of the change, for good and ill.
4. What happens if you wait?
5. Make your decision.
6. Implement the change.
We go through this process even when we don’t deliberately identify each
step. Sometimes we use emotional shortcuts that cut to the chase. We can
review a new restaurant in a single sentence (“The food’s good, but it’s not
worth the money.”) or with 2,000 words of in-depth analysis discussing each
item on the menu (particularly its chocolate dessert).
But, ultimately, the decision-making process takes each of these issues into
account.
The many questions I raise below may make it sound as though you should
never adopt anything new. Certainly, these seem critical to my ear. But I raise
these objections because other people in your organization are sure to do so
— and it’s a good idea to have an answer ready. Also, when you realize that
you can honestly respond (to yourself if no one else), “Hey, we’re set with
that; no problem!” you can begin the adoption process with far more
confidence.
A jargon note: by now you understand that the whiz-bang item adoption
might be new hardware, a cloud-based application, a new Agile development
methodology — really almost anything. That’d get unwieldy if I needed to
describe each of these options repetitively. So let’s just refer to the attractive
new technology as the Turbo Ninja Plus, as a generic name for the item
you’re swooning over. Got that? Groovy.
Determine What You Want: Introducing the Turbo Ninja
Plus
“Oh cool!” you might shout, when you first learn about the new opportunity.
“I want me one of those!”
But before you even consider adopting a Turbo Ninja Plus, you have to
determine if it solves any kind of problem you currently experience or that
you expect to experience. And that sends you back to square one of any
business plan: contemplating your goals.
Whether you run a multimillion-dollar enterprise, volunteer with a
community organization, or lead a tiny development team, there is a shared
purpose. It might be, “Create software that makes architects shout with joy”
or “Give homeowners peace of mind” or “Enable payroll professionals to
pass their certification exams” or “Have fun with N-scale model trains” or a
thousand other things. Sometimes people give this a formal label, such as “a
mission statement,” but ultimately you provide something of value, usually
something that people are willing to pay for.
And nearly everything you do is in service to that goal, whether or not you lie
awake at 2:00 am agonizing over it. Which means that the Turbo Ninja Plus
must either contribute to you achieving your goal, or reduce the obstacles that
prevent you from achieving that goal.
The goals and obstacles may present themselves in several ways. For
example, the Turbo Ninja Plus may give customers a new feature they care
about (oh look, more blinking lights — they love blinking lights!). It might
make it easier for you to create those new features (oh look, an application
interface that makes it faster to create brighter blinking lights!). Or it may
remove a barrier that slows or prevents your ability to deliver on the goal
(finally, accounting software that automates our ability to charge customers
for those blinking lights!).
Alexis Davis, founder of H.K. Productions, has a four-step process when the
company contemplates a major tech shift:
1. We revisit our mission.
2. We ask, “How can we best utilize this new technology to better
serve our audience, customers, users?”
3. We research — learning from the best as well as learning from
others’ failures.
4. We put the pieces together to create a plan of execution.
That’s not a bad plan.
Document your process! Take the time to write down your goals — and the
problems that are preventing you from reaching them. Otherwise, you might
buy a solution that’s a great answer — to the wrong question. In addition, the
act of writing down the goals and problems helps you ensure that your team
shares the same perceptions.
Plus, in the long term, you can learn from your own mistakes. Let’s say your
company does adopt the new technology. Two years down the road, look at
this documentation to judge how well you estimated the goals, identified the
problems, and predicted the issues.
For example, Praveen Puri, management consultant and president of Puri
Consulting, listens to his clients describe what they want to do. “I ask them
questions such as, ‘Why do you want to make the change?’ and ‘How is the
customer affected?’ Usually, this is a multistep process, where I have to keep
asking the questions to get the next level of answer.”
The conversation might go something like this:
Client: We want to change the website.
Puri: Why do you want to change the website?
Client: Because it uses an old design.
Puri: How would the change affect the customer?
Client: It will look more modern.
Puri: Do the customers complain about the appearance?
Client: No.
Puri: Will the customer be affected any other way?
Client: Yes, the system will be more secure, so their information is more
secure.
Puri: OK, then it is innovation worth doing.
Measure the Promise Against Your Goals
Sometimes, the situation is obvious: you’re in danger. The existing hardware
keeps crashing, and it’s more expensive to fix than to purchase a new system.
You see a competitor gaining ground and taking business away from you. A
vendor has become unreliable. You recognize that employees are wasting
time (and thus money and energy) because they use different software whose
data is perpetually out of sync.
When you know something has to change, you’re already one step ahead,
because you’re working in service to the team’s goals.
Spreadshirt is an ecommerce platform for on-demand printing of clothing and
accessories. Its platform evolved over more than 10 years, says its CTO,
Guido Laures, beginning as a PHP monolith back in 2003. But, says Laures,
the system reached the “point of no more innovation” in 2013. “Any
improvements or even small new features required major development
efforts,” he says. “Every change had become risky because of the many
interdependencies from rather unrelated parts of the platform. Changing
something at one place caused multiple issues at other places of the
architecture.”
Obviously, something had to change. Even if the existing system generated
significant revenue for Spreadshirt, its fragility was evident. “But how do you
get rid of a system that is unmaintainable but generates millions in revenue?”
Laures asks.
If you have never owned a database before and you see a need to adopt one,
the only issue is, “Which one?” You can make a choice based on your feature
wish list, your budget, and your heart’s desire.
It’s more complex when fixing one problem raises new ones, as Spreadshirt
discovered. Sure, the Turbo Ninja Plus (hypothetically) promises to help your
development team create its products faster, which certainly would make
happier customers and stuff more cash into the company’s coffers. But
adopting it means that staff have to be trained to use the new tool, you have
to upgrade the company’s servers, and you may need to argue with another
department about changing the workflow. Sure, the Turbo Ninja Plus is better
than what you have now — but is it better enough? It might bring in more
money — but are the profits more than the costs?
In either case, you need to investigate the opportunities and measure them
against the team’s mission. It’s a good idea to make a list of the criteria to use
in deciding to jump on board. Whether the Turbo Ninja Plus’s promises
originate with a vendor, from the tech community, or via a fad, often we can
be distracted by features that sound appealing, but can’t demonstrate that they
support the team’s goals.
“The question to ask about anything new is whether it adds real customer
value,” Puri says. “It must either allow customers to do something new that
they want or need, or it must make core functions better, faster, or easier.”
“Remember that innovation is applied creativity,” Puri adds. “Cleverness
which does not add value to the underlying business needs is throwing good
money after bad.”
Sometimes, familiarity rightfully wins out over coolness. “We tried to
implement a new instant messaging solution to address email overload
problems,” says Sushil Kumar, CMO of Robin Systems, a small but growing
company. “There are lots of discussions under way at any given time, which
can form the basis for critical business decisions.” Traditionally these
conversations happen in email threads, which can be difficult to archive and
to share with new employees. Kumar decided to test-drive the newest, coolest
messaging application. “However, we could not get people to use it,” Kumar
says, “partly because of the product issues and partly because of the cultural
issues.” Most users stuck to email, which meant more complexity — since
employees now were having conversations in two places instead of one. “We
therefore decided to abandon the messaging app implementation until we
were ready for it,” Kumar concluded.
That’s why it’s important to understand the value creation process in your
business, says CA Technologies’ Berkes. He suggests answering these
questions:
What specific value will it bring to your customers and your business?
What are the risks? What are the opportunity costs for adoption?
Is it something that you can try to adopt incrementally, or will it require
a “big dig”?
Consider the Consequences of Adoption — and Failure
Many people ask, “How well does it solve the problem or improve our ability
to deliver on our promises?” But there are at least two additional issues to
consider, as you analyze the Turbo Ninja Plus’s suitability to the task.
What consequences would you encounter if you implemented it?
What would happen if you didn’t?
As much as we’re drawn toward new and better solutions, implementing
them affects the way we do business. (If they didn’t, why bother?) We like to
think about the positive effects, such as improved efficiency or faster delivery
time. But what else might happen? How likely is it to occur? What could you
do to ensure the best outcome? What would have to change in order for the
adoption to be a success?
The earlier the innovation appears on the technology adoption curve, the
more often your answer is, “I have no idea,” and the more you should assume
the associated costs are relatively high — at least in the short term.
For example, imagine you are considering adopting a new programming
language that is optimized for part of your knowledge or technology domain.
Only a handful of developers have any level of expertise programming in that
language, so they’re harder to find and they command a higher salary than
the average programmer on your staff. Training resources are difficult too;
nobody’s written a book about the language yet, much less created a track for
it at your favorite programming conference.
Those concerns are balanced, presumably, by the advantages of being first to
market and getting a head start on the learning curve, and by the actual
benefits of the new language. Plus, you don’t want to adopt the technology
too late and miss out on its competitive advantage.
But those advantages are difficult to prove. And what happens if your
assumptions are wrong?
Almost by definition, you are proposing a major change. How comfortable
are the players and stakeholders with the disruption caused by the tech
adoption?
Don’t think only in terms of the managers and other people who have to sign
off, who may never actually touch the new system. Consider the line-ofbusiness worker. For instance, your chief financial officer may decide that
it’s time to replace the expense reporting system. Until now, every employee
has had to email a spreadsheet and PDFs of receipts; that’s a pain for the
accounting staff, especially as it has no useful reporting procedure and they
need to construct their analysis manually. But if you consult only the CFO
and accounting staff about what’s needed in a new SaaS expense-reporting
application, you won’t learn about the features most valued by the employees
who have to use the software.
Unless you meet with each group of people affected by the proposed change,
you also won’t learn about their fears and desires, which absolutely reflects
their willingness to make a change.
The following questions may help you evaluate the consequences.
Technology consequences
Does the Turbo Ninja Plus require you to change infrastructure? What
depends on the current and proposed technology, and what does it
depend on? What do the changes cost, in dollars, time, and complexity?
Will those downstream changes turn into a yak shaving experience?
What’s the reliability of the Turbo Ninja Plus? Based on what metrics,
measured by whom? How does that compare to the current system?
What’s the performance like? How does that affect what happens at a
later stage in the process?
How can you measure its value? How long will it continue to provide
value?
Do you need to provide training? How available is it, at what cost? How
much staff time needs to be budgeted for the training? What work won’t
get done while they’re learning the Turbo Ninja Plus’s intricacies?
How do you judge your team’s ability to implement the change, based
on existing in-house knowledge?
People and team consequences
How much support do you have from company leadership? How much
has the boss bought in to the proposed innovation?
What will it take to convince management of the suggested path? How
do you keep them up to date during the transition? What happens to the
company, project, and your reputation if it fails?
What needs to happen to ensure user acceptance? Especially given that
“new and different” is jarring? How can you overcome resistance to
learning the new technology?
Do you have time to make changes and adjustments?
Process adjustment consequences
How does the innovation affect current processes or procedures? For
whom?
Does this have social implications? Does it mean changes
in collaboration or communication styles?
What are the direct and indirect costs? How does this interweave with
other budgetary priorities?
What is the effect for the development or implementation teams? How
does this affect their existing workload and work stress?
In each case, also ask yourself: what would happen if we waited?
Many of those questions may yield heartening results. For example, if the
Turbo Ninja Plus really is as fast as the vendor promises, your answers
largely may be positive: customers get their products faster, employees aren’t
frustrated by having to respond to downtime problems, and you can break
into new markets.
These questions should raise opportunities, not just challenges.
For example, Puri worked with a major bank that acquired a smaller bank.
“The original plan was to shut down the smaller bank’s banking systems and
switch their customers to the acquiring bank’s system,” Puri says. “They
found, however, that the smaller bank’s software was rated higher on user
surveys. We ended up combining the systems. Now, all their customers use
the smaller bank’s frontend software, while the older bank’s backend
software handles the combined customer volume.”
Even after you resolve all those questions, you still won’t think of everything.
In fact, it’s the problems you didn’t consider that are apt to hurt you the most,
because you put nothing in place to address those issues.
Sell the Change
Let’s say that you personally have concluded that the Turbo Ninja Plus is a
good option. Now you need to convince other people of that direction —
even if the decision is yours to make.
“Successful organizational change requires a shift in perspective,” says
Reinvention Consulting’s Osolind. “Employees become an integral
component of the entire change equation.”
Remember the technology adoption cycle? You might see the opportunity of
the Turbo Ninja Plus, but it is unlikely to be equally evident to everyone in
the company. When you discuss the new option’s advantages and
disadvantages with managers, users, and other stakeholders, consider their
worldviews too.
For example, when you talk with an early adopter about the Turbo Ninja
Plus, you can bring up its technical specifications, its likelihood to give the
company a serious competitive advantage, and the irritation of putting up
with its growing pains. To a technology enthusiast, it’s often worth taking a
chance on something new, and such supporters are happy to invest in at least
a pilot project.
But if you aim to insert something truly new into a corporate environment,
acknowledge your listeners’ mainstream attitudes. The same sales pitch you
gave to the early adopters can turn off conservative decision makers. Buyers
in the early majority can understand practical value, but they want to be
reassured that they aren’t the very first to encounter problems. Stress the
business references and metrics collected by other reputable organizations.
You can comfort these people by citing the Turbo Ninja Plus’s conformance
to industry standards and its sustainable improvements.
Not every person says no because he is a technology laggard. Among the
reasons people prefer to wait before adoption are:
Their needs are latent
While they suffer the same effects as those who are excited about the
proposed improvement, they haven’t actively identified that a solution
exists, let alone considered a product or service. A trusted comrade can
speak to the situation (“We never realized how much time we spent
doing that!”), and hopefully you’re the person with that reputation, but
in general these folks are immune to any marketing beyond word of
mouth. Help them see that they have a problem worth solving, and they
will be ready to consider a solution without friction or interference.
They perceive a high cost of change
That can be monetary: surely the budget can be spent on something with
a safer and predictable outcome? Or we know the product price will
come down when the technology is more established? These people also
may view the cost in terms of the difficulty of moving data and
procedures from one system to another, such as a database transfer or
rewriting code. Consider how your implementation answers each of
these concerns.
They are wary of losing competence
Even minor changes affect employee routines and rituals, such as adding
yet another social media client or recreating an invoicing process. Even
when a dusty old tool is substandard, it’s familiar, and you know how to
work around its foibles. A new system means discovering the new
weaknesses (usually the hard way) without any idea of how to fix the
problems. Yet again, education can make a difference; so can creating
documentation that guides users from the “old way” to the “new way.”
For example, when Microsoft worked (successfully) to displace
WordPerfect with Word in business environments, it emphasized how
easy it was to import WordPerfect files.
“It’s important to address each challenge head on, while making sure
everyone is comfortable with the change,” says Kumar. In practical terms,
you need to build safeguards against unexpected roadblocks or failures.
“Education and realistic expectation setting is key to making sure adoption
happens at a pace that is acceptable,” Kumar says.
“Selling a change impacts the entire ecosystem of an organization, from
employees and customers to strategic partners, vendors, the supply chain, and
processes/procedures,” says Osolind. “Change leadership works best when
you invite the entire ecosystem to help you rewrite the storyline. When folks
make decisions and feel like they are choosing for themselves, they’re more
likely to be committed to the outcome.”
“Beyond communicating a clear vision, allocating the right resources, and
aligning performance management systems, the key to successful
organizational change is removing barriers and creating circumstances in
which employees’ inherent motivation and drive is freed and channeled
toward achievable goals,” says Osolind. “Doing so requires that
aforementioned shift in perspective, where employees at all levels are not
merely informed about change or trained to manage and handle change but
rather deemed to be an integral active component of the entire change
equation. Start a small groundswell. Create a grassroots movement. Train the
trainer. Consider perks for ideas and usage adoption at various levels.”
Some organizations are more open to change than others. For H.K.
Productions’ Davis, opinions are welcomed when backed with proactive
suggestions. “We listen, apply what’s useful, and move forward,” says Davis.
“And as progress is made so are the minds of those who were hesitant in the
beginning.”
Ideally, you’d like to work for a company with a culture of innovation, where
it’s okay to experiment and fail. But that doesn’t have to mean, “Be the
company that takes big chances.”
“Any company has a culture that it should look at as an asset when it’s
contemplating change,” says Dave Gray, management consultant and author
of The Connected Company (O’Reilly, 2014). Those aspects shape decisions,
including the choices you reject.
For example, says Gray, both Nokia and Samsung had similar strengths in
manufacturing. Nokia saw the digital culture on the horizon, so it sold off
everything that wasn’t related to mobile phones, and invested heavily in
software. “They took major risks that were (in retrospect) obvious mistakes,”
says Gray, because the culture of software and manufacturing directs
different kinds of risks.
But instead of repeating Nokia’s mistakes, Samsung recognized its culture
and its capabilities, and chose a different path, says Gray. Samsung’s attitude:
smartphones are coming, and we don’t know who will win — but whoever
wins, they use Samsung hardware, whether it’s a Samsung phone or screen
components that form part of Apple’s supply chain.
“The culture is the huge center of gravity you can use to accelerate on your
path, like spacecraft going around Jupiter,” says Gray. “But often, companies
disregard their greatest asset.”
Consider a Slow-but-Sure Approach
In general, the smoothest solution is to change as little as possible. Try the
Turbo Ninja Plus in only one department, for instance. Use it on only one
product line.
It’s important to discover if the advantages outweigh any costs before you
roll out to the entire company, says Wowza Media Systems’s VP of
engineering, Barry Owen. “Better yet, do a pilot project on one team and
verify if the benefits are real,” he says.
This approach minimizes the disruption by keeping explosions small.
Problems are dealt with locally so that they don’t ripple across the entire
project. It also gives the company an opportunity to identify “Oh, I didn’t
think of that effect” problems and to solve them early, before implementing
across the organization.
Incremental adoption helps avoid several types of risks. Among them are
testing the solution for actual readiness and discovering the transition’s
unanticipated social and environmental issues.
To mitigate the risk of adopting too early, consider:
Performing benchmarking and quality evaluation of the technology
itself.
Measuring the upward compatibility of existing systems to become
informed about the impact of the change.
Creating alternatives, so that a project’s success does not depend on the
new technology being adopted. (For example, create a plan for the
project to still be accomplished with the previous technology, even if the
old technology increases the budget or schedule.)
Measuring and monitoring pilot projects so that project estimation tools
can be refined to reflect early experiences.
Coordinating the new technology’s impact with support tools so that the
entire set continues to work together.
Here’s how Spreadshirt’s Laures went about the process with his ecommerce
upgrade. His situation may include technical decisions and processes that
don’t apply to your own Turbo Ninja Plus, but most of the steps have rough
equivalents.
Define the order of migration
Once Laures and his team committed to modernizing the company’s
technology stack, they defined the order of migration. “We analyzed those
areas of the business that suffered most from the inability to change,” he says.
For example, most of their online marketing directed traffic to the website
frontend. The company’s user experience experts had concepts sitting on the
shelf that could never be implemented because of missing flexibility in the
old, monolithic system.
Migrate only what needs to be touched
“Tech people sometimes tend to work in an all-or-nothing approach,” says
Laures. In their desire to avoid complexity, developers may conclude, “Let’s
start from scratch on a greenfield and switch everything to the new platform
once it is finished.”
If you can swing it, great. But at Spreadshirt that was not the case. “The
monolith consisted of a couple of million code lines covering three different
business models, ERP, and production processes,” explains Laures. A project
to start again from scratch would have taken years, during which the old
system would continue to suffer.
Plus, there are no real guarantees with that methodology. Laures has never
seen a successful Big Bang migration in his career. “Touching only those
components that will be modernized next is a better approach to reduce
complexity, stick to the things that work, and still innovate in certain areas,”
he says.
Minimize synchronization
Once Spreadshirt identified the first component to update, they faced the next
decision. “Besides the Big Bang approach, there are actually two additional
paths to modernization,” Laures points out: duplicate and sync and rip and
integrate.
With “duplicate and sync,” you start from scratch (only for the single
component) and duplicate the business logic within the (in their case) new
microservice. New components can use the new services, without being tied
to the monolith. “To ensure that the service has access to the required data,
database synchronization between the legacy and the new system is set up,”
Laures says. “After that, new frontends can easily integrate with the new
service using modern frontend technologies.”
The alternative approach, “rip and integrate,” tries to avoid error-prone and
expensive data synchronizations by switching off the legacy component after
the new microservice is available and reroutes all clients into the new service.
This approach could also be seen as the last step of a component’s legacy
migration, says Laures.
Assign one team per business concern
Don’t ask the entire company or department to be involved in the change.
One team should own the entire business process. Advises Laures, slicing
team responsibilities along technical layers (the frontend team, service team,
database team) might lead to unintended friction points. And, when problems
arise, it could result in some finger pointing between the dependent teams.
Organize the Transition
Don’t throw a ton of resources at something that seems like it might be a
good idea without concrete evidence of value or customer need, suggests CA
Technology’s Berkes. Start small, and evaluate progress at each stage.
“Accelerate the development of new ideas that are proving their value;
chances are that you’re not the first one with the idea,” he says. “And just as
importantly, stop development of ideas that aren’t working out as hoped to
make room for more promising ones with your limited resources.”
Owen followed this process well when Wowza migrated from one software
development tool to another. The team began with a clear goal: “Modernize
our version control infrastructure and get all teams on the same tool.” It
articulated Git’s benefits to the organization: “Most new hires are much more
familiar with Git than any other tool. And lots of new tools and source
repositories only support Git.”
And then the migration got under way, with these guidelines and activities:
Any new project is started in Git instead of SVN.
Teams using Git help train the teams using SVN on best practices.
Develop a migration strategy and use tools to migrate existing SVN
codebases to Git without any history loss. For example, one product
used sequential build numbers instead of commit hashes; a way to
replicate that in Git was needed.
Make necessary changes to the automated build system.
Practice migration. Fix and repeat as necessary.
Rip off the Band-Aid: “As of Monday we are using Git.”
Note that training came first, so that the developers familiar with SVN didn’t
feel lost with the new tool. Owen’s team also tried to contain the change in a
small group and to ensure the bugs were worked out before, as he puts it, the
Band-Aid was ripped off.
Coping with Change
When we individually grasp the promise of a Turbo Ninja Plus — which
surely is smaller, faster, cheaper, quieter, and more powerful than the
previous technology — quite often we’re tempted to drop everything and
move to the new tool immediately.
But