Interruptions and Expectations
I originally wrote this essay for the Proof+Geist team, but the core ideas I’m working through here apply beyond our internal processes. It’s an ongoing experiment and a work in progress.
Energy and focus at work
I’ve been thinking about work and energy – what makes me feel energized and excited at work, and what makes me feel drained and depleted. Broadly, I’ve noticed that I am energized by unstructured time for thinking, immersion in a task or topic, reaching completion or closure before moving on to the next thing, and interacting with people. I feel depleted when I am rushing, when I push myself to continue to work past the “low energy” warnings my body gives me, and when I am scattered and unfocused.
This has led me to attempt to block off time for focused, immersive, uninterrupted work. But somehow, I haven’t been able to make it happen in reality. It was as if I wasn’t disciplined enough, or had set the wrong priorities… other things always seemed to sneak into my “focus” time, and I could not figure out why, or how to stop it from happening.
In this blog post, John Sindelar talks about some of the reasons that blocking time off for “the important things” doesn’t work. His ideas resonated with me, but felt incomplete. It wasn’t just that I needed to be more clear about my priorities, or more defensive of my time blocks. It was that the people I work with have real needs that I want to be able to help with. As I talked through it more with John, I found myself saying something along the lines of “I can’t just tell people to wait until… when?... to have their needs met.”
That stopped me in my tracks – if *I* didn’t know when I would be able to pay attention to something unless I did it immediately… I couldn’t possibly ask another person to defer their needs until this mystical unknown future time.
Expectations in customer support
That striking insight brought me back to another conversation in which I’d forcefully argued that when a customer is having an urgent support need, it’s very rare that the thing they need right now is an elaborate, thought-out, developer-produced solution. The urgent part is this: I need to have confidence that you will pay attention to my issue, that you will get back to me about it, and that I know when to expect to hear from you. It isn’t even “resolve my issue” so much as it is pay attention to it and give me a status update.
When I had my own FileMaker consulting business, I took several weeks off at a time, away from my email. However, ahead of these trips, I made sure that I informed every customer that I was going away and that I would be out of touch. I also gave them a backup plan – either a cell number where they could call me or, if I was going to be truly unreachable, another developer they could contact – so they had a lifeline if there was an issue that really could not wait three weeks.
In two years, there wasn’t even one emergency. Which isn’t to say that emergencies don’t happen – I was working at a very small scale, so encountered fewer of them than we do at Proof. However, when given clear parameters and an understanding of what the options are that are available to them, I believe that most people will be generous, considerate, and patient. I think that what we crave is certainty. While it’s not the same as knowing I’ll always fix your issue within one business day, there is still a certain kind of certainty in having an expectation that you have confidence in. In this case, I was setting an expectation that they would not hear anything for three weeks, but that once I was back, I would respond with an acknowledgement and a date when I would be in touch again, either with a solution or with next steps.
Expectations in team support
How does this apply to my current situation? One of the roles I have is as an internal “help desk.” I’m a resource that the team can turn to for help with internal problems or sources of friction.
The lightning bolt struck me as I realized that I needed to set aside time on my calendar for help desk tasks not just so that I knew when to do them, as a self-management tool, but in order to help everyone else set an expectation about when I can pay attention to those tasks. If I had that, I could say, “Got it – can this wait until Wednesday at 3:10pm?” because “Wednesday at 3:10pm” would be a time slot that exists and has meaning.
The mutual gift of agency
Creating a visible, predictable time slot gives everyone on the team the agency to decide if something is urgent and needs attention before the designated time, or if it can wait. It simultaneously sets their expectation for when their need will be attended to. This is exactly the same as getting back to a customer in crisis – it’s not so much about leaping to fix the issue, it’s about letting them know when I’ll pay attention to their request and get back to them, so they don’t have to keep thinking about it.
I am willing to bet that this makes two additional things possible. One, at least some of the time, people will wait and surface non-emergency issues during that time slot. This might mean scheduling the sending of a slack message, keeping a list for themselves, or even sending a message that says “this can wait.” Regardless, it means that I not only have an easy response (“can this wait until my next help desk time slot?”), but also that I sometimes won’t need to respond at all, because issues will self-direct into that time.
Second, I suspect that making this time explicit will actually allow more issues to surface. This may sound counter-intuitive. When there isn’t an explicit home for these things, only the urgent ones get discussed because people generally don’t want to interrupt. The potential to hear more, non-urgent issues is truly exciting to me because I think there is a whole class of problems that are important but not urgent and the risk is that we never get around to talking about them. These sometimes (often?) turn out to be underlying systemic issues that, when attended to, resolve a suite of other problems. I want to create a forum for those to surface, so this feels like an exciting opportunity.
Nuts and bolts
I want to test this out, and see what it looks like in action.
Here’s my v1 implementation plan:
Designate help desk times in advance and put these both on the team calendar and my personal calendar, so they’re visible. The current plan is Monday and Wednesday from 3:10-4pm ET and Friday from 11:10-12pm ET. (There’s a future essay that I
’m going to writewrote about “why not start on the hour”!) If I need to adjust based on prior commitments, those adjustments are also on the team calendar, so it’s easy to see. I picked those times because I think that we have a natural tendency to want to wrap things up by the end of the business day or by the end of the week. Hopefully, these times allow me to unblock things while still leaving enough time for us to take next steps after being unblocked.Host my help desk in Gather. Even if it’s just me, alone, working on asynchronous tasks, Gather is a context that is different from my usual day-to-day. I think that changing context can help me clearly differentiate this time. From everyone else’s perspective, the barrier to go up and talk to someone in Gather is low, so perhaps being there also reduces friction for others to come and talk to me. I plan to be on the office roof in Gather, which seems like a relaxed “outdoor” space; there’s a link in the calendar event that takes you directly there. Of course, I’ll also be available on Slack.
If things need more focused or longer attention, the help desk time is an opportunity for me to schedule additional time for a task and to communicate that back to whomever is involved. I don’t necessarily think that everything can be addressed in three hours a week, but I do think that plans to address issues (or, decide not to handle them), can be made within that window. Scheduling additional time for more involved or complicated tasks helps make those commitments both more explicit and more likely to be completed.
What does success look like?
Here are some things I want to evaluate once I’ve tried it for a few weeks, to see if this format is “working”:
Does my week feel more focused with these designated times on the calendar?
Am I able to use the designated times as intended?
How do I feel at the end of those time slots? Is it energizing? Draining?
Do they feel long enough? Frequent enough?
Does Gather work for me as a context?
Is it easy for me to respond, “can this wait for my next help desk time slot?” and does that help me stay focused on other work?
Am I hearing about important but not urgent issues as a result of this time slot, and does that feel like an effective use of time?
For all of the above, does it work for me? Is it working for the team?
I hope you’ll be patient with me as I try this out, and let me know what it’s like for you. Also, to be very explicit – sometimes things ARE urgent and cannot wait. That is okay. This isn’t intended to completely eliminate all interruptions – it’s intended to give us a concrete expectation of what the alternative to “just take care of it now” looks like.