On eye level with IT: A translation guide for decision-makers
In first meetings we regularly see the same moment. The managing director nods, the IT provider talks about sprints, story points and a backlog, and both leave the room feeling they understood each other. Three months later it turns out they meant different things. The project was not too hard technically. It was never aligned in language.
This guide is meant to close that gap. It explains the terms that most often pass each other by when you work with agencies and IT departments, gives a concrete follow-up question for each, and ends with four patterns where communication breaks down. The goal is not to turn you into a developer. The goal is for you to recognise an evasive answer as such.
Why translation matters more than technical knowledge
A common belief goes: if you want a say, you have to understand the technology. In our projects we see the opposite. Decision-makers who try to argue at the level of code get lost in detail and miss the questions that really are their responsibility: what does it cost, when is it ready, what happens when requirements change.
Your role is that of the client, not that of an in-house translator. You have to name goals clearly, set priorities, and recognise when an answer is meant to reassure you rather than inform you. You do not need a computer science degree for that. You need a handful of terms in their correct meaning and the nerve to keep asking until you have understood.
Mini glossary: ten terms and your follow-up question
The table below collects the terms that cause the most misunderstandings in our projects. The middle column explains what is meant. The right column gives you the one follow-up question that creates clarity in the meeting, instead of an understanding nod.
| Term | What it means | Your follow-up question |
|---|---|---|
| Sprint | A fixed period (usually two weeks) in which an agreed part of the work is completed. From the Scrum framework. | What exactly will be visible or usable for me at the end of this sprint? |
| Backlog | The ordered list of all open tasks and wishes. Re-prioritised continuously. | Who decides the order, and how do my priorities get into it? |
| Story point | An estimate of effort relative to other tasks, not in hours but as a comparative size. | How does that translate into calendar time and budget for me? |
| MVP | Minimum viable product: the smallest version that delivers real value and can be tested on the market. | Which feature are we deliberately leaving out, and when does it follow? |
| Lead | A qualified prospect, meaning a contact with recognisable buying interest, not every website visitor. | From which signal does a contact count as a lead for us? |
| Technical debt | Deferred clean-up work in the code that makes later changes slower and more expensive. | Which debt are we taking on deliberately, and when do we pay it back? |
| Deployment | Releasing a new version to the live server so users can see it. | How often do we release, and how do users notice it during operation? |
| Interface (API) | A defined access point through which two systems exchange data automatically. | Which data flows, in which direction, and who maintains the connection? |
| Refactoring | Rebuilding existing code without changing its behaviour, to make it more maintainable. | What does that make easier or cheaper for us in future? |
| Bug vs. feature | A bug is a fault against the agreement. A feature request is a new requirement. | Was this in the agreed scope, or is it an addition? |
Two terms deserve a closer look because they are so often used wrongly. What a sprint and the Scrum framework actually involve is explained in detail in our knowledge article. And why a lead is not the same as a visitor decides whether you and your agency mean the same marketing number when you talk about success.
Four follow-up questions that fit any project
The glossary questions help with the individual term. Alongside them there are four general questions that create clarity in almost any project situation. They are short, they are friendly, and they force a concrete answer.
"Can you show me that with an example?" Abstract descriptions hide gaps. A concrete example exposes them. Anyone who cannot give one has often not thought the matter through themselves.
"What happens if we do not do this?" This question separates the genuinely necessary from the merely well-sounding recommendation. Sometimes the honest answer is: nothing bad.
"How will we know in four weeks that it worked?" It demands a verifiable effect instead of a promise. Without an answer, no success can be established later.
"What do you need from us for this to succeed?" It makes the collaboration two-sided. Many delays do not originate with the provider but with a pending approval or a missing access on your side.
Four communication anti-patterns
Terms and follow-up questions help in the detail. Alongside them there are recurring patterns where understanding fails on a larger scale. We see these four most often.
The pretend understanding. Both sides nod, no one asks, because no one wants to look ignorant. This is the most expensive reflex in a project. A good agency recognises it and explains again unprompted. As the client, you may say at any time: "Please put that in simpler words."
Jargon as a wall. When every answer gets more technical instead of clearer, that is rarely an accident. Sometimes jargon hides uncertainty, sometimes it is meant to fend off an awkward question. A provider who works on eye level translates into your language voluntarily.
The silent assumption. "But that was obvious" is the sentence that follows every misunderstanding. It was only obvious to one side. Written summaries after every important meeting cost ten minutes and save weeks of detours.
Shifting the line through words. When an agreed feature suddenly becomes a "complex special case", it is worth the calm question whether it was in the agreed scope. Here language quietly shifts the line between target and extra. How such shifts can throw whole projects off track is shown in our article on the most common mistakes in web projects.
As a decision-maker, do I really not need to understand the technology?
You do not need to master it, but you should be able to place its effects. The difference matters: you do not need to know how an interface is programmed, but you should be able to ask which data flows through it and who maintains it. That is exactly what this guide is for. The technical depth belongs in the hands of your provider, the decision about goal, budget and priority belongs in yours.
How do I tell whether my provider communicates on eye level?
By a simple signal: they translate unprompted. A good agency explains technical terms without you having to ask, gives examples, and answers your follow-up questions more clearly instead of more technically. If answers get more complicated with every question, that is a warning sign. Understandable communication is not an added service, it is part of the work.
What do I do if I did not understand something in a meeting?
Say so immediately and calmly. One sentence is enough: "I have not understood that yet, can you explain it differently?" In our experience the threshold drops once you do it early, and the meeting becomes more productive for both sides. The expensive option is to swallow the question and discover three weeks later that something other than intended was built.
Is a shared glossary worth it for the project?
For projects above a certain size, yes. A short, jointly maintained document with the central terms and their meaning in the project prevents the same word from circulating with two meanings. This applies especially to terms that already have a specific internal meaning for you, such as lead, campaign or approval. The effort is small, the benefit grows with every person in the project.
The first step for your next conversation
You do not need to memorise this glossary. Take it into your next project meeting, as a cheat sheet on the table or open on the screen. Ask one of the four general follow-up questions as soon as an answer gets vague, and request a short written summary after every important meeting.
If you are facing a larger initiative and are unsure whether you and your provider really mean the same thing, talk to us. In a Future Check we place your initiative together, in your language, without jargon. You can arrange the appointment easily through our contact form.
Go deeper in our knowledge base
Want to know what these topics mean for your company? The Future Check shows you the biggest levers within 2–4 weeks.
