A World Without Email - second-hand-tigers/badocter-career-learnings GitHub Wiki

Learning Hub › Career Learnings Directory › Dr. Docter's Career Learnings › Workplace Communication

A World Without Email

The deck is linked below because this page can only argue the case; it can't show you the screens. Task boards, cards, the wiki hierarchy — seeing an actual example of one beats a paragraph describing one every time. Read the page for the "why," flip through the deck for the "what it actually looks like."

A World Without Email.pptx

Bottom Line Up Front makes the case for a specific structure. This page makes the case for the medium underneath it — that email and Excel, the two tools most teams reach for by default, were never built for team planning, coordination, or knowledge retention, and that purpose-built tools do all three better.

The Book This Page Is Named After

Cal Newport's A World Without Email (Portfolio/Penguin, 2021) argues that email is being asked to do jobs it was never designed for, and doing them badly as a result — not that electronic communication itself is the problem. The way I break his argument down:

Team collaboration — email threads over multiple days get buried and split; a new collaborator can't easily see the whole conversation, in order, without being forwarded a stack of old messages.
Team workflow planning and coordination — email gives you a personal task list, at best. It has nothing for the team's. It does not provide a framework to prioritize and drive the important initiatives to closure. In a pile of 1000 emails a month that were all important to their senders, nothing can stand out past a day or two.
Knowledge retention — most corporate retention policies purge email older than a year, for legal-exposure reasons that have nothing to do with whether the content still matters. Even if email is not purged, the knowledge it contains is buried under a mountain of ever accumulating day-to-day communications.

Newport's fix is purpose-built tools, not less communication. GitHub is the exemplar I use here because it's what I actually use — for Second-Hand Tigers and the last 4 years of ExxonMobil RTO sustainment and projects that I did before it — but the argument is about the class of tool, not the brand.

Cards Hold What Excel and Email Can't

The individual work item entry "cards" on GitHub's task-boards are called "issues." Each card/issue carries its own worklist, its own full communication history, and its own edit history — all in one place, findable by anyone who opens it, in the order it actually happened.

Put a matrix of work items into a spreadsheet instead, and you get the title, maybe a status column — none of the communication, the subtasks, the images, or the attachments that actually explain the work. Spreadsheets have a second, more basic problem in a team setting: one person editing the file locks everyone else out. They were never built for simultaneous multi-user collaboration, which is exactly the setting a team task list lives in.

The GitHub project board I use to run my own career-learnings wiki work is the illustration I lean on across the source deck: 16 active cards over the space of a month is 16 email threads you'd otherwise be trying to hold in your head, or roughly 80 individual pieces of correspondence lost among the couple hundred other emails that same month brings. A board doesn't ask you to remember that a thread exists. It just sits there, organized by priority and status, until you look at it.

Institutionalizing Learnings, Not Just Archiving Them

Completing a task and updating its GitHub issue status to "Done" doesn't delete it — it's still in the repository, still searchable. But a closed issue isn't something anyone is looking at. By definition, the work item is done and settled, and whatever got learned along the way sits buried in the task list and conversation clutter of an issue nobody has a reason to reopen.

The fix is a habit built into the work process itself: before a done item gets archived, the periodic work planning review screens it for anything worth keeping and moves that piece — not the whole issue — over to the wiki. The wiki is where team members already expect to find guidance, and it returns better search results than an archived issue ever will, because it isn't competing with a to-do list and a conversation for the reader's attention.

That's not an abstract claim on this particular page — it's the practice that produced it. This page exists because a closed-out PowerPoint-deck issue got reviewed for learnings before archiving, and what was worth keeping came here instead of staying buried in a comment thread. If you want to see what "institutionalize learnings before archiving" produces on the other end, you're reading it.

No Idea Sells Itself — Including This One

Getting a team to actually adopt a new tool is its own project, not a footnote. A board with one contributor is just a personal to-do list with extra steps; a board the whole team is actually using is the source of truth. That gap only closes through deliberate adoption work, the same No Idea Sells Itself discipline that applies to any other idea worth spreading:

Target the actual objection, not the one you assume. A Business/Results skeptic responds to the cost of the status quo in hours and risk. A Technical/Operational skeptic needs to watch one real card tracked start to finish, not hear about the feature set. An Interpersonal skeptic's concerns are people impacts — they will lock onto the benefits of more effective team communication that breaks down silos and fosters inclusivity and will want details on guiding team members through the rollout. And adoption doesn't stick company-wide until leaders reference the board out loud, in the room, not just in a memo.
Lower the activation energy instead of arguing the merits. Start with one board on one live project, not a rollout plan. Migrate something real people already recognize rather than inventing a toy example — this deck's own outline and revision history lived on one card from the first draft, and that's a more convincing demo than any description of what a card could hold. Model it yourself before asking anyone else to.

Getting Started (Job Aid)

I won't be in a position to walk another organization's champion through this personally, so here's what I'd point them to instead — GitHub's own docs where a doc answers it cleanly, and three videos I've watched and vetted myself where a doc alone doesn't quite cover it:

Topic	Resource
Account setup	GitHub's own docs: creating an account
Your first repository	How to create your first GitHub repository — no Git command line required
Task boards and Issues	How to use GitHub Issues and Projects
Setting up an organization	GitHub's own docs: creating a new organization from scratch
Wikis (for institutionalizing learnings)	GitHub's own docs: about wikis — free-tier catch: only public repos get a wiki; private needs Pro, Team, or Enterprise
Profile setup	GitHub Profile Tips to Stand Out (& Stay Secure)

If you get stuck past what these cover, an AI assistant open in a second browser tab is a genuinely useful diagnostic partner — copy-paste the error message, or just describe what's not working, and it can usually suggest a step-by-step fix. That's exactly how I set up my own GitHub organization, repos, and wikis.

Acknowledgements

None of the above would have happened on my own initiative. A big thanks to YC, BS, and AW for introducing me to GitHub several years ago and getting me up to speed on its base features.

References

Newport, C. (2021). A world without email: Reimagining work in an age of communication overload. Portfolio/Penguin.

License: © 2026 William Docter. This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). You may copy, redistribute, remix, and build upon this material, including for commercial purposes, provided you give appropriate credit to William Docter and indicate if changes were made. The Second-Hand Tigers logo is not covered by this license. All rights in it are reserved.