Slamet Hendry

design

10 Innovation Proverbs for Leaders

I received this from Joyce Wycoff a long time ago. It's interesting that what many people claim as “innovation” would not qualify as innovation according to below.

  1. PEOPLE do innovation.
  2. Innovation means doing something that has not been done before. By definition there is risk involved. No risk; no innovation.
  3. Innovation is a win-win process. It creates new value for the customer and the organization.
  4. Innovation is a team sport. Teams are built around a common objective and trust.
  5. Innovation requires risk. Risk-taking requires trust. Trust requires honesty and openness.
  6. Innovation requires energy. Energy comes from challenges that excite the imagination.
  7. Innovation is about creating the future. Cost-cutting and downsizing are about fixing the past.
  8. Innovation is not just a rah-rah word or fad. It is an investment in the future that requires new processes, time, energy, commitment and resources.
  9. Innovation requires new information — from co-workers, customers, suppliers, competitors and from the world.
  10. Innovation requires time — time to think, time to tinker, time to talk about possibilities and ideas. Down-to-the-second controls can kill innovation.

by Joyce Wycoff

#learningorg #design

“All growth is a leap in the dark, a spontaneous, unpremeditated act without benefit of experience.” Henry Miller

#quotes

Best tool vs optimal tool

I was looking for a cloud data storage solution recently and researched it on the internet. I read a number of product reviews with pros and cons. And then I read some users comments that provided some real world rebuttal of the reviewers assessments. These users used the product within their use cases longer than the product reviewers who used the product only a short time for the sole purpose of writing a review article for the internet. The perspectives from other users put the product reviews into context whether they are relevant or not for my use cases.

Context matters a lot, but context is often overlooked

When we want something, we research it to find the best product / service that we can buy for the specific use case. We buy it and then sometimes we discover afterward that the best product / service has other costs aside from the money we pay for it.

It is not necessarily wrong, if best performance or best value or best whatever is the one and only goal. But it is important to understand well: are we absolutely sure there is no other goal that we ought to consider within the context of the big picture?

We ought to avoid “local optimisation” that can degrade the overall expected benefit.

For example, let us say that we have two inter-dependent jobs that need to be done by two different tools and we bought the best tools we could find for each of the jobs: tool A and tool B. Great, so now we will get the maximum benefit when we put these two together, right? Not so fast. It depends on how well these two work together in managing the inter-dependent aspect of their jobs. We need to understand the short term and long term implication whether problem or additional effort or cost may ensue out of the integration between A and B.

Considering the full context, we ought to assess if A and B are still the tools of choice for the jobs, or whether alternative options will integrate more optimally to yield a better overall benefit.

Assumptions can mislead

This one is obvious, but also often gets overlooked. We want to be explicit about all our assumptions and understand how each assumption affects our decision making process. If our assumptions change, the optimal solution may change also, because what we need may turn out to be different.

As for my cloud data storage search, I challenged my assumptions and in the end I reframed my “jobs to be done” differently from when I started my initial research. By questioning my assumptions of what I need vs want, I reconsidered a solution that I excluded previously. This solution is not the technical best because it does not meet a few of my criteria, but it fits perfectly one criterion: simplicity.

Optimise for total benefit

The optimal tool balances trade-offs to maximise the total benefit.

“The whole is greater than the sum of its parts.” Aristotle

In my cloud example, the best tool is not the simplest and, for now, simplest is what I need. Therefore the optimal tool that I bought, in this case, is not the technical best, but I am happy with it, because it gives me the maximum total benefit.

#design #learningorg

P.S. May I interest you to read my older post: Best practice can be wrong?

Product vs mission

A team's mission is not more important than the product that the team is building. But the mission is more important than introducing any product.

If we stumble upon a new product that has the potential to be a rainmaker, but it does not fit the mission, then a decision is needed.

  • Pivot (i.e. change the mission) or
  • Spin off (i.e. create a second team with a different mission) or
  • Shelf the product to pursue at another time or
  • Sell the product to another team / company

When a team launches a product that does not fit the mission, that means they have a different agenda that is more important than “the mission”. In other words, “the mission” has stopped being the team's mission.

Change the product or change the mission (or adjust both). One is not more important than the other, but the product should be the manifestation of the mission.

#design

Donald Knuth

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

#quotes #design

Navin Chaddha

“Focus when you’re building a company. A startup die of indigestion, not starvation.”

#quotes #design

C.A.R. Hoare

“The most important property of a program is whether it accomplishes the intention of its user.”

#quotes #design

Russ Cox

“Software engineering is what happens to programming when you add time and other programmers.”

#quotes #design

Dick Hamming

“It is better to solve the right problem the wrong way than the wrong problem the right way.”

#quotes #design

Ted Kaminski

“With engineering, we’re tasked with the long term maintenance of a piece of software, and we also become concerned with many lower-priority properties, such as its performance. With wizarding, we’re often best served by designing for ease of throwing code away rather than maintaining it.”

From Wizarding vs engineering

#quotes #design

Robert Muth

“Tests are your safety-net when refactoring. Improving test will not only make this safety-net more effective, it will also improve your understanding of the code. Don’t start any refactoring until you have a proper test suite in place.”

#quotes #design