Business ↔ IT: the alignment meeting, with subtitles

Business and IT both speak English. They use the same words, sometimes the same slides, and almost never mean the same thing. Every alignment meeting is a conversation between two languages that only look alike on the surface, like Spanish and Portuguese, or == and === in JavaScript.

To document the phenomenon, we transcribed a meeting. The characters are made up; the lines, sadly, are not.

Cast and interpreters

• DR BRAMBILLA, Chief Vision Officer, degree in Potato Chip Science. Already known to readers for asking for "just one more if".
• FERRETTI, backend engineer, twelve years of night-time on-call, one mug that says it works on my machine.
• GIADA, Product Owner and unofficial simultaneous interpreter. Her translations are in square brackets.

A meeting room on the fourth floor. Tuesday afternoon. On the projector, a slide titled "Q4: 360° Synergies". The coffee has run out.

Scene I — "Real-time"

BRAMBILLA: Right, the new sales dashboard has to be real-time.

FERRETTI (lighting up): So an event stream, Kafka, windowed aggregations, WebSockets to the browser, sub-second latency…

GIADA: Doctor, how often do you look at this dashboard?

BRAMBILLA: Monday morning. Before the committee.

GIADA: [Translation: "real-time" means "updated by 8 a.m. on Monday".]

Translator's note. In computing, "real-time" has at least three meanings, with very different costs. Hard real-time: a missed deadline is a failure (an airbag controller, a train's brakes). Soft real-time: a missed deadline degrades the service (a stuttering video call). Near real-time: data a few seconds or minutes old (an event stream). Then there's the nightly batch, which costs a fraction of the others and is perfectly fine for Brambilla's dashboard. The right question isn't "how fast?" but "what decision do you make with this data, and when?".

Scene II — "Always available"

BRAMBILLA: And the site must never go down. Ever.

FERRETTI: How many nines?

BRAMBILLA (after a pause): All of them.

GIADA: [Translation: "I'd rather it didn't go down during the Christmas campaign".]

Translator's note. "Always" doesn't exist. There's a percentage, and every extra nine costs roughly ten times more, because it needs redundancy, more cloud regions, zero-downtime releases and people on call at night:

And there's a detail nobody mentions in the meeting: availabilities in series multiply. If a page depends on five services, each at 99.9%, the page is available 0.999⁵ ≈ 99.5% of the time, which is almost two days of downtime a year. Brambilla's "never" only happens if the payment provider, the CDN and DNS all agree.

Scene III — "It's just one more field"

BRAMBILLA: I also need the customer's date of birth on their record. It's just one more field, isn't it?

FERRETTI (staring at the ceiling): The customers table has 400 million rows.

GIADA: [Translation for the Doctor: "it's one more field". Translation for the engineer: "it's a schema migration, a new API version, old mobile app versions to support, personal data under GDPR and a report to update".]

Translator's note. On a large table, adding a column naively can lock it for minutes or hours. The safe way is called expand and contract: add the column empty and optional, update the code to write it, backfill existing rows in small batches, and only at the end make it mandatory.

-- 1. expand: nullable column, no long lock
ALTER TABLE customers ADD COLUMN date_of_birth DATE NULL;
-- 2. new code writes the column; the old app ignores it
-- 3. backfill in batches, at night, calmly
UPDATE customers SET date_of_birth = ... WHERE id BETWEEN 1 AND 100000;
-- 4. contract: only once every client is updated
ALTER TABLE customers ALTER COLUMN date_of_birth SET NOT NULL;

Four steps, three releases, one privacy review. "Just one field".

Scene IV — "Delete the customer's data"

BRAMBILLA: Customer Bianchi has asked us to delete their data. Make them disappear.

FERRETTI: From the main database? The replicas? The last 35 days of backups? The logs? The data warehouse? The marketing emails already scheduled? The spreadsheet the sales rep downloaded in March?

BRAMBILLA: …Just so they don't show up in the list any more.

GIADA: [Translation: the business asked for a soft delete; the law requires a real deletion.]

Translator's note. "Delete" in computing has at least three levels: hide (a deleted_at flag), remove the row, and remove the data everywhere, copies included. The GDPR's right to erasure (Article 17) is about the third level, which is exactly the one nobody designed for. The trick used for backups is called crypto-shredding: encrypt each customer's data with its own key, and to "delete" it from the backups too, destroy the key.

