Breaking up with Slack

In Slack, I'm Breaking Up With You, Samuel Hulick pens a personal farewell letter to Slack, citing a string of disappointed expectations, mostly time management focused.

His points are certainly genuine and valid however the most important aspect of his perspective is how we expect technology to completely remove the need for social agreement in how we use these technologies. Our disappointment in the way technologies help or hurt us needs to be understood in the context that what makes them work is not there design but our agreements and how we will use them together.

We need  to agree on simple specific things like how often we're expected to visit and respond within these technologies as a team. We need to agree on when and how we use them and when we don't and instead use other media to accomplish our communication and coordination and knowledge sharing. It's in these agreements that make the technology work for us rather than the frustration of feeling like working for the technology.

Team trust through agreements

The importance of working by agreement as a team is based on the simple observation that we are either working from the tension of assumptions or from team constructed agreements. Agreements are shared commitments to what will work for all based on the realities that we work within.

Agreements build trust and trust is important because performance and creativity move at the speed of trust.

We can create some agreements as a whole team, as subgroup members of the team, or in one-to-one contexts. It is a good practice to keep these documented somewhere for reference so that we can work from the actual language that we create for our agreement. It's okay that several agreements do not get recorded because they're more on the basis of an understanding between and among us as a team.

The agreements grid demonstrates that there are four kinds of agreements that we can create as teams. There are general and specific agreements as well as immediate and tested. These four categories create a grid of four possibilities.

In this grid we can create general immediate agreements, specific immediate agreements, general tested agreements and specific test agreements.

A general immediate agreement is one in which we can just simply implemented without any testing because we have enough consensus in the team to go ahead with it. An example is that we agreed to use a certain kind of software app to update each other every day but it doesn't specify how we are going to do that, that it's up to each one of us to decide how we will do that, but we will according to agreement update each other in a daily basis.

A specific immediate agreement is one which again we can just simply implement without testing and it's one in which we specifically detail what the agreement is about. So and example would be that we not only agree to use the specific software app but we also agree to update each other first thing in the morning and at the end of business.

The general tested agreement is one which is flexible but is one that we actually go through testing, after which we critiqued the test in which we can or concerns and finally craft a general agreement that the team will implement.

The specific tested agreement is flexible and one in which we implement after testing and critiquing as a team.

The process for creating tested agreements whether general or specific is very simple. We talk about what matters to us as we work together considering things like communication and coordination, points of tension and disconnects, where things can get bogged down or where people can get overwhelmed.

We choose one that we want to start with and we together craft proposal which is a proposed agreement that we can test as a team for specific periods of time. It's important to ask people to voice any concerns, considerations or exceptions as we consider proposals. This makes proposals highly realistic and more engaging and more supported. We then test our proposals and get together for the critique. The critique is simply the questions of what went well and why and what might want to change based on our experience. We then tweak and if necessary retest the new proposal and then as a team implement what works.

Why teams need to work from agreements

According to a recent HBR piece on work stress, 92% of work stress stems from team dynamics. Studies show stress occurs at the intersection of unilateral expectations and perceived lack of control. 

The antidote to both is the use of agreements, specifically ones that address the more tension inducing dynamics. The article doesn't outline an approach, however it isn't complicated. All it takes is crafting and testing proposed agreements related to what matters to us as we work together. 

Not everything needs to be a formal agreement. Some alignments can be understanding or promises.