I have been working with technology for more than two decades. I have programmed in more languages than I can now remember, worked with servers, databases, DevOps, cloud platforms and artificial intelligence, and written books about software architecture.
Despite all this, I must confess something publicly:
I am bad at technology.
At least, I am bad at the version of technology in which the objective is to use the maximum number of tools, introduce the maximum amount of complexity and create an architecture diagram that requires its own tour guide.
My problem is that I continue to believe technology exists to solve problems. This belief has made me deeply unsuitable for certain technology conversations. Here are seven reasons why.
1. I keep asking, “What problem are we solving?”
This is an extremely inconvenient question.
Imagine that someone has prepared a beautiful presentation containing Kubernetes, microservices, event streaming, serverless functions, artificial intelligence and seventeen arrows pointing in different directions. Then I enter the room and ask:
“But what exactly does the customer need?”
The temperature immediately drops.
The customer may simply need invoices to be generated faster. They may need their application to stop crashing every Monday morning. They may want two systems to exchange information without requiring an employee to copy data manually. But we technologists are imaginative people. Give us a small business problem, and we can convert it into a three-year digital-transformation programme.
My experience has taught me that programming is not a solitary intellectual performance. We are building systems to solve somebody’s problem, and the architecture, deployment and technical trade-offs must remain connected to that problem. Therefore, before discussing the solution, I ask what success will look like.
This makes me bad at technology presentations, but occasionally useful to customers.
2. I do not become emotionally attached to programming languages
I have worked with QBasic, FoxPro, C, Perl, Java, PHP, C#, Ruby, Python and several other languages.
Normally, this should have turned me into a warrior. I should be spending my evenings explaining why one language is elegant, another is obsolete and everyone using the third language has misunderstood computer science. Unfortunately, I have learned that languages change while problems remain remarkably loyal.
The important things are usually the approach, architecture, maintainability and judgment. Those survive when the fashionable language changes and the framework’s website quietly disappears. My own journey across languages, servers, cloud platforms and data systems taught me that the language matters much less than the thinking behind it.
Customers rarely wake up thinking:
“I hope my consultant uses a sufficiently fashionable programming language today.”
They usually want the software to work. This is unreasonable of them, but we must learn to adjust.
3. I sometimes recommend less technology
A good technologist can always find another service to add. A database needs a cache. The cache needs monitoring. The monitoring system needs a dashboard. The dashboard needs authentication. The authentication system needs another database. Soon, the customer’s original application has become the smallest component in its own architecture.
I have worked inside the cloud-solutions world, including environments where technical decisions and sales targets can sit at the same table. That experience became part of my book Diary of a Solutions Architect, which looks at customer meetings, commercial pressure and the difference between what a system genuinely requires and what merely looks impressive on a dashboard.
Sometimes the honest recommendation is:
- Keep the existing database.
- Do not create twelve microservices.
- Do not migrate merely because everyone else is migrating.
- Upgrade the current application before rewriting it.
- Buy the smaller cloud instance.
These recommendations are terrible for architectural diagrams. They can, however, be excellent for the customer.
4. I believe DevOps is not a collection of expensive tools
Many years ago, I wrote that DevOps is a culture of practices, not a tool. Tools support the processes and rituals, but purchasing a collection of products does not automatically create collaboration, automation or operational discipline. I still believe this, which is unfortunate because tools are much easier to purchase than culture.
You can install Jenkins in an afternoon. Changing the relationship between development and operations may require patience, leadership and several uncomfortable meetings.
You can create a cloud account in minutes. Creating ownership may take months.
You can buy an observability platform. Convincing everyone to examine the alerts before the customer calls is a separate implementation project.
Technology is frequently used to avoid addressing human problems. We automate a confused process, digitise a bad workflow and then act surprised when the confusion begins moving faster.
A tool can support a good practice. It cannot attend a difficult meeting on our behalf. Not yet, anyway.
5. I do not trust artificial intelligence simply because it types confidently
AI can now generate code at impressive speed. It can also generate mistakes at impressive speed. The dangerous thing is that both versions arrive with the same confidence.
My book You Are the Quality Control is built around this exact issue. Tools such as Claude Code and GitHub Copilot can generate large amounts of software, but review discipline, security guardrails and production judgment remain human responsibilities. The AI may write the code, but the human remains accountable for what enters the system.
This makes me bad at AI enthusiasm. When AI produces 700 lines of code in thirty seconds, I do not immediately announce that software engineering has been solved. I ask irritating questions:
- Did it understand the requirement?
- Did it expose sensitive information?
- Did it delete something important?
- Did it invent a library?
- Did it write a test that tests absolutely nothing?
- Why is there a function called
temporaryFinalFix2()?
AI is a powerful assistant, but it should not be given the production password merely because it completed the autocomplete confidently.
6. I prefer boring systems that continue working at 2 AM
Architects enjoy discussing scale. We imagine millions of users, international data centres and traffic levels normally experienced only by Google, Amazon and websites publishing examination results.
The customer currently has 600 users.
But we must prepare.
For all six billion future users.
My book Bed Time Stories for Programmers and Solutions Architects uses stories involving production pressure, launch deadlines and late-night war rooms to explain architectural patterns. The point is not that every system needs every pattern. The point is to recognise the problem and select the pattern that genuinely addresses it.
A good architecture does not need to be exciting. It needs to survive Monday. It should be understandable by the team that maintains it. It should recover when something fails. It should provide useful logs. It should not require the original architect to be summoned through a ceremonial ritual whenever a configuration value changes.
The highest compliment a production system can receive is:
“Nothing happened.”
No outage. No emergency meeting. No dramatic message in the company chat. Just customers quietly using the system.
Very boring.
Very successful.
7. I measure success from the customer’s side of the table
Technologists often measure success through technical achievements:
“We migrated to the cloud.”
“We introduced microservices.”
“We implemented AI.”
“We created a data lake.”
The customer may still be unable to find last month’s invoice.
The real question is not whether the organisation adopted a technology. The question is whether the technology improved something that mattered.
My current work includes AI-assisted software development and offline, on-premise AI deployments. But even there, the objective is not to install AI merely so that a company can announce that it has AI. Private deployments exist to address practical concerns such as security, privacy, performance and control over organisational code and data.
Technology is the instrument, not the concert.
Cloud is not the outcome.
AI is not the outcome.
Microservices are certainly not the outcome.
The outcome is a solved problem, a reduced risk, a faster process, a happier customer or a system that performs its work reliably.
The Final Confession
I have maintained my blog since 2004, written about programming, cloud, DevOps, architecture and AI, and published three books for programmers and solutions architects. After all these years, my conclusion is disappointingly simple:
Being good at technology is not the same as being good for the customer.
A person can know every tool and still solve the wrong problem.
A person can create a technically brilliant system that nobody can afford, maintain or understand.
A person can win every architectural argument and still lose the customer.
Whenever I am invited to the table, I try to remember why I am there. I am not there to demonstrate how many technologies I know. I am there because somebody has a problem, and technology may be able to help solve it.
That is why I am bad at technology.
I keep allowing the customer’s problem to interrupt it.
