Some of the best work I’ve been part of started without anybody’s permission, and I think the habit of assigning every hour kills more good products than bad strategy ever has. Protect a small amount of unassigned time and you keep the only condition under which unplanned products get built.
Where do software products come from?
Some come from research. Somebody studies a market, finds a gap, writes a plan, and gets it funded. Others come from an engineer who was annoyed. The second kind never appears on a roadmap, because a roadmap is a list of things somebody decided to do. Nobody puts down that in March an engineer will get irritated enough about a slow machine to fix it on a weekend. Both kinds produce real products. Only one of them can be planned, so companies build processes around that one and eliminate the conditions the other needs.
| Attribute | Planned product | Unplanned product |
|---|---|---|
| Where it starts | Someone studies a market, finds a gap, gets it funded | An engineer annoyed enough to fix something |
| On the roadmap | Yes, it’s a thing somebody decided to do | Never; nobody can schedule irritation |
| Order of events | Plan first, then the work | The thing first, strategy assembled around it |
| Predictability | Result is predictable | Nobody could have forecast it |
| Whether it works | Unknown until the work is done | Answered before any planning meeting |
| What it needs | Process, budget and approval | Unassigned time nobody audits |
Why does performance work never get funded?
Because a successful performance project has nothing to show at the end.
New features demo. Integrations demo. A dashboard demos. Performance work produces the absence of a problem, and absence is the hardest thing in technology to get paid for. Ask for two weeks to make something faster and the question comes back: faster by how much, and what does that buy us. Both are fair questions and neither has an answer before the work is done.
So the work doesn’t get approved. And then somebody does it anyway, on their own time, because they have to use the thing every day and it’s driving them out of their mind.
I have a lot of sympathy for that engineer. Using a slow tool every day while being told there’s no budget to fix it wears good people down, and the companies that do it are spending goodwill they’ll never see on any report.
What happened when two engineers fixed a slow machine on their own time?
At the consulting firm where I spent my early career, Steve Davis and another engineer built a disk defragmenter for the operating system we all worked on.
There was no company mandate. Nobody assigned it, nobody scheduled it, and it didn’t appear in any plan. They did it themselves, on the side, because disks got fragmented and everything slowed down and they were tired of it. It worked. Performance before and after wasn’t marginally different. It was different by orders of magnitude. Then somebody looked at what they had and realized it was a product.
How do you turn an internal tool into a product?
You decide the market is bigger than the one you built it for. The original tool served the operating system our clients ran. The firm judged the larger opportunity to be on the other major platform of the era, so the work turned into a port and a plan.
I led that side of it. We also decided to bundle and not ship a single utility, so it became a set of disk tools instead of one defragmenter. One person handled the defragmenter, another handled a directory program.
The thing came first and the strategy was assembled around it afterward.
None of that was possible before the side project existed. The strategy came second. The thing came first and we assembled the strategy around it afterward. That’s the opposite of how the story usually gets told. I loved working on it for exactly that reason. The hardest question in any product, whether the thing works, had been answered before a single planning meeting was held, and all we had to do was take something good to more people.
What does slack mean in an engineering organization?
Unassigned capacity. Hours not allocated to anything in particular.
Slack is the first casualty when budgets tighten, and cutting it is easy to justify. Every hour is now attached to a deliverable and the numbers improve immediately. What disappears is invisible, because it was never on a list. Nobody writes down the products nobody built because nobody had a spare afternoon. I think this is among the most destructive habits in management, and the people it hurts aren’t the ones who chose it. The engineers who’d have built the next useful thing lose their spare hours to status reports, while the executives who cut the margin get a better quarter and never learn what it cost them. I’m not arguing for a formal program. Twenty percent time is a large-company answer to a large-company problem and it usually decays into another meeting. The small-company version is simpler and cheaper. Don’t schedule every hour. Leave a margin, don’t ask what it produced, and accept that most of it produces nothing.
How do you spot a side project worth backing?
Somebody built it without being asked, and then other people started using it.
Nobody writes down the products nobody built because nobody had a spare afternoon.
That second half is the test and it’s a good one, because adoption without promotion is hard to fake. When a tool spreads through a team because it’s useful, the market research has already happened.
Ask two questions when you find one. Who else has started using this, and what were they doing before. If the answer to the second is something slow and painful, you may be looking at a product.
The mistake is the other reaction. A manager who discovers unapproved work and asks who authorized it won’t get told about the next one, and there’s always a next one. That reaction makes me furious. Asking who authorized it teaches your best people to hide their best work, and a company that has trained its engineers to hide things has lost something no process will bring back.
My take
Cut the slack and you kill the next product, and you’ll never see the bill. Our most valuable product started as two engineers fixing a slow machine because it bothered them. Nobody funded it and nobody could have forecast it. Protect some unassigned hours on your team, even when budgets tighten. Watch for the people who fix things nobody asked them to fix, and back them. The strategy can come later.
What did the defragmenter project prove about planning?
The plan followed the product instead of producing it.
Something annoyed two engineers. They fixed it on their own time and the result was orders of magnitude better than what existed. Only then did anyone think about markets, ports, or bundles. Every company would prefer this to run the other way, and for most work it does. The plan comes first, the work follows, and the result is predictable. That’s how the majority of anything gets built and there’s nothing wrong with it.
Protect the exception anyway. It costs a margin of unassigned time and the discipline to not ask what that margin produced, and I think any manager who won’t pay that is trading the company’s future for a tidier spreadsheet. The defragmenter would never have existed under a boss who scheduled every hour, and I’d bet most companies have killed something like it without ever knowing.
Frequently Asked Questions
- Founders’ IPO Letter, Alphabet Investor Relations