Scene V — "When will it be ready?"

BRAMBILLA: How long will it take?

FERRETTI: About three weeks. If the integration with the ERP goes smoothly.

BRAMBILLA (writing): So the 30th.

GIADA: [Translation: the engineer gave an estimate; the Doctor heard a deadline. And "if the integration goes smoothly" vanished as he wrote it down.]

Translator's note. An estimate is a probability distribution, not a number. "Three weeks" is usually the median: a 50% chance of finishing earlier and 50% of finishing later. A more honest sentence would be: "P50 three weeks, P90 six". And the ERP integration usually turns out to be a CSV file uploaded over FTP at 3 a.m. Hofstadter's law applies: it always takes longer than you expect, even when you take into account Hofstadter's law.

Scene VI — "Let's add AI"

BRAMBILLA: And then let's add AI. The CEO talked about it at the conference.

FERRETTI: To do what?

BRAMBILLA: AI.

GIADA: [Translation: it's September 2025. Every strategic plan must contain the word "AI", just as in 2015 it had to contain "big data" and in 2018 "blockchain".]

Translator's note. For IT, "let's add AI" translates into very concrete questions: what problem does it solve, how much does each request cost (models are billed per token), how much latency does it add, how do we measure whether it answers well (evals), what happens when it's confidently wrong, and which customer data are we sending to an external service. If the answer to the first question is "the CEO asked for it", the other five become even more important.

Scene VII — IT speaks, the business listens

Brambilla asks for an update on yesterday's bug. Ferretti answers. Giada translates in the other direction.

FERRETTI: It's probably a caching issue. GIADA: [We don't know what it is yet.]

FERRETTI: It works in staging. GIADA: [It doesn't work in production.]

FERRETTI: There's a workaround. GIADA: [We'll never really fix it.]

FERRETTI: It's an edge case. GIADA: [It happens to one customer in ten thousand. Unfortunately, it's the biggest one.]

FERRETTI: That library is deprecated. GIADA: [It works, but we're slightly embarrassed to use it.]

FERRETTI: We need a refactoring sprint. BRAMBILLA (hearing "two weeks of doing nothing"): Absolutely not. GIADA: [Changing the tyres while the car is moving costs more than a pit stop.]

FERRETTI: It depends. GIADA: [Sit down, this will take forty minutes.]

BRAMBILLA (standing up): Perfect. So we're aligned.

GIADA (aside, to the audience): We never were.

Curtain.

Behind the scenes: why there are two languages

It isn't stupidity on one side or pedantry on the other. These are two domains with different vocabularies, and software engineering has a precise name for this. In 2003 Eric Evans, in Domain-Driven Design, introduced two ideas:

• Ubiquitous language: a shared vocabulary, defined together by business and engineers, used in meetings, in documentation and in the code. If the business says "claim", the code has a Claim class, not RequestEntityDTO.
• Bounded context: the same word can mean different things in different contexts, and that's normal. To sales, a "customer" is someone who might buy; to billing, someone with a VAT number; to logistics, a delivery address. Trouble starts when everyone pretends it's one thing.

When translation fails, the damage is real. The most famous case is the Mars Climate Orbiter in 1999. A contractor's software produced impulse values in pound-force seconds, while NASA's software expected newton-seconds. Same numbers, different units: the probe entered the Martian atmosphere too low and was lost. Nobody got the maths wrong. They got the language wrong.

A few field-tested remedies:

1. Numbers instead of adjectives. Not "fast" but "p95 under 300 ms". Not "always available" but "99.9% monthly SLO". Not "soon" but "P50 on the 30th, P90 on the 15th of next month".
2. Ask what it's for. "What do you do with this data, and when?" turns "real-time" into a nightly batch nine times out of ten.
3. Concrete examples. A table of concrete cases clarifies more than any sentence (we covered this in the story of the ifs).
4. A living glossary. One page with the domain's words and their definitions, updated when they change. Boring to write, priceless to have.
5. An interpreter. Product Owners, analysts, tech leads: the people who speak both languages are a company's most underrated asset.

Emergency phrasebook

The engineering moral: a requirement isn't a sentence; it's an agreement on a meaning. Until business and IT use the same words with the same sense, every alignment meeting is just another chance to misunderstand each other politely.

See you at the next bit's tale. Subtitles included. 🎬