Resources > Articles

The Fire Method

implementing the fire method for success

How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation

In December 2010, at a tiny research facility in freezing-cold Rome, New York, U.S. Air Force scientists cut the ribbon on a supercomputer named the Condor Cluster. Operating at 500 TFLOPS—trillion floating-point operations per second—it was the fastest supercomputer in the entire Department of Defense and the thirty-third fastest in the world. Contributing to its awesomeness was the price tag—the Air Force only paid 10 percent of what it would cost for a comparable supercomputer. On top of that, the Condor Cluster uses a mere 10 percent of the electricity typically required by similar machines, which means it’s got a smaller carbon footprint and is less expensive to operate. Not a bad day’s work.

implementing the fire method for successOne other interesting fact about the Condor Cluster: It was built out of 1,760 Sony PlayStations. True story.

In other parts of the Department of Defense, results were decidedly less awesome. Just three months earlier, in September 2010, the U.S. Supreme Court agreed to hear arguments related to the U.S. Navy’s A-12 Avenger airplane, known to some as the Flying Dorito because of its triangular shape. Begun in 1983 and envisioned as an all-weather, carrier-based stealth bomber/attack jet, the Avenger program was terminated in 1991, at which point the Navy had spent $2 billion but received nothing for its money beyond a really exciting case study in failure for students at the Defense Acquisition University.

After almost 20 years of litigation, the nation’s highest court was finally going to consider whether the government’s decision to cancel this bloated project was justified. The resolution was apparently not to be, and in May 2011 the court returned the case to the lower appeals court instead of deciding, so the saga continued.

We could spend all day looking at similar examples from all the military services, highlighting the ups and downs of defense technology. The Army, Navy, Marine Corps, and Air Force all have their own stories of critical new gear being delivered in a matter of weeks, right alongside stories where billions and decades are spent to deliver exactly nothing. Of course, these highs and lows are not limited to the military. NASA has some of the best failure and success stories around. For that matter, the federal government does not have a monopoly here.

Why do some programs deliver their product under budget, while others see their costs expand by orders of magnitude? Why do some deliver ahead of schedule, while others experience endless delay after endless delay? And, most critically, which products work better—the quick and thrifty, or the slow and expensive? Which situation leads to superior equipment?

After a few years of conducting informal research into these questions, I spent 18 months at the Air Force Institute of Technology looking at them more rigorously. The pattern that emerged is this: The most successful project leaders from government and industry alike tend to deliver top-shelf stuff with a skeleton crew, a shoestring budget, and a cannonball schedule. In interviews I read and those I personally conducted, project leaders continually echoed one theme: “We had no time and no money. We were just lucky to have a small team of really creative, dedicated people and we got it done.”

In contrast, project leaders who are cursed with large budgets, large teams, and long schedules generally have a difficult time delivering even a fraction of the promised capability, an outcome often blamed on an excessively cumbersome process. Interestingly, when faced with cancellation due to severe cost overruns and delays, these leaders typically respond, “If I had a little more time and money, I could fix this.”

Yes, those who had the largest budgets were most likely to ask for more money and least likely to deliver an actual working product. Those with the smallest budgets were most likely to have cash left over after delivering 10 pounds of awesome on a five-pound purse. The faster, cheaper stuff also tends to perform better in actual use than the slower, more expensive stuff. The idea that spending less time and money leads to better outcomes sounds a bit like claiming that moderate amounts of red wine and dark chocolate are good for you. Surely this is too good to be true. And yet, as with the aforementioned health benefits, the data are compelling.

We haven’t said much about complexity yet, so let’s remedy that right now. Successful project leaders tend to place a premium on simplicity in their organizations, processes, documentation, and technologies. They tend to view simplicity as a desirable attribute and pursue opportunities to simplify when they are able.

FIRE codifies the practices, principles, and tools used by some of the best technology developers in the world—people who sent spacecraft on intercept courses with asteroids or who built fighter planes that dominated the skies of World War II. FIRE also describes the way clever toy designers teach science lessons that are actually fun.

One final note: While improving one’s process might be a fun way to spend a sunny July afternoon, FIRE is emphatically not a process-improvement initiative. Given the modern popularity of process-improvement methodologies, that last sentiment bears repeating: FIRE is not about process improvement.

