Agilebits recently caused a stir with their announcement that they’ve rewritten 1Password 8 as a cross-platform Electron app, replacing their well-loved native Mac app. The takes came hot and fast. Like many developers, I love and appreciate a well-crafted native UI, and I’ve been somewhat skeptical of the consistent trend towards cross-platform app UIs.

Now, the discourse around cross-platform app technologies has traditionally revolved around a simple idea: cross-platform development is cheaper, while native development leads to better apps.

And this is kinda true. Like, it’s true enough for a hand wavey explanation of why cross-platform tools are popular. But it is wrong enough that this mental model tends to obscure exactly why the latest large, profitable company has gone down this path. Each time a cross-platform app has found itself in the crosshairs of the internet, I hear a variant of this question: “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?”

Well excellent question, synthetic rhetorical person!

In practice, the tradeoff is about more than “cheap vs. good”. Unintuitively, sometimes native tech can actually be the cheapest way to achieve a certain goal, and sometimes cross-platform technologies actually lead to better products, even for very well-funded companies. So what is a useful way to think about the tradeoff?

Over the last decade I’ve talked to people at hundreds of companies about how they’re developing and supporting apps, helping them evaluate and plan native and cross-platform app work. While there are a lot of factors that go into this technology decision, there’s one that I think is particularly illuminating.

The Primary Tradeoff

At the highest level, cross-platform UI technologies prioritize coordinated featurefulness over polished UX.

Imagine the hero case for cross-platform UI: a complex enterprise app intended for a couple thousand employees to use on various platforms. They’re required to use the thing for work, and they need to be trained on it, but does it need to delight them? It does not. “Delight” is near the bottom of the priority list, between “cool soundtrack” and “joystick support”. The features just need to work, consistently – and cost effectively – across platforms.

Given that, enterprisey companies love cross-platform tools. Enterprises love feature checklists, and there is hardly a term more synonymous with “questionable UX” than “enterprise software”. A classic criticism of cross-platform tools is that they often get you to 75% quality quickly, but the remaining 25% gets increasingly difficult. But if 75% quality is as far as you need to go, then I guess you’ve successfully fulfilled your fixed-bid contract.

So naturally, internal enterprise apps converged long ago on cross-platform UIs – mostly web-based, mostly terrible. It’s a match made in heaven.

Where things get interesting is when you look at customer-facing software. Products where the experience is a big contributor to success or failure, and the higher “UX ceiling” that platform-specific UI code enables can help retain paying users. It seems, conceptually, that a big company willing to spend big money to build really nice native Mac and Windows apps would be in a position to outcompete the Electron-based Slacks, Figmas, and Spotifys of the world. Right? So why isn’t that happening?

The Exponential Cost of Coordination

On a small product team, keeping a couple native apps consistent with one another isn’t hard. At Steamclock, we’ve built and iterated dozens of nice native apps with teams of 3 to 6 people, and kept iOS and Android products in sync with one another and their siblings on the web with little difficulty. At this scale, the UX and simplicity wins of native tooling can be a huge win.

However, consistency starts to become a problem as your product and organization grow. When you’re rapidly hiring, rapidly adding client features, and adding support for a third, fourth, and fifth platform, things start to get dicey. 1Password’s Michael Fey touched on this in his excellent post about the development of 1Password 8:

Inconsistencies both small and large had crept into our apps over time. From small things like password strength being different between platforms to larger things like differences in search results and entire missing features.

This matters because as the number of feature, design, and bug variations between your platforms grows, coordinating clear conversations about your product gets harder.

• When is this feature rolling out on Mac?
• Is this support doc valid for web users?
• Wait, what platform was that big sales lead on?

At first this can be mitigated by throwing money at the sales and support teams, but as the inconsistencies accumulate, you hit a more dangerous problem: the product teams start to struggle to reason about their own product. You end up with siloed platform teams that aren’t on the same page. Product conversations slow down, wires get crossed, and details get neglected.

Some companies successfully avoid this fate by keeping their client apps lean. If you can stay disciplined in keeping your product simple, your platforms few, and your teams small, keeping everybody in sync can be workable. A critical tactic here is keeping as much complexity as possible server-side, working to keep your client apps as “dumb” as possible so you’re not simultaneously iterating a horde of logic across many different clients.

If your team size and product complexity do approach Scale™ though, laden with giant teams and reams of features across a half-dozen platforms, the inconsistencies will eventually get out of hand.

• A critical customer is angry because sales told them a feature works, but it only works on the platform sales checked.
• Somebody is dunking on us on Twitter because our docs are wrong, so a product manager dug into it – but it turns out they’re only wrong for Android.
• We can’t test a promising new improvement because it needs to be on all platforms at once, and those dinguses on the Windows team are 6 weeks behind.
• A terminology gap between the iOS and Android product teams led to a nasty bug being live on iOS for 5 weeks, when the Android team had already pushed a trivial fix.

Things get messy.

So at a certain size of product org, you get crackdowns on consistency and coordination. Product instates more process to keep the platform codebases in sync. More time is spent on procedure, docs, and formality. Feature quality goes up, but feature progress gets slower. The product becomes easier to communicate about since it’s more consistent, but… actually it’s not changing very much anymore at all?

So now you’re keeping a half-dozen featureful codebases consistent, but at a high cost. Hiring more engineers makes for a non-zero improvement, but the exponential – or at least super-linear – nature of coordination overhead means the additional product velocity per new hire can get disturbingly low.

Slow and ineffective loses the race

Slow is a dangerous place for a product company to be. Slow product teams tend to be outcompeted by fast ones. We complain about how Figma and Slack don’t feel native, but why are most of us using Figma and Slack? We’re using them because they outbuilt and outcompeted their native competitors. There are so many things that could improve in these products, but they’re the best tools yet built for their purposes.

The reality of coordination overhead at scale adds an additional layer to the tradeoff between cross-platform and native tools. Yes, native code is well suited to creating great user interfaces, but at a certain size of product team and for a sufficient number of different client codebases, the systemic costs of coordinating feature development across that many platforms itself will undermine the user experience.

So instead of a straightforward “good vs. cheap” tradeoff, we get a kind of non-linear tradeoff where the teams trying to coordinate the most feature work across the most number of platforms feel an incredible gravity towards cross-platform tools – even if a high priority on UX would predispose them to building native clients. On mobile platforms, where teams are often more disciplined about features and more focused on UX polish, the tradeoff is a bit different and teams more often go native than they do on desktop.

Of course, there is more than one way to use cross-platform technology to reduce the drag of coordination. As controversial as 1Password’s move to Electron for UI was, their decision to base all their apps on a shared Rust library was well received. Fascinatingly, in recent years teams like Dropbox and Slack have written about moving away from having a cross-platform core library powering their mobile apps – both teams are now fully native on iOS and Android. In a similar way, there seem to be two long lines of app teams, one announcing that they’ve moved towards React Native, and another announcing they’ve migrated away from it – a topic well deserving of its own post.

