Constant progress without being certain you’re getting anywhere. Reflecting on the adrenal dropkick that was 1917, I realized this perpetually delayed sense of resolution was familiar in other aspects of my life too: the parts where plans and action come together.
—
I’m a design generalist — switching hats between product, research, and strategy in my consulting work, and developer and designer for my own products. Depending on what hat I’m wearing — what the tasks are, who the team is, what my role is — the mechanics of tracking where intent turns into action and then outcome, changes dramatically.
As a designer, I rely heavily on the physical and the linear: post-it notes and notebooks to plan, simple to-do lists, and tools like Invision or Figma to communicate feedback.
As a mostly solo developer, I have tried everything under the sun and have recently settled on a tool called Workflowy, which offers dead simple hierarchical and collapsible lists. I use Helpscout and Github Issues for tracking customer issues, but otherwise, I just need a list.
As a product manager, things get more complicated. I’ve used Excel/Google Sheets, Airtable, Github (it’s actually quite good for this), Podio, Notion, Trello, Basecamp, and Asana — all often with Slack or Microsoft Teams, or weirdly even WhatsApp, bringing everything together. Sometimes Zapier, IFTTT, or a Slack bot is lurking in the background somewhere, nominally making the teams’ lives easier.
The problem is that while we might select these tools, they shape reality in unexpected ways.
—
The movie 1917 is a series of long-shot vignettes, telling the story of two soldiers’ attempt to warn a British battalion of a German maneuver meant to draw them into a trap. In the travesty of World War 1, such communication was often accomplished by runners, and so these two soldiers named Will and Tom make for the front.
Along the way, they encounter a series of different environments and stories that they must traverse, in what they believe is their route to the endangered battalion. Each of these vignettes presents a different challenge: a calm field, an abandoned German trench line, a shattered city. Within each, small stories and moments of peace, panic, and grief are experienced before the characters move on, unsure of when that forward progress might give way to rest and completion.
Productivity software can present the same kind of exacerbating and varied landscapes, with each presenting a greater or lesser degree of friction and risk. Tools like Notion and Trello, for example, present a level of flexibility that is unrivaled. But one quickly discovers that this flexibility comes with the cost of discipline. When managing a team, you also have to manage that team’s use of the tools and the natural entropy brought on by different mental models of a problem coming together on a shared canvas.
A wide canvas and a flexible tool has the benefit of responding to a wide variety of needs, but it demands the vision to bring those needs together. Unfortunately, it’s not always clear whether a decision made in the expanse is a considered one or simply a reaction to the lack of direction. I’m guilty of this with Notion: I switched my product team to Notion for documentation and decision-making purposes, but initially simply made a more friction-filled version of Trello and Kanban. It worked, but it wasn’t until we’d spent a month using the tool that its real utility emerged: a way to “zoom” in on strategic imperatives through the lens of user stories with the ability to create relationships and aggregations on those relationships. This feature ultimately gave me what I needed: transparency for the team, a necessary gut check for me when managing the project complexity, and rapid accountability mechanisms for the project stakeholders.
That said, it’s also a constant battle. These open tools require constant management lest they become overgrown with accumulated information. Slipping up in that management means a team member might misread something, or go down an overgrown path you’d meant to erase ages ago. None of these tools do a good job of managing this because they can’t read your intention: all you can do is set up a point on the landscape and order it as best you can.
Many tools are seemingly more ordered and perhaps more easily resemble the familiar patterns of streets, parks, apartments, and communal spaces. But any urbanist will tell you that the nominal order of the city belies a deeper emergent quality — nature abhors a straight line and humanity rebels against too much order.
The benefit of more ordered and opinionated tools is that they direct you towards what they think is the right path. When used for project management, Jira, Asana, and Github Issues are all good examples of this. Even when using more open tools like Notion and Trello, it is easy to default to these well-worn paths. Without critical thought, the open field becomes a grid or hub-and-spoke town.
The benefit is that these patterns provide for rapid movement and a consistent mental model. Teams can share a common language when collectively resolving the abstractions of intent into action. But there are always gaps and biases. In a previous experience using GitHub for project management, the nuances of design decisions and user feedback often got lost in the drive to “close those issues.” In the relentless drive towards hitting our milestones, the focus on shipping undermined our team’s capacity to engage with alternative solutions over simply polishing or extending what already existed. The way we engaged with the project and the tool locked us into a kind of path dependence that perhaps a more open tool wouldn’t have. Put another way, our bias toward shipping engendered the selection of a tool that served to reinforce that bias.
In other words, these tools impose an order, as do a city’s streets, alleys, and walls. While we can’t walk through walls (or at least we can’t without a pretty radical reframing of the problem), we can use the city as it was intended to make certain aspects of daily life run more smoothly. And in the margins where friction emerges, perhaps there’s a place to explore and experiment.
The “To-Do” list is where intention becomes some form of action. In 1917, with rows of infantry waiting to go over the relative protection of the trench walls into no-mans land, the strategies of leaders rapidly resolved into action.
Strategies are intentions mediated by scale, beliefs about reality, information, peer influence, bias, fatigue, resource constraints, etc. For all that we laud the brilliant strategic thinking of individuals throughout history, often good vs bad strategy comes down to one’s ability to mediate these factors and not become bogged down by indecision (Boyd’s OODA loop is a good way to frame this).
To-Do lists are an absolutely miserable place to strategize. While a good strategist should be aware of how that list slowly gets crossed off, the immediacy and bias presented by that frontline can easily blind one to decisions and actions needed at a higher level.
I’ve vacillated between different To-Do list approaches over the years. Functionally, they all kind of do the same thing: list out a set of things that need to be done that can be removed when finished. I used a hobonichi religiously for several years, before switching to Things 3, and then switching back to a notebook. Today, I’m using a “Weekly” To-Do list in a notebook (normally takes 1-2 pages). I’ve found that all I need is the ability to record, easily and consistently access, and shift things into the future if need be. A system like GTD or bullet journaling also helps with this.
But what happens when you DO need to strategize at the front line? When a supposedly simple To-Do item becomes more complicated than you thought? I tend to think this is where my dissatisfaction with tools comes from. I might write out a To-Do, discover that it is actually several To-Do’s with a potential for more, and attempt to capture and organize that complexity. Tools like Things 3 do a good job of transitioning single items into multiple, or creating projects, or splitting lists, etc. But ultimately, what helps me is to leave that tool and not try to over-extend it. Shifting to post-its, or to one of the more ordered team-level tools can give you the illusion of abstraction and control, even if you’re steps from the churn of action.
I’m writing this as a decidedly un-Nordic one week vacation comes to an end. I’m writing this because I’m back to looking at all of these insufficient tools: At Notion with its complexity, at Trello with its beckoning lists, at my notebook with its rows of unchecked boxes, at Workflowy with its unexplored assumptions, and at Help Scout with its suspicious bugs.
I don’t think that consolidating all of these is the right call. But I do think I’ll be eliminating some. In a few weeks, I’ll be completing a year-long consulting project and leaving a well-functioning team with a hopefully well-functioning Notion database. If I check back in six months, what will it look like?
I’m also preparing a big feature push on my app, Knowsi — basically with the goal of getting it out of beta and into a new business model. I’m actually reducing the complexity of how I track things immensely here: as a solo, multi-hatted founder, I need the focus of a map, compass, and a moment away from the minutia of writing code — not the complexity of Notion or Asana. After all, I’m only communicating with myself so far.
Ultimately, there is no such thing as a productivity hack.
1917 captured the collected stories of horror and heroics that the director Sam Mendes’ grandfather recalled. But the first World War, as the second, was a slaughter brought on by bias, indifference, pride, technical and tactical experimentation, and path dependence.
Bloviating over productivity hacks in an age of capitalist excess, reflects a conceit that driving ourselves into the ground is a universally acknowledged virtue. It’s not. Though these tools are meant to drive efficiency, speed, cohesion, etc; efficiency at any cost leaves one wondering.
Rather, let’s use these tools to see differently. As Malcolm McCullough states in his book Abstracting Craft:
“When the tools are complex, when the artifacts produced are abstract, or when tools provide the only means of access to the medium (all common conditions in high technology), it can be difficult to say where a tool ends and a medium begins.”
If that act of producing — be it software, hardware, services, organisations, anything — is a craft, then the means by which we organise these crafts must be continuously interrogated, if we are to avoid our creations simply reflecting the limitations of our tools. When these fundamentals of the craft are questioned, then new forms, new paths, and new futures can reveal themselves.
Monthly updates from Andrew Lovett-Barron, mostly writing about design practice, theory, and projects. Occasionally, I may link out to a new project.