Umwelt, it means the world as it is experienced by a particular organism. I find this particular concept from the world of biology to be an interesting one.
Not in the least because we are biological organisms and the cooperate world is our Umwelt.
The common trope in this ecosystem is just how useless frustrating and time wasting meetings are. It has been argued by heavyweights like James A. Whittaker that these sessions should always take a secondary position to real work.
I argue meetings are real work, and furthermore, they are the most effective way in a cooperative environment to ensure everyone is working on the same thing.
In this entry, I would like for us to look into more detail as to why and what you need in an action plan
But first, what is an action plan?
As the meeting proceeds, certain items will come up needing action. For example, if you are discussing a list of candidates, an action may be to follow up on one of the candidate’s referees.
The strange thing in our Umwelt is such actions are mentioned and mixed in with the general notes, or even worse, not recorded anywhere. Unless you and your whole team are blessed with some kind of super memory, this information is bound to disappear.
Instead, this information should be separated out and put on a list of its own with relevant metadata attached to it. The most important being, who is going to do it and by when they are going to do it.
Let’s discuss a bit more what a good action sounds like.
It has an action in thename
Yes, I saw you roll your eyes, it’s not as obvious as it seems.
You see, we are all so used to having our intuition guide us on the actions we need to do, we barely notice the shorthand in our to-do lists.
For example, you may find such a list for a developer:
- The system is failing periodically
Probably by looking at it, the developer will immediately understand what he meant.
But if you are facilitating a team, such notations lose meaning fast.
It’s better to be explicit. The list can now be something like
- Check the system logs for clues on what is causing failures at 11:15 pm
- Configure Atom as my new editor
- Deliberate with the architect on whether we can change our core language from Java to Go
The latter list has the great advantage of having what needs to be done embedded in the action itself. If you do this, your future self will thank you!
For teams, the importance of being explicit is doubled. You can be sure your teammate lacks the context. More formally:
The curse of knowledge is a cognitive bias that occurs when an individual, communicating with other individuals, unknowingly assumes that the others have the background to understand.
Someone owns theoutcome
How many times have you watched the news, seen something outrageous and resigned yourself out of it, after all, someone else will handle it.
This pattern plays out in many other forms in our lives. Think about the activist dilemma, everyone wants there to be an activist, but no one wants to bear the painful attention from malevolent power such a role attracts.
In a less dramatic fashion, people within our umwelt will not take on anything they don’t have to. After all, everyone’s plate is already quite full.
Thus having only a list of actions is not enough, someone who is present at the meeting must commit to getting it done. Here I don’t mean implicitly assumed to take it, they actually must confirm verbally they will do it.
If no one is willing to do it, then you as the facilitator own it. If you can’t, then just note the item will NOTbe done and remove it from the action list.
There is no need to collectively lie to yourself, tasks get done by individuals, not groups.
Actions must have a duedate
In my personal list, I very rarely have a do by date. Combine this with my philosophy on treating colleagues as adults, you end up with a list of actions for the group without expiry dates.
You can not escape it, normal humans respond to deadlines.
I still don’t have a theory as to why someone needs a date for a task which is clearly very important and should be done as soon as possible. My best guess at it is work items without a clear deadline tend to get pushed further and further into the future till they face death by neglect.
Personally, I prefer a regular cadence, say weekly, where actions from this weekly meeting must be completed by next week
Work is only done once it’s reported to be done
In programming, there is a pattern called fire and forget. In this pattern, an event is generated and listeners act on the event. Say if a new user registers, you may have a listener that sends them a welcome email, another that triggers a trial account and yet another that updates your management board.
This is an extremely powerful pattern, providing an easy way to both extend your code and ease dependency.
Of course, humans are not computers. The same pattern applied to a team fails terribly!
If a task is assigned and no one ever checks if it’s complete, then the action owner almost certainly takes this as a strong signal that its just not that important.
Actions and decisions must beshared
There is always some apprehension to having others look at your work. There is always the chance your work will be judged and found wanting. The fear of rejection runs rampant in our umwelt.
Still, even if you don’t share all your notes, at least share the actions and decisions!
This way others incorporate the work from the meeting into their own daily workflow.
Will your next meeting have an action plan?