In the end, the best we can do is be thoughtful and watchful of these technologies and what problems they solve well. We watch them evolve, talk to people who are using them, and take in what teams share about their experiences – all with a pinch of salt.

Will Rust turn into more of a success story for cross-platform app cores than C++ was? Will React Native tamp down its problems and become a more and more compelling competitor in this space?

It will be fascinating to see.

I like to write.

Well, I like to have written. And I especially like when people read what I’ve written, and find it useful. It brings me joy.

Writing useful things also helps me do my job. When you’re growing a team, you only get so far on oral tradition, habits, and institutional memory. When folks need to bug a senior team member to access your most valuable knowledge, it’s harder to level people up.

Given that, I’ve been spending more and more work time on docs. I’ve written docs about project management, client communication, hiring, architecture, 1:1s, product development, and dozens of other topics. It’s been really valuable for helping clarify our approaches to certain things. Concise, readable docs can give folks a big leg up.

However, I recently started to notice a problem.

I would gather input from our team on a topic, draft a doc on it, we’d iterate and refine it, and yay it’s great. But beyond that, it wouldn’t get referenced. Creating the doc would help us learn and refine our thoughts, but its value would too often stop there. A team would be waist deep in some tricky problem, and eventually I’d realize, “Wait. Isn’t this a problem we wrote about in our Project Management at Steamclock doc?” And we’d all sort of nod in vague recollection, not quite sure why none of us have have referred to that clearly written doc from a year or two back.

And if a doc isn’t being referred to, it’s not doing any good.

We already do a lot of things to help ensure our docs are useful: we make them short and sweet, well maintained, consistently formatted, and for the most part they’re on topics we’ve agreed are important. We work to organize them in an easy to navigate hierarchy in our Coda (think Notion but with more powerful automation and a bit rougher around the edges). So why was nobody referring to some of them?

The power of guides

My latest level-up on this came via Adam Avenir, who has led companies and teams for ages. He explained that the docs he’d written that were most often referred to had a theme: they were how-tos or checklists. Guides on how to get a thing done.

This struck me as powerful. Obvious in retrospect, as many powerful ideas are.

If a doc is clearly a guide for doing a certain thing, then people are a lot more likely to think of that doc when they’re doing that thing.

A team of individual contributors might be aware of “Project Management at Steamclock” existing, but are unlikely to prioritize re-reading it when a certain project management topic comes up. On the other hand, docs like “How to Prioritize Issues”, “Making Tough Decisions”, or “Run a Design Sprint” draw you in at the right time – the title tells you when the doc is useful!

Thoughtbot’s Playbook is mostly organized this way – you can sort of drill into it with a certain task in mind, and many of the docs are titled in a way that indicates what they’re meant to facilitate. And for the ones that aren’t titled that way, well – I’d wager that their page “Facilitating usability tests” gets more hits than the generically titled “User Experience Design” primer.

With this in mind, I’ve recently retitled and refined many of our docs to act more like how-tos and less like topic overviews. A couple months in, it’s already paying dividends. Not only is the team more inclined to navigate and refer to these guides, but they’re easier to write!

Mind you, a guide doesn’t need to be too prescriptive or constraining. You don’t want to bog down a thoughtful and creative team with a ton of policies that tell them what not to do. You do want to equip them with useful guides outlining how we typically do specific things, especially if those lessons were hard won.

And yes, from time to time it’s worth writing a primer, overview, or a thoughtful exploration on some key aspect of the business. In practice though, the docs your team will reach for most are the how-tos. Guides that help them do something.

In order to help encourage this style of doc, without discouraging less formal notes and docs, we now distinguish between a Guide and a Note in our doc “How to Start a Guide”:

• Guides are nice docs we’re maintaining with the goal of them being concise and correct. This is most often worthwhile for “how to” docs that will be referred to more often than they change.
• Notes can take any other form, and are great for capturing knowledge from a specific point in time: meeting minutes, findings from research, results of a brainstorm, a project update, etc. These are generally docs “as of $date”

Growing a team is all about iteratively putting yourself out of a job. You teach people how to do what you do, so you can go and do the next layer up of broader, trickier, or more uncertain work.

Sometimes all you need to do is write out how to do something, so talented folks can pick it up and do it – then do it better.

Early in one’s life, it’s easy to be driven by goals. Pass the test, get the grade. Get a job, buy a car. Get into university, finish university. Get married, have a kid. There are a lot of things to do!

While the specific goals vary from person to person, our lives start out with a lot of low hanging fruit. Things that haven’t been done, but are clearly worth getting done. It can be a big motivator.

At a certain point though, perhaps in your 30s or 40s, this loop becomes less satisfying. The most straightforward goals have been achieved, and the most ambitious goals are starting to look, uh, ambitious. Even when you’ve done what you set out to do, it doesn’t feel quite right. “I’ve achieved all these things. I’m successful! Why don’t I float through each day radiating the tranquil joy of an accomplished human? Why do I still sometimes wake up feeling, a little bit, like a duffel bag of shit?”

Of course it’s well known that that achieving goals doesn’t directly make you happy. I learned the phrase “Life’s a journey, not a destination” all the way back in 1993, when it was coined by noted philosopher Steven Tyler. But it took 26 years for me to actually do something with this information, when I read an essay from Ed Batista that put me onto this idea, titled “Not Every End Is a Goal (On Midlife Malaise)”.

I was initially hesitant to read an article about midlife crises. I’m not even 40 yet. I have neither the inclination nor the time to have a crisis, let alone a midlife one.

And even if I did, what an embarrassing privileged white guy thing to do. People are out there – as we speak – fighting for their rights, fighting for their lives. Meanwhile I’m sitting here like a jackass thinking, “Hm, checking off these OmniFocus tasks isn’t giving me as deep a sense of self actualization as I’d imagined; what is my path to lasting purpose?”

Still, checking off those OmniFocus tasks really wasn’t giving me as deep a sense of self actualization as I’d imagined. So when that article put the following very useful idea on my radar, I was primed to receive it. Perhaps it will help you too.

You can divide how you spend your time into two categories..

1. Telic activities. Things whose purpose is the end. Drive home. Have a wedding. Unclog a drain. Ship an app.
2. Atelic activities. Things whose purpose is the middle. Explore the forest. Listen to music. Tinker with something you enjoy.

The problem for ambitious people comes when we load up on telic activities. We push ourselves to check things off and get things done, and feel perhaps guilty when we’re not getting anything done. There’s gotta be a balance.

