- 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
Tinker, tailor, strategist, innovator
What do you want to be when you grow up?
I’m still not entirely sure that I know, so it’s slightly scary when people ask for my advice on their career choices. Fortunately, being a technology architect means that I’m always prepared to express an opinion on something I don’t completely understand.
Two of the career choices I am asked about most frequently are technology strategy and innovation (probably because I have people that do both of these types of work in my team). Here is some of the advice I offer people to help them figure out whether these choices are good for them, and what kind of qualities they need to do this work well. (Like all advice from a technology architect it is well meant, but possibly wrong.)
Cloud helps us solve the rocket fuel problem
Putting code into production is a bit like going to space.
If you want to reach Earth orbit from the surface of the planet, you will need some help. To start with, you can’t survive on your own in space: you need a spacecraft.
But your spacecraft needs help too. It can’t escape Earth’s gravity on its own: it needs a boost. The only way humans have found to solve this problem so far is by using rockets.
But your rockets need help too. Lifting you and your spacecraft needs fuel, determined by your combined weight. But that fuel adds to the total weight, so you will need more fuel to carry that fuel. And more fuel to carry that fuel.
Innovation needs light bulbs . . . and lenses
Thomas Edison didn’t invent the light bulb, but he made affordable, long lasting electric light a reality. And this wasn’t just because he was struck by a sudden inspiration (a light bulb going off over his head): it was because because of disciplined experimentation coupled with a commitment to industrialisation. Most people know that Edison worked his way through thousands of designs for bulbs before patenting a bulb with a carbon filament, and that, even after filing his patent, he worked through thousands more choices for the material that would provide the carbon filament, finally settling on bamboo. It is less frequently mentioned that Edison and the workers at this lab also invented much of the equipment necessary to produce bulbs at scale, as well as the infrastructure needed to distribute power.
Edison himself said of this endeavour that, ‘There was no precedent for such a thing, and nowhere in the world could we purchase these parts. It was necessary to invent everything: dynamos, regulators, meters, switches, fuses, fixtures, underground conductors with their necessary connecting boxes, and a host of other detail parts, even down to insulating tape.’
What is the C that your are trying to P?
Three little letters strike terror into the hearts of architects everywhere: P. O. C.
This seems strange. Surely in the age of digital transformation, innovation, and a willingness to fail fast, conducting proofs of concept is exactly what we should be doing. Why should architects be scared of POCs?
The reason is that, unfortunately, in large enterprises, many POCs are not POCs at all. Whether deliberately or accidentally, they stand little chance of proving a concept: in fact, it’s not even clear which C they are trying to P.
Let’s look at two types of POCs which standing little chance of P’ing a C: POCs in name only (let’s call them POCINOs) and POCs without concepts(let’s call them POCWOCs).