The Strategy Of Speed In IT - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IT Leadership // IT Strategy
07:00 AM
Mark Thiele
Mark Thiele
Connect Directly

The Strategy Of Speed In IT

Speed in developing and delivering applications has obvious benefits, but IT leaders have to know when to move fast and when to proceed with care.

Speed is good, but it can also be bad. Speed for the sake of speed isn’t an answer to anyone’s need any more than a specific technology is the “why” for a project opportunity.  For example, speed is good when you can leverage people, architecture and technology to provide rapid iterations on projects that have real-time benefit potential for the business. However, speed is bad when you apply it to subjects such as architecture and strategy. 

The Importance, Nay the Imperative of Speed

Speed should be considered an imperative for many reasons, not the least of which is corporate competitiveness. The ability of a business to respond immediately to opportunity derived from IoT, big data, AI or VR will likely be the difference between success or failure in the market. Why build solutions that provide real-time information if you don’t have the culture and technical capability to support them?

While it’s true that speed can get you in trouble, if you’re using effective planning and strategy to build your speed of delivery you’re in effect reducing the risk of a “speed bump”.  Building for speed is no different than the science around DevOps. When DevOps is done right you’re not only delivering on shorter cycles but you’re delivering more consistent and resilient solutions.

The benefits of speed can be measured in many ways, but for the sake of this article I’m only worried about the ability to provide time-to-value. Translated, that means you can gain advantage from a new solution more quickly. By shortening the time-to-value you are in effect gaining more value from the solution you’re implementing and in theory you’re enabling improved business performance.

Creating a Speed-based Team

How you go about creating the speed-based IT organization depends on many things, and each organization should make choices based on their situation. If you’re a very large, single application, external customer facing company like a LinkedIn, Facebook, or Paypal you are more likely to make choices that reflect a unique team makeup and value proposition.

Example: Facebook

It almost doesn’t matter what you spend on making your solution and its delivery perfect, because the return on value from 100s of millions of customers can easily justify it.

In the case of an enterprise you might make a different decision relative to how you build your infrastructure, team, and delivery platforms. The average enterprise doesn’t have developers in operations, which means you are likely safer going with a more turnkey-oriented approach to a delivery platform. 

Example: Enterprise

Providing support for tens of thousands of customers for hundreds of applications means that no single application or application set has the volume of demand that justifies the bespoke, perfect infrastructure or management solution to deliver it.

There are dozens of other factors that need to be taken into account as you make your “planning for speed” decisions, and I highly recommend keeping the following as considerations in your planning a platform acquisition effort.

How high do you think the percentage of failures are when you make the project longer than six months?

What about projects that require new staff and skills that need to be pulled from a very competitive market?

Just looking in the mirror, how many of us have “tried” to do a major home remodel on our own? How about rebuilding a car in our garage? Assuming the work was ever finished, do you think you provided “time-to-value” for the deliverable? In other words, how many extra months could you have been driving that fixed up car if you’d had someone who fixes cars for a living do it? When it’s a home project the joy of “the work” is an OK assumption. In your business the joy of “delivery” is what’s appreciated. 

How Do You Apply a Strategy” to Speed?

Think of a racing team’s pit crew. Speed and agility are cornerstones of any race team’s strategy but only in the right places. The pit crew acting quickly when the car arrives is where speed is awesome. Where speed would have been bad is if you had sped through your planning for how to be fast during a pit stop. Driving the car fast is critical to winning the race, but speeding through a safety check or not taking the appropriate time to strategize driving tactics to combat weather conditions or other drivers could be disastrous.

Defining your architecture and organizational structure is critical to your ability to deliver successfully, repeatably with speed.

If we were to compare IT to the race team analogy above how would it look?

The basic message is captured in this quote from Abraham Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

The above planning and strategy options are a very limited list of what should be considered in your effort to build for speed. The question each of us must answer is: Why is speed important to us?

Give Speed a Meaning and a Purpose

You should be looking at time-to-value, not cool, not shiny things. Using the 80/20 rule, look at what solutions you can put in place that allow you to implement a foundational platform for delivery in a way that maximizes the capabilities and resources of your existing organization. There are a million bright shiny objects in the sphere of IT these days, but keep in mind that many of them are projects and technologies, not solutions. If you give speed a strategy – and view it in the larger context of your organization’s goals – speed will serve you very well.  If you don’t; well, I hope you have good air bags and insurance.


Mark Thiele's successful career in IT spans 25 years and has focused on both operating roles and on driving cloud adoption across enterprises of all sizes. Mark has deep industry experience and extensive knowledge of the requirements of policy-driven cloud computing and ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Charlie Babcock
Charlie Babcock,
User Rank: Author
1/27/2017 | 6:14:49 PM
Quick, cheap or right, pick two -- isn't quite 'right'.
Well said, Ron Hodges. You can have it quick, cheap or right, pick two. Also, Mark Thiele's the joy of work is good for an avocation, the joy of delivery is good for a vocation. With perfectionists unwilling to experiment until everything is just right, substitute "correctness" for joy of work and you can see why "right" is sometimes a source of slow delivery. To get it quick and almost right on the first try is a way to add "cheap" to the first formula, because a quick solution that's almost right can be corrected through experience and be producing as a deliverable long before exactly right ever gets delivered.
User Rank: Moderator
1/26/2017 | 12:38:12 PM
Tolerance for risk, and the "iron triangle"
A couple of observations to add to your insights.  One aspect of the desirability of speed is the tolerance for risk the organization has.  If the organization performs functions where errors in applications can have catastrophic consequences, then speed may be secondary to correctness.  Speed can itself mitigate such risks in that if you can fix problems fast after they are identified, this reduces the impact if the risk is realized.  But risk of errors is categorically different in air traffic control than it is in Facebook pages.

This seems to lead back to the old "iron triangle" of "you can have it quick, cheap or right -- pick any two."  While things like Agile development methods and DevOps can alter the relationship between these factors, it won't fundamentally change the nexus of constraints.
How to Create a Successful AI Program
Jessica Davis, Senior Editor, Enterprise Apps,  10/14/2020
Think Like a Chief Innovation Officer and Get Work Done
Joao-Pierre S. Ruth, Senior Writer,  10/13/2020
10 Trends Accelerating Edge Computing
Cynthia Harvey, Freelance Journalist, InformationWeek,  10/8/2020
White Papers
Register for InformationWeek Newsletters
Current Issue
[Special Report] Edge Computing: An IT Platform for the New Enterprise
Edge computing is poised to make a major splash within the next generation of corporate IT architectures. Here's what you need to know!
Flash Poll