And that ideal balance tends to shift as you get older. Your youthful focus on telic activities – things you’re glad to be done with – ideally adjusts over time to more atelic activities – things you’re glad to be doing.

This isn’t a secret formula to guarantee a purposeful and fulfilling life – that can only be achieved by playing a very 90s VR game where you watch a guy play a similar VR game about motorcycles and making out and… weird 3D dogs? But I’ve found it helpful.

Honestly, even just being thoughtful about when I’m doing something for the sake of doing it has been nice. I walk a little slower when I’m just going for a walk, I’m a bit less focused on finishing games, and I’ve been getting better at enjoying the parts of my job that I really enjoy – in the afternoons, once I’ve checked off the thing that really needs doing.

It’s amazing.

As we grow at Steamclock – we’re now at 14 and hiring our 15th – we’re getting more intentional about how we do things. I worry less about how to do the work, and more about how to build the team and our processes.

Which is great. But it’s a problem set that is a bit more… ambiguous. We want to constantly improve. But how do we separate the big opportunities from the stuff that’s just inherently annoying?

There’s a sentiment I sometimes hear when we’re considering these kinds of problems:

Well it’s not great. But we’re already better at this than any company I’ve worked at before.

Which is nice to hear – we’re already the best! Phew. Maybe it’s just a hard problem, and nobody’s great at it. We can just move along and… wait a minute. Waiiit a minute.

We’re better at this than any company you worked at before. But how did things go for those companies? Poorly enough that you left.

Do they even exist anymore? If they do, presumably they’ve gotten better. If not, they’ve been replaced by leaner and smarter competitors. Meanwhile, we’re comparing ourselves to companies that couldn’t retain great team members. We’re ignoring the existence of the teams that are out there kicking ‘tocks, and defining the new standard for how ‘tocks can be kicked effectively and profitably.

Of course the past experience of our team members is invaluable. But we need to be actively researching what effective teams are doing nowadays. Find people who work at companies that do great work. Read what they write. When you can, build a relationship where you can share what you know and they can share what they know. Don’t let yourself feel smugly superior to the last generation of companies.

Benchmark yourself against the folks kicking the most ‘tocks.

I talk to a lot different companies about their mobile app plans. Sometimes they have a really compelling business case for an app. Sometimes getting a quality app their customers’ hands is the key to supercharging their business, and is something that will pay dividends for years.

More often, it is… not that. Usually they just need a website.

So my team made a little checklist to help explain to folks why they might (but probably don’t) need an app.

For most of my life, I rarely read books.

I’m a pretty high-energy person, but a rather slow reader. Ever since I grew into an Extremely Online teenager, books have felt a bit… sluggish. Less informative, per hour invested, than the alternatives. Low density.

I’ve always loved the idea of books. But did you know that finishing a book can take days, if not weeks?! Meanwhile, our world is thronging with fascinating topics, perspectives, and information. There are so many things one could be learning about. You could read dozens of short-form articles – or thousands of tweets – in the time it would take to finish a book!

Going wide

Unfortunately, there’s a problem with gorging short form writing. Although it can expose you to a wide array of things, your understanding of those things eventually hits diminishing returns. Eventually, all the quick takes start to sound familiar. The Wikipedia articles start to feel a bit samey.

A book, on the other hand, can take you in a different direction. It can help you go deep.

In long form, authors can do more. They can do more setup, provide more context, and build a more thorough framework for considering a topic. They can also give more memorable examples, work through more potential criticisms, and offer more variants of their most useful ideas.

Something I’ve only recently come to understand, though, is the value to readers of going deep themselves. Taking the time to read something a little bit each day, highlighting passages, taking notes, and thinking about a topic throughout the week helps you really process it. You can consider something in a deeper and more meaningful way, often leveling it up from something you’ve been exposed to towards something you can do – or even teach. You can really immerse yourself in how this thing really really works.

Of course, it’s not possible to engage in depth with every topic out there. But for me, going deep on a few things a year has been really cool.

When building teams, we sometimes talk about the value of “T-shaped people” – folks who have a broad array of experiences and skills, but also deep experience in a specific area. In the same way, mixing a few deeper works in with the broad reading we do online can make for a powerful combination. A T-shaped information diet.

And it can be really nice to get some distance from the shitstorm du jour. Not all books are timeless, certainly. But their production cycle lends itself to ideas and treatments that might still be meaningful years, or even decades later. Whether you get your recommendations from Goodreads, friends, or coworkers, you’re probably not going to be inundated with books like Everything you need to know about Apple’s AirPod Socks production delay rumours. Or You Won’t BELIEVE What Elon Musk Just Said About NFTs. And that’s pretty great.

Since books often have more durable value, you can also justify putting a little more into reading them. You might add a few notes, highlight some passages – Kindle makes this easy – and write a brief reflection afterward.

Afterwards, you have gained not just the knowledge of the book, but a new tool in your belt. A new seed you can plant in the minds of others – or your future self. You can refer to your notes when you revisit the topic.

Of course, any book is at its best when you read it at the right time, and sometimes that time isn’t now. But by taking notes, you can cue yourself to revisit it later, when it’s exactly what you need.

Recommending a book to others can be a bit trickier. A lot of busy people don’t exactly love having “read a whole-ass book” added to their todo lists. But if you have a culture of reading on your team or in your family, then building a library of books you can suggest or refer to can really help you help the people around you.

Admittedly, getting there can be a little slow. But sometimes – especially when everything is feeling like a lot – slowing down can be worthwhile. Nice, even. Just for a while.

I’ve spent the last year trying to decide if Steamclock should go all-remote, or if we’re better off going back to all-in-office. Both options have substantial upsides! And both avoid the dreaded “hybrid” meetings with half the team in a conference room and half on Zoom.

I feel a bit silly that, after all this time, we’ve decided to do neither. For us, neither extreme is going to build us the best team, and lead to the best software.

Still, I think our approach for avoiding hybrid meetings – namely, cutting down meetings – will be great. And “Vancouver HQ or Remote” feels like the right heading on our job ads.

So if you’re one of the many thoughtful, skilled developers doing quality work in many of Canada’s beautiful out-of-the-way places, I’d love to chat! Especially if you make apps. But even if you don’t – yet.

I am not instinctually a planner.

In school, I didn’t keep a todo list, or even a calendar. I would make the occasional list, but for the most part I was a “we’ll do it live” sort of person. And sometimes that served me well!

And other times it didn’t. At times, I would end up needing to pull an all-nighter to finish something. Or feel discouraged by the sheer number of half-completed projects I had laying about. Or only realize that today is midterm exam day because the test papers are being handed out this very moment.

I did okay in school, but it was certainly more stressful than it needed to be.

