The biggest improvements come
from working across silos and involving all stakeholders. If there is no collaboration across teams, then each
team will optimize their area, often to
the detriment of the efficiency of the
other teams. By working across teams,
you develop empathy and can create
the most impactful changes.
I recently read about a U.S. company
that stayed ahead of foreign competition through efficiency. It was able to
achieve this advantage by constantly
examining the end-to-end process. In
one case large amounts of materials
and manufacturing time were being
spent on plastic covers. A major customer was removing and disposing of
those covers because they got in the
way. If the manufacturer had not visited the customer, it would never have
realized it could improve efficiency by
selling a model without that cover.
Likewise, both the process of building software and the process in which
the software is used must be under
constant revision brought about by
8. Technical debt is bad
Technical debt is the work you will
need to do in the future because you
chose an easy solution now instead
of using a better approach that would
take longer. Any software project of reasonable size has technical debt. 7 Technical debt makes all forward progress
slower, and it snowballs the more you
I fear that executives with a finance
background hear “debt” and think it
is an investment that will pay off in the
future. Technical debt is the opposite.
It is toxic and painful. It is a ticking
time bomb. Caskey L. Dickson4
compares it with “naked call options,” future obligations that could arise at any
time, without advance notice, and having an unlimited downside.
In 1972 Fram ran a TV commercial
for its oil filters in which an auto mechanic explained that a customer tried
to save $4 by not replacing a filter; later
the customer had to pay $200 for an
expensive main bearing replacement.
The mechanic concluded, “You can
pay me now, or pay me later.” 8
Once I was involved in a software
project with a subsystem that com-
It is your job to balance security
paranoia with reality, and budget time
and resources appropriately.
6. Feature size doesn’t
predict developer time.
Feature size (as perceived by users) is
entirely unrelated to how long it will
take to create said feature. Small features can take days or years. Big features (as perceived by users) can take
days or years.
It is your job to create and support a
software development process that accepts this and does not second-guess
engineering’s work estimates. Producing the work estimate itself may take a
surprisingly long time.
Negotiation is encouraged. The engineers may reply with a surprisingly
long work estimate but offer changes
to the requirements that will cut the
time significantly. Remember to include time for testing, training, deployment, and unexpected family or
Never promise a feature without
consulting with engineering for a
work estimate. It is not a sign of your
corporate power to promise a feature
by a certain deadline on the spot. I assure you that what people find more
impressive is a professional process
where their request is taken seriously,
work estimates are produced, and the
request is delivered on time (or rejected
for honest reasons).
7. Greatness comes from thousands
of small improvements.
Greatness comes from thousands, perhaps millions, of small improvements
done over a long stretch of time. The
effect of each change is measured, and
the change is rolled back if the outcome is negative.
Google was not built in a day.
Google’s search engine is the result
of millions of individual improvements. Once a week the search-qual-ity panel meets. Engineers step up to
the podium and present their proposed changes. They show how much
of an improvement would be made
based on simulations. The committee debates and votes it up or down.
Weeks later the measurements are reviewed, and the change is either kept
or rolled back.
Google search is the triumph of iterative development over “big bang”
thinking. You can’t make a good search
engine on your first attempt.
Only in Hollywood movies does a
brilliant young mind come up with an
amazing new idea that is implemented
and works perfectly the first time. In
the real world, it takes years to create
an overnight success.
This is true whether the greatness
you are trying to achieve is a system
that provides better service to customers, is more efficient, has fewer
errors, or just organizationally runs
It is your job to require systems to
be designed to make it easy to try new
things and to define pertinent KPIs (key
performance indicators) that can easily
be measured before and after changes.
Most importantly, there must be a process by which the results are examined
and a decision is made to keep or roll
back the change. A rollback should not
be considered a failure or be punished.
What is learned from each rollback is
as valuable as what is learned in each
change that is retained.
Thomas Edison claimed to have
tested 1,000 filaments on the way to
creating his light bulb. When a report-
er asked, “How did it feel to fail 1,000
times?” he replied, “I didn’t fail 1,000
times. The light bulb was an invention
with 1,000 steps.”
This is another reason why software
systems need to support rapid releases.