The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today.
Let's say you've found some new, good way to do business.
for example. Or Agile Methods in general. Or TDD specifically. Or
use of an ORM.
You read up on it. You build a
spike solution to show that it's more efficient.
You make The Essential
Pitch. You keep it simple and direct.
manager says "that's too Blah-Blah-Blah, we don't want to add the
cost/risk/complexity." Of course, it doesn't matter what specific
things are said. This is management "No #1". We just can't. There is
too much "we" (that is, "I, as a non-technical manager") don't
The first answer must generally be
"No." No manager can agree unless it was their idea before it was your
idea. If they'd already heard of this and ask you to look into it,
then you might get a yes. But if it was your idea first, management
must say "No".
You work some more, you refine
your pitch to address the Blah-Blah-Blah issue and show that it
does not actually increase cost, risk or complexity.
there's no point in trying to pre-empt the initial "No". It has to be
there. You have to get specific objections, so you have to go through
this "No" gate.
The Second No-Gate
make the Address-Your-Concerns Pitch. You elaborate with lots of
what-ifs and alternatives and objections and solutions. Two Powerpoint
slides expand to about a dozen.
A manager says
"I'm not sure that it has the cost-benefit we need to see." This is
management "No #2". We just can't afford it. [Yes, this is a repeat
of the cost argument, but it's different because the expected response
is now different.]
The second answer must
always "raise the bar" from technical issues to monetary issues.
this point, you really can't go too far. There's essentially no
cost-benefit information on any element of any technology stack in use
anywhere. No one sits down and finds the most cost-effective operating
system, the most cost-effective language, the most cost-effective
protocols. There's no data and cost-benefit is not a core part of
approval. It's tangential at best.
the real answer in technology selection always boils down to skills.
Does the organization have the necessary skills? Do they understand it?
work some more, you refine your pitch to address the cost-benefit issue
and show that it does not actually increase cost, may reduce risk, and
have have some tangible benefits.
You make the Cost-Benefit pitch.
You try to keep it factual.
At this point,
you've entered a loop. Essentially, you must be redirected to address
one more concern. That concern, once addressed, won't have the
monetization. Back and forth until something breaks you out of the
You're stuck here because there's no compelling
reason to adopt. Managers talk about cost and risk and benefits and
other vaguely monetary ways to determine if the technology has or
creates value. But those are reasons to say "no", not "yes."
Technology rarely has a compelling monetized business case. It's just a
little better or a little less risky. But that involves change and any
change is inherently more risky than anything else.
the first fax machine was useless until someone else got a fax
So you iterate. Pitch, refine.
some point, you either implement your spike solution, which makes
management's approval a fait accompli, or some force outside IT
(business demand for a new kind of software product, external force from
competitors) compels the organization to make a change.
that there has been no change to the technology itself. JSON was
unacceptable until a customer demanded JSON-format files. Now JSON is
required. The organization, however, has flipped from "No with a
million reasons" to "Yes".
Agile cannot be done
until a customer requires it. TDD has no ROI until someone gets their
project done early because of TDD. An ORM is needless complexity
until the new web framework requires it.
this point, there are a series of steps to go from "acceptable" to
"required" to "standard" to "irreplaceable legacy". Those just as
puzzling as the No-Gates.
isn't possible to finesse this and reduce the frustration. The
organization must resist change until compelled to make the
change. Once compelled, it must then stumble forward as though all the
nay-saying never happened. And what could have been a simple technology
adoption must turn into a morass of competing bad ideas.
we can (and should) continue to find new technology. We can (and will)
make the pitch. We will be shot down.
trick is not to take it personally. Just keep refining so that when the
organization is eventually compelled to adopt, we've already got it
The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today.