Most projects don't fail because someone lacked the skill to do the work. They stall, drift, or quietly derail because a sentence meant one thing to the person who wrote it and something else entirely to the person who read it. After years of running projects across borders, time zones, and very different working cultures, I've come to treat communication as the actual job, not the thing I do between the real work.
The fix is rarely more words. It's more precise ones. A project manager spends the day translating complex, fuzzy intentions into instructions that can't be misread, and the gap between a vague message and a specific one is the gap between a team that moves and a team that meets to figure out what you meant.
Specificity beats brevity
Short isn't the same as clear. "Meeting tomorrow" is short and useless. The version that actually works tells people exactly when, where, and why: a client presentation meeting on Tuesday, January 24, 2:00 PM Eastern Time, via Zoom, with the design team presenting final mockups. Nobody has to ask a follow-up question, and that is the whole point.
The same discipline applies to tasks. Look at how much ambiguity disappears when you swap the lazy phrasing for the explicit one.
| Vague version | Version that prevents rework |
|---|---|
| Update the website | Replace the homepage hero image with the approved Q1 campaign visual and change all call-to-action button colors to #FF4500 by end of day January 25 |
| Additional plumbing work needed | Install two new water supply lines in the second-floor bathroom, copper grade L, between January 26 and 27, requiring a water shutdown from 9 AM to 2 PM each day |
| Who's handling the bug? | Critical login page error reported by Client X needs immediate attention: which backend developer can investigate this in the next hour? |
Notice what the better versions share. Scope, timing, and impact are spelled out. The construction note tells everyone exactly what gets touched and when the water goes off, so a tenant or a foreman can plan around it. The Slack message names the severity and asks a single answerable question instead of floating an open call into the void, which is how bugs sit unowned for a day.
Distance multiplies every assumption
Working with international teams adds a layer that domestic projects let you ignore. Time zones stop being trivia and become the most important detail in the message. "Let's meet next week, same day, in the afternoon" is a trap. "Team sync scheduled for January 30 at 2 PM GMT+0 (7 AM PST / 10 AM EST / 3 PM GMT+1 / 9 PM SGT)" is a meeting people actually attend, because nobody has to do mental arithmetic and quietly get it wrong.
Culture shapes meaning just as much as the clock does. A phrase that reads as perfectly polite in one place lands as aggressive or evasive somewhere else. "We'll try our best" can mean a genuine commitment to attempt the task, or it can be a face-saving way of saying no, depending on who's saying it. I don't try to decode the intent anymore. I remove the ambiguity at the source by asking for a binary answer: can you complete this by Friday? Please reply either "Yes, will complete by Friday" or "No, cannot complete by Friday," and tell me why.
Language proficiency deserves the same care. Even when English is the shared language, fluency varies, and idioms are where things quietly break. "Let's touch base" becomes "let's schedule a 15-minute status update." "ASAP" becomes "please complete this within the next 4 business hours." The idiom feels friendlier to you and means nothing reliable to a non-native reader.
For documentation across languages, I lean on standardized templates and visual cues that survive translation. Consistent icons for deadlines, priorities, and action items bridge gaps that prose can't, so a line might read: π΄ HIGH PRIORITY (Alta Prioridad / ι«εͺε εΊ¦): Complete security update by January 28, 16:00 UTC.
Feedback is another place where culture quietly rewrites your words. Some teams expect blunt criticism; others find it humiliating. Rather than guess, I give the feedback a structure everyone can use safely: please provide three specific improvements needed and two aspects that work well in the current design. And calendars matter more than people assume. Not everyone shares your weekend or your holidays, so I state it: this timeline accounts for Lunar New Year, February 10 to 13, and uses a Friday to Saturday weekend for the Middle East team.
What an assumption actually costs
About 15 years ago I was managing a credit card clearing platform implementation inside a large enterprise ecosystem, where several applications were lined up for deployment in the same window. At kickoff, the client's project manager assured us they'd handle all internal testing coordination, and I took that at face value.
When their QA team started, nobody had told them which environment to use. They were supposed to run initial integration testing in the lower test environment. Instead they began in the upper test environment, the space where five other applications were finishing their final pre-production validation for the following week's release.
The damage was immediate. Our tests generated heavy transaction data and rewrote shared configuration tables, corrupting test scenarios that other teams had spent weeks building. We had to stop everything, restore the environment from backups, and absorb a two-week delay across the entire release pipeline.
The client PM had assumed their QA team knew the standard testing protocols, but in enterprise systems, assumptions about common knowledge can be extremely expensive. A simple environment specification document could have prevented this cascade of delays and the resource rescheduling that followed across multiple teams.
Giovanni Toccu
The real lesson is about people, not specs
Clarity in project management isn't really about words. It's about building bridges across cultures, languages, and technical backgrounds. Multicultural teams taught me that assumptions are the silent saboteurs of good projects, and explicit communication is the foundation that holds everything else up.
I find it useful to picture each person's background as its own operating system: a private set of working norms and defaults. My job isn't only to coordinate tasks. It's to create a shared language of specificity where everyone, whatever their origin or experience, can move with confidence.
And the hardest part is human, not technical. We hesitate to state the obvious because we're afraid of sounding condescending. But being explicit isn't doubting someone's competence. It's respecting that every person at the table arrived by a different road. The next time you catch yourself thinking "this is too obvious to mention," say it anyway. In the few seconds that costs, you've probably just headed off the misunderstanding that would have eaten your next two weeks.