The Lessons No One Writes Down
Every tool you use at work comes with an owner’s manual, even when nobody hands you one. Open a new project management app, and within a few clicks you learn what counts as a “task,” what counts as “done,” and who gets notified when you miss a deadline. Nobody taught you those rules in a meeting. The software taught you, just by being built one way instead of another.
This is the hidden curriculum of technology: the set of assumptions and habits a tool trains into us simply through its design. It is not written in any onboarding document. It shows up in default settings, button placement, and the small frictions that make one action easy and another nearly impossible.
The Default Settings Nobody Chose
Defaults are quiet teachers. If a messaging app marks you “active” the moment you open it, you learn to feel watched. If a calendar app schedules meetings in thirty-minute blocks by default, you learn to think of your day in thirty-minute units, whether or not that matches how your work actually happens.
Most people never question these defaults because questioning them takes effort, and the tool is already working well enough to get by. But “well enough” is doing a lot of quiet shaping. Over months and years, a person’s sense of a normal workday gets built out of hundreds of small decisions somebody else made, usually for reasons that had nothing to do with that person’s actual job.
How Tools Define What Counts as Real Work
A spreadsheet rewards you for turning messy judgment into clean numbers. A chat app rewards you for responding fast, even when the honest answer needs more time. Neither of these facts is stated anywhere. They are learned through repetition, the way a child learns a language by hearing it rather than studying its grammar.
Eric Morrison, a User Experience Research Lead who currently leads research at Google on the future of AI in the workplace, has spent years studying how people actually use the tools put in front of them, as opposed to how those tools were designed to be used. That gap between intended use and real use is often where the hidden curriculum becomes visible: people build workarounds, shortcuts, and private rituals that reveal what the tool is actually teaching them, which is sometimes very different from what its designers intended.
Reading the Curriculum Before You Adopt Something New
Most teams judge a new tool by its feature list. A more useful question is simpler: what will this tool make easy, and what will it make hard? Whatever it makes easy, people will do more of. Whatever it makes hard, people will quietly stop doing, even if nobody decided that on purpose.
A few questions help surface this before a tool gets fully adopted:
- What does the tool assume is the smallest unit of work? A task, a message, a document, a line of code?
- What happens by default, before anyone customizes anything?
- Who sees what, and who gets notified, without being asked?
- What does the tool make visible, and what does it hide?
None of these questions require technical expertise. They just require paying attention to what a tool rewards with ease and what it punishes with friction.
Noticing It in Your Own Habits
The clearest way to spot a hidden curriculum is to watch yourself change. If you find yourself writing shorter messages because the app cuts off previews after two lines, that is the tool teaching you something about brevity. If you find yourself checking a dashboard every hour because it refreshes in real time, that is the tool teaching you something about urgency.
People in fields like UX research spend a lot of their time studying exactly this kind of shift, often by watching how people actually behave with a product rather than asking them to describe it afterward. Eric Morrison‘s work sits in that space, using methods like interviews and direct observation to understand what a tool is really training people to do, separate from what it claims to do on its marketing page
Working With the Curriculum Instead of Against It
You cannot opt out of being shaped by your tools. But you can get more deliberate about which lessons you accept. That might mean overriding a default that does not fit how your team actually works, or building a habit of pausing before a notification dictates your next ten minutes.
It helps to remember that every tool was built by people making choices, not handed down as a fixed law of how work must happen. Eric Morrison’s research often returns to this point in a different form: the gap between a tool’s design and a person’s real needs is not a flaw to tolerate, it is information. Paying attention to it is often the first step toward using technology on your own terms, rather than simply absorbing whatever lesson it happens to be teaching.