When I got into the “real world”, especially once I started a business, the seat of my pants stopped being a viable method of flight. When you’re running the team, nobody is reminding you to do things. You either do the important things, or you’re gonna have a bad time. If you forget to invoice a client, or neglect to check in with one of your team members , things will get rough and it’s your fault.

You need a system to draw your attention to what’s important, before it becomes urgent. For me, I maintain that system in OmniFocus.

Being kind to future you

Many years ago, I started my time management journey the way many people do: with a calendar, Things, and the book Getting Things Done.

I had a hard time getting through the book – David Allen is far more interested in putting pieces of paper in filing cabinets than I am. But I liked Things. It’s simpler and prettier than OmniFocus. That makes it a good place for establishing some core habits that can put focus on what’s important:

1. Capture everything that is worth doing, bothering you, or distracting you.
2. Organize it into a simple system that flags what’s actually critical.
3. Iterate that system and your habits over time.

After a couple years improving my habits around capturing and organizing, I started to hit limits when it came that third point: iterating the system. Things is a great starting point, but switching to OmniFocus gave me the power I needed to start really getting in there, patching and refining my workflow to keep me focused and effective.

In the years since, I’ve wound my way through many different setups and workflows. I’ve learned a lot about what my personal weaknesses are, and what kind of setups are the most effective for me.

I also should say that, recently having re-read Getting Things Done, that there are a ton of useful ideas and tips in there! Is the revised version better? Or did I just grow up? Either way, a really useful book. Still gonna be a no from me on the filing cabinets though.

Anyhow, after many attempts at devising the One True System that will bring me ultimate productivity and focus, I’ve come to terms with the fact such a system can not exist. As life and work are always changing, and so are our habits, and priorities, and weaknesses, the ideal system for a given person is always changing. To stay effective and calm, I now expect to keep tweaking my workflows over the months and years to come. The system now grows along with me, so it can help keep me focused on what’s important.

Iterating work, life, and systems

My need for iteration became even clearer in 2019, when we made a big decision at Steamclock. We decided to leave a safe, calm territory we’d occupied for years – a 10 person studio with no real structure or management layer – and start growing. For a decade I’d managed our development team directly. Now I manage managers, and we’re hiring and building like never before. I’m now presented with 10x more interesting ideas and opportunities than I was previously. I run strategy meetings now? I basically have an entirely different job than I did two years ago.

During this transition, we also got thrown into unexpectedly working from home, and my family welcomed our second child.

So it’s been a lot. Together, these changes have meant I’ve been flooded with things worth doing. Which is cool! But there now are way more things coming to my attention than I can actually do, or that we can even do as a company. So as is the way, I started trying iterations and variations on my workflow to handle this. Tuning it, so I can effectively navigate this new environment.

When doing that work, there are 4 principles I’m looking for. In rough priority order, I want to see that:

1. Time and attention is going to what’s important – I’m not only working on urgent things.
2. Blocked and “someday” stuff is out of mind – not distracting me from the “now” stuff.
3. The system is resilient – if I get overwhelmed one week or neglect maintaining the system for a while, it needs to still be workable.
4. The system calms and motivates – it should be a source of focus, not stress.

If the above is true about my setup, I’m in good shape. If not, it’s time to experiment to get me back there.

Since my setup is relatively simple as far as OmniFocus setups go, it might be interesting to folks who are on their own journeys, trying to achieve a little more peaceful control over their task lists. So here’s where I’m at.

The Forecast

My most important view is OmniFocus’ Forecast view. This is where I pull work from, primarily. In the Forecast you set can up a “hero tag” so any actions with that tag will appear, sortable, underneath anything that is now due.

I’ve learned, through trial and error, not to over-use due dates in OmniFocus. Deadlines are powerful things, but putting fake due dates on stuff tends to set you up for “due bombs” where a bunch of stuff is supposedly due but only 1-2 of the items are really due. I prefer to only set due dates where an actual bad thing happens if you don’t do that thing by then. I’ll often indulge by also putting a “fake” due date on a couple of my most important things – but that’s it!

On the other hand, Defer dates are wonderful. If you can’t do something right now, or you’re realistically not going to do it anytime soon, but it’s still pulling on your attention, then defer it. Bye, thing! I have a ton of deferred tasks in the system. I don’t think about them, until they’re useful.

Naming actions

OmniFocus is a way more motivating place to be when you’ve named your tasks not as if they’re reminders, but rather like recipes for getting started. That’s why the app calls them “actions” and not “todos”. GTD calls this principle the “next physical action”. My rule is if that I look at a thing, it should describe the way I go about starting it.

My follow-on rule is if I find myself still not starting an action, even though it’s important, I try rephrasing it. I’ll try adding more detail about how I can start doing it, or even just use different wording. I want my lazy “monkey brain” to see an action, and instead of thinking, “Ugh right, that thing I haven’t done” it will think “Okay, I can easily start that.”

Projects

David Allen defines a project as anything that takes multiple steps, and which you will complete in the next 12 months. That’s cool, but I find it a huge distraction trying to organize my OmniFocus Projects that way. Creating hordes of Projects with 3 items in each is too much work for me, and it’s a pain trying to clean up my inbox when I have a horde of Projects set up that are weirdly worded because I wanted them all to be actionable and completable.

Instead, I keep about 10-15 ongoing work Projects, mostly named after areas of responsibility in my role, roughly sorted by importance. I keep about the same number of home Projects, set off in a folder. They all start with emoji. Obviously.

I often name Projects with reminders about why the thing matters, paired with a quick keywords for autocomplete filing purposes. I do marketing to bring in new clients and customers – it’s not an end to itself – so it’s called “🧁 Find new clients – marketing”.

Sometimes a project is important and complex enough that I do want to promote it to a top-level OmniFocus Project. Often, though, multi-step things live in my system just as the next action I’m going to take on them, often with a reminder of why attached. For example, I might have an action like “Refine this hiring principles doc, so I can share it with the team”.

Finally, I’ve learned to notice certain patterns that indicate something has gotten off track and needs a changeup. If a project isn’t well served by this system – it’s stressing me out, or not getting done, or just gumming up the works – I’ll usually try promoting it, demoting it, splitting it, or renaming it to get things moving.

Getting Things Calmer

I have two special projects. These sit on the top of my work and home project lists, respectively: “🎯 Make work more relaxed and focused” and “🧘🏽‍♀️ Make home calmer”. These are for fixing things that are distracting me, impeding me, or otherwise harshing my vibe.

Sometimes these lists clear out and I’m just happily working on project work. Other times though, there are so many things I should be doing that I notice myself getting overwhelmed and actually doing fewer things. If you notice this, it’s a warning sign that you’re veering towards burnout. In those times, I find it really useful to put a priority on clearing out things that are contributing to that stress or distraction. This might be responding to an intense email, finding a meeting we can cancel to open up more focus time, even just cleaning up my desk. Simple tasks that help bring back focus can have a huge payoff.

