Choose Paper

If you wanted to ensure it lasted for 150 years – you’d choose paper.

As amazing as our current electronic technologies are – despite their strengths – terribly, terribly ephemeral. The code the worked yesterday isn’t support today. The processors of – five years ago, ten years ago – are brought to their knees by the computational complexity and presumed processor capabilities of today’s software. The runtime environments required by the digital creations I manifest as a University student not only do not exist – computers of today don’t even recognize the file types.

Perhaps it’s good that my chances of becoming a world-renowned graphic designer are quite slim. For if they were higher, and exhibits celebrating my early digital work were to be held, recovering that early work would be a significant undertaking. Even today. Unlike like my drawings and pastels – for those seem to be holding up just fine. I looked at them just the other day. The same day I went through the box in my office containing 25 years worth of my sketchbooks. All the paper – just as I remembered it. All the sketches just as they were the last time I looked at them.

I didn’t need to convert them into a different file format or upgrade the software before I opened each sketchbook and revisited each page. I simply opened it. I simply turned the page. No need to for anything more. The paper persists.

One story at a time, I’m writing down the stories of my life.

In a book.

A high-quality, hardcover book.

One story at a time, handwritten on paper in the book.

A book I want to exist for a century and a half, if not longer. The book will go into the box with all the other family stories and photos – all of which are on paper. Stories and photos that – while they may not be on their original paper – are on paper.

Sure, I could type out these stories into this site just as I’m writing this. I enjoy writing here. But there’s no chance this site will be around in more than a century. I even have a hard time envisioning it living another quarter century. Even if it does, that will mean countless technology migrations, not just server migrations, but also application layer and database migrations. All of these changes requiring regression tests – however humble.

Somewhere out on the internet there’s a story describing the problem of archiving electronic art. In it, the author describes the process. The process of picking the ideal computer for perpetually running the archived software, completely isolated from the rest of the internet. They described the need to prevent any of the bits of software from ever updating, from the intended application, all middleware, to the operating system, everything. All of which will ensure that this singularly valuable bit of software can continue to provide value for generations to come.

Unless those generations have something other than electrical service expected by the computer’s power supply.

Then – poof. It’s gone.

Last month, I brewed a batch beer. This particular recipe was originally used by a British brewery circa 1868. It was included in a book collecting a number of British and German beer recipes from 1850-1950. Theses recipes were extracted from the actual brewers logs of the time. Brewers logs that were written on paper in books and shared in-house to ensure a consistent product from batch to batch.

Am I using the same ingredients the Tetley Brewery did 147 years ago? Highly doubtful. Today’s grains, hops, and yeast are far more optimized for brewing than they were a century ago. But, since I have the beer’s characteristics; alcohol, bitterness, color, clarity, along with specified grain, hops, and yeast, I can get very close to recreating this beer. As can anyone else.

I don’t necessarily need their equipment or their process for creating fire. That’s all changed. I need the identifying, distinguishing characteristics. The same distinguishing characteristics that were originally written down 150 years ago on paper to help the next brewer on the shift.


Complications

when I started here my wife

gave me a white gold chronograph

from her jewelry store in the mall

like all successful salesmen here wear

it weighed my left hand down,

silver and crystal reflections

constantly tugging at my attentions

I left it

for this softer, flatter one, yes, yes

weeks ago the batteries stopped at 9:43

but my ex-wife still runs the jewelry store.

Ongoing List of Underused German Words

Verschlimmbesserung: An improvement that makes something worse.

Doch: An expression for indicating an outcome occurred that was counter to the supplied evidence. Loosely translates to, “although I thought otherwise.” Even more delightfully – it can be and is used sarcastically.

Missing Connections

sipping rosé
beneath my rudderless patio umbrella
the recently divorced mother of two

is so
fucking
livid

by carpools, elevators, and skinny jeans
packed with stage actors
longing to buy her rosé.

What Can You Achieve in 30, 60, & 90 Minutes?

When I ask my clients where they found the biggest benefit in my How to Use a Calendar program, they often reply:

“Scheduling for 30, 60, or 90 minutes.”

It’s tempting to block off a massive chunk of time for a big project. Whether that massive chunk of time is a an afternoon, a day, or a series of days – doing so subtly encourages procrastination in two ways;

  • It doesn’t specifically define the desired outcome
  • The extended duration of time allows you to constantly say, “I’ve got plenty of time to figure it out.”

Overcoming both of these requires peeling apart the project into smaller, more discreet, incremental tasks. Then estimating the time to accomplish each of those specific tasks. Finally, scheduling those tasks with their corresponding estimated duration on your calendar.

This has three subtle benefits:

  1. Timeboxing each task mildly increases the sense of urgency to complete it, for this is the only time available for this part of the process (er, project).
  2. Increasing the number of completed tasks makes it easy to see progress and build momentum toward a larger goal.
  3. Discreet task level scheduling makes it easier to confidently communicate expectations of progress to yourself and your collaborators (at whatever granularity is appropriate).

I encourage my clients to use the following estimation framework I talk about The Power of When:

  • 30 minutes for a small, known* task.
  • 60 minutes for a small, unknown task.
  • 60 minutes for a large, known* task.
  • 90 minutes for a large, unknown task.
  • Tasks taking longer than 90 minutes should be broken up into more smaller, more specific tasks.
    *known = something you’ve done before and can confidently complete within minutes

