Literally from Spanish “Manual Oracle and Art of Discretion”, it is commonly translated as The Art of Worldly Wisdom is a jewel I just found and that I will keep for years. The wit and concentration of significance of his words makes you think and question your self about many different life situations that you can face.

In a world where people write books taking 300 pages on a single topic, Baltasar Gracián does not expend an extra coma if it’s not required. As he comments on the book:

Some estimate books by their size, as if they had been written to exercise the arm, when their true purpose is to strengthen intelligence.

Written by Mark Schwartz in 2017.

Some notes from the book

Challenging questions:

• What is the relationship between IT and the business, and how does it change as we introduce Agile and Lean approaches?
• The way the CIO role is defined, conceived, and executed today is incompatible with Agile thinking.
• Honest and open conversations are not taking place at the interface between management and Agile delivery teams.
• Can we encourage shadow IT so that we can take advantage of all of the skills and enthusiasm that exist across the enterprise?
• How “Open-Source” is your organization?
• How do you empower your organization with an “Open-Source” approach?

Other notes:

Transformational projects are evidence that a mistake has been made. The worst of these transformational projects are socalled “modernization projects”—transformational projects undertaken to bring technology platforms up to date. But whether these projects are to transform business capabilities or their technological underpinnings, they are the result of poor stewardship of IT assets and old ways of thinking about IT governance and execution.

A transformational project occurs when the amount of debt has become too much to bear.

An example of this growing divergence is technical debt. Technical debt arises when the development team takes a shortcut to release a feature more quickly, leaving known imperfections in the code. This debt will need to be paid off sooner or later by improving the code, but for the moment, the feature works in production and users cannot tell the difference. As with any other debt, though, the company will need to pay interest until it is retired. Perhaps the code is poorly organized—future modifications will be difficult and costly until the debt is retired by reorganizing the code. This is neither an argument against pappardelle nor against incurring technical debt—companies often properly take on debt to finance activities. But too much debt can sink the company.

I don’t mean that standards are bad. Let’s just agree that they might be overrated.

Three major trends have dramatically altered the trade off between building and buying: virtualization, abstraction, and script-ability.

Notes related to risks

The Agile way to deal with uncertainty is to create options and then “buy” information to more accurately assess probabilities.

We build something, measure results, and thereby learn enough to cope with the uncertainty. “The purpose of measurement,” they remind us, “is not to gain certainty but to reduce uncertainty.” Uncertainty is still a given, but we want to drive out as much as we can until it stops being cost-effective to do so.

The main risk we should be worrying about is the cost of not meeting our business objectives on the designated schedule and at the designated cost.

A senior executive’s job is to manage risk. We often interpret this as reducing or mitigating risk. But really the executive’s job is to take risks, not to avoid them.

Notes related to quality

One of the hardest things to explain about IT to outsiders is why all this failure is considered acceptable.

Don’t build faster, build less