design other


Build models based on historic data but be ready to place bets to increase potential IRR. Track budget IRR vs current IRR and have visibility of the spend as an absolute measure what assets can move the needle.

innovation other process

New market entry

When entering a new market makes sense to think like a hedge fund: come early, faster, sweet tooth the market and take longer bets.

Your platform needs to be market agnostic to a practical level (limited generic functionality, low complexity) while your processes could be market specific.

decisions future other

New IT

IT is responsible for all tech/dev/R&D/innovation. Right?

But what is the function of IT in a fast-moving data-driven hyper-competition market?

It is no longer mostly CTOs who hold businesses’ purse strings; by 2017 chief marketing officers will spend more on IT than their CIOs, reckons Gartner.

Customers are no longer willing just to buy the latest technology; they want to pay for specific results, for instance for sales increases achieved by using analytics software.

other work

Progress not

“Do not confuse motion and progress. A rocking horse keeps moving but does not make any progress.” ― Alfred A. Montapert

other process support

SaaS Prenap

When you consider buying a SaaS make sure that you have a prenap strategy in place (does service deactivation in FAQ section exist, for example).

At least test their support (send them an email with two questions since most support processes cannot handle branching queries) to find out if there is anybody behind the flashy website who is able to respond and guide you.

design other system

Useable software

Making software useable makes it harder to be used while making it easy to be used makes it less usable (across other software).

Search for The Learning CTO, a friend’s blog covering enterprise architecture.

decisions other process

AWS vs Azure support

We are testing migration to cloud. The long tech list of requirments is met by both clouds. But in our experience Microsoft wins in terms of suppoort which is by default phone based walk throughs while (paid) Amazon support defaults to emails that tend to be imprecise while their documentation is supperior (with cool Kindle integration). Assuming this is reflection of their cloud strategies (MS keen to build capability and customer base while AWS is optimising) pick the one that is aligned with the stage of your development.