Search for tech consulting and you find the same thing on the first ten pages. Different logos, same sentences. Sometimes you wonder if there is a template generator running somewhere.
This is not a coincidence. It is intentional. Vague sounds professional. Non-committal commits to nothing. And those who promise nothing cannot fail to deliver.
Here is a translation of the most common phrases into honest language.
The phrase dictionary
“We help organizations define clear and scalable technology adoption strategies.” Translated: We write down how you should use technology in the future. A document. Usually nicely formatted. What happens after that is not our problem.
“Aligning IT investments with business goals for maximum ROI and future-readiness.” Translated: We make a presentation showing that your IT spending is strategic. The document goes into the filing system. The ROI is not measured.
“AI-driven transformation.” Translated: We added the word AI to our existing services. The process behind them is the same as 2019. The invoice is higher.
“Value-add.” Translated: We are expensive. But we do not call it that.
“Paradigm shift.” Translated: Something is changing. We are not quite sure what. But it sounds important and justifies the next workshop series.
“Synergy effects.” Translated: When two things fit together we call it synergy. What that specifically delivers, when and for whom: remains open.
“Deep dive.” Translated: A meeting that lasts longer than the others. With more Post-its.
“Tech roadmap development.” Translated: We create a PowerPoint with a timeline. What gets lost between slide and reality: not our responsibility.
“Architecture assessment and refactoring.” Translated: We look at your code, write down what is broken, and recommend a rebuild. Who does the rebuild, with what budget and in what timeframe: follow-on engagement.
“Digital product engineering.” Translated: We also have developers.
“Cloud migration and optimization.” Translated: We migrate you to the cloud. Whether it will be cheaper than before: no guarantee. Whether it will be faster: depends. Whether someone takes over operations afterwards: good question.
Why does everything sound the same?
Because consulting language is not there to communicate. It is there to signal competence without committing to anything. The more abstract the sentence, the harder it is to measure afterwards whether it was delivered.
This is not an accusation against individual consultants. It is a structural problem. Those paid by the hour and day rate have no incentive to clearly state what comes out at the end.
What the other side is thinking: “You can have whatever you want from me, as long as I get to stay long enough.”
And clients accept it because it is easier internally. When an external consultant recommends something, nobody personally carries the responsibility. The project fails? The consultants were to blame. The decision? Was data-driven and externally validated.
From practice
We once received a request for proposal.
- CRM tool selection. Multiple PDFs, plus a three-page completion guide. And an Excel spreadsheet. 28 columns, 372 rows.
- First thought: wow, that was expensive.
- Second thought: will anyone actually read this carefully? When seven other vendors received the same email?
- Third thought: before we put effort into this, we want to talk first. If only to ask three questions, because the Excel spreadsheet is inconsistent. Or is the answer in one of the other PDFs? Hard to say.
- We called. The conversation was illuminating.
- The consultancy had built the RFP, would evaluate the responses and facilitate the vendor presentations. All correct. All agreed. The probability that someone from the consultancy’s network was also on the shortlist: estimated 95 percent.
This is not the exception. This is the model.
What good technology consulting says instead
Concrete sentences that answer a concrete question. And that can be measured.
Not: “We develop a scalable technology strategy.”
But: “We look at your three biggest process problems and tell you in two weeks what can be automated. With concrete tools, concrete costs, concrete time investment.”
Not: “AI-driven transformation.”
But: “We test an AI use case directly in your operation. If it does not work after 48 hours, we talk openly about why.”
Not: “We support your tool selection.”
But: “We select the tool and implement it. Because only those who do both truly take responsibility.”
Not: “Value-add.”
But: “At the end you will know whether it was worth it. If not, we failed.”
And what truly good technology consulting looks like beyond that:
- Focus on the problem, not the hype. AI, cloud, microservices, all can be useful. But the starting point is always the problem, not the technology. Those who come to the conversation with a pre-built solution are looking for a customer for their product. Not a partner for your problem.
- Pragmatism beats PowerPoint. A working prototype in one week says more than a slide deck in three months. Those who build first and then show have their back to you. Those who show first and then build have their back to reality.
- Measurable results. What cannot be measured at the end was not an engagement. It was a conversation. Good technology consulting defines what success means before starting, and measures afterwards whether it was achieved.
- Radical honesty. Even when it is uncomfortable. If the existing architecture is completely oversized for what the company actually needs, that needs to be said. Even if it means the engagement gets smaller. Those who do not say it are optimising for their own invoice.
- Independence from software vendors. Those who receive commissions from tool vendors do not recommend independent solutions. That is not a conspiracy theory, that is mathematics. Good technology consulting has no interest in which tool you buy, as long as it solves your problem.
- Getting hands dirty instead of drawing pictures. Looking at the code. Working with the team that has to live with it afterwards. Those who get back into the taxi after the final report never really understood what you were dealing with.
The difference: those who consult and implement have skin in the game. Those who only consult always have an explanation for why it did not work out in the end.
Three questions that show the difference
Before booking a tech consultant:
- what exactly is delivered at the end, and how do we measure whether it works?
- who is responsible if the result does not materialise? And what happens then concretely?
- how many hours of presentation are included, and how many hours of implementation?
Those who get concrete answers to these questions have found a good partner. Those who get vague answers have found a sentence for the bullshit list.
Technology consulting is not a bad concept. It has become a bad industry because too many people in it have profited from ambiguity for too long.
Anyone looking for a technology partner today does not have to accept what everyone else writes. The question is not which phrases are on the website. The question is: does this person build with you, or write down what you should build?
— Robert
