Before we launch into this essay: Welcome to the 11 new faces (wallets?) that bring the total subscriber count up to 16! 👋🏻

And a special thank you to the 2 collectors of my previous essay.

Don’t want to miss a piece? Hit the subscribe button below:

If you don’t have a crypto wallet, you can get updates on Twitter instead.

The UX of Work

In The Great Online Game, Packy McCormick wrote:

„The Oxford English Dictionary defines a video game as, “A game played by electronically manipulating images produced by a computer program on a television screen or other display screen.”

If you’re working remotely from a computer, what you’re doing perfectly fits the definition of a video game.“

The Great Online Game (TGOG) was a „hidden in plain sight“ idea. Like the word FOMO, it packaged something we all knew and felt, but couldn’t articulate. The concept rippled through Twitter, gaining adoption with minor and major tech personalities.

The discourse has cooled since then. TGOG sounded much more plausible when you could make thousands of dollars in a day by staking your Cyberkongz NFT for Banana tokens. As economic tides changed, we all shockingly realized that Axie Infinity wasn’t as viable a career choice as we thought.

But even after this latest balance patch, The Great Online Game is still up and running. And in this eSport we call creating, building and side hustling, lots of teams want the best names on their jerseys.

In other words, companies need talent. And it’s hard to get good players to put on your jersey. To do that, you need to make the game fun to play.

And who makes games fun to play? Game designers!

That’s why it’s odd that nobody talks about Great Online Game Design. While many people play TGOG, a good game needs a good game designer. And games are software. Managers might not know it, but they’re building a software product, even if they never write code.

Work is a software product

We access work as a software product. This is not only true conceptually, it’s true literally. I do 90+% of my work in:

• Google Docs

• Google Meet

• Google Mail

• Slack

• Notion

(You could replace Notion with Google Sheets and Slack with Google Chat and all my work runs through Google).

Even if you don’t work in marketing, you probably do most of your work using less than 10 pieces of software. It’s obvious enough that we access work through software. But work also behaves like software.

As a writer, I put an input into Google Docs and transfer it via a Notion task API so that my colleague in Slack outputs an error or success message.

Feel free to substitute your specific tech stack, but you’ll realize that your work resembles using a software product more than any traditional notion of work. This is true even if you’re at the office full time. In that case, you’re creating digital inputs to generate physical outputs.

It sounds heartless to reduce your work, the time you spend to make a difference in the world, to programming an abstract machine running in the cloud. What about the beaming customers thanking you? Or the team camaraderie that gives you purpose? The feedback that makes you feel appreciated?

Modern management advice almost exclusively talks about this. They regurgitate:

• Trust your employees

• Give clear feedback

• Show empathy

• Be transparent

• Take feedback

While these are essential, they neglect technology. If you’re lucky, they humor it with a point like „use technology to your advantage“ that tells you to use Trello.

Telling knowledge work managers to use project management tools is like telling logistics folks to use shipping containers. Every tech company has abundant tools. It’s about using them to facilitate good work.

The problem is that we’re operating in the wrong management paradigm. Work is a software product and managers are building it. But the current management paradigm is one of logistics.

Designing Work UX Instead of Managing

Let’s prevent some confusion first. Management is a broad title: One company’s marketing manager might write copy, run paid ads and create graphics. At another company, someone with the same title oversees a team of 11 and does
no hands-on work herself.

So let’s demarcate what we mean by management for the purposes of this essay: Management is the task of organizing and enabling work for yourself and/or others.

If your title includes the word manager, this likely describes a good portion of your work. If you’re not a manager, you probably still do some management. The activity of managing doesn’t require you to manage others (or a manager title), though that’s often the case.

We’ll also distinguish it from leadership, which is the work of motivating, goal setting, inspiring and so on.

With the boring stuff out of the way, here’s the problem with today’s management paradigm:

In any type of knowledge work, most managers unknowingly think about their work as „knowledge logistics“.