Someday

One issue I’ve recently been getting more strict about is “someday/maybe” projects. As I’ve gotten more and more ideas of things that seem worth doing – from our team, from books, from the daily inputs of running a team and being a parent – my OmniFocus projects have become infested with interesting potential actions that, if I’m brutally honest with myself, I probably won’t actually get to. Especially not in the next few months.

If you can get real and convince yourself you’re not gonna do the thing, you can just delete it. That’s not always fast and easy though. Look at all those cool ideas! It would be so great if I did them! So what a lot of people do is put things they want to reconsider doing later in a giant “Someday” project. When I’ve tried that, “Someday” quickly becomes a black hole from which ideas will not return. An admission of defeat, and source of angst.

But!

I’ve had great success recently with, instead of one giant Someday list, demoting not-right-now actions to a set of “Ideas” lists. Marketing ideas, Learn a new song, Ways to improve process, Prototype an app idea, and so on. This has made it psychologically easier for me to demote a non-critical action that’s clogging up my OmniFocus, since it will be easily findable and retrievable if do want to spend more time on whatever kind of idea it is.

Like many habits worth building, this is kind of an arbitrary distinction, and its benefits are mostly psychological. Which is fine! It satisfies my monkey brain and that helps me live my best life. A life which may or may not involve actually doing anything with the things I stick on those lists. 😅

There’s another form of Someday task I’ve been recently banishing with great benefit: other people’s Someday tasks. As a manager, I often have or receive ideas about things another team member could do. In busy times, I’d be reluctant to say “Hey, how about someday you do X?” since it was liable to distract people from the actual top priorities of the day. So I’d instead store them in my OmniFocus, and I’d feel recurring angst about whether now was the time to promote this to a “Hey now you should think about this” idea.

Recognizing the folly of this, I’ve made a big move to get those things out of my personal system and into ones we share as a team. It doesn’t matter if it’s Notion, Google Docs, Trello, or even a shared Apple Note. Having these ideas and tasks off my computer and on the fringes of our team’s radar – yet clearly labelled as “someday” tasks – has been a big win for us all.

Tags

Like many people, I set up my OmniFocus with a “Home” tag and an “Office” tag, so I can filter out stuff I don’t want to look at right now. I have a sub-tag of Office, “Now ☕️”, that I use as my next actions for work, which I keep in my Forecast view. I used to call it “Today”, but that was too often a lie and was causing a bit of angst, so now it’s “Now”. Always be iterating.

Beyond that, I mostly use tags to experiment and prototype. For example, I recently noticed how often I was looking at actions that I could in theory do any day, but which I couldn’t do right now because the baby was sleeping. My home tasks were starting to get crowded with blocked actions: take a specific baby picture, fix something in the baby’s bedroom, whatever. The problem is that whenever the baby is awake, I’m probably not looking at OmniFocus! So I’ve been trying out a sub-tag of Home I’ve called “Baby Awake” for these actions. It’s usually On Hold, which hides them unless I specifically seek them out. Seems to be working well so far.

This is the kind of thing tags are great at: trying out workflows. They can be easily discarded if they don’t end up be worth the effort of maintaining.

Flags and Perspectives

Flags are another thing you can use for ad-hoc prototyping of new workflows. The main thing you need to avoid with flags is over-using them. If most of your actions are flagged, then none of them are flagged.

Currently, I use flags to indicate “this thing is more important than most other things in its project”. I often sort things in my Projects in rough priority order at Review time, and flagging something as it goes into the Project helps me do that quickly.

Flags also power a Perspective I’ve called “Office Next”. That’s where I go when I’ve checked off most of the “Now” items that appear in my Forecast, so I can populate it with a few good candidates for what’s next. Importantly, that Perspective only shows me things I haven’t yet promoted to “Now”.

I also have a “Home Now” perspective which makes use of flagging. This is more or less the Home version of the Forecast view I use for work. It’s also pretty simple: basically things that are due or flagged in my Home projects.

I know that there are a lot of folks who advise against relying on flagging as a core part of your workflow. Flags’ meaning isn’t explicit, and they’re easy to make a mess of. But flags are also really visible, and easy to make use of. In my opinion, they’re a handy tool in the toolbox.

The Review

The last key piece of the puzzle is doing a periodic review. I do cleanup, promote what’s important, jostle stalled work, and make sure I’m not missing anything critical. OmniFocus’ Review feature is really helpful for this, where it brings up each project for review on a frequency you decide – I use the weekly setting for a few key projects, but most of mine are set to come up between every 4 weeks and every 12 months for my “someday” stuff.

To ensure it happens, I have a time blocked out at the start of our weekly No Meetings Day – you should also have a No Meetings Day by the way – where I do a fairly quick Review. This takes me between 20-60 minutes, depending how things are going, and how much I’ve been neglecting my system. If I find it’s taking too long to get through a Review, or things are getting really messed up whenever I miss one or two weeks of Reviews, that’s a signal to me that my system is overcomplicated and I need to shift back towards to where I started: having a simple system that flags what’s important.

Living your best life

How did somebody who is not instinctually a planner, a person predisposed against specifications and overformalization, end up with over 1000 actions cleanly organized with a myriad of tags, rules, repeats, and reminders? One step at a time. If you’re new to this stuff, I encourage you to start with something, and experiment.

Likely, you’ll get off track from time to time. The framework you try at first is unlikely to be the right one for the way you currently work, and your particular mix of strengths and weaknesses. Sometimes it’ll get out of hand. That’s how it goes!

All you need to do is come back to the core principles – getting the not-now stuff off your mind and the most important stuff on your mind – and iterate.

I also presented this topic at Learn OmniFocus, where I gave a more in depth view of my workflow setup.

“We are looking for a development team for our app idea. We have our brand and logo finalized – with a worldwide go-to-market plan – and just need to finish things off by building the app.”

I’ve spent a lot of time building new products with different people. I’ve picked up on various signals that hint at whether a product will succeed or fail. Some of these signals are subtle hints; mild warnings. Others are the most crimson of red flags, pulsing with danger, like a lighthouse in a storm.

One of the more alarming flags is a founder that thinks they have finished the marketing before they start the product.

Telling tales

Now, marketing is a crucial part of any venture. You must tell stories that your potential customers find compelling. Marketing is a multiplier, and without it even a strong product can stall out, failing to find the customers it would serve well.

This is especially true in markets that are commoditized.

If you’re getting into a commoditized market – say, laundry detergent – then your marketing should come before the product. You start by understanding the competitive landscape, who the customer is, and how they want to feel about their detergent.

Then you craft a compelling detergent-based story, design brand assets, and build a compelling marketing campaign that compels people to want your very specific tub of fragrance and alkyl sulphate.

