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.
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.
beneath my rudderless patio umbrella
the recently divorced mother of two
by carpools, elevators, and skinny jeans
packed with stage actors
longing to buy her rosé.
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:
- 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).
- Increasing the number of completed tasks makes it easy to see progress and build momentum toward a larger goal.
- 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?
- 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.
- 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.
- 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?
- 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.
- 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.
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?
This was going to be a crappy project. The red flags were there from the very beginning.
The first: when my my buyer said, as I was about to sign the contract, “Today is my last day.”
I should have set the pen down right there, replied with a ‘Thank you for letting me know’ as I walked out the door. But I didn’t. I shook it off as a quirk. A minor curiosity. A small hiccup between me and their payment for my services. Definitely not a loud and flashing DANGER sign. Definitely not the high-point of the engagement.
With each day that followed, delays on the client’s end chewed away at my estimates and our agreed upon timeline until my side of the project heavily overlapped my family’s summer vacation. It’s my penance I told myself. My penance for committing to this project, for not firmly renegotiating when the timelines slipped, then slipped agin. A painful price for saying ‘Yes’ to something I shouldn’t have. So I, buckled down and resentfully, dutifully, worked through my vacation. A day or two from the completion the client called to say, “We had to bring in someone else to finish up.”
Oh, I was completely pissed. Pissed I wasn’t able, with all the odds against me, to make this project successful. Pissed I didn’t walk out on that first day. Pissed I didn’t say GTFO first.
Mostly though, I was relieved. Relieved I was now off the hook. Relieved I could now wash my hands of the project, the client, and their entire industry, with a long swim in the Wisconsin River.
Like an addict in a slow recovery, I began measuring time in the days. Days since I was kicked off that project.
This wasn’t the only project shouldn’t have worked on over the past 20 years. I could easily rattle off three more over a flight of Belgian beers. There’s probably a dozen mild and wholly forgotten failures. Even more that weren’t bad, but simply crowded-out better-fitting projects.
I’m sure you’ve had some painfully bad projects as well.
There were any number of points across all of these projects where someone needed to stop the line – and no one did.
Over the past few weeks, I’ve had a number of conversations around the client/vendor relationship. I’ve heard stories of six month projects being stretched out to a year – with the outcome barely distinguishable from the starting point. I’ve heard stories of software developers (inadvertently?) sabotaging a client’s project. I’ve heard of clients stiffing their vendors for no other reason than agreeing to a larger fee than they could pay within the project’s timeframe.
Sure, I’ve also heard stories of vendors flying executives cross country the very first hiccup of an implementation and stories of that elusive project that turned out better than anyone imagined.
Knit through all these conversations, there’s an unfortunate thread;
- The absolutely best case scenario, is everyone doing what was expected when it was expected.
- This is rare.
It doesn’t matter which project management process is followed; some bastardization of Agile, a traditional waterfall, something Scrum-like, or a more structured EOS. Too often both the client and the vendor have incentives and biases encouraging an unwavering march to an disappointing end, rather than a constructive, successful partnership. This doesn’t need to be the case.
There are many places to look for improved alignment:
- Clearer articulation of the client’s business goals, measures of success, and business value of the project.
- A better cultural fit between the client and the vendor.
- Clearer tying of the vendor’s solution to those goals and returns.
- Improved communication throughout the project.
- Someone (everyone?) on the team feeling comfortable stopping the project at the slightest hint of things going sideways.
- Fee structures encouraging maximizing business value rather than delays, low quality work, & maximizing hours.
- A culture focused on success of the project, not which teams the players are on.
In the real estate world, there are Buyer Agents, advocating and representing the buyer’s interests, gathering their requirements, researching an array of options to select from, in ensuring every step of the process is successful for the buyer.
In the B2B technology world there is no equivalent, similarly well-understood role. The account manager usually isn’t involved in an ongoing basis, the project manager usually doesn’t have enough gravitas, and the remaining team members are usually so stretched they don’t notice if one project drags a little – let alone that it achieves the desired business goals. Neither side has an incentive to clearly and honestly communicate delays, unforeseen challenges, and mistakes to the other side. There’s no one with the incentive to keep both the buyer and the seller accountable for their sides of the partnership successful.
No wonder technology success stories are few and far between.
I want this to change.
This kind of work has been an underlying thread of my consulting and advising for the past five years;
- from helping a multi-million dollar foundation select and implement a CRM,
- to helping a non-profit selecting a vendor for a massive custom software development effort – leading to their successful multi-year partnership.
- to introducing clients to vendors based on cultural fit.
- to working with clients to start capturing the perceived business value sooner than they anticipated.
- and leading the hard conversation on stopping the project when the pre-cursors of success weren’t evident.
About fifteen years ago now, I was reorganizing how search results are displayed in a popular travel site (one you’ve probably used). The goal of the project was to to increase readability and scannability. To do this, I needed to move a few bits of information around. In my rush to prepare the prototype for the initial usability tests, I neglected to move all the bits of information to their new home.
The majority of the evaluators caught the mistakes – unprompted.
Commenting on mistakes – below the fold – unprompted?
I’ll happily take that as proof the scannability & readability improvements were successful. For, if the problems weren’t obvious from even this smallest-level engagement – we still had work to do.
Fast forward a decade, I’m building a proof-of-concept for a startup client. We agreed upon the smallest, most unique functionality necessary to communicate the value of the product. I went off to build it and they went off to find a cohort of interested, beta users.
A couple weeks later, the prototype was ready to interact with and I mass-created a few dozen accounts for the initial users, including a one for my client
I waited. I waited for bug reports, questions, for server performance issues, for emails, for phone calls. For I knew there would be some. Some bringing up issues I hadn’t dealt with yet, some bringing up edge cases that are only exposed during actual use. Some wanting to do something we hadn’t even considered yet.
A week went by – and nothing. No bug reports, no emailed questions of ‘How do I?’. Complete radio silence. On my way out the door, to meet my client in-person, I quick checked the access log – not a single person had logged in since they received their credentials.
Not even my client.
“I haven’t received any bug reports from any of the initial users,” I started after the Arnie Palmers arrived.
“Not good. No one’s logged in since the site’s been up. I don’t think the idea is compelling for the initial users – or for you.
“What do you think we should do?”
“Shut it down and find something more compelling to you and your interested users.”
The next day, we did.
This morning I received an email from a different client. One of their news products was throwing a series of admin-only messages into a publicly-available view. The issue was easy enough to resolve, though in resolving it, it was clear the issue had existed for least two years. Which means, this part of the site has had zero human engagement for that entire time. For if there was any engagement, I would have received emails from concerned users notifying us of the bug. Doch.
If you’re looking for a cheap way to measure actual human engagement and attention – deliberately insert an obvious and miniscule mistake and wait.
If a flood of corrections don’t come in, you’ve got a much bigger problem – nobody actually cares.
In CBS’s world adventure race program ‘The Amazing Race’ there’s a game element called the ‘Detour’. The ‘Detour’ is a team activity requiring completion before continuing on the race itself. Each ‘Detour’ includes two activities – each team needs to select one from an opaque two- or three-word description of each.
The goal is to complete the selected, obscure activity quickly and continue racing to that leg’s pitstop – and not be the last team arriving. For, as Phil says at the beginning of each leg, “The last team may be eliminated”.
The vast majority of teams select their activity, complete it with some level of difficulty, and continue on. A few teams struggle so substantially that they decide to cut their losses on the initially selected activity and switch to the other activity. With this decision they’re betting that, even with the additional time cost of transporting themselves to the new activity and figuring out what it is, they’ll complete it more quickly than continued attempts at the initial activity. Mathematically, the odds are against them. Each minute they spent on switching (transitioning out of the first activity and into the second – both physically and mentally) could have been spent on another attempt to successfully complete the first activity.
“…An old Dutch farmer, who remarked to a companion once that it was not best to swap horses when crossing streams.” – Abraham Lincoln.
While the costs of switching are substantial and obvious from the armchair, they’ll more invisible and subtle in the banality of our own lives. We pay switching costs in; time commuting, time moving between meeting rooms, time switching between projects, time switching between different kinds of activities all from the same swivel office chair. It doesn’t matter if these activities are two equally important projects, a project and email, a project and an unexpected interruption by a co-worker, a project and a Facebook notification. Each switch delays the completion of the initial task by diffusing available mental energy. Across a team of any size these individually invisible minutes quietly evaporate hours and days.
This is horribly unfortunate considering the entire purpose of a firm, of a company with employees in a centralized office, is to minimize these switching costs. It’s a promise that if everyone is in the same office at the same time, day in, day out, and applying effort in the same direction then coordination, collaboration will be easier and business value will more likely be captured than would be with a distributed group of solo practitioners.
Unfortunately, the promise is not always fulfilled. Today’s corporate environments are chockfull of switching costs; sudden interruptions, unanticipated ‘urgent’ meetings, multiple high priority efforts running concurrently within the same team. Each response, each pull from focus, subtly and imperceptibly subtracting from the available time to do the work, across teams, across departments.
I first felt the pain of switching costs early in my independent career where I, far too late, realized I could sell the work or I could do the work I sold – but I couldn’t do both in the same day. Not that I didn’t try, time and time again. Each time I tried, found myself mentally stuck halfway between the two contexts – completely unsure where I left off or what I needed to do next. I was paralyzed – watching the hours melt away.
Since that time, I’ve found 5 strategies to dramatically minimize losing time to switching costs:
1. Schedule work of the same tightly-defined context into a single uninterrupted timeblock.
Think of contexts as singular ‘trains of thought’ that you want arrive at the station as quickly as possible. Anything slowing the train down is likely a different context. Schedule that context separately and distinctly.
The expectation of supporting two very different contexts simultaneously is not unique to solo practitioners (e.g. selling/working as I described above) – it’s also surprisingly common in the corporate world. A member of a management team I work with stacks their 1:1 team meetings three-deep at 1pm everyday. Same kind of conversation, same kind of energy, same time each day.
Some of my clients alternate days of the week for individual projects; Monday for Project Alpha, Tuesday for Project Beta, Wednesday back to Project Alpha etc. This ensures a fixed day-long context for each project, uninterrupted by the others. This is the only definition of multitasking that I’ve found to be both productive & sustainable. The in-between day also bakes-in the creative benefit of stepping away and returning with fresh eyes.
Processing messages (email, voicemail, snail mail), replying to them, and doing the work they describe is in fact three contexts masquerading as one. Break them up and schedule them accordingly – yes I regularly have appointments on my calendar like, “reply to John’s email about research questions.” This also means only checking inboxes at the appointed time – for even tabbing into the inbox risks a switching cost.
2. Schedule your interruptions.
I hear audible disbelief every time I suggest interruptions can be scheduled. There are a number of ways to do it.
The first is eliminating visual and auditory interruptions from devices (i.e. silence your phone). One of my clients always has their phone on silent. Always. Has for years. My phone (Motorola Pure X) automatically silences itself when there’s an appointment on my calendar. It won’t ring if I’m in a client meeting or deep into project work (for both are scheduled).
Extending beyond needy devices, college professors for years have had ‘office hours’ – scheduled time where they expect to be interrupted by needy students. In recent years that notion has extended into the venture capital realm. Recently, in an effort to reduce interruption and stay focused on a substantial, strategic project, one of my client teams has instituted weekly ‘office hours’. To date it has wholly eliminated interruption outside of those pre-defined hours. Presuming you start with a couple sessions a week, it’s rare the issue is so pressing it can’t wait a day or two.
If you don’t yet feel comfortable with scheduled office hours, a first step in that direction would be to encourage your reports to explain their problem to a rubber duck before bringing it to you (the problem, they’ll need the duck later). Too often our knee-jerk response is to add another person to a problem – when what we really need is to fully describe the problem out-loud and without interruption (oh, the irony).
3. Find the best location for each context – maximize your time there.
I meet my best clients outside their office, for we’ve found that stepping slightly outside those familiar four walls helps our conversation stay focused on solving tomorrow’s challenges, not today’s urgency. I regularly stack appointments in the same neighborhood, sometimes even the same restaurant or coffee shop. This minimizes overall transportation costs. Back, when I worked more on-site, when I had a conversation unrelated to that specific client’s project – even if it was with a different buyer at the same company – it was far easier to focus our conversation out of the office (out of the office is likely where your best work happens anyway).
Similarly, just as there is some work that’s best done in front of the screen, some work is done best completely away from the screen. Maybe your best thinking comes from staring out across Silver Lake. Then schedule your thinking there – not feeling trapped in a dark, cramped office overlooking the city bus garage. Don’t rush back after you found the answer you were looking for. Linger, find one or two more. Your brain just got warmed up. If ‘where’ you work includes the tools you’re using, my best thinking usually comes from one of two places; three-pages handwritten, or one of my four 36″ * 48″ whiteboards.
4. Minimize commutes.
Traffic is one of the most challenging things to consistently estimate. If Scheduling was a superhero, Traffic would be the arch-enemy. An easy 20-minute trip always has the potential to suddenly and unexpectedly take 60 minutes for visible reason. Doesn’t matter if you’re traveling by car, bus, airplane, or bicycle. Each mode has this risk. Effectively and consistently accounting for travel time for any distance over five miles makes minimizing switching costs a challenge. One way is to travel outside of peak hours. Here in the midwest that often means planning to arrive at the office before 8am – which is great if the intention is to get ahead of the afternoon rush hour and arrive home before 4pm. Unfortunately, it too often becomes 7pm.
Another method is to shorten the commute either in distance or in frequency – this is where working from home (or within walking distance of home) all or some part of the week is beneficial. The people I work with are always surprised and delightful how much can be accomplished when a regular commute is swapped for actual doing. The world is a touch easier with when your schedule is ever so slightly out of sync with the rest of the world. Breakfast with the family is completely worth it. Target at 2pm is completely worth it. The DMV at 8am is completely worth it.
Commutes come in all sizes. Today, look for those little commutes you do regularly. Maybe it’s walking across the building to the printer. Maybe it’s an elevator ride or two, next time you’re doing it – ask yourself, ‘How can I retain the benefits of this trip while minimizing the switching costs?’
5. Schedule your switches and fuel through them.
You can deliberately schedule your transitions. You can add margins to your commitments.
While our digital calendars allow us to specify travel time to a commitment, travel time from a commitment is a little trickier. You could schedule an appointment (‘travel from x to y’). As a way of universally solving this across all my commitments, I leave 15-30 minutes of white space between commitments. While not ideal (protecting white space requires constant vigilance – both to ensure it doesn’t evaporate and remembering why it’s there) it has made transitions far easier. Even with this small technique you can see how quickly context switches can chew up your day – 15-minute transitions on either side of a 30-minute conversation turns it into a 1 hour commitment. If you include even a paltry 30-minutes of prep & follow-up, the same phenomenon invisibly turns a 1-hour conversation into a 3-hour commitment. It’s all these invisible parts of ensuring commitments are successful that we underestimate when we make the commitment.
Even the smallest transition, say from working on a screen to face-to-face conversation is a context switch requiring a deliberate transition. Give yourself 15-minutes to come to a complete stop out of one context and prepare for another (hat tip Jamie Thingelstad). During the transition – grab a glass of water and some quality fuel (e.g. a handful of fruit, veg, nuts).
6. Make fewer commitments.
Fewer commitments inherently means fewer switching costs. It also means more time to ensuring the commitments you do make are as wildly successful as they can be. Not every discomfort needs to be resolved. Not every discomfort needs to be resolved now. Say ‘No’ more. Decline more. Delegate more. The time & mental space you open up by eliminating the work you don’t want to do will inevitably be filled by the work you do. As my good friend Patrick Rhone says, “Saying ‘No’ is saying ‘Yes’ to other things.”