Imagine a logistics manager needs to ship some bananas from Brazil to Belgium. The bananas go from palm tree to supermarket shelf through various stages. They find packaged in crates, containers and conveyors. They cross the Atlantic by ship, rest in warehouses and sprint to the finish on a truck.

She decides whether the bananas go via Itaqui or Valparaiso, which warehouse to store them in, where to offload the shipping container, etc.

Knowledge work managers are similar. Let’s replace bananas with bookkeeping and walk through a tech example: A SaaS company launches a new feature and tasks its marketing manager with launching it.

This starts a chain of knowledge logistics: The manager takes some knowledge (we have this feature and customer should use it) and convenes a meeting to determine the best ways to transport this knowledge to their customers. Let’s keep it simple and say the team agrees to promote it with a blog post.

Like a banana farmer loading product into crates, the manager now packages that knowledge into a briefing for the copywriter and graphic designer.

Like supermarket workers unloading crates and filling supermarket shelves, these two unwrap the knowledge from the briefing and transfer it to a customer-friendly container: A blog article and a graphic.

Like a shopper at a supermarket, the customer unwraps the knowledge and understands „The company now has this feature and I should use it“.

In reality, processes are less linear. But this example shows how intuitive logistical thinking is as management. Even management language springs from logistics:

• „Let’s ship that this week.“

• „How should we package this?“

• „Let’s wrap this up“

We see management as knowledge logistics. And optimizing work like logistics can make you more efficient. But logistical thinking has 3 giant constraints

1. You have limited control

No logistics manager can shorten the distance between Brazil and Belgium. You can optimize the route, but you can’t change the distance itself.

2. Shipping routes are (almost) set in stone

Logisticians don’t build new ports. You need big scale to even have your own warehouse. And unless you’re Amazon, you won’t have your own trucks or planes—and you definitely won’t have your own container ships.

Because you can’t change the infrastructure you operate on (without spending dozens of millions), you can only arrange preexisting pieces.

3. You don’t decide what to ship

If you’re in logistics, you don’t decide if you ship bananas or blueberries. You also don’t influence quantities. You’ll lose your job if you decide to ship 420 tons instead of 500 because it had better vibes.

In essence: Logisticians manage a fixed amount of work and with a fixed set of tools.

When work is software, these constraints don’t apply:

• Knowledge Managers can determine processes freely.

• Knowledge Managers control the spreadsheets, kanban boards and templates they work with.

• Knowledge managers usually get strategic directions, not tactical instructions.

Constraints also loosened around other work. Unlike physical labor, knowledge work escapes narrow boundaries. It’s not only the tools and methods of management that have changed. The things managers manage are less tangible, too.

The old paradigm won’t serve the new reality. We have move on from the logistics paradigm and think of management as UX design.

Management As UX Design

Your outlook change when you stop thinking about your team as labor units to arrange and start thinking about them as software users. This improves things for everybody:

1. UX design is a user-focused process that aims to help people reach their goals. Make it easy for your team to do their best work—and they’ll do their best work.

2. Great UX scales. Software keeps working after you stop, so you’re creating assets that help your team do their best work, even when you’re not actively managing.

Few companies nail this. If work is software, most companies have atrocious UX. Imagine the sum of softwares and interfaces you use to get work done as a software product called Werk.

Because it’s so versatile, Werk is infinitely customizable and modular, with each company running its own implementation. Most Werk implementations follow UX worst practices:

• Meetings that should’ve been an email are like customer support calls that should’ve been a setting.

• Feedback like „Will have a look and circle back if necessary“ is like a success message that doesn’t tell you what has happened and if you need to take further action.

• Absent documentation is like a lack of FAQs and support docs, leading to conversations that delay processes.

• Lacking dashboards and overviews are like, well, lacking dashboards and overviews, leading to frustration and confusion.

(For the rest of this essay, we’ll use Werk as the combined software experience of work)

Good UX design reduces overwhelm by simplifying processes to the minimum required to get the job done. It creates clarity by clarifying the inputs required and the outputs the user will get. Most importantly, it creates joy by helping the user reach a goal better than alternative products.

