---
title: "On an equal footing with IT: Translation guide"
lang: en
type: blog
canonical: https://www.arocom.de/en/blog/it-on-eye-level
alternate: https://www.arocom.de/blog/auf-augenhoehe-mit-der-it
author: "Axel Roth"
published: 2026-09-19
last_updated: 2026-10-31
---

# On an equal footing with IT: Translation guide

Web projects rarely fail for lack of technology, but often for lack of a shared language. This guide gives decision-makers three tools: a mini glossary of the terms most often misunderstood in agency and IT conversations, one follow-up question per term to create clarity, and four communication anti-patterns that quietly slow projects down. You do not need to be able to code. You need to ask the right questions and recognise when an answer is dodging the point.

## On an equal footing 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 cause people to talk past each other 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](https://www.arocom.de/en/knowledge/development/scrum)
actually involve is explained in detail in our knowledge article. And
why a [lead](https://www.arocom.de/en/knowledge/development/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 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 with you as an equal 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 calmly asking 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](https://www.arocom.de/en/blog/why-web-projects-fail).

### 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 with me as an equal?

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](https://www.arocom.de/en/future-check) we place your initiative together, in
your language, without jargon. You can arrange the appointment easily
through our [contact form](https://www.arocom.de/en/contact).