How we prevent "nobody told me" on our team: the SMART framework repurposed for communication

"Nobody told me" as a diagnostic

"Nobody told me" is one of the most revealing sentences you hear on a team. On the surface it sounds like blame, or a passive complaint about someone else's failure. It isn't. It's a symptom.

When "nobody told me" surfaces, the underlying issue isn't usually that the information wasn't shared. Almost always, it was shared somewhere, with someone, at some point. The issue is that the communication system didn't make sure the information reached the person who needed to act on it, in a form they could use, in time for it to matter.

Teams that hear this sentence often have smart people doing good work. What they lack is a shared discipline for how information moves between them. The fix isn't "tell people more." The fix is "structure communication so the right information reaches the right people without constant follow-up."

SMART, the goal-setting framework most teams already know, turns out to be a useful communication check when you repurpose it. Not for goals. For every project-affecting message you send.

SMART, repurposed for communication

Each letter becomes a check you run before sending an update, a request, or a decision.

S: Specific

Say exactly what you mean. Short, concrete, no coded language.
Weak: "Hey, can you take a look at this when you get a chance?"
Strong: "Can you review the homepage copy draft in the Figma file? I'm specifically looking for feedback on the hero section and the pricing block, not the visual design yet."
The first version leaves the reader guessing at scope, intent, and priority. The second tells them exactly what to do and what not to do.

M: Measurable

Define what "done" looks like, so both sides know when the task is actually complete.
Weak: "Make the site faster."
Strong: "Get the homepage to load under 2.5 seconds on mobile for the core web vitals test. The current baseline is 3.8 seconds."
Measurable communication keeps the team from discovering, at the end of the task, that "done" meant different things to different people. In design and development work specifically, this often means naming the specific pages, components, or states in scope instead of gesturing at the broader task.

A: Attainable

Check that what you're asking for is actually possible within the constraints the receiver is operating under.
Weak: "Can we ship the redesign by Friday?" (sent Thursday afternoon, to a team with three other deadlines)
Strong: "Given your current workload, can the homepage redesign ship by next Friday, or would the following Monday give us better quality?"
Attainable communication acknowledges that the reader has other commitments. Asking for things that can't realistically happen produces either burnout, missed deadlines, or quiet disengagement.

R: Relevant

Check whether the message is actually for this reader, and whether it's about something they need to act on.
Weak: Forwarding an entire email thread with "FYI."
Strong: "Forwarding this thread because the client changed the API timeline, which affects your work on the integration module. No action needed from you right now, but wanted to flag it before Tuesday's planning."
Relevant communication trims away what the reader doesn't need. A useful rule: before including a recipient, ask "what would I want them to do or know?" If there's no clear answer, they probably don't need to be on the message.

T: Time-based

Name the timing. Deadline, check-in, expected response window.
Weak: "Let me know what you think."
Strong: "I'd like to lock this in by Wednesday end-of-day so the design team can start Thursday. If you have concerns, Tuesday would give us time to discuss."
Without time framing, async messages often drift. The recipient doesn't know if it's urgent, routine, or blocked on them. Adding a timing cue (even a soft one) keeps things moving.

Fact-based communication

A parallel principle that shows up constantly in SUFFIX team communication: separate facts from opinions. "The work is slow" is an opinion. "Task X, due Tuesday, is still in progress because of blocker Y" is a fact. The first invites emotional response and defensiveness. The second invites problem-solving.

This distinction is covered in more depth in our article on telling actionable client feedback from opinion. The short version for internal team use: when you're naming a problem, name the observable facts first, and keep your interpretation separate. It keeps the conversation focused on the work, not the messenger.

Channel discipline

The fifth piece of the system isn't in the SMART framework but matters just as much: where things get communicated. On a remote or hybrid team, channel discipline prevents context-switching overhead.

Our basic rule: project updates go in project channels, internal strategy in team channels, personal chat in DMs, organization-wide updates in the company-wide channel. The specific tool (Slack, Basecamp, Microsoft Teams, or something else) matters less than whether the team agrees on where each kind of information belongs.

We cover the full channel-discipline approach in our article on running fully-remote at SUFFIX. The core idea: if a teammate has to check four different places to figure out what's happening on a project, the channel structure is broken.

When SMART communication is overkill

SMART isn't for every message. Applied universally, it becomes ceremony: people adding formal structure to casual exchanges until even "want coffee?" turns into a numbered list.

Where SMART earns its keep:

- Project-affecting updates. Anything that changes scope, timeline, or another person's work plan.
- Task handoffs. When one person's work becomes another person's input, the handoff message needs to be complete.
- Cross-team communication. When someone outside your immediate working group needs to understand the request, they don't have the context you do.
- Async messages that can't be quickly clarified. If a back-and-forth would take hours because of timezone or schedule gaps, front-load the clarity.
- Decisions that others will act on. If someone is going to do something based on what you wrote, the message needs to survive without follow-up.

Where it's overkill:

- Conversational exchanges within a working session.
- Quick reactions ("agreed," "good catch," "let me check").
- Casual social messages between teammates.
- Real-time video calls, where clarification is immediate and cheap.

The rule of thumb: the further a message is from the sender (in time, in team distance, in topic), the more SMART helps. The closer and more conversational, the less you need it.

How to introduce SMART communication on a team

Teams that adopt SMART communication top-down usually end up with compliance theater. People paste all five letters onto messages without actually thinking through what's being communicated. That's worse than the original problem.

What works instead:

- Propose it as a shared standard, not a mandate. Frame it as "we've been having this problem, here's a framework that helps, let's try it for a month and see."
- Define where it applies. Agree on which kinds of messages SMART applies to (project updates, cross-team asks, handoffs) and which don't need it (casual chat, in-meeting exchanges).
- Pick one letter to start. Most teams already do several letters intuitively. Start with the one that addresses the most common failure mode. For most teams we've worked with, that's T (time-based). Adding deadlines to messages makes more difference than any other single change.
- Review after a month. What helped, what felt like overhead, what should change. Keep refining.

SMART communication is cultural, not procedural. It holds up when the team genuinely believes in it and fails when it's imposed without buy-in.

The cultural effect

Beyond the immediate communication benefit, consistent SMART communication signals something the team feels over time: respect for each other's attention. A reader opening a SMART-structured message doesn't have to reconstruct context, guess at priority, or send three follow-up questions to understand what's being asked. They can read the message once and act.

Scaled across dozens of daily messages and dozens of teammates, this compounds into meaningful time saved. More importantly, it compounds into trust. People start assuming messages from teammates will be clear, actionable, and worth their attention. That assumption itself accelerates work, because the team stops second-guessing every message.

"Nobody told me" doesn't disappear entirely. It surfaces less, and when it does, it's more often a genuine gap worth investigating than a symptom of poor communication hygiene.