Imagine Sherlock without Watson, chocolate without peanut butter, or an accelerator without a brake. In each case, we would have something good but incomplete. Sherlock may be brilliant at solving crimes but he lacks a humanizing bedside manner, which Watson provides. Chocolate is delicious on its own, but the sweet notes are improved and elevated by the addition of a slightly salty peanut butter. And the gas pedal is terrific at making the car go, but at some point we’ll want to slow down or perhaps even stop. Thus, the brake pedal. In each case, adding something (a partner, a complementary flavor, an opposing mechanism) improves the overall experience. The story gets more interesting, the dessert more delicious, the vehicle more drivable.

As designers, coders, or engineers, adding to a design is one of the first creative steps we take. In fact, when we face a blank sheet of paper or an empty screen, adding is the only move available to use. Of course, a single element is seldom sufficient, so we continue to add new pieces, parts, and components as the design matures and gets more complex. The theory is that these additions make our design better – and much of the time, that is the case.

During this early phase of a design, where we add new parts that make the design better, we can map our trajectory on the Simplicity Cycle diagram as a line that points up and to the right. The slope and degree of straightness may vary, but if the design is simultaneously becoming more complex and better, we’re basically heading in this direction:

It turns out there are many different additive moves available to us, different approaches which allow us to expand and improve a design. Here are eight additive strategies to consider:

