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.