Mapping team mechanics

I wrote about mapping team operations about a month ago. Lately, I’ve been thinking about it more concretely.

Audio excerpt from “Brave New Work” podcast 02/12/2019

Maybe it’s because I recently heard a real life use case (audio clip on the left), as told by an engineer from Slack – that oh-so-trendy work chat app that many tech people love to use.

It seems that a key aspect of creating adaptable teams is being explicit about the required output and how tools & processes play into making it happen.

I’m all for that idea.

The first step would be to map out the team’s structure and dependencies. I’d refer to these properties as the team mechanics.

What’s the point in doing this? So that we as team leaders and managers can visually identify change patterns and areas of risk.

Once we have the basic output structure – activities that must be done – we can link up tools and processes that will allow us to make it happen.

Example of activities that each output area requires (source: Organizational Physics)

When a tool changes and gets added to the mix, we should be able to see how it impacts the activity and subsequently the team’s output.

When a team member is lagging in their output, we can pinpoint activities where we think they have room for change (aka improvement).

Whether team leaders would care to know this, I don’t know. But it seems in the same spirit as being explicit about the work being done.