Before to visit a customer and recommend anything, it’s always good to remember this picture: Think about this:

  • How much inside knowledge you really have?
  • How deep you know your customer?
  • How strong is your delivery to deal with the real issues?


The Art of Worldly Wisdom

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.

A Seat at the Table: IT Leadership in the Age of Agility

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


Shadow IT: source of problems or source of innovation?

Shadow IT is a non-ending story on companies where they have a centralized IT department. So CIOs and their teams have been working always on this topic.

Typically Shadow IT is seen as a nuisance, but there are other organizations that see it as a source of innovation as the business is implementing a solution for a given problem without the hurdles of the bureaucracy.

The sources of Shadow IT

These sources change every single year, as the technology evolves and evolves.

20 years ago the main source of shadow IT came from a Visual Basic program, a Lotus Notes local application or an Excel. Now, the sources are infinite.

I’m looking for specific actions that IT department on a global company can do to limit and uncover Shadow IT. Not the traditional ones, but the new ones that comes from new and emerging technologies.

Any suggestion?


Wardley map for Infrastructure environment

I have been working on a value proposition for a major deal where the customer is looking for a technological partner that enables them to unblock a set of challenges they are having on their data centers.

The customer’s main pain points are highlighted in red, the links between assets are drawn in blue, and the green lines shows the expected benefits for a given user.

All the improvements are implemented through a project, and in the business case there are some interim steps before to achieve the expected state.