Why 30, 60, and 90 minutes?

  1. Nothing takes less than 30 minutes.
    Once you factor time for preparing do do the work (including switching mental contexts), reviewing the work to ensure it has in-fact created the desired outcome, and properly closing out the work – nothing takes less than 30 minutes. Not even replying to that important email or phone call. This is before factoring in any disruption or interruption.
  2. If you can’t achieve the outcome in 60 minutes you need to step away.
    Sixty minutes is a long time to be intensely working. In endurance running it’s here at 60 minutes where you need to start considering additional food & water to counter act the physical and mental fatigue. The same goes for intense creative work. Fifty minutes into a task, you know if you’ll reach the intended outcome within the next ten minutes or not. Either way, stop after those ten minutes, step away from the work environment, and get something to eat and drink, take a walk around the block. I’d be willing to bet, when you return you’ll have a new perspective – if not a breakthrough.
  3. After 90 minutes you’re fried.
    Maybe you figured, this tasks is just a little bit bigger, a little bit unknown, but totally do-able with a little push past the 60 minute mark. Ninety minutes would get you to a more substantial milestone and more resilient stopping point. Fantastic. Go for it. Know that at the end of it, you’ll be completely fried, totally mentally drained. The break we talked about at the 60 minute mark? Yeah, it’ll need to be longer and even more re-energizing than before. Especially if you’re expecting to do it again when you return. The best place for intense 90 minute tasks is very first thing in the morning and the very first thing after lunch.

Now, what if you reach the outcome before the estimated time is up?

  1. Review it thoroughly to confirm it is in fact completed. You might be surprised to find one or two more small, quick, easy things that could make it that much better.
  2. Pat yourself on the back for beating your estimation and take a break.

If you’re interested, I wrote this post in two 60 minute sessions with an hour lunch in between.

You’re Not Going to Need It

Neal Conan: “You had solar panels (on your sailboat) for electricity.”
Matt Rutherford: “I did, but they broke.”
Neal: “They broke?”
Matt: “One by one.”
Neal: “I think you had a Kindle for reading books.”
Matt: “I did. It broke in a storm.”

I like Matt’s story for all that it tells as about our expectations and presumed requirements for a huge project we’ve never done before.

When I started out professionally the teams I worked on created deliverables; mockups, storyboards, sitemaps, taxonomy listings, content maps, wireframes, process flows, clickable prototypes, specification documents, usability testing, amazing looking proposals, Photoshop, timesheets. When I struck out on my own I assumed all of these things were required, so I packed them all with me.

Project after project I saw how each of these tools could bring as much confusion, delay, and tedious re-work as they could clarity. I saw how easy it was to iterate, debate, and perfect them, while losing sight of the project’s purpose and its promised business value. One by one, I stopped promising any specific design planning deliverable – other than a wireframe and a functioning web app. Then I dropped the wireframes. I eliminated all of this design planning documentation in favor of engaged conversations directly with the buyer that culminated in pen-on-paper sketches of how the key functionality should work followed by an estimate on when it’d be available to click-through.

Everything else? So much jetsam.

It’s not that I stopped doing the thinking encapsulated in those deliverables, the thinking became hyper-focused, hyper-prioritized on the core function of the project. If the core function couldn’t actually work nothing else will save it, not the color palette, not the logo, or which order the navigation labels are in. Hell, not even the project management methodology choice will save a project where the unique value proposition is neither.

The tools we actually need to be successful on a regular basis are so basic as to be taken for granted:
– trust in & respect for each other’s abilities
– clear, efficient, constructive communication
– absolute clarity in goals
– complete flexibility in execution
– a comfort with continual iteration

In this day and age, the rest can learned, negotiated, or rolled into the project as needed – whether it’s a project management philosophy, a unique software application, or a greater understanding of the subject matter. Presuming the four tools listed above are present, prior experience in the expected deliverables, vocabulary, or value chain of a specific domain is not only unnecessary but actually be counter-productive. Counter-productive to delivering the compelling innovation the creative team was assembled for.

Throughout its history, Apple – regularly cited as one of the most innovative and creative organizations – regularly dropped components presumed required for all computers; 3.25″ floppy drives, ethernet ports, optical drives, the ability to run arbitrary code.

At the time Google started getting becoming popular, having ads and headlines and other ‘portlets’ surrounding the search box was a presumed requirement for search engines.

Uber, Lyft, AirBnB dropped the presumed requirement that drivers/hosts needed to be licensed by the government.

Telsa, recently surpassed GM in market value, doesn’t have dealerships – a presumed requirement for an automotive brand by many states.

Yes, every one of these organizations is controversial for any number of reasons – but the very first one, the one deep down in their DNA is their bold dismissal of a presumed requirement around their core product.

So, yes I was disheartened when a Director at major employer confessed to me, “We don’t kill projects here.” For it meant a significant part of the organization was not yet boldly willing to separate the presumed requirements from the actual requirements far enough to spot the energizing, clarifying, innovation hidden in-between.

One of your presumed requirements is keeping you from growth. Do you know which one?