There's Too Much To Do, And So I Do Nothing: Regaining Momentum In Your Startup

Yesterday, I had a long and productive conversation with some of my friends about their startup. The conversation started when we were discussing roles, and they were noting how—in a startup—everyone is basically doing everything. They weren't feeling a lot of forward momentum, and when we poked at it and actually listed who was doing what, it turns out that when everyone is doing everything, no one is doing anything. The reason became clear: there was simply too much to do. With no clear delineation of roles, expectations, or deadlines, lots of things were being started and few things being finished.

I think this is a common occurrence. I don't think it's unique to startups, and I think it's prevalent because we've never formally learned strategies for managing the overwhelming amount of communication in our lives. Specifically, we've never learned how to manage context switching, how to establish effective collaboration, and how to prioritize our actions. I'm pretty sure these are all teachable, but I was forced to learn them through experience, and so I failed at most of them when I started working. Here are some of the strategies I use, and some of the challenges I run into when I use them.

Establishing Effective Collaboration

When we were speaking yesterday, it became clear that different working styles were creating tension. One of my friends likes to dream—to think of the future, and to paint a romanticized vision of it. Another likes to wrangle complexity, by reducing it to actionable parts. And a third thinks in systems, connecting ideas through narrative. This makes for a phenomenal team and for fantastic output. But the mechanics of how work gets done are really different for each person, and this creates conflict. I've found that the conflict typically falls around expectations of what it means to be done, and so here are some suggestions to help ease the pain around these misaligned expectations.

Identify that "done" means different things to different people. For someone who thinks in big and broad strokes, "done" means when they've solved the problem in their head. They've moved on to other things, and they no longer feel a nagging sense of anxiety around a particular issue because they've resolved it. They have new knowledge, and so they feel good about it. The trouble is, no one else has that knowledge, and they don't feel good about it. Simply recognizing this is important, and recognizing if you are this type of person, or if you work with this type of person, is critical. I do this, and I never realized how much it bothered people; I could see an end-state, and so I would build things as if that end-state was achieved. But it wasn't, and people literally thought I missed steps.

Make ownership handoffs explicit and public. Since all of our work is digital, "handoff" is really misleading. There's no demarcation of a change in ownership, no object to be literally handed to someone else. And so, when you've stopped working on something and think your role is over, think about how you can take some action that illustrates a change in expectations. This might mean saying to someone else, "I'm done working on this. I'm handing it off to you. My expectation is that you will continue working on it." This is truly weird, and socially awkward, and so no one does it, and so the digital handoff wafts away and is lost.

Empower everyone to make decisions, and be prepared for the resulting conflict. When there are expectations of hierarchy, things don't get done until the person at the top does them. If you empower everyone to make decisions, a lot more will get done. To empower people to make decisions, you need to continually tell people that "I would like you to make decisions on your own. I expect you to make decisions on your own." This, like the above, is socially strange, because most of us don't talk that bluntly about work expectations (or anything else). But I've encountered a lot of people that simply don't feel comfortable making decisions without hearing someone say something like this to them. The flipside of this, of course, is that when people make decisions autonomously, they won't make the same decisions you will, and that will produce conflict. I think the benefits outweigh the potential problems created.

Context Switching

When you start working in a consultancy, you are normally resourced to a single project, and you have a single set of tasks, and a single set of expectations. And then, when you become a creative director (or, when you join a startup), you suddenly have multiple projects, with multiple tasks, and multiple expectations. At one point, I remember my colleague and I were running about twelve different projects for a single account, and our calendars were literally walls of thirty minute meetings, usually three and four deep, from eight till six. A big part of being a creative director is not directing creative, but instead, playing interference for your team so they can actually get work done, and so a lot of these meetings were conference calls, check-ins, and client-reviews. And because meetings usually start late and run long, we would literally be running from conference room to conference room, arriving just as the PM had started the call, and with no real understanding of what was happening and to whom. It was not rare for me to arrive and mute the phone, ask "What meeting is this?", unmute the phone, and begin speaking.

This is an absurd illustration of the context switching problem: your brain and entire soul wants to stay with a single problem, exploring the details, talking through the implications, critiquing design work, and forming relationships with the client. Yet now, for a completely arbitrary reason, you need to move on to a different problem, with different details, different implications, and different relationships. I'm not proud of this, because it's a silly way to work, but it's a reality, and so here are ways I support context switching.

Think of work in discrete buckets. I consider all of the different projects that I have going on as unique containers. The containers have names: right now, I'm tracking buckets like "AC4D Graduation" and "Trip to Mexico", because these are projects I'm working on. If I formally start to associate email, communication, projects, activities, meetings, and "design stuff" with a bucket, then the name of the bucket becomes a recall proxy for me. When I had multiple projects for a single client, each project got its own bucket. I could never get the "just imagine it in a palace" memory trick to work. Putting things in buckets seems to function in a similar way: as a single proxy for a larger set of data.

Do a bucket walkthrough once a day. On paper, or in a plain-text notepad, I'll walk through each bucket, listing the name, and identifying the things that happen, have to happen, or might not happen today. I can't keep track of all of the buckets in memory, because I have a lot going on, and so writing them down helps to "get it all out." These are simple lists, but begin to outline expectations for the day. (There's a pretty miserable feeling that occurs when you walk through the buckets, identify things to do for the day, look at your calendar, and realize there's no way it's all getting done. See below, "Prioritizing Action.")

Be extraordinarily diligent about file management. I maintain a rigid file structure of every document, artifact, presentation, and design deliverable, organized by client, project, project phase, and so on. When I enter a new context, I can immediately change my work space to ensure I'm ready to work; there's no searching for files, or locating old emails. It's just ready to go.

Scan every email as it comes in, but don't reply. As new data and communication arrives, I can let it "marinate" and therefore be aware of the often last-minute changes in strategy and plans by a team. I won't know the details, but I'll know that there were last minute changes, and so I'll be aware of my own knowledge limitations.

Prioritizing Action

With so much to do and so little time, it's important to pick the right things to do. That can feel like a crap-shoot, and this is where the paralysis occurs: I don't want to pick the wrong thing, and so I pick nothing. My strategy for handling this was entirely emotional, and had three components.

First, put the bucket list items in order of deadline. What has to happen first, second, third, and so-on? This is a forced stack rank, and that means things can't tie; only one thing can be first.

Next, examine the list in order, and ask the question, "Is this the most important thing I could be working on right now, OR, will this take an extremely short amount of time?" If the answer is Yes, work on that immediately. If the answer is No, move on to the next item.

Finally, be OK with the fact that you aren't doing all of the things you said you wanted to do; you are consciously skipping things that have looming deadlines. This is attitudinal; it's about letting go. I'm truly bad at this. Once I started trying it, I realized that things I deemed were "not the most important thing I could be working on right now" were, in fact, not that important at all. And no one seemed to mind that they weren't done when they were supposed to be done.

*

When we are in school, we typically don't learn how to work. It's strange that we expect people to know these skills when they start their careers, because most of these skills are unnatural and built on truly bizarre social norms. I hope that, by establishing effective collaboration, learning to switch contexts seamlessly, and finding ways to prioritize action, you can start to gain more control over your work.

Originally posted on Tue, 01 May 2012