It's urgent? So what?
Constant urgency can derail an async-first work culture. Leaders must shield their team from false urgency. Here are some ways to do so.
- Use the Eisenhower matrix to triage work and understand if the incoming tasks need immediate attention. If not, schedule the tasks for a later time or delegate them.
- Responsiveness is seductive, but it comes at the cost of deep work. Don't run your dev team like a call center. Equate urgency with emergency and when you have hard deadlines, negotiate scope.
- Plan your sprints and communication in a way that work doesn't spill over to people's personal lives.
- Protect your experts' time by instituting "office hours" to respond to queries. Share these responsibilities if possible and document responses so you save time in the future.
One of the easiest ways to start your async-first journey is to give yourself a taste of success. A “maker week” works brilliantly for this purpose. The idea is simple. Here’s how I recommend going about it.
Get your team to clear off their calendars for one full week. Be sure to keep your stakeholders informed.
Just so no one reclaims these free calendars, everyone on the team blocks out the week for “focus time”.
If you need to coordinate, use instant messaging.
If you have an IM exchange that takes over five minutes or five messages, then you probably have a problem that deserves a slower medium. Write things up in a document and take things from there, async.
During the week, encourage people to work with distraction blockers like Freedom. That way email, IM and social media don’t sabotage their focus.
When a team experiences interruption free work for a week, it feels like being hooked to a drug. They want more of it. Of course, some people will come back wanting to connect with colleagues. That’s when you can have a conversation about the balance between sync and async communication. You can then plan activities that focus purely on connection and relationships.
The biggest enemy of such experiments though, is “urgent” work. You work a certain way, and something “urgent” comes along and scuttles everything. The team shrugs their shoulders and does what they can to be responsive. Often this means getting on meetings, and being ok with days full of IM interruptions. With enough of these “urgent” tasks, even the most motivated teams can slip back into their old, synchronous ways of working.
“We think urgency is overrated, and ASAP is poison. Real-time is the wrong time most of the time.” - 37 signals.
In today’s post, I want to address this notion of urgency. So what if it’s urgent?
Unbundle urgency with the Eisenhower matrix
Dwight Eisenhower was a five-star general during World War II and an American president. His military and political accomplishments aside, we know him in the business world for his prioritisation framework - the Eisenhower matrix. MBAs and management types love it because it’s a 2x2 and I like it for its simplicity. On the X-axis you have urgent and not urgent and on the y-axis you have important and not important. I won’t go into the details of the matrix in this post, because there are several articles about this on the web already. I recommend looking up this post by Doist.
Here’s the key thing to take away though. There’s only one “do it yourself right now” quadrant. That’s quadrant 1. It’s the stuff that’s urgent and important. And for a software development team, this should be a tiny percentage of work. I have two qualifiers for quadrant 1 activities.
They have a clear deadline and there are serious consequences to not meeting the deadline.
Only you or your team can perform this activity.
It’s important to triage “urgent” work with these qualifiers because you often have work that seems like it belongs to quadrant 1, but it’s in fact work from other quadrants masquerading as quadrant 1.
If the consequences of missing the deadline aren’t too serious, this may be quadrant 2 work. Just schedule for a time when you or the team can address it calmly. Agile is all about iterative improvements. So how about you address this in a future sprint?
If there are others who can perform this activity, then it may be quadrant 2 work. Yes, developers can address support tickets, but isn’t that the support team’s job? Yes, you can answer an urgent ad hoc question, but shouldn’t people search the handbook first?
If you lead a team, then triaging incoming work and de-escalating seemingly “urgent” work can be amongst the most important services you provide to your team.
Lead with empathy and coach others too
Urgency is seductive. If you lead a team that responds immediately to everything that seems urgent, you build a reputation for yourself and the team. From everyone else’s perspective as well, it seems wonderful. All they need to do is label something as “urgent” and the team responds.
Before you know it, things can get toxic.
It’s very easy to be trigger-happy with urgency. After all, what does it take to email with an “urgent” label?
That trigger-happiness creates an environment of constant pressure. It’s never a healthy team environment to chase deadlines constantly. You end up with what we call a death march.
Deep work and flexible hours are amongst the first casualties of such a team environment. If you’re constantly fighting fires then where’s the time to pause and think things through? And who cares about flexibility and work life balance when the team’s all-hands-on-deck?
Software development is creative work. You can’t run your dev team like a call-centre. People need time for deep work and reflection. A constant stream of seemingly urgent work can foster that call-centre environment which is counterproductive to the work your team’s meant to do. Coach yourself and others to think hard about what you label as urgent. If it’s not an emergency, it can wait. Delays are most often OK. Even if you have a hard deadline, scope is always negotiable. The next sprint is just around the corner. Prioritise right, and you’ll leave yourself with only the long tail of requirements to address, even when you cut scope.
Foster a conducive work environment
How you set up your work patterns also affects how you address urgency. For example, at Thoughtworks most teams begin their sprints mid-week. That way the sprint also ends in the middle of a week. Just in case there’s something truly urgent to address at the end of a sprint, it doesn’t spill over to the weekend. You end up protecting people’s personal time.
Building on the same sentiment, I encourage people to send out messages at a time that’s convenient for the recipient. This is especially important on globally distributed teams. If you send out a message when someone usually ends their workday, you may induce them to stay back at work longer than usual. Worse, if they see your message at a time they usually reserve for their personal life, they may feel like they have to attend to work. Most email and messaging software allow you to schedule messages for a later time. Most things can wait. Your email or IM can too.
Clarify responsibilities and free up knowledge
If you notice that your team gets bogged down by urgent work too often, it may mean that your problem needs a deep fix. Sometimes this is down to unclear roles and responsibilities. Back in the day, I was leading a team for a B2B product. The dev team was also responsible for support tickets. When paying customers raise hell, it’s easy to get sucked into a doom loop where developers are only responding to support tickets and getting on troubleshooting calls. Coding takes a back seat.
We fixed this problem by carving out a support team whose job it was to respond to tickets. In teams where we didn’t have this luxury, we’ve experimented with rotating the responsibility to address support issues. This allows both support and engineering personnel to get into the zone with their specialised tasks. Flow and deep-work are the obvious benefits of such an approach.
The other anti-pattern I’ve observed is when a certain person gets a disproportionate number of queries from stakeholders or other teams. Sometimes this is a matter of expertise which only one person has. In such cases, I’ve found “office hours” an effective solution. Here’s how it works.
The expert provides a predictable availability schedule. E.g. an hour each at 4pm on Tuesdays and Thursdays.
During this time they get onto a widely broadcasted Zoom call, or they monitor a specific IM channel.
People can get answers to their questions at this time, and the expert documents the QnA in a growing FAQ doc, so they don’t have to answer similar questions again.
Often it’s not a case of expertise though. It’s just that everyone knows only one person, and that person becomes the visible face of the team. This is where you should seek payoff from all the effort you’ve put into knowledge management and into building your handbook. I suggest you do three things, to take the pressure off the “expert”.
Share your knowledge base and handbook with your stakeholders. Teach them to first search these resources before they ask you a question. This isn’t rude. It’s efficient.
Inform your stakeholders that your team’s bigger than just the person they always reach out to. Provide them a team inbox and encourage them to use it instead of reaching out to individuals.
For the queries that you receive, you and your team must act in one of two ways.
If you’ve already documented the response, respond with the link. That way you train people to self-service.
If no one’s documented the response earlier, this is the time to do so. The few minutes you invest in writing up a response now, will save you time in the future.
Whatever you do, don’t normalise constant urgency. And don’t avoid the deep fix.
Jason Fried
“If stress is a weed, urgency is the seed. Don’t plant it if you can help it.”
A hard deadline is actually a good thing. It prevents us from spinning our wheels endlessly to ship a mythical, perfect product. But we shouldn’t conflate these deadlines with false urgency. If you’re aiming for deep work, work-life balance and diverse teams, urgency can be a formidable foe to these goals.
So the next time you face a hard deadline - check if some things can wait. Consider if you can negotiate scope. Don’t let quadrant 2 and quadrant 3 items masquerade as quadrant 1. Don’t let quadrant 1 activities take up over 10% of your team’s time. Protect people’s time. You’ll see the payoff in your team’s morale and the quality of work you all produce.