Once you’ve done that, you can choose the fragrance – one that helps tell the chosen story. And oh yeah, don’t forget to add the actual alkyl sulphate before you package it all up and send it off to do battle in the crowded field of laundering agents.

There are a lot of business opportunities like this. By bringing a compelling marketing vision to a commodified market, you can build a monster of a business by displacing a similar product that has a less compelling story than yours.

Famously, Grey Goose started with a name, then a feeling, and a price point. Then they decided on a provenance – how about we make it in France? Oh hey, we can filter it through limestone from Champagne? YES! Okay we’re almost done, we just need some vodka.

8 years later they cashed out for $2 billion.

Vodka is a beverage that is supposed to taste like nothing.

Starting with marketing is a great approach if you’re selling a commodity by attaching a feeling to it. But it’s a not-great approach if you’re trying to build a new software product.

The tricky part

Software is, generally, not a commodity. Most software companies succeed by solving new problems, or solving old problems in better ways. Building and scaling software is a complex undertaking with ambiguous requirements, rife with pitfalls and tradeoffs. As a result, different teams tend to end up with different software, differing depending on their path and environment.

Further, successful software often benefits from network effects and economies of scale, further differentiating it from would-be competitors. Duplicating Facebook is not a way to get anywhere.

This makes a head-on challenge – the detergent approach – ill-advised in software world. Fledgling apps are usually leaky buckets: most prospective customers bounce right off of them. Helpful for the team’s learning and iteration, but hardly a business. And all the marketing in the world won’t fill a leaky bucket.

So the approach in the software world is to first build a good bucket. When that’s coming together – often many iterations in – you can hone in on a marketing strategy that suits the kind of bucket you’ve ended up with.

Alternatively, you can try to nail down an exact product vision, from brand to marketing strategy, up front. Then when you start building, you will be surprised. You’ll realize that the hero feature you were banking on is actually just table stakes. You’ll discover that your supposed target audience doesn’t have the budget to fund this amount of work. You’re going to learn that the platform partner you intended to rely on wants you – and any company like you – to thoroughly die, and they have the means to make that happen.

Companies that have invested a lot in up-front branding and marketing often struggle with these surprises. “Dude, we paid $2 million to buy tea.com,” they’ll say. “I don’t care what the margins are on coffee, we’re going to be a tea delivery app or die trying.” So they die trying.

If you want to survive in software, your product is going to change. If your marketing is going to be worth anything, it needs to roll with that change, not impede it.

Getting started

A lot of founders agonize over naming their company. “How will this fit in to our larger brand vision and achieve optimal strategic synergy?”

Meanwhile, the company that built Buddybuild from nothing to world-class to being aquired by Apple in only 3 years was not founded on a long-term brand vision. It was founded as “doe pics hit, Inc.” As in, “DoEpicShit.” Then they dove into the process of making something people needed. That initial brand, such as it was, was irrelevant as soon as they’d built a product that was the best in the world at what it did.

So yes, absolutely invest in marketing, once your product is crystallizing. Once you’re selling something that people want, and you’ve proven it, telling your product’s story well is a critical multiplier for your success. But you need to get the order of operations right. At a company level, the recipe for marketing is as follows: Do great work, then tell people about it.

Until then, focus on doing epic shit.

Today I posted a recap of iOS’ new 3rd Party Tracking rules and their impact on analytics over on the Steamclock blog:

Apple did not – and from a legal perspective likely can’t – explicitly ban the Google Analytics, Flurry, Facebook, and Firebase SDKs. Their wording leaves some wiggle room. It seems like it could be possible to use them. It seems even more possible that Facebook and Google could make them usable. However, this puts developers in the situation of evaluating the changing documentation, complex privacy policies, and large settings panels that these tools offer, trying to judge whether a given setup of a given SDK would now pass muster from Apple’s perspective.

This doesn’t even get into the even gnarlier uncertainty facing businesses that rely on 3rd party ad attribution via the Facebook or Google SDKs, or indirectly via something like Segment or Branch. Hopefully we do get something conclusive about how App Review is going to manage all this, but I doubt it. As is often the case, you can either do what Apple is implicitly asking you to do – remove these SDKs entirely – or figure out exactly what’s permitted by an App Review trial-by-fire.

Conventional wisdom says that spending hours in front of a screen is not great for young kids. Most guidelines encourage parents not to give kids under age 2 “screen time” at all, and not to give kids ages 3 to 5 more than one hour a day.

Now, in the best of times, limiting a 4 year old to one hour a day of screen time can feel… ambitious. In the worst of times – say, in the middle of winter during a global pandemic, that kind of thing – it’s outright gruelling. That’s because screen time is like pixie dust.

Kids love screen time. Parents love screen time. During screen time, kids can do what they want to do: watch princesses defeat evil. Parents can do what they want to do: finally fix that door that doesn’t close properly. Everybody is happy.

Everybody is happy, at least, until the designated time limit comes up. Eventually – whether by parental intervention, or by Apple’s excellent Screen Time controls – we return to reality.

As a result, parents spend a lot of time asking themselves: what indoor activities are wholesome and engaging enough that they facilitate half-assedly accomplishing things that are required for our household to function?

There are a lot of options. Drawing princesses. Playing with princess Lego. Building structurally unsound princess castles out of random household objects. I’m here to point out an option that is under-utilized, perhaps only for technical reasons: streaming kids’ audio stories.

Once upon a time

Watching a story on-screen is a pretty passive activity. Contrast that to when kids are told a story: they imagine the story unfolding, get exposed to new vocab, and are less likely to be scared when the villain magically transforms into a giant demon octopus thing.

So, if you subscribe to Apple Music – or are willing to try it out – check out their high-quality kids’ stories. They have audio adaptations of many Disney movies, most Robert Munsch books, and countless renditions of classic fairy tales. When we first discovered this, it was like being granted extra wishes.

But there are a few, uh, provisos. A couple of quid pro quos.

For starters, although Apple Music has a lot of kids’ stories, it’s fiendishly difficult to find them. There are no official playlists or categories for stories. They’re just buried deep in a sea of dodgy search results. So you get to play a game.

Hm, do they have a Moana story? Nope. The Gruffalo? Ye… no, it’s just the music. What about Winnie the Pooh? Okay cool, now to locate the story track amongst all this music… Ah okay, I can search “winnie the pooh story” and it’ll work. Oh, other times the tracks are just titled, e.g. “Yertle the Turtle” so if I search “yertle the turtle story” it’ll return nothing…

I said it was a game, not that it was a fun game.

Still, some of the stories are quite good. Our daughter loves them! In some cases she’ll play and listen for an hour while we get some human-adult stuff done. It’s great.

