- 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
Buy pipelines, not products
We’ve all experienced buyer’s remorse: the experience of building up to a big important purchase like a car or a house, thinking hard about all the options, finally taking the plunge . . . and then experiencing the sinking feeling that you’ve made the wrong choice. The cars you chose not to buy seem bigger and shinier, and the houses you rejected seem lighter and roomier.
Psychologists have researched this phenomenon and some suggest that it might be to do with the sudden shift from possibility to reality: when we still making our minds up, we have nothing but possibility ahead of us, and focus on the positive aspects of each of our choices; when have made our decision and made our purchase, we have nothing but reality, and have to deal with all the negatives and compromise of what we have bought.
Buyer’s remorse is particularly strong when buying enterprise software products. Our decision cycle can be long: we often construct detailed evaluation criteria based on our requirements and standards, conduct paper based and technical reviews, run POCs and bake-offs, take reference calls and read research by analysts.
This not a negotiation: beyond win-win?
When is a negotiation not a negotiation? And can we do even better than win-win?
In the HSBC Architecture team, we aspire to the three dimensions of architecture excellence we call Zang Jing Ge: technical excellence, communication mastery and leadership power. In a recent article, our Head of API Integration and Microservices, Marco Tedone, argued that we need a fourth dimension: negotiating skills, or Minghzhi De, meaning ‘wisdom’.
I agree that all architects need good negotiating skills, and believe that we can fit them in the centre of the Zang Jing Ge model: good negotiation needs technical excellence (knowing what you want), communication mastery (getting the other party to understand your position and goals) and leadership excellence (leading everyone, if possible, to a win-win outcome).