Why it matters
What this principle is for.
Textbook solutions will not get you there. Sometimes the problem has no parallel. Sometimes last year's solution will not scale. Invention imagines a future that is markedly different, then figures out how to get there. Innovation blows apart the constraints that make today's process behave the way it does.
Invention without Simplify is decoration. Teams add features to a thing that is already too hard to use. They keep a step because "that is how we have always done it." Simplifying an existing process often frees more time than a new feature ever will.
The work is disruptive. If you champion a new idea, expect resistance. Push it forward without listening and you erode Earn Trust, and you may miss the fact that would make the idea better. You need Have Backbone; Disagree and Commit when the scrutiny comes. Run a pilot. Measure whether the idea actually delivers. Say out loud what you are worried about.
If a good solution already exists, inventing your own is usually vanity. If the off-the-shelf thing will not scale, say why, with evidence. Keep a critical eye. Do not reject a solution just because you did not write it.
Inventing well means being stubborn and flexible at the same time. Stubborn, or you quit the experiment too soon. Flexible, or you pound the wall and miss the other solution.
Calibration
Under, just right, over.
Look for a simpler path that still solved the customer problem. "We added a feature" is not this principle. Neither is rewriting a working system so someone could feel clever. Look for experiments, pilots, and a willingness to use someone else's idea.
| Situation | Under | Just Right | Over |
|---|---|---|---|
| An idea from another team | Waves it off because it did not start here. The team keeps building its own copy of something that already works next door. | Gives the idea a real look even when the source is unexpected. Takes what fits this problem and invents only the part that is still missing. | Copies the other team's whole approach without checking the fit. People spend the week bending a solution that was built for a different job. |
| Extra steps on a request form | Leaves every field and approval in place. Requesters keep filling out details nobody reads. | Sits with a few recent requests and removes the fields that never change a decision. Keeps the two or three questions that still catch a real miss. | Cuts the form to almost nothing. Reviewers have to chase people for context, and the queue slows down for everyone. |
| A prototype in review | Pulls the prototype when the room looks confused. The week goes back to the familiar design so no one has to sit with something new. | Walks through what the prototype is trying to make simpler and names what is still unproven. Leaves it in play long enough to get one concrete reaction from the people who would use it. | Treats every objection as proof the room just does not get it. Review time runs out, and the people who have to live with the change stop offering useful pushback. |
| A rough idea in standup | Cuts it off because it is not ready. People learn to bring only finished thoughts, and the half formed ones never show up. | Gives the idea a few minutes and asks what pain it would remove. Either parks it with a next step or says why this week is the wrong time. | Turns every spark into a thread or a spike. Standup runs long, and the work that was already on the board loses the morning. |
| Scope on a ticket this week | Implements the request exactly as written. Adds another screen and another setting when a smaller change would have removed the same friction. | Checks what the person is trying to finish and ships the smallest change that unblocks them. Writes down what was left out so it does not vanish. | Trims the ticket so far that the original pain is still there. The requester opens a follow-up, and the team touches the same area twice. |
| A manual weekly patch | Does the same hand edit again and treats it as normal. No one looks for a simpler way to make the patch unnecessary. | Does the patch so this week's delivery still goes out, and names a simpler fix with an owner. Comes back to it before the patch becomes the official path. | Halts the delivery to invent a clean replacement immediately. The thing people are waiting on slips while the team rebuilds a side path. |
| A repetitive task that eats the afternoon | Clicks through the same steps again and treats that as the work. Nobody asks whether the middle can go away. | Automates the boring middle and keeps a human check where a wrong output would go out the door. The next pass is shorter, and the risk is still visible. | Scripts the whole path, including the judgment call. When the odd case shows up, the afternoon goes to untangling a tool no one else can read. |
| First cut in a demo | Hides the draft until it looks finished. The demo is a slide, and no one has used the thing. | Shows the rough cut and says what is still missing. Gets a reaction on the simple path before the design is locked. | Demos every half built idea as if it is already the plan. People leave confused about what is real, and the next few days go to resetting expectations. |
Examples
What it looks like in the work.
The whiteboard in the corner
The room is staring at a chart of arrows. Someone walks to the board, crosses out half of it, and the whole thing fits in a corner. People say it cannot be that easy. Look for the person who did that, and also whether they checked the failure cases with the people who run the process. Simplifying in private and throwing the result over the wall is the over move.
Pilot it
A big invention that can only be tested after three years and a giant spend will not get many cycles. Find a team willing to try it, or a slice of the audience. Measure whether it delivers. Be vocal about what you are worried about. Partner with the loudest critic. If you cannot say how the change helps the customer, you are not ready to invent it.
Not invented here
A good solution already exists on another team, or outside the company. Building your own feels like invention and is usually waste. The other failure is the reverse: rejecting the external thing because it was not born here. Look for the person who can say what they reused, what they refused, and the evidence for both.
In the role
Individual and manager.
Individual
You notice when you are solving the same problem for the third time. You ask what you could remove. You look outside your team before you write a new system. You can explain the customer problem in a sentence, then show the simpler path.
Manager
You require invention and you require simplicity. You fund small experiments and kill the ones that do not move a customer metric. You do not let "not invented here" become a team sport, and you do not let elegance eat the goal.
Go deeper
Questions that make the principle concrete.
- When did you last recognize that last year's solution was no longer scaling?
- What experiment did you run to lower the cost of being wrong?
- What did you remove from a process, and how did you know the customer problem was still solved?
- Where did the idea come from if it was not invented on your team?
- What would the process look like if you had a tenth of the time, or ten times the traffic?
- When is the last time you set aside delivery work to look at the bigger picture?
- Which part of the current process takes the most time, and what happens if you remove it?
- Are you stuck re-implementing the same fix, or did you change the system underneath?
- How do you reward invention on your team without rewarding novelty for its own sake?
- What criticism of your idea was right, and what did you change because of it?
From the blog
Writing that goes deeper.
- Breaking Down Innovation & Invention
A lexicon for invention versus innovation, so the words stop floating.
Related