- 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
- partnership
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Locally rational; strategically irrational
Enterprises frequently find themselves sliding down the slope from strategic rationality to strategic irrationality, while acting in ways which seem locally rational. To put it another way: if everyone’s so busy, how come we’re not going anywhere?
Working for a large enterprise can feel like being on a ship where the boiler is being stoked, the engines are churning, the propeller is turning, the kitchen is turning out meals, the brasswork is being polished, but, when you look out the window, you are still at the dock.
Actually, that might be too optimistic: many enterprises feel like a ship where the coal is being delivered to the kitchen, the stewards are working in the boiler room and the navigator is holding the charts upside down.
And if you work in technology, it often feels like the engines are overdue for a service, steam is escaping from the valves, and the pumps are struggling to keep the water at bay, but despite the constant, frantic activity, basic maintenance does not seem to be anyone’s job.
Don’t settle for horses when you could have dragons
Sometimes, when we are talking about technology, we quote Henry Ford, who said, ‘If I had asked people what they wanted, they would have asked for a faster horse.’
Except that Henry Ford never said these words. They were first associated with him in 1999, when an article by John McNeece suggested that, ‘There is a problem trying to figure out what people want by canvassing them. I mean, if Henry Ford canvassed people on whether or not he should build a motor car, they’d probably tell him what they really wanted was a faster horse.’
Architecture as balance #2: strategic vs tactical
Technology architects frequently ask me how they should balance tactical choices with strategic goals. Sometimes this question is asked in a grand, enterprise context: how is it possible to transform a complex enterprise while maintaining service and delivering immediate change goals? More often, though, it is asked in a very narrow, specific and personal context. How do I get my team to stop picking bad solutions and justifying them because they’re ‘tactical’? How do I get my project manager to let me design a proper solution, when they won’t provide the time, money and resources to do a good job? How do I convince people that they should adopt the ’strategic’ solution when it’s so expensive and hard to implement?
Almost all technology architects face these problems almost every day, and if any of them claim to have solved them once and for all, then you should go and read their blog. I can’t offer a perfect solution, but can offer some thoughts which might be helpful. These will come in two instalments: this is the first, which deals with some common conceptual mistakes made by technology architects.
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.)