Working agreement

I’ve had a good experience with something called a “working agreement” in the last couple teams I’ve worked on.

The main value I’ve seen is in the discussion, when everyone can have a voice regarding how a high-performing team operates. The process can help a new team gel. The resulting artifact provides a third value of resolving operational details for future reference. For example, rather than debate an issue anew, we can just reference the agreement, which all parties had a role in.

I’ve found a scaffolding helpful for structuring the conversation:

  • Core values
  • Expectations
  • Norms
  • Agreements

Core values are simple ideals and can be aspirational. For example, “we provide each other psychological safety”, or “we do our best work together.” An artificial constraint of, say, five values can help motivate discussion, and improve accessibility of the resulting list.

Expectations provide an opportunity to state explicitly what we might be assuming. For example, “I assume best intentions” or “I assume folks have the big picture in mind, even for small changes.”

Norms provide an opportunity to express preferences. For example, “(given designing, writing and reviewing code requires focused attention) I benefit from no-meeting blocks”, or “I read emails, but aggressively purge (so I don’t mind a follow-up a day later).” Note that norms are becoming more operational.

Agreements build on and finalize the preceding sections. For example, “(To work efficiently and respectfully) we’ll respond to code review requests within a day, or communicate otherwise” or “We’ll use a single email adress for the team, differentiated by suffix (so it’s easy to find all emails, but it’s also possible to filter).”

It can take some time to build rapport, especially if the team is new, so budget an hour for discussion, and likely an additional hour on another day to finalize. It’s helpful to share the scaffolding in advance, so folks can start adding ideas. Having a different person lead development of each section improves participation.

These teams have a stated goal to review the agreement periodically, but in practice I’ve found on-demand is sufficient.

Bias for action

This is straight from Amazon’s leadership principles. It also seems related to binary/ruthless prioritization, the Agile principle of “Simplicity — the art of maximizing the amount of work not done”, and customer focus.

An ambiguous problem may have many possible solutions. We risk slowing to a halt investigating all of them. It’s helpful to regularly question if a given task is important. “Analysis paralysis” might describe this, but I prefer Amazon’s phrasing: “Bias for action”.

As a concrete example, in an interview, there may be many possible ways to solve a problem, but time is limited and solving the problem by any means is preferable to identifying all possible solutions without implementing any.