- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Tackling the AI market: more than just a product
My Dad used to enjoy buying things. Or, to be more accurate, he enjoyed the process of getting ready to buy things.
If we needed a new washing machine, or a microwave, or, best of all, a car, he would break out his graph paper and pencil, and a big pile of Which? magazines and other literature. He would make a list of criteria, and he would go through all of the candidate products, scoring them out of ten, adding the scores up, and adjusting them if he wasn’t convinced by the answer. And then we would tour the shops, interrogating the sales staff to a level of detail they were not always prepared for.
Your Moonshot doesn’t have to be a Moonshot
In 1962, NASA faced a difficult technology procurement choice.
They needed a guidance computer for the Apollo Moon missions. Did they go for a design based on new technology, working with researchers at MIT, or a design based on proven technology from their existing suppliers?
They chose the new technology: rather than discrete electronic transistors, they would use silicon chips, which combined multiple transistors into a single component. These chips weren’t like the chips of today, though: rather than millions or billions of transistors, they contained just a few transistors, each representing a single logic gate. Thousands of them were needed to build the Apollo Guidance Computer (AGC).
Software is not an asset
Which side of the balance sheet does your software sit on? Is it an asset or a liability?
When people enter the technology profession, they often expect to spend their time solving coding problems – and are surprised to find that they spend much of their time solving accounting problems. It’s an especially shocking revelation when they realise that money comes in at least two flavours – opex and capex, or revenue and capital, or whatever terms are used to distinguish money spent on continuous running costs and money spent on the purchase of new assets. And they thought that regular expressions were difficult to understand.
Build systems like you hire teams
Despite advances in AI, software systems are not people. But perhaps we should sometimes treat them like people - at least when it comes to budgets and financing.
A couple of weeks ago, I claimed that building software is not like building a bridge, and that the analogy of construction which we use - which I use - so frequently, may be harmful rather than helpful. Rather less usefully, I also suggested that there aren’t any perfect analogies, and that the best way to think about building software is to understand the business of building software. I’m now going to contradict myself and suggest another analogy: that we should think about building software in the same way that we think about hiring teams.
Should you try to take your cloud with you?
In their 1973 research paper Availability: a heuristic for judging frequency and probability, Daniel Kahneman and Amos Tversky introduced the availability heuristic to the world. Roughly stated, the availability heuristic says that, when making decisions or judging probabilities, we give disproportionate weight to information that comes readily to mind. For example, if lots of people who live down my street drive a particular make of car, I may judge that that make of car is very popular, when it may just be that I live in a street with people of a certain wealth, age, social class and so on. Or maybe I live next to the owner’s club.
I believe that the availability heuristic may be responsible for some of the ways we think and talk about one of the biggest shifts under way in enterprise technology today: the shift from on-premise infrastructure to public cloud platforms. I think this because much of our talk about public cloud is dominated by concepts of movement: we talk about portability, about vendor lock-in, and about various types of exit strategies, to a much greater degree than we do for our on-premise infrastructure. And this is because, right now, the story of public cloud is a story of migration. The adoption of public cloud is still in its early stages across most industries, and much of the work that is being done is to move workloads and data from one platform to another. The idea is prominent in our minds, and leads us to dwell on the thought: ‘If I have to put this much effort into getting in, then what will I need to do to get out?’
When evaluating startups, evaluate yourself. Will you be a good customer?
Last week, I was privileged to support the annual Female Fintech Founder competition run jointly by Google, Deutsche Bank and Atos. The competition seeks to find the most promising early stage fintech companies founded by women, and to provide the winners with support for the next stage of their success. (And to provide all the participants with advice and networking opportunities.)
At the heart of the session I attended was a great presentation by my colleague Prue MacKenzie. You can read more about that here.
I can’t improve on Prue’s advice, but the session did prompt me to think about how established companies work with new companies, and whether they always get it right. Many of the founders taking part in the competition will offer their services directly to consumers, but many will have corporates as customers or partners. Founding a company takes great courage, especially in times of great uncertainty. Whether they win the competition or not, all of the founders have already taken a greater risk than any I have ever taken in my career. I think that they deserve customers and partners who think deeply about how to work with them.