Some of the stories, however, are not great. Some are just kind of poorly acted or produced – tiresome but tolerable. More annoying, to me, is the minefield of “why did we think this was a good idea” plots and topics that many kids’ stories revolve around if they were produced before, say, 2000. You know, princesses whose sole purpose in life is to marry. Characters who shame one another for being fat or ugly. A surprising amount of murder? Generally just a lot of people being horrible to one another.

I know there’s only so much we can do to set positive examples for our kids. But if a 4 year old is going to be enraptured by a story, why not make it one without sexism, murder, or blatant racism? Is it too much to dream?

To its credit, Disney Plus locks down some of its most egregious historical artifacts from being accessible by kids. Apple Music, meanwhile, decided that once a wholesome Winnie the Pooh story completes, it should auto-play “similar” tracks, specifically this uncensored version of Peter Pan. Yes Peter Pan, the movie where characters infamously and repeatedly refer to indigenous people as “redskins”. Where they sing:

In the Injun book it say
When first brave married squaw
He gave out with heap big “Ugh!”
When he saw his Mother-in-Law
What made the red man red?
What made the red man red?

After noping the fuck out of that, we decided it would be best to play stories from playlists only.

How far I’ll go

Unfortunately, there are no curated playlists of kids’ stories on Apple Music. So we had to accumulate one ourselves, via expeditions into the search system, with periodic removal of ones we found too inappropriate or annoying to tolerate. Throughout this process, though, I found a frustrating pattern: our daughter wanted princess stories, but most of the ones I could find were old-school – the Sleeping Beauties and Cinderellas. Sleeping Beauty is wonderfully animated, but the princess’ primary traits are:

1. Her appearance, and
2. Her lack of consciousness.

Not exactly a robust role model.

Meanwhile, the stronger modern stories like Moana, Frozen, and Brave didn’t have audio versions. Or, in the case of Brave, did have a “Songs and Story” edition, but not available on Apple Music. How peculiar.

Recently though, things changed. Apple Music suddenly added some of Ellie’s favourite stories: Frozen, Ratatouille, Moana, WALL-E, Peppa Pig, and more. And in doing so, they revealed why so few kids’ stories were being released in the streaming era.

Here is a Peppa Pig story released on Apple Music this month.

Behold. A 5-minute story released not as a single track, but as an “album” split into seven tiny chunks. 38 seconds, 36 seconds, 40 seconds, 34 seconds.

Of course it was. Because streaming services pay rightsholders not by length. They pay by number of tracks played.

So while Disney was previously producing 50-minute audio versions of their animated movies, they’re now producing 9-minute versions, split into 3-minute chunks. Each story starts with a clear warning, “Be sure to set your device to play in order, and not on shuffle.” Meanwhile, Apple Music persists your shuffle state in such a way that sometimes it will unexpectedly be on. Don’t worry, you won’t notice – not until the story suddenly warps to an arbitrary location. “DAD, THE STORY’S WEIRD AGAIN!”

Streaming giveth, and streaming taketh away.

I want to be… where the stories are

So stories are great, but Apple’s offering here leaves something to be desired. What’s a bear to do?

Audiobooks. Audible has a number of kids’ stories. However, the books often cost $20 each. This can be a good investment if your kid will listen to a given story multiple times, but that can be hard to predict. I’ve long pined for a 30 to 60 minute long version of Moana, but the options on Audible are hours long. Does your kid have a 3 hour long attention span?

Audiobooks are also much less likely to include the voices, sounds, and music from the properties the books are based on. And audiobook apps certainly don’t expect you to build up a playlist of books and shuffle them, listen to the same book repeatedly, and overall behave like a 4 year old. Oddly.

Spotify. A few years back, Spotify didn’t have much in the way of kids’ stories. Recently they seem to have leapfrogged Apple Music on this front, offering not only many of the same stories, but a whole Spotify Kids app. This makes discovering them far easier than on Apple Music. Having kids stuff in its own app also makes it easier to keep kids’ listening interests from destroying your own recommendations and playlists. (Spotify thinks my favourite album of 2020 is the soundtrack to Pixar’s Cars. It is not.)

While having curated lists is great in theory, Spotify not only offers the aforementioned “redskins” edition of Peter Pan, but happily features it at the top level of the Stories section in the Spotify Kids app. Yikes.

Podcasts. There are a number of kids’ story podcasts out there. Some are pretty good. For example, our daughter likes specific episodes of Earth Rangers and Girl Tales. Now, good luck getting the Podcasts app to help you listen to specific episodes over and over. (In the app’s defense, I don’t particularly want to listen to them over and over either.)

Hoping for some variety, I recently checked out the popular “Stories Podcast”. I put on their version of “Princess and the Pea” since it’s an interesting litmus test: how do they treat a tale whose traditional moral is that a princess’ purpose in life is to be extremely intolerant of discomfort, then marry?

Before we find out, we get 3 minutes of ads. Two of the ads were for life insurance. Now, I get that ads are part of podcasting. But life insurance? Even relevant ads are not great in kids’ content. 20% of the podcast episode was about Toronto Dominion Bank.

In their defence, they do have a Patreon for ad-free episodes. While that’s hardly convenient, given the annoyance of trying to collect stories within a podcasting app, maybe juggling Patreon downloads would be less annoying.

I should say that their Princess and the Pea was better than most. Unlike the insufferable pea-intolerant royals of generations past, their princess doesn’t notice the pea’s discomfort at first. She then susses out that she’s being given an unreasonable test, and uses her wits to resolve the problem. So, that’s cool.

Unfortunately, when I tried to play the episode for Ellie, after two grown-up ads, she asked to hear a Disney story instead. We try our best.

The moral of the story

I do think audio stories are a great addition to any parent’s bag of tricks, even if they’re a little tricky to collect. I’ve exported the current state of our ‎Kids’ Stories playlist on Apple Music – if you’re curious, be our guest.

And to any poor unfortunate souls entertaining young ones out there, stuck inside and trying to make do: best of luck.

For better and for worse, this too shall pass.

Humans are wired for language. Soon after birth we start noticing phonemes, and within a year we’re recognizing words. Then we’re off to the races, absorbing vocabulary, trying out new words, and refining how we communicate.

Despite having learned enough words to get by, as teenagers we continue to rapidly assimilate new words and phrases. We go beyond saying what needs to be said, and experiment with how it can be said. We learn the nuance between different word choices, and the subtext that certain phrases imply.

For example you could say that something is “cool”, which means you think it’s good. It also means, these days, that you are old. Alternatively, you could say that thing “slaps”, which means you think it’s good, and also that you are not old. Or you don’t want to be seen as old. Or you are attempting to embarrass your kids.

While preceding generations may roll their eyes at today’s kids’ flexing, capping, and yeeting, new words and phrases like these stick out. Through exposure, they often enter our receptive vocabularies whether we like it or not. They become words we recognize.