In other words: You want your version of Werk be stress-free, clear and simple.

Logistician-driven Werk does the opposite: It shuttles you back and forth between 5 different platforms, jams you into meetings you don’t say a word in and frustrates with ambiguous feedback.

To fix these issues, take off your management top hat and put on your UX designer beret.

Here’s how to improve your Werk’s UX:

Defining Your User Journey

Any good UX design process begins with a user journey. Where is the user? Where do they want to go? If you don’t know these things, no pretty illustration will make users care.

You need to know your user’s goals and frustrations before worrying about fonts and gradients.

UX designers will first map out the user’s milestones. For Mirror users, milestones might be „first publication“, „claim subdomain“, „first subscriber“, „first NFT sale“.

The next step is engineering where and how they happen. The corollary to the above might takes you through the editor, draft stage, wallet confirmation, etc. If it took 12 clicks and 3 tabs to publish on Mirror, fewer people would do so. A good user journey is simple and to the point.

Good UX hides what’s unnecessary in a given context and surfaces what the user needs to accomplish their goals.

Most Werk implementations are the opposite: They maximize the steps you need to take and pages you need to visit.

Tasks that should take 30 minutes expand into hours when they take you on a scavenger hunt for information between Github, Slack, Jira, Notion and Docs. And that’s before the „oh, I forgot to tell you this…“ in the next recurring meeting!

This frustrates team members, lowers productivity and wastes resources. Ambiguity also makes work more stressful: When work diffuses into a cloud of obligations, you never know when you’re done and your brain keeps stressing, even when you want to sleep.

Instead, you need to define your team members’ user journey within Werk to give them clarity. It’s probably best to do this together with your teammate. Here’s how to create clarity for them:

Define starting points

Many teams don’t have clear stages for their work. It needs to be clear when something goes from an idea to being something your teammate is expected to work on.

A good way to do this is to create an item somewhere in Werk (and NOT IN SLACK) with a deadline and expected deliverables, assigned to someone responsible for delivering.

Clearly outline the phases your work goes through (e.g. with a kanban board) to create more clarity for everyone. It also forces feedback to happen in feedback rounds, not in a „looks good at first glance but I’ll have a detailed look later) way.

Define end points

Teammates need to know when they’re done with something. Many teams stop working on something when everybody kinda sorta agrees it’s done—not by a clear, documented process.

Define formats & expectations

This is one of the biggest levers in Werk user journeys. Things become radically easier when you:

1. Standardize briefings: When you develop (and use) a briefing template, you ensure your team gets the information they need.

2. Define where and how to deliver work. Dropping files in Slack buries them in a pile of messages and muddles your organization. Instead, clearly define the format (PDF? Google Doc? Docx?) and create a plan to deliver it (e.g. a spreadsheet).

3. Clearly outline expected deliverables and the ultimate goal of the task. This boosts motivation and lowers overwhelm.

Defining the user journey of work this way streamlines operations, removes many meetings and leads to less stress for everyone. But there’s a risk, too:

You want processes to serve people, not people to serve processes.

This means you should keep the process as simple and short as possible. As Gall’s Law states:

„All complex systems that work evolved from simpler systems that worked.“

Your UX may grow more complex as you add more people, sophisticate strategies and systemize QA.

But it should start simple. Don’t demand complex processes, but give broad directions and document from there. Process documentation should follow desire paths, like Ohio State University: They let students walk to class and back and paved the paths they already walked.

Your Werk user journey should be the same: Give a start and end point, see what works (and what doesn’t). Then „pave“ those paths by turning them into documented processes and systems.

UX design isn’t done after the website goes live. It’s an ongoing process. As in design, so in Werk.

But a user journey is only the beginning.

Why FAQs matter

Oh no! An evil wizard has turned your entire team (including you) into chickens. Luckily, HR already hired a new team and they’re starting today.

Question: How well could that team run your operations? How long would it take them to replicate your effectiveness?

If the new team (assuming the same skill level of the pre-chicken team) could start where you left off, awesome! If they had to start from scratch… you’ve got some work to do.

