As the world of software development continues to wander down the remote work path, it can make one wonder…what else can we shake up? There are so many aspects of a daily office life that could use a revisit: a new lens, a new perspective a new approach…a new way. One of those aspects is meetings. We can all probably think about a job where meeting culture was the status quo. That being said, status quos are meant to be scrutinized periodically…let’s schedule a meeting to talk about it.
Let’s Pull Up
Meeting culture has some great positives. There are fairly obvious benefits to the “getting everyone in the room (or zoom)” approach to work and problem solving. Those real time decisions are impactful and can help to launch a project into a new phase or clear a roadblock or create some amazing artifacts. When a slack thread hits 40 messages, some of us are inclined to say. Enough! Let’s pull up and discuss. Sometimes, that may be the right move, sometimes it may just be introducing an unnecessary roadblock to momentum. If everyone on that thread is immediately free to discuss the issue, then great! Take those 10 minutes, hash it out on a zoom call then hang up and go forth and prosper. Just make sure you document the outcome of that call in that slack thread.
What happens if only two of those people is free to hop on a zoom call? Or if someone in the chat hasn’t weighed in yet because they are deep in a coding flow and have gasp silenced their Slack notifications. The thread AND the meeting missed that person. Rather than giving that asynchronous problem solving time to play out, our natural inclination towards meeting culture rushed the conclusion. In some cases, the conclusion of the meeting may have been exactly the right thing…but at what cost?
A Shift To Async
There is an increasing focus on researching and quantifying the cost of context switching. I won’t attempt to offer that calculation here, but rather make the point that a meeting is the ultimate context switch. Every time you have to stop what you are working on to walk down the hall to a conference room or join a zoom call, you lose a little part of the day. It takes time to draw out of what you are doing and dive back into it the next time. A day full of meetings usually equals the same thing for folks - mental fatigue and a lack of productivity.
Very little of what we do is intensely time sensitive in software development. Sometimes there is a crucial bug that we have to jump on and solve immediately (especially when our work is customer facing and our bugs customer impacting), but a lot of times questions posed can be answered at a later time. Everything does not need to be discussed real time in a collaborative setting.
The Power of Tools with Norms
How do we solve it…tools! Tools alone cannot solve this problem. There are some excellent tools on the market to empower companies to even just take a step away from meeting culture towards asynchronous work. That being said, more software is not the answer in and of itself. We have all been in situations where the chat tool of the day ends up creating stress, discord and distraction throughout (and sometimes well beyond) our work day. When tools are implemented as a “band-aid” rather then as part of a thoughtful solution to the root issues around collaboration within a team they run rampant and often exacerbate the underlying problems rather than solve them.
When we make a decision to adopt a new tool, thinking through how we want our teams (and how people ultimately will) to use it is an important step. Training on a new tool is fairly intuitive; tailored training for specific teams around tool norms is a bigger leap.
Who should establish the norms?
Sometimes it can be difficult for enterprise-wide norms around a tool to be delivered in a top down, ubiquitous fashion. This can be for many reasons. Perhaps leadership is a little too disconnected from the day-to-day behaviors of employees or teams across the organization. It could also be that the tool is too unfamiliar to anticipate the exhaustive list of norms that may be needed as it is adopted across the organization. While these issues can be daunting as we “shop” for new tools to support our asynchronous collaboration goals, it is important to have some guardrails in place before rolling out access.
Enterprise norms can come from all different places within the organization. Here are some options:
The executive leadership team
A culture committee (or whatever name it has in your place of work)
Crowdsourcing
Another approach is to keep the enterprise norms somewhat high level and provide time and space for teams to generate their own norms. These can be posted or shared in a public forum in case one team’s norms resonate with another…we can borrow from each other this way.
Revisit and Revise…Often
As with any norms, they can get stale. Team members come and go, tools release new functionality, we shift how we work, or we learn new things about a tool: all of which may call for a norm revisit. This can take many forms depending on the level (team based or enterprise wide) of your norms and the size of your organization. Regardless of what it may look like where you work, the practice of reflecting on why we do things the way we do them is a powerful one and it can be an important key to effectively leveraging tools that support asynchronous collaboration.
Some Tool Norms to Get Started
This list is in no way exhaustive, but it is a nice launch pad from which to jump into the world of asynchronous engagement models within a project team, office group or at an enterprise wide level.
Create rules for chat tools as they relate to work. This can take a few different forms such as:
Set specific hours where people can expect answers back from one another via the Chat App of your choosing.
Allow questions to be posed when they bubble up, but set the expectation that they will be answered at a time that is not disruptive such as at the end or beginning of the day or over a lunch hour.
Set an expectation that if a slack thread results in a meeting where a decision is made…DOCUMENT the decision in the thread and tag any team members who weren’t a part of the conversation or who need to be aware of the decision
Implement a standard operating procedure for chat app responses; there is no one size fits alls here think about what makes sense for your space
Assign topics or types of communication to different mediums. For example:
Documentation lives in confluence
Questions about work items travel with those work items…think Jira ticket comments
Leverage the use of away messages or statuses for team members to communicate time in deep focus or flow state and silence app notifications
Establish company wide (or department or team wide) focus times
This could be a Focus Friday model with no meetings and no direct messages
Teams can agree to silence their chat notifications for a period of time each day
set the expectation that no one will be responding during that time to any stakeholders or collaborators outside of the team so they know that the team won’t be available during those times
This may not be feasible if your team is scattered across time zones with no overlap
Not all Meetings are Created the Same
While there are many merits in guarding against meeting culture, there is still a place for meetings in our workplaces. It is difficult for most teams and organizations to conceptualize a world without any real time collaboration. While it may be possible in some instances, there is something to be said for operating within our comfort zones.
Thinking about why we are meeting or why we think we need to meet before we throw a meeting invite into someone’s planned day is a valuable practice. An eye towards efficiency and a shift towards asynchronous work and collaboration can actually make those real time meetings incredibly more impactful and efficient. If we start to think of meetings as one of many weapons we have in our collaboration arsenal, we can begin to break away from the meeting culture mindset and drastically shift our workday experience.