What does have a tendency to calcify with age, though, is our expressive vocabularies. The words we say, and the meanings we ascribe to them, tend to kind of settle in, and don’t change much unless we intentionally update them.

Although the meaning when I use the word “cool” is, ironically, changing over time to communicate that I am not cool, I don’t really want to stop saying “cool”, and I am certainly not cool anymore – if I ever was, which I wasn’t – and you know what? I’m cool with all that.

In the case of cool, the word’s meaning has shifted, but it still works. Sometimes though, words’ implications shift in ways that we don’t want. Or their implications already are something we don’t want, and we just don’t realize it yet.

Meaning is in the ear of the recipient

While our language continually mints new words, our society also deprecates old ones. Sometimes they just fall out of fashion. I know my grandma calls a couch a “chesterfield”, but nobody in my generation would call one that. That’s the way it goes.

Other times, though, we retire a phrase because it has an in-built hurtful or discriminatory connotation, or has developed one. As our society has become more tolerant, many overtly racist, sexist, and homophobic terms have fallen out of use in everyday speech.

More recently, we’ve started making progress on less overt but still racist language, ableist terms, gendered phrases, insults that stigmatize people living with mental illness, and… wait a minute. Did we actually have a major league sports team using the name “Redskins” in 2020?

There’s still a lot of work to be done. That work though, the process of improving our expressive vocabularies, is a complex process.

Let’s take “crazy” as an example.

Popular discussion around mental health terms like crazy, and how we should probably not be using them, has been going on for a few years now. Although a few people have successfully retired crazy from their repertoires, it is still an extremely commonly used word.

Although most of us would be uncomfortable directly labelling a person living with mental illness “crazy”, English speakers of today constantly label negative, unpredictable, or ridiculous things as crazy. I myself used the term over 30 times over the years on this very website, especially before 2015. It’s in commercials, it’s in music, it’s in kids’ cartoons. Over the same years that terms like “retarded” have fallen into disuse, use of the word “crazy” has actually increased.

It’s pervasive.

Yet, if it is to be a retired word, as it seems like it probably will be, its demise will probably still follow a familiar pattern:

1. Term is pervasive, concern about it is not mainstream.
2. Pushback against it builds, discussions occur, “early adopters” start working it out of their vocabulary, years of habit make change difficult.
3. Term slowly becomes thought of as inappropriate. It stops appearing in polite media. Laggards protest, claiming the change is “political correctness” or “cancel culture” run amok.
4. The change hits a tipping point, and the word is widely considered offensive. Grandparents using the word at dinner cause a ruckus.

Like many changes, words are retired first slowly, then quickly.

A strategy for evolution

One of the things the last few decades of civil rights progress has taught us is that social justice is an ongoing process. The sheer scale of the racism, sexism, ableism, and other kinds of discrimination in our day to day speech is staggering. We can’t fix it all simultaneously. Society develops awareness of it, and strips it out, in waves. And as with any society-scale change, the size of it all can feel overwhelming.

It can seem, especially if you’re Very Online, that there is a correct and socially acceptable way to talk, and it’s constantly changing, and you’re constantly at risk of being wrong, and even if you’re putting in effort, there is a legion of more-correct hyper-woke Twitter people poised to strike you down if you speak in error or ignorance.

And maybe that’s a little bit true.

But that idea, the concern that we should be motivated by the social-justice word police out on the internet, is not a productive frame of mind for doing this work. Fear of backlash is a bad place to start from when you’re doing slow, meaningful, lifelong self improvement.

Because – and this is easy to forget in the noise – the actual goal is not to just avoid backlash. The goal is to show love. It’s to be respectful of people worthy of respect, to invest in small changes that can make people feel more welcome in this harsh world. The goal is to slowly build a better understanding of how our words make people feel, and the example we set when we use them. To refine our communication so it gets across the love and respect and empathy we’ve built.

And if it prevents you from getting destroyed on the internet for saying something poorly and necessitating a screenshot of your heartfelt Notes-app apology, well then that’s a nice bonus.

An empathy-first mindset to language actually feeds two birds with one scone: it informs and motivates our process of doing better, and can also act as a damper on the “smash people on the internet” instinct. The goal is not to alienate. We don’t need to be the person who learned how to use “racialized” last month and then turn around and jump on somebody who did not use it today. Heck, Apple’s autocorrect hasn’t even picked up that racialized is a word yet.

Meanwhile, there are many phrases probably worth banishing, dozens of words we may not yet recognize as problems, but that could – if we don’t work them out of our systems – make us that caustic grandparent at some future dinner table. So it’s a journey.

If you are interested in prioritizing “crazy” for a vocabulary eviction, I have a little tidbit for you. The word is used really broadly these days, to the point of being a cliché. Since crazy is usually used to describe something that is interesting, there are a lot of novel words you can use instead. Depending on what you’re trying to say, your kids might be acting feral, that proposed schedule might be ridiculous, and your uncle might have been trying to sell you on his latest absurd scheme. And overall, it’s probably worth focusing first on avoiding labelling people or their actions as crazy, and worrying less about how to describe the crazy day you had.

Especially if you’re in a visible position – parent, writer, manager – it’s worth putting in the effort, slowly over time, to work words and phrases out of your vocabulary that might be seen as hurtful. Even if there’s no consensus yet that they’re offensive. Even if nobody notices, other than people who read your reluctantly self-righteous blog post about developing a just vocabulary.

Truly though, words are a case where I think the price of being an early adopter is worthwhile.

We can’t control how people interpret what we say, but we can practice continual improvement of the words we choose.

Addendum

In my research for this post, I reviewed a lot of problematic phrases and proposed alternatives. (There are a lot. That’s why this is a process.) One of the more surprising candidates for banishment was the term “Kill two birds with one stone”. Coincidentally, I’d recently started using an alternative for this in recent months after seeing it on Twitter and enjoying it. To wit:

• Kill two birds with one stone: Cliché, rather morbid
• Feed two birds with one scone: Evokes same meaning, is adorable

To me, this is a clear upgrade.

What I hadn’t realized until this week was that the “scone” phrasing was featured in a 2018 campaign by PETA to end “common phrases that perpetuate violence towards animals”. As with many PETA initiatives it instigated more eye-rolling than actual change – most of their proposed phrases are pretty awkward, and I’d argue we have more pressing linguistic battles to fight than the campaign to retire the poultry-hostile phrase “put all your eggs in one basket”.

However, in addition to the birds and scones, I also liked another of their suggestions: swapping “Beat a dead horse” with “Feed a fed horse”. It subs in seamlessly for the existing cliché, and it also replaces the quite unnecessary unpleasantness of bludgeoning a deceased equine. Everybody wins.