We Can’t See Late

I don’t need a new productivity hack; I need to rewire how my mind sees time

Conference season is winding down in software land and while it’s been good to catch up with people I rarely get to see, it’s also really clear that my people are pretty stressed out. Folks preparing their talks are barely meeting their deadlines, and folks attending conferences are worried about their projects and schedules back home.

We’re right to be worried; our projects are slipping past their milestones in a way we don’t seem to understand.

“Slipping” happens to me all the time. At the start of a project, I’m psyched and my deadlines seem reasonable or even easy. But half-way through, I look up, things have drifted, and we’re in danger of missing our deadline. My team is agile, we’re timeboxing^[1], I read: but this keeps happening. My projects keep slipping.

It’s not the slip itself that’s baffling–making stuff is hard–it’s my inability to respond to the slip. It turns out that we humans can’t recognize schedule slip until the slip is unavoidably large and grotesque. My responses at that point are equally grotesque: pressuring my team, long days, and chop-shopping the scope.

Only Heroes Work Here

I haven’t learned to take action when slip crops up early in a project. All the corrections I learned coming up are tactics for when slips have already compressed the project to the point where heroic action is required. And while it feels good to be the hero, this way of working is not sustainable. We end up living with too much vigilance: a background panic that heroic action might be needed at any moment. 

This is why most high school graduates have the all-nighter as their signature move–their only move–when deadlines get tight that first year in college. Imagine a generation of kids that took action early enough that all-nighters weren’t necessary.

Getting a late start is incredibly common. But the consequences of late starts are widely misunderstood. Click To Tweet

Examples: Small Catastrophes

Let’s see how small slips destroy a two-week schedule. It’s Monday morning and you’re starting a two-week project: a software sprint, writing a business plan, whatever. You’re told you have two weeks to do it and let’s say you agree that it’s about two weeks worth of work. You agree with the estimate and with the assessment of your capacity. 

This isn’t about getting your estimates wrong, or misjudging how much time you have available each day–though they may be causes of schedules slipping. We’re looking at our inability to see schedules slip and our inability to react appropriately. Though I’m sure our biases^[2] distort our estimates and our sense of capacity, the problem of slip occurs even when your estimate of the work required is accurate and is irrespective of how much capacity you have allotted for the work each day. In the example that follows, a “day” could be a full day’s work or the two hours a day you have allotted for a project.

Let’s contrast how we casually think about these “two weeks” with how much time we actually have once the project begins to slip.

So we hear “two weeks,” and we think “cool, I have two weeks”. I’m not planning to put in two full workdays over the weekend, but the 7-day connotations of the word “week” are strong. I don’t think “14 days,” but in my head, it’s definitely more than 10: maybe it feels more like 12 days. However, in reality, we only have nine workdays at best. That difference alone is something I haven’t consistently internalized.

Why nine days? Two things conspire to shave a whole day off our schedule: we learned about the project on Monday and so haven’t cleared the day of everything else so we can work on it. Left-over work from last week takes at least half a day to put to bed so we really only get half of Monday to work on it.

At the other end, we can’t exactly turn this in the very last minute of the day on Friday. I’m always surprised, when I ask for something “on Friday”, how junior developers will send it over at 11 pm Friday night as if it’s some tax filing deadline. Of course, this is my fault for not specifying *when* on Friday I need it; it’s my problem for not using time words^[3], but you get the idea. We have neither all day Monday nor all day on the second Friday, so our “two weeks” is at best “nine workdays.”

Next is where things really get interesting: what if we don’t get to start on time and lose that first day’s work to something else?

Getting a late start is incredibly common. But the consequences of it are widely misunderstood. This is what we just can’t see: if you miss the start of this “two-week” project, you have to be 112.5% productive every subsequent day in order to make it up. The rest of the project doesn’t have to just go perfectly: it has to be beyond perfect.

It’s not so much the amount you have to make up (it’s just over 10%, right?) as the consistency required. You now have to over-execute every single day you work on this.

If you’re starting to recognize some of your past projects in this pattern, I’m right there with you. What gets really scary, is that losing time at the beginning of the project is the best case for slip: that’s as good as it gets. Losing a day later in the project is devastating, as we’ll see next.

Being 120% productive five days in a row is a big ask. In addition to the stress and lack of sleep implied, there is probably a good deal of debt being pushed into the next week so we can be super productive this week. Stresses like this bleed over into subsequent projects and our personal lives. Most of us know we’re taking on this kind of temporal debt (borrowing time from our next projects) but how many of us have a plan to pay it back? For me, the plan has usually been to be 120% productive a bit the next week also. That’s incredibly optimistic.

Note that in this example and the one below, we’re not compounding our problem. We’re not suggesting you’ve gotten a late start AND lost a day mid-sprint. This is simply an illustration of how losing a day is vastly more destructive later in the project. Losing a day in the second week is, of course, even worse.

To put that 140% in perspective: each remaining day on the project would require the same effort you’ve expended before lunch be applied again, after the end of the day. That’s nearly three days of the most productive work you’ve ever done. 

Your code compiles the first time, the words just flow out of you, all the research you need is at your fingertips. Your colleagues are all holding up their end and firing on all cylinders: that’s what 100% productive feels like. I don’t even know what 140% feels like.

The Background Panic of Late Projects

Because late starts are so common, and the consequences are so dramatic, most of us now worry that every project might be late and carry this low level foreboding around all the time. Is something falling apart right now? Is some deadline around the corner about to bite me? If we saw and reacted to slip more accurately, maybe this background panic would go away as well.

Slip sucks. Slip later in projects truly sucks. And most of us don’t recognize slip for what it is, so our reactions are at best delayed and more likely wholley inadequate to the effort required to recover from losing just one day on a two-week project.

This may be why we’re so stressed out: we think we’re looking at our schedules, but we’re not seeing them.

Can We Change the Way We See? How Do We Retrain The Mind?

I’d like to suggest that traditional calendar grids reinforce this afterimage. We see time as interchangeable squares in a game of productivity Jenga. 

To correct this, we need to retrain the human brain to see something it couldn’t see before. To see time as a thread between two events instead of empty cells on a grid: as something we inhabit instead of blocks to rearrange.

Brett Victor suggests how we can retrain ourselves in Media for Thinking the Unthinkable. Victor talks about the invention of the oscilloscope and how that let engineers visualize waveforms that humans can’t see^[4]. Using this tool, engineers have gradually developed intuition about how changes in circuitry will affect the waveform. More than teaching themselves a new metaphor, it’s almost as if they’ve developed a new sense. And anyone who’s been taught electrical engineering could well be forgiven for experiencing this sense as being “passed down” from one generation of engineers to the next. This is the (dark) magic of tools. We build them; they train us.

Can technology do the same for our intuitions about time and scheduling? Yes. I believe that tools which let you better visualize projects could teach a generation new, less heroic coping mechanisms for getting projects out the door. A calendar that depicted things more like the charts above would be a good starting point: fewer boxes, more spans.

That calendar wouldn’t just show your projects in pristine isolation, but place them in the context of all your other commitments. Maybe that calendar would let you work at longer timescales so your milestones didn’t sneak up on you and the consequences of borrowing time were more obvious.

You wouldn’t have to dread looking at your schedule: it wouldn’t be filled with things going wrong, but would be a picture of the good decisions you’d already made.

---

Special thanks to Jason Young and Kate Lee for reading early drafts of these ideas.