My book F.I.R.E. introduces specific techniques and practices to simplify, streamline, and accelerate our efforts to innovate. These practical tools equip us to make wise decisions about our processes, organizational structures, communication methods, and technical designs.

For example, the stormdraining technique is a group brain-hack designed to counterbalance the less productive aspects of brainstorming. It basically stands brainstorming on its head and provides a few simple rules to help us reduce a large collection of ideas down to the most important few. Instead of encouraging the addition of new ideas as in brainstorming, stormdraining encourages creative deletion and rewards participants for removing superfluous elements from a design.

Stormdraining is an example of a “reductive thinking” method, one of several such methods introduced in the book. The practice of reductive thinking involves creation through subtraction, like a sculptor chipping away at a block of marble, instead of the more common practice of creation through addition, like an engineer adding new features, parts and functions.

The innovation tools and techniques in F.I.R.E. are summed up in a collection of heuristics. These memorable little rules of thumb aim to help guide our decision making as we address technical and organizational challenges alike. While this brief manifesto doesn’t have room for them all, here are a few to get things started:

If the schedule gets longer, you’re doing it wrong-er

This heuristic helps us see whether we are heading in the right direction by assessing the project’s approach to time. Is the team determined to maintain its schedule and maybe even beat the deadline? Or are delays accepted as inevitable or—even worse—desirable?

It turns out delaying a project’s delivery date in response to difficulty is a demonstrably ineffective problem-solving technique, to say nothing of being inefficient. Despite the dismal track record of this approach, adding more time to a schedule is also a very common strategy in large organizations, particularly among projects that have a long timeline to begin with.

Tolerating delays is a great way to encourage status-quo thinking, which is not exactly compatible with innovation. In contrast, setting a firm deadline acts as a forcing function for creativity and helps nudge teams in new directions, particularly if the deadline is closer than seems reasonable. Interestingly, projects that start with short schedules are least likely to ask for more time and instead tend to finish early, whereas projects with long timelines are most likely to ask for delays. Why? Because placing a premium on speed tends to encourage even more speed, while establishing a distant completion date does the opposite.

The more you delay, the more you will pay

Long timelines expose projects to more changes than short timelines. Technologies change, markets change and economic situations change. Responding to these changes can be expensive, not only in terms of dollars but also in the amount of intellectual investment required. The most impactful and successful innovations tend to be produced by small teams with short schedules, tight budgets, and strong commitments to simplicity. 

Further, the longer the schedule, the more opportunities we have to add new features and functions to the project, increasing the overall complexity of our design. Some of these additions will be a response to emerging technologies or market requirements, but others are simply the result of overthinking and overengineering. These unnecessarily complicated results are not only more expensive to produce, they are also less reliable and harder to maintain. We pay for the delay with dollars but also with the frustration caused by an unreliable, complicated design. In contrast, near-term delivery dates minimize opportunities for unnecessary design expansion and help keep us focused on the things that really matter.

The smaller the crew, the more they can do

One of the best ways to unleash talent is to not have too much of it. That is, a small team of talented people will generally outperform a larger group of similarly skilled people, because the members of the smaller group have a greater personal investment in the outcome and thus apply their talents more effectively.

People in large groups are more likely to demonstrate social loafing, which means they contribute less than they are capable of. In addition to reducing the team’s overall effectiveness, social loafing also restricts the further development of each person’s talent, because if we want to get better at something, it helps to actually do it. When we don’t do as much, we don’t grow as much. Members of smaller teams are less likely to get crowded out of the action and thus have more opportunities to gain experience that will improve their future performance. Bottom line: a small team has both near-term and far-term advantages, for the individuals and the organization.

A simpler design will work just fine

Simple systems tend to outperform more complex systems, for a variety of reasons. Complex systems tend to have greater maintenance requirements, lower reliability rates, and have more ways to go wrong than simpler systems. They also take longer to develop, which can cause problems if the object’s development doesn’t keep pace with changes in the environment.

Generally speaking, complexity is not a sign of sophistication. Simplicity is. Increases to complexity therefore should be approached with caution.

The things we choose to not do, the things we say no to, and the elements we omit in the name of restraint— these are what enable us to be fast, inexpensive, and elegant. They also ensure that the final product is first-class. That is why F.I.R.E. is fundamentally about exercising restraint across the spectrum of decision making, and keeping a lid on our costs, schedules and requirement sets. ChangeThis | 117.06

When, in the name of restraint, we build only the essential functions and include only the necessary interface components, we discover deep simplicity. Not simplicity for its own sake, but a simplicity that fosters quality, reliability, and usability. Similarly, when our commitment to restraint leads us to perform only the necessary activities, to only write useful documents and only hold meaningful meetings, we find that the pace of progress accelerates far beyond our hopes. Like simplicity, speed is a product of restraint. So is thrift—doing less has a strong correlation with spending less in the long run.

Designing and delivering new technology projects is hard work. The F.I.R.E. approach does not make it magically easy, but doing things the other way—throwing lots of time and money and people at the problem—is not easy either, nor does that approach guarantee a positive outcome. In fact, a lack of restraint tends to result in projects that not only cost more and take longer but also underperform.

The good news is that in F.I.R.E. we have an alternative. It genuinely is possible to be fast, inexpensive, restrained, and elegant. When we put those pieces together, we just might discover we are capable of producing something amazing.

0

No comments

You must be logged in to post a comment.