Now, your team (hopefully) won’t spontaneously become chickens. But asking this question is a useful heuristic for operations in your team. For many teams, a gang of fresh faces would start from zero. The knowledge of „this is how we do things around here“ only exists in the heads of the team.

And that works for knowledge logisticians. After all, the process does create outputs. But what happens when somebody quits? Takes a vacation? Turns into a chicken? That would paralyze operations.

That’s why Werk admins think different. UX-driven managers understand that keeping knowledge in people’s heads is like having no FAQ and sending every question to support.

Software with good UX makes it easy to find the information you need, where you need it. As a manager, this means:

• Creating playbooks, instructions and documented processes

• Surfacing those resources when you need them

Both matter. The materials themselves provide instruction to reduce revision rounds, meetings and ambiguity. The surfacing matters because you need people to use the materials, not treat them like a McKinsey 300-slide PowerPoint.

UX designers put settings close to the features they govern and provide links to FAQs, blog posts, etc. at points where users might need further input. You can do the same in your Werk. Here are a few examples from marketing operations (you can probably translate to your area):

• When assigning articles, auto-populate an article template that reminds your writer of the structure you’re looking for.

• Create or adopt frameworks by which you evaluate work—and reference them in your feedback.

• Turn successful efforts into repeatable playbooks to create more consistent success.

These activities create objective standards, free up everyone’s time and create more consistent results. They also provide a higher-leverage optimization mechanism: When something goes wrong or exceptionally well, you can enshrine the insights at a systems level rather than noting it once in a meeting.

This is the UX equivalent of having useful error and success messages, FAQs and blog articles right where the user needs them.

Like UX designers, UX-driven managers can step away from what they’ve built and know it’ll run itself. Sure, you need to fix errors, optimize things and get user feedback—but the system is designed to keep running, even when you step away.

As you’ve read my thesis UX design as a management theory, you may not have liked parts of it. That’s because perfectly streamlined Werk implementations make human collaboration transactional.

Should Werk UX Be Perfect?

So far, the „management is UX design“ theory has abstracted away humanity. We’ve reduced the colleague you’ve mentored for the past year to user. The meetings where the team laughs together? Replaced by some templates and automations. The random conversations from which unique ideas bubble up? Replaced by standardized to-dos.

The reason the theory above sounds dystopian is because while Werk might be a software product, work is not. Our work embodies our ambitions and contributions. It’s a core part of our identity.

Do we want work to be roaming through a sterile internet ghost town of templates, standardized processes and step-by-step playbooks to obey?

From this extreme, „Management as UX design“ sounds like it turns knowledge work into the very factory labor it helped us escape.

But that’s off. Management as UX design doesn’t advocate abolishing meetings or figuring things out together. It creates space for them.

Most teams (and most people) put off the things they need to do most.

The fundamental strategy work repeatedly gets postponed to „when there’s time“ so we can keep running on momentum until just one more thing is done. But „when there’s time“ is on nobody’s calendar.

The work that constantly gets postponed is where we get to share ideas, brainstorm and tell stories. It’s where we’re creative. Where our ambitions roam free. It’s what makes work worth doing.

But as the chaos of knowledge-logistics-management rages on, cobwebs grow on the high-leverage foundational work.

Being a UX-driven manager isn’t about eliminating the things we love about work. It’s about making space for them.

=

And that’s a wrap! I hope you enjoyed this essay and learned something new today. If you want to read more from me, follow me on Twitter for my short-form stuff and subscribe with your wallet on Mirror using the button below.

Want to help more people leave behind the knowledge logistics paradigm and embrace the UX design paradigm? Please like and/or retweet the tweet about this essay below:

If this essay brought a smile to your face, put one on mine too by collecting it as an NFT! You’ll support independent writing and—should I start a tokenized community—will give you access to that (no promises). Click the button below to collect:

ethereum://0x60f80121c31a0d46b5279700f9df786054aa5ee5/1.4506826964960857e+100