Time is Never On Your Side (no it’s not)

I was coaching a master’s student, reviewing a prototype for an app he had designed. We went through the entire prototype, and I made a number of suggestions from architecture to affordances to font choices.

Then he mentioned it was due next week.

“How much time do you have to make changes?” I asked

“As much as it takes!” He replied.

“No. That’s not right.” I shook my head. “You have other classes right?”

“Um. Yes?”

“And they assign homework?”

He nods.

“And you sleep? Occasionally?”

“If I have to.”

This is the problem. We don’t take time seriously.

Time is a medium. We have to stop treating it like it’s a great unknown. Time has a size, a shape and properties. It goes fast when we get into a flow state — which takes time to achieve. It goes slowly when we’re stuck or bored. Some events in time are fixed, some are malleable. But time is not infinite. Time is not unknowable.

As well, this student was working in a cross-disciplinary team, as the interface and brand designer. That meant that there were people sitting idle, waiting him to finish his task so they can start theirs. This is something anyone who has written code knows about, but few students do. Not all time is equally valuable. Some of it is yours, but some of it you’re stealing from someone else.

Here’s what we did

  • We figured out how much time he really had. 
    We looked at a calendar, marked classes, marked homework for those classes, then marked out work time. Turns out “whatever it takes” was five hours.
  • We made a task list of the fixes.
  • We stack ranked them in order of impact
  • We threw out everything except the top five. (well, I think he kept them in the hopes of finding more time.)
  • We unpacked subtasks of the key fixes, in order to size them accurately.
  • We sized the tasks (estimates.)
    Estimating is a skill. Always guess how long things will take you, measure how long it takes, and compare the two numbers. 
    With practice, you’ve be able to size anything, even creative work.
  • We marked dependencies. Do the logo last! Fix the navigation first!
  • We ordered his tasks based on dependencies and priorities.
  • We looked at his calendar again. His day was all broken up by this and that. We moved a couple calls and meetings so had had a couple large 3 hour blocks. (we cancelled a meeting he didn’t even need to have this week, gaining another hour!) 
    If you can avoid task switching, you pick up speed as you enter flow. 3 hours in a row is worth 4 broken up.
  • We put the tasks in the calendar. This led to more dumping of tasks. We ended up with the two that had the highest impact, plus some polishing.

Ten minutes of planning ensured his precious six hours of work would be used to get the highest possible grade on his project.

Sure, he probably will stay up all night one night and he might get another four hours of work done (one hour of work can take three hours to do, when you’re sleep deprived. Not all time is equally valuable.)

But by starting with a worse-case scenario of five hours, he assured the most important work was done first, when he had the greatest energy. Instead he could have assumed he’d do everything, working all night every night until it all magically got done before the deadline.

I don’t believe in magic. I believe in planning.

We need to teach time design in school, instead of pretending it’s wibbly wobbley stuff that can’t be managed.

But don’t just take it from me. Listen to Abby Covert