Email Should No Longer Be the Default

Email should be the exception, not the default.

For decades, email has been the backbone of corporate communication. It was simple, reliable, and revolutionary in its time.

But the way we work has changed dramatically.

Today’s workplace has countless tools at its disposal: instant messaging, ticketing systems, project management platforms, shared documents, knowledge bases, and collaborative workspaces. Yet people still choose email as their default, even when the work clearly belongs somewhere else.

Need someone to fix something? Send an email.

Need a decision? Send an email.

Need a status update? Send an email.

Need someone to review a document? Attach it to an email.

Then we wonder why work gets lost.

The problem isn’t that email has no purpose. It does. The problem is that we continue to use it as the default when purpose-built tools are better suited for most of the work we do.

Email is a communication tool. It is not a system of work. And in a modern workplace, we should need as little of it as possible.

Email Creates Noise, Not Priority

Most corporate inboxes contain everything from critical requests to automated notifications, newsletters, meeting updates, FYIs, and reply-all chains.

Everything competes for attention in the same place.

Personally, I archive the vast majority of emails where I’m simply copied and not directly addressed. I have to. Otherwise, managing email could easily become a job of its own.

The inbox effectively becomes a queue, but not a particularly good one. There is usually no clear owner, priority, due date, status, dependency, or escalation path. An urgent production issue can sit next to a company newsletter and a meeting invitation.

Important messages get buried. Tasks fall through the cracks.

If something actually requires action, why are we putting it somewhere designed primarily for communication rather than accountability?

Work Should Live Where Work Is Managed

Consider a simple email: “Can someone look into this issue?”

Who owns it? What is its priority? Has anyone started working on it? What happens if the recipient is out? Where does someone look months later to understand what happened?

Now put that same request into ServiceNow, Jira, Azure DevOps, or another work management system.

Suddenly, the work can have an owner, priority, status, history, due date, comments, related work, and an auditable record.

That leads to one of the simplest rules organizations can adopt: If work must be done, put it in the system where work is managed.

Email can notify someone that the work exists. But it should not be the work.

And once a ticket or work item exists, keep the conversation about that work with it.

If an incident is managed in ServiceNow, but half the discussion happens through email, another portion happens in Teams, and the final resolution exists only in someone’s inbox, you’ve fragmented the record.

The next engineer, shift, manager, or auditor shouldn’t have to reconstruct the story from multiple places.

The system of record should tell the story.

Email Creates Invisible Work

There’s another problem with email-driven work: much of the work becomes invisible.

A manager sends an employee three requests through email. Another stakeholder sends two more. Someone else forwards a thread asking for help.

None of those requests appear on the backlog or story board. None are reflected in capacity planning.

Yet all of them are competing with the employee’s formally assigned work.

Then leadership wonders why planned work isn’t getting finished.

You can’t effectively manage work you can’t see.

Structured work management systems make demand visible. They allow teams and leaders to understand capacity, priorities, bottlenecks, dependencies, and competing commitments.

Email hides that demand inside individual inboxes.

Reducing email isn’t simply a personal productivity preference. It is an organizational discipline.

Stop Sending Attachments Around the Organization

The same principle applies to documents.

We’ve all seen files like:

ProjectPlan_Final.docx

ProjectPlan_Final_v2.docx

ProjectPlan_REALLY_FINAL.docx

We have better tools.

If multiple people need to access, review, or edit a document, put it in SharePoint, OneDrive, Google Drive, or another shared platform.

Everyone works from the same version. Changes can be tracked. Permissions can be managed. And the document has a permanent location.

Better yet, when possible, share it through the workspace where the work is already happening instead of emailing the link.

If more than one person needs the information, give it a home. Don’t give it an attachment.

“Well, I Sent an Email!”

We’ve all heard this one.

A task gets missed. A deadline slips. Someone doesn’t respond.

“Well, I sent an email!”

But sending an email isn’t the same thing as creating ownership.

If something matters enough that someone needs to take action, give the work an owner, priority, status, and a place where everyone who needs to understand it can see it.

Email may prove something was communicated. A proper system of work makes the request visible, trackable, and actionable.

“I sent an email” should never be our definition of effective handoff.

So What Tool Makes Sense, and When?

The answer isn’t to replace email with one universal tool. Different types of work belong in different places.

Task & Work Tracking Systems

Examples: ServiceNow, Jira, Azure DevOps

Use when: Work needs ownership, prioritization, deadlines, status, history, or an audit trail.

Not for: General conversation or informal FYIs.

Rule: If work must be done, track it.

Once a work item exists, conversations that change its scope, status, ownership, priority, or resolution should be captured with it.

Instant Messaging / Chat Platforms

Examples: Microsoft Teams, Slack

Use when: You need a quick answer, clarification, or real-time conversation.

Not for: Long-term documentation or work requiring structured accountability.

Rule: If you need it fast, chat. If you need it tracked, ticket it.

If an important decision is made in chat, capture it somewhere permanent.

Shared Documents & File Collaboration

Examples: SharePoint, OneDrive, Google Drive

Use when: Multiple people need to access, edit, review, or reference the same information.

Not for: Passing multiple versions of documents around as attachments.

Rule: Share the location, not the file.

Knowledge & Documentation Platforms

Examples: Confluence, SharePoint, knowledge bases

Use when: Information will be reused, referenced, taught, or needed again.

Not for: Temporary conversations with no lasting value.

Rule: If someone is likely to ask again, document it once.

Live Conversations

Examples: Teams calls, Zoom, phone, face-to-face conversations

Use when: The topic is complex or sensitive, alignment is unclear, or a written conversation has turned into a lengthy back-and-forth.

Not for: Being the only record of an important decision or assigned work.

Rule: When the thread becomes a debate, talk. Then document the outcome.

Email

Yes, email still has a place. But that place should be increasingly narrow.

Use when: Communicating externally, sending formal announcements, communicating across organizational boundaries, or when no better shared platform exists.

Not for: Managing tasks, tracking operational work, collaborating on living documents, or maintaining project status.

Rule: Email should be the exception, not the default.

Design the Workplace to Need Less Email

The goal should be simple:

Design our ways of working so that we need as little email as possible.

Work should be visible in the systems where it is managed. Documents should have a shared home. Knowledge should be documented and searchable. Quick conversations should happen in collaboration tools. Decisions should be captured where the people doing the work can find them.

When those practices are working well, much of the internal email we send today becomes unnecessary.

That doesn’t mean banning email. It means no longer treating it as the default answer to every communication problem.

Use systems of record to manage work.

Use shared platforms to collaborate.

Use chat when you need to communicate quickly.

Use email when those tools genuinely aren’t the better choice.

Email should be the exception, not the default.

The less work that depends on someone noticing the right message in an overflowing inbox, the more visible, accountable, and efficient our organizations become.

And maybe, eventually, we can finally retire the phrase:

“Well, I sent an email.”

If you like what you’ve read, please subscribe so you don’t miss my latest posts.

And yes, you’ll get an email when they’re published.

Published by

One response to “Email Should No Longer Be the Default”

Leave a comment