1. Introduce: Insert a previously absent piece into the design. This addition might be a counter-point that performs the opposite of an existing function (i.e. a brake pedal to accompany a gas pedal), or a counter-weight to balance out an existing component.
2. Replace: Exchange an existing element with an alternative piece. This strategy is additive in the sense that it introduces a new component, but it also involves removing something from the design.
3. Divide​: Split a single element into multiple elements. Rather than one superhero with 10 powers, create a team of superheroes with one or two powers each.
4. Expand: Transform an existing element into a larger version of itself.
5. Add copy: Introduce redundancy. These could take the form of a hot-backup, ready to take over a function in the event of a primary system’s failure. Or the copy can perform its function alongside the original, as in the dual wheels on a semi-trailer.
6. Monitor: Insert a check function to confirm an existing element performs as designed. A monitoring function generally produces a signal to indicate status and may automatically trigger a switch-over to a back-up system (see #5 above).
7. Roughen: Increase friction between design elements, either in the form of a time delay or a more physical degree of friction. Friction can improve traction and prevent slippage.
8. Accelerate: Introduce an element sooner in the process than planned. This is a form of time-shifted addition, where the element was always intended to be part of the design but is now included earlier.

A word of caution: Because additive moves are most effective in the early stages of a design, they are also the easiest tools to over-use. Adding new pieces and parts is an essential and productive strategy — until it isn’t. We need to be sure we don’t flood Sherlock with too many Watsons, overwhelm the chocolate with too much peanut butter, or equip our car with too many brake pedals.

So, in addition to learning how to use additive strategies, we’ll need to add an additional method to our toolbox: subtracting. That is the topic for our next 3-minute design lesson, coming soon.

(This first appeared on SmartBlog)

In December of 2015, I was invited to testify to the Senate Armed Services Committee, on the topic of defense acquisition reform. The video is available on the Senate’s website, but here is a transcript of my opening statement.

My perspective on acquisition reform can be summed up in two words: constraints work.

That perspective is based on my 20 years of service as an Air Force acq officer and my research over the past decade. I’ve observed that small teams who embrace constraints tend to outperform large teams who adopt an expansive mentality of “take your time, spare no expense.”

I contend that if we want the acquisition community to deliver world-class, affordable systems at the speed of need, we must look to small teams with short schedules, tight budgets, and a deep commitment to simplicity. We should resist the urge to launch big, slow, expensive programs, which inevitably cost more, take longer, and do less than promised. As I explained in an article about technology lessons from Star Wars, we should build droids, not Death Stars. Droids work, Death Stars keep getting blown up. This does not just happen in the movies – it happens in real life.

The opening story in my book FIRE is about the Condor Cluster, a supercomputer developed by the Air Force Research Laboratory in 2010. At the time, it was the fastest supercomputer in the entire DoD. Remarkably, it cost less than one-tenth the price of a comparable machine. How did AFRL produce a best-in-class technology on a shoestring budget? They built the Condor Cluster out of 1,760 PlayStation 3’s, which makes it an interesting, funny story… but also an important story.

If the scientists and engineers at AFRL had a large budget for that particular project, they would have bought a standard supercomputer… which would have cost more and been slower than the system they actually developed. Their small budget forced them to pursue a different path – which not only saved a lot of money, it also outperformed every other supercomputer in the Pentagon’s inventory.

And that is a key point. A constrained approach helps save money, but that is a secondary objective. The primary objective is to ensure we deliver best-in-class capabilities, so that our men and women in uniform continue to enjoy unsurpassed technological advantages. As a person who has strapped on body armor and carried a loaded weapon in a warzone, I take this very seriously. The data is overwhelmingly consistent: we get better acquisition outcomes –programmatically and operationally – when we take a constrained approach.

That is what I mean when I say “constraints work.”

The question is how to build a culture that incentivizes constraint. The first step is to recognize that constraint is not a foreign concept. The armed forces are full of people who embrace constraints and take pride in doing the most when they have the least,

I had the privilege of leading one such team during my final year on active duty. There were six of us in uniform, along with a handful of civilian partners. Our $84M project was one of the smallest in our division – so constraints are relative. Outside experts said it should take seven years, but my predecessor wisely decided to do it in two years. Our first test flight was a month ahead of schedule, we flew twice as many tests as originally planned, and when the program ended I was able to go to my commander and report that we were $8M under budget.

This is not the typical outcome, but it is more common than you might think. If we want more projects to look like this – world-class technologies ahead of schedule and under budget – my suggestion is to seek, support, and celebrate these teams.

Take steps to find these high-performing innovators, and support them, and tell their stories. If prominent leaders tell the world “This is what right looks like, this is who we are when we are at our best,” that will help provide incentives for others to move in that direction as well.

The US military is fantastic at achieving its goals. Give us an objective, and we will do whatever it takes to satisfy that objective. Military innovators have proven we can deliver world-class capabilities ahead of schedule and under budget when that is the goal. But acquisition programs run into problems when that is not the goal, when concepts like speed and thrift are dismissed, viewed skeptically, or written off as impossible. Acquisition programs run into problems when big budgets are treated as signs of prestige, long timelines are treated as signs of strategic genius, and high degrees of complexity are treated as signs of sophistication.

We need to set better goals and incentivize the right things. If we are going to reform the acquisition system, we must take steps to emphasize and incentivize three things: speed, thrift, and simplicity. And we need leaders who will seek, support, and celebrate the teams who pursue these goals.

And we need to do these things for a very simple reason: constraints work.

So there I was, a self-published author, just waiting for the world to break down my door clamoring for thousands and thousands of copies of my Simplicity Cycle book.

Yeah, that didn’t happen.

Some people did buy copies of the self-published version, and I literally made enough in royalties to occasionally buy a pizza. Very occasionally. A small pizza. Without pepperoni. But hey, that’s a bite or two more than I had before, right? Plus I was having fun with it, meeting new people and learning a lot.

I eventually decided to give the digital version of the book away for free. Almost nobody was paying for it anyway, so no great loss of income there. But it was more than an economic decision. It was actually strategic.

The idea to give it away came from an article by John Perry Barlow, former Grateful Dead lyricist and co-founder of the Electronic Frontier Foundation. It was titled Selling Wine Without Bottles, and he argued that “Familiarity Has More Value Than Scarcity.” In fact, he wrote “It may often be the case that the best thing you can do to raise the demand for your product is to give it away.”

The principle that an idea’s value increases with familiarity made a lot of sense to me. If lots of people heard about The Simplicity Cycle, and I was the Simplicity Cycle guy, then demand for my services should (theoretically) increase. Accordingly, I set out to make my Simplicity Cycle idea as easy to find and share as possible.

By Dec 2008, the free version had been downloaded more than 1,000 times. By Sept 2009, it was up to 1,400 and in January of 2010 it broke 2,000. Then Lulu broke my heart when they stopped tracking how many times free PDFs got downloaded.

Where did the idea for The Simplicity Cycle originally come from? Well, let me tell you.

The year was 2002. I was a young Captain in the Air Force, assigned to an intelligence agency in Washington DC. My duties includes serving as program manager for a little imagery system called BRITE, and sometimes I got to give demos of BRITE to potential users.

One day as I was about to begin a demo for a Navy Lieutenant Commander, she held up her hand and spoke two sentences that blew my mind and changed my life forever. She said:

“I don’t care how good this system is. If it isn’t easy to use, I don’t want it.”

Whoa. That was basically the opposite of what everyone around me was saying (i.e. we don’t care how easy it is to use, as long as it has all the latest cutting edge gadgets & features). If a system or process was hard to use, no problem at all. Just give the users more training. Problem solved. But she was saying ease of use mattered more than performance?

Mind. Blown.

I actually wrote down those two sentences (and yes, BRITE was easy to use, she did like it, and her unit used it quite successfully thankyouverymuch). I continued thinking about what she said over the next few weeks… and months… and years. Her words rang in my ears and wouldn’t let go of my imagination. So I began an informal investigation into the relationship between complexity, ease of use, goodness, and design. I had no idea where it would all lead, but I knew it was a path worth exploring.

I guess the first lesson is to pay attention. Listen to people who are saying the opposite of what everyone else is saying. Listen to the complaints, the pain points, the alternative views. Carry a little notebook and write these things down. And then pick one to investigate. It’s OK if you don’t know where the path ends. Check it out and see what happens. Who knows – you might end up with a book someday (13 years later).

NEXT WEEK: The Simplicity Cycle Meets The World