The process of building software requires strategy (what are we going to build), tactics (how are we going to build it), and communication (how do we share what we are doing, the progress of what’s being built, and resolve differences). Momentum is built in teams by removing drag. We all know what drag feels like – the sensation of losing momentum and being stuck in a place you don’t want to be – and what it feels like when drag is removed: wonderful.
Removing friction in writing often means changing up a format or removing words. To get better at conveying meaning, I’m starting with an observation my friend Brendan Short provided: “be super focused.” We were talking about how to make newsletters (and short-form writing) more interesting, and it comes down to a combination of permission and attention.
When you agree to listen, and I agree to focus on the thing I’m telling you and make it relevant, concise, and data-driven, it will have a better impact.
Removing friction by making conversations engaging and permission-based makes sense. This shouldn’t be surprising, so why we do we ignore this all day long when having conversations with co-workers?
We interrupt each other constantly
A 2020 study found that office workers are interrupted frequently, with 15% reporting over 20 interruptions per day. Researcher Sophie Leroy writes that we don’t easily return our prior task easily, and that the interruption persists:
More often than not, part of our attention stays focused on the interrupted task and does not fully switch to the interrupting demand — a term she coined attention residue. This happens because we have a fundamental need for completion that makes switching our attention quite difficult for the brain to execute; we hold on to incomplete work instead of putting it aside even when a switch of focus is necessary.
So it’s difficult to achieve optimal work (or even to experience flow for anything), especially when you are being interrupted.
Yet interruption-driven is the way to go in most work environments. Whether it is a well-intended animated gif, a “quick question”, or a legitimate post that requires multiple people to respond, your attention is being borrowed.
Many people are typing… and yet we haven’t gotten closer to establishing:
-
the question we are trying to answer
-
who needs to be involved to resolve
-
at what point we need to convey a brief audio or video call with the purpose of making a decision to move forward
We have limited productive time daily
Given the interruptions above, it’s not surprising that programmers work in a flow state only for a few hours daily.
Flow – the feeling of being completely involved or immersed in activity – is the key to getting deep work done. Mihály Csíkszentmihályi, the psychologist who coined this term, equates flow with emotional well-being and happiness. (See his 2008 talk below)
If we take Csíkszentmihályi at his word, then flow is the most important thing any of us can do in a day. Yet in our working day, flow is fleeting.
What products can do to help flow
Creating a great product experience includes a responsibility to consider when using the product (hiring for a job) is going to be most useful. For example, Slack positions itself as a product that will help you to avoid unnecessary email for in-company communications. But a side effect of that utility is that anyone in the company can demand your attention at any time. It’s true that you can turn off your notifications or leave the product. It’s also true that the default has been set to “always on, all the time.”
We could do better. Consider the difference between these two messages. You need a response, and you need to know by the end of the day Tuesday whether to go forward. You’re pretty sure that it will take someone about 10-20 minutes to review, consider their feedback, and write back to you.
Here’s an example of a mild anti-pattern → it requests immediate attention, does have an expiration date, and asks for a response. You could send this immediately:
And now add the context of when this is being sent. Sending this immediate message on a Saturday, for example, breaks the idea of a weekend and doesn’t add useful context. Why not send it Monday morning at 9am, with enough time to respond by the deadline?
This small feature turn (allowing the message to be sent on a delay instead of immediately) gives lots of space to anyone who is in the flow of a weekend.
Now, imagine that this feature was the default – flipping it to “deliver on the recipient’s schedule – while retaining the “deliver this immediately” option when needed. That would be a product improvement helping anyone to be interrupted less often.
What’s the takeaway? Attention – especially attention from your own team – is at a premium. When you ask for it, providing the context of why you’re reaching out, what needs to be done, when it has to be completed, and the value of that effort really helps for the other person to know how to answer. And if they are actively protecting their time to build a flow state, they will appreciate it even more.
