The tools a company chooses to build on top of says a lot about how serious it is about the craft. The industry-wide drift toward Word, Teams, and Microsoft 365 is not a productivity upgrade — it is a slow erosion of competence dressed up as convenience.
The Convenience Trap
Every tool that hides complexity from you takes something away. When a new hire can open a laptop running Windows, install Office in ten minutes, and be "operational" by noon, that feels like a win. But operational is not the same as capable. What that person has actually learned is how to navigate a UI. They have not learned how their machine works, how their data flows, or how to adapt when the abstraction breaks.
Large vendor ecosystems like Microsoft 365 are engineered for the lowest common denominator. They are excellent at onboarding someone with no background — and they stop there. The ceiling is built in by design. You cannot meaningfully extend Word. You cannot script Teams in any serious way. You are a tenant inside someone else's system, paying monthly for the privilege of not understanding what is happening underneath you.
Convenience optimizes for the speed of the newcomer.
It does not care about the ceiling of the expert.
What We Trade Away
The deeper issue is what gets lost over time. A team that has never had to configure anything has never had to understand anything. When your document pipeline is Word plus SharePoint, you never learn what a proper typesetting system looks like. When your servers are Azure with a click-through UI, you never develop intuition for networking, permissions, or failure modes. The knowledge simply does not accumulate.
The companies most dependent on big vendor stacks also tend to be the most fragile. A license change, a price increase, a deprecated feature — and suddenly nobody knows what to do. There is no internal knowledge to fall back on. The stack was always a rented abstraction.
Vendor-Locked Stack
- Fast to start, hard to master
- Knowledge lives in the UI, not the team
- Expensive at scale, locked by contracts
- No meaningful customization
- Fragile when the vendor changes terms
- Homogeneous — everyone works the same way
Custom Infrastructure
- Slower to start, no ceiling
- Knowledge compounds inside the team
- Cheap at scale, you own what you build
- Configured precisely for your workflow
- Resilient — you understand every layer
- Personal — the environment fits the person
Linux as a Philosophy
A Linux desktop is not just a different operating system. It is a different relationship with your machine. You configure your window manager, your keybindings, your terminal, your dotfiles. The environment becomes an extension of how you think. Two engineers on the same team can have entirely different setups that are both optimized for their own cognitive style — and that is a feature, not a problem.
This is not about being difficult or contrarian. It is about the fact that a person who has spent time configuring neovim, managing a systemd service, or writing their own shell scripts has fundamentally more understanding of computation than someone who has spent the same time clicking through GUIs. That understanding compounds. It transfers across every problem they touch.
Documents Should Be Code
The same logic applies to document production. Word processing is a GUI wrapped around formatting decisions you did not make. The output is inconsistent, the versioning is painful, and the result is never quite right. A typesetting system like Typst treats a document as source code — deterministic, version-controlled, composable. You write a template once and it is correct everywhere, forever. The document becomes a reproducible artifact.
Custom pipelines like this require an upfront investment. You have to learn the tool, build the template, establish the workflow. But once built, the leverage is enormous. Reports, invoices, analysis documents — all generated cleanly from structured data, with zero manual formatting. That is not possible in Word. It is not even imaginable in Word.
Own Your Servers
Self-hosted infrastructure demands that someone in your organization understands it. That is not a burden — it is the point. When you run your own services, you know exactly where your data lives, what it costs to run, and what happens when something fails. You build operational knowledge that no managed cloud service can give you.
This does not mean rejecting cloud entirely. It means being intentional. Use the cloud where the economics clearly favor it. Build and operate everything else yourself. The goal is a team that could reconstruct its own stack from scratch if it had to — because a team capable of that is a team that actually understands what it has built.
The best infrastructure is not the most convenient. It is the most understood. Tools that demand something from you — configuration, learning, patience — are the tools that make you better over time. Convenience is a ceiling. Complexity, embraced deliberately, is a floor that keeps getting higher.