The primary objective is to improve our objectives and outcomes rather than our processes. There is a tremendous difference between them. Clever project leaders should certainly make an effort to streamline, simplify and accelerate their processes, but the bulk of their attention is rightfully spent on the product itself and on taking care of the people who make it.

The reason for this is simple. Process-centric improvement efforts have a maddening tendency to be process-centric, despite official protests to the contrary. This myopic orientation frequently overshadows both the team members and the product itself and instead focuses on delivering a set of lovely, full-color, hypothetical process flow diagrams that signify nothing.

In contrast, FIRE is all about helping people make good decisions as we design and create new things. These little guidelines don’t dictate behavior, nor do they represent a step-by-step formula. Good luck trying to build a process flow diagram out of them. Instead, this heuristic approach echoes Visa CEO Dee Hock’s explanation of how he succeeded in founding the Visa credit card association: “We have no precise plan, only a clear sense of direction.”


The four components of FIRE combine to create a heuristic-based approach.

Here’s the meaning for each component:


F Is for Fast

This is about defining a project objective that can be satisfied on a short timeline, not one we know full well will require 20 years to accomplish. But here’s the twist: We must not be content with the superficial appearance of speed, where we appear to be moving quickly but are in fact spinning our wheels or running in the wrong direction. Nor should we pursue speed at the expense of doing good work. This means no cutting corners, no skipping essential steps in the development process. The project is only fast if we do quality work on a short timeline.


I Is for Inexpensive

It’s important to have a small budget. That may be an unpopular position in an environment in which budgets equal prestige, but in my experience, I’ve found that the ability to deliver meaningful capabilities on a shoestring is actually a widely respected skill, even in the cash-rich defense business. Being inexpensive is about designing our organizations and processes with thrift in mind and solving problems with intellectual capital instead of financial capital.


R Is for Restrained

This is the common thread that runs through the whole FIRE concept. It is a preference for self-control, tight budgets and small teams, short schedules, short meetings, and short documents.


E Is for Elegant

The E in FIRE stands for elegant in the sense of “pleasingly ingenious and simple.” It’s important to have a low level of complexity. Embracing elegant simplicity means designing our organizations and processes with simplicity in mind. It’s about stating goals clearly and incorporating mature, proven technologies into our designs. True sophistication, true design maturity, and true process maturity are shown through deep simplicity, not through brain-meltingly complex diagrams and structures.


Book excerpt from F.I.R.E., How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation by Dan Ward. Copyright © 2014 by Dan Ward. All rights reserved. Published by HarperCollins Publishers.


Other Resources in this Series

Most Recent


[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.

Benefits of Bundle Pricing

Bundle pricing is simply a strategy where services or products are packaged together for one (often reduced) price rather than priced separately. This article covers some benefits of bundle pricing followed by a system for getting started.

A Quick Guide to Value-Based Pricing

Value-based pricing begins with knowing the customer’s willingness to pay based on the perceived value of your product. You can charge less than a customer’s willingness to pay, and they feel like they’ve received an

What Is Captive Product Pricing 

If you’re looking for a simple answer, it’s this: captive product pricing is when consumers make a one-time purchase (usually a lower-priced core product) but are required to purchase accessories for the main product to

OTHER ArticleS


[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.



Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

First Name*
Last Name*
Email Address*
Job Title
How can we help you?
Preferred method of contact
Privacy Policy*
Map Your Message to Its Audience with the Communication Compass
Map Your Message to Its Audience with the Communication Compass
Ensure your message hits the mark. This eBook helps you visually map communication styles so you can tailor your design story to a stakeholder or business partner.

Download Ebook

Demystifying Data Projects: A Guide for Business Leaders
While data science is a competitive advantage, data isn’t magic. Learn how to make magic happen by partnering more effectively with data professionals. This eBook delves into types of data projects, sample questions, tools and methods, key points and cautions—so stakeholders like you can initiate data projects with real business impact.

Download Ebook

Define Ebook Thumbnail
What’s the difference between a successful data analysis project and one that falls flat? 

Before you begin working with the data, you need to understand what you’re solving for. Gathering context and aligning around goals with your stakeholders from the outset will help you avoid disconnects and deliver actionable insights. Discover the most vital questions to ask before embarking on a data analysis project in our in-depth guide, “Define: Laying the Foundation for Successful Data Analysis.”

Download Ebook

Download Now