Last week I lost two hours to a Word document.
Not writing it. Formatting it. Adjusting line spacing that refused to stay put. Fixing a numbered list that broke when I added a new item. Hunting for the option that lets a heading start on a new page without forcing every other heading to do the same. By the time the document looked the way I wanted, I had forgotten what I was trying to say.
This is not a rare experience. Most of us have lived this hour, and we have learned to budget for it. We treat formatting as a tax we owe to the document, and we pay it.
I want to suggest a different idea.
The tax is real. The document is not the thing being taxed. The way we package documents is.
Why everyone hates Word, and why everyone is wrong
The conventional story is that everyone hates Word, and that the cure is a better app. I have heard this for twenty years. Replacements have come and gone. Pages, Google Docs, Notion, Dropbox Paper, Coda. Most of them are good in some way. Almost none of them have actually replaced Word in a corporate setting, because the corporate world is locked into Office for reasons that have little to do with quality. Office is the format people send you, the format people review in, and the format people expect back.
So the “everyone hates Word” framing is partly a complaint and partly a wish. It is a way of saying we want this to end without admitting we have no idea how it ends.
I want to make a smaller, more useful claim.
The problem is not Word. The problem is the file.
A file is a single object. When you treat the file as the thing you share, you have to put everything inside it. The text. The images. The version history. The reviewer comments. The styling rules. The author metadata. All of it gets stuffed into one binary container, and the container does its best.
This is why Word documents grow heavy and break. It is why filenames balloon into things like:
Q3-Report-FINAL-v4-with-edits-from-John-revised.docx
It is why you scroll through forty seven comments trying to figure out which are still active. It is why an embedded image can corrupt a whole document. It is why “the latest version” is a question people ask in meetings.
The cure is not a better app. The cure is a different unit.
The folder as the unit of sharing
Here is the move.
Stop sharing files. Share folders.
In code, this is already how things work. A project is a directory, not a single file. Source code lives in one place, assets live in another, build outputs live in a third, and the whole structure is what you commit and share. No one tries to compress a project into one binary blob, because doing so would lose the structure that makes the project legible.
Documents deserve the same treatment.
When the unit of sharing is a folder, the folder can hold the structure that a single file cannot. Concretely, my template looks like this.
project-name/
├── README.md
├── assets/
├── drafts/
├── notes/
├── output/
└── CHANGELOG.md
The folder name carries the meaning of the project. The README.md at the root is always the canonical document. The assets folder holds images and any other media linked from the README. The drafts folder holds previous versions, replacing the unfortunate convention of:
report_v2_FINAL_REALLY_FINAL.docx
The notes folder holds working notes and reviewer comments as separate markdown files, replacing the embedded comment thread in Word. The output folder holds exported versions in Word, PDF, or PowerPoint when those are needed for sharing with colleagues who live in those formats. The CHANGELOG.md at the root tracks significant edits with dates, replacing the version history that lives invisibly inside a Word file.
Every problem the file format causes has a home in this structure. Heavy embedded images go in assets and stay out of the main document. Version chaos goes in drafts and stops cluttering filenames. Reviewer comments go in notes and become reviewable as their own artifacts. Compatibility with the corporate world is preserved by the output folder, which is where you generate the .docx or .pdf when you have to send something to someone outside the system.
Importantly, no one has to learn anything new about the document itself. The document is text in a markdown file. The structure carries the rest.
Word, Excel, PowerPoint, one app at a time
The case for replacing each Office app is not equal. It helps to look at them separately.
Word is the easy one. Most Word documents are prose, occasionally a table, sometimes an image. Markdown handles all of this without effort. The canonical document becomes README.md. The output folder holds a generated “q3-report.docx” if your boss wants one. Pandoc converts in one command. The friction you remember from Word, the formatting tax I described in the opening, simply disappears. Markdown does not let you fight about line spacing because there is no line spacing to fight about.
PowerPoint is harder, but workable. For content-driven decks, internal updates, engineering talks, a teaching deck, the canonical content can live as README.md and convert to slides through a tool like Marp. The deck in “output/talk.pptx” is generated, and the source of truth remains the markdown. This works well for decks where the content does the heavy lifting. It works less well for visually designed decks, the kind a designer touches, the kind with bespoke layouts and brand polish. For those, the .pptx eventually becomes the source, and you have to be honest about it. Not every deck fits the markdown pattern, and pretending otherwise is how this kind of practice gets a bad name.
Excel is where I want to spend more time, because the case is the most interesting and the most often misunderstood.
Excel cannot be replaced by markdown. This is true. Excel is, at its core, a database with a flexible front end. It does formulas, pivots, what-if analysis, and live calculation. None of those are markdown’s job, and trying to force them into a CSV is missing the point.
But here is the part most people skip.
A great deal of Excel use in the corporate world is not Excel-as-database. It is Excel-as-document. Project trackers with fourteen tabs. Status reports with prose written into cells. Org charts kept in spreadsheets because no one knew where else to put them. Meeting agendas in row form. Inventory lists that are really just lists with a header.
When Excel is used as a flexible document editor, it inherits all of Word’s problems and adds new ones. The file is still a heavy binary. Comments and version history are still buried inside. Sharing is still file-based. And on top of that, the structure is unconstrained, which means people invent ad-hoc layouts that no one else can read without an explanation.
The fix is the same as the Word fix.
If you are using Excel as a document, you are using the wrong tool, and the cure is not a better spreadsheet. The cure is a folder. Your project tracker becomes a project folder with a README.md describing the project, a tasks.md listing the work, and a milestones.md showing the schedule. Your status report becomes a folder with a README.md and a notes folder for the weekly entries. Your inventory list becomes a CSV in an assets folder, with a README.md explaining what the columns mean.
This is the structural insight that makes the whole approach more than a Word complaint. Word and Excel-as-document are the same disease in different costumes. The disease is the file as the unit of sharing. The cure works the same way for both.
Excel-as-database stays. It has earned its place. But Excel-as-document deserves to be retired with the same care we apply to Word.
Demote, do not escape
The most useful framing I have found is this one.
Do not try to escape Office. Demote it.
Trying to escape Office is a battle most people will lose. The corporate world runs on .docx, .xlsx, and .pptx, and you cannot send a markdown file to a legal team and expect a polite reply. Every time someone tries to abandon Office wholesale, the social cost of switching falls on them, and they end up converting back, exhausted.
Demoting Office is different. Office stays in the workflow, but it moves to the export layer. It becomes the format you produce when you need to talk to the outside world, not the format you write in. The canonical work happens in the folder, in markdown, where the friction is low and the structure is clean. The .docx or .pptx is generated on demand, dropped into the output folder, and sent off.
This is the same pattern that exists in code. Engineers do not write JavaScript by editing the minified bundle. They write source code, and they generate the bundle as an artifact. The bundle is necessary for the world to consume, but no one mistakes it for the work itself. The /src folder is where the work lives. The /dist folder is where the output goes.
Documents have always deserved this distinction. Until recently, the tooling was not good enough to make it practical for non-engineers. That is changing.
Why this is becoming possible
Three signals are worth paying attention to.
The first is OneDrive. On April 21, 2026, Microsoft brought native markdown support to SharePoint and OneDrive into general availability. You can now create .md files directly from the Create button, and the browser viewer renders tables, checkboxes, links, and syntax-highlighted code blocks with modern typography. This matters because Microsoft is the gatekeeper of corporate file storage, and as long as OneDrive treated markdown as a foreign object, the markdown approach was confined to engineering teams. Now markdown sits beside .docx in the same folder, with native preview, and the corporate IT story for “I want to write in markdown” is no longer a fight. The vendor that benefits most from the file-as-unit model has just made a meaningful concession to the folder-as-unit model. That is a signal.
The second is AI, and the same OneDrive announcement makes the point. Microsoft is rolling out an “Agents Assets library” in SharePoint, where AI agents store team preferences and learned skills as markdown files. The reasoning is plain in the announcement: as AI and agents increasingly create and update markdown to do their work, teams need a reliable place to manage that content. Microsoft is acknowledging that markdown is the AI-native format. Almost every AI workflow today is markdown-native because models read text and produce text, and they handle markdown structure naturally. When your canonical content is markdown, AI can read it, summarize it, expand on it, and help you revise it without a conversion step. When your canonical content is a .docx file, the AI is working with whatever a parser managed to extract from a binary blob, and the fidelity drops. The shift toward AI-assisted knowledge work is a shift toward markdown-friendly knowledge work, whether or not anyone calls it that.
The third is broader. Git, version control, and the patterns of folder-based work are slowly migrating from code into knowledge work. PKM systems like Obsidian and Logseq are folder-and-markdown-based. Static site generators have made markdown the default authoring format for the web. Even academic writing is moving toward markdown through tools like Quarto and Pandoc. The corporate world is the last redoubt of the file-as-unit model, and its walls are thinning.
None of this means Word and Excel are going away. They will not. But the alternative is becoming practical for more people, and the practical alternative is what eventually shifts behavior.
Try the smallest version
If any of this lands for you, the temptation is to plan a sweeping change. A new system, a new tool stack, a new way of working. Resist that.
The smallest experiment is one folder.
Pick your next personal project. A planning doc, a trip itinerary, a side project, a research note. Make a folder for it. Put a README.md inside. Add a CHANGELOG.md with one entry. Make a drafts folder, an assets folder, a notes folder, an output folder. They can stay empty until they are not.
Write the project’s content in the README.md. When you need to share it, generate a .docx or a .pdf into the output folder and send that. Put any reviewer comments you receive into a “notes/comments-from-jane.md” file. After thirty days, look back and ask two questions. Did anything I would have done in Word feel hard to do this way? And did anything I usually fight with in Word feel absent?
If the answer to the second question is yes, you have your evidence. You can keep going, one folder at a time, until the practice has shape.
It is worth saying what the two hours I lost at the start of this essay actually represent.
They are not about Word. They are about the way we have collectively agreed that the document is the artifact, and that all the other things, the assets, the comments, the versions, the metadata, belong inside the document, and that the document belongs to whatever app made it. We pay the formatting tax because we accepted the package.
There is another way to package the work.
The folder is the artifact. The file is the export.
Once that flip happens in your head, the rest of the practice becomes obvious, and Word stops being a thing to fight. It becomes a format, useful in its place, no longer the thing standing in the way of the work.
Image: Pexels
Tom’s Blog 