Category: lessons-learned

Most teams have a lot of recurring tasks they have to keep track of, such as an HR team doing annual benefits ‘open enrollment’, or an IT Service Desk team reviewing weekly automated backup status messages, or an Accounting team doing their monthly book close, or that annual data audit people always forget to do.

Many teams remember those types of tasks in the heads of different people on the team. Some have recurring Outlook/G Suite calendar reminders.  Some have sticky notes.  Or smartphone alarms.  But all those approaches are prone to lots of issues (e.g. someone is sick on a key day, or someone leaves the organization and doesn’t transfer that knowledge well to new team members).

I’ve seen a lot of value in creating a centralized Recurring Activity Matrix (RAM), which can be a simple table in a wiki tool (e.g. Microsoft SharePoint, Atlassian Confluence) where a team can see what recurring activities exist, their frequency, and what procedure/checklist goes with that task.

I’ve found a great, simple, cheap approach is to publish that table and then create an automated, email reminder for each row using SendRecurring, which is a free or cheap service (depending on how many tasks you juggle) to send emails as a reminder, ideally to a system to ingest and publish them to the group, such as Atlassian Jira Service Desk (JSD).

Just creating this simple knowledge management tool and incrementally refining it, each time you identify something the group should know about it, is a great way to improve the operational resilience of a group, and drive people to identify the work they do (and ideally create procedures/checklists/processes to define them).

A RAM table could have columns like this:

• Owning Team (if your organization has more than 1 team in it)
• Task Name
• Associated Task Procedure/Checklist (e.g. maybe a link to a wiki-based checklist or a formal process asset that defines the procedure)
• Frequency (e.g. Weekly)
• Trigger Day/Time (e.g. 28th of each month at 11am EST)

(I’ve written about this before, but I think it warrants another post because it can be so valuable for teams to do)

It sounds obvious, but as a leader, it’s critical to manage a team based on the team’s current maturity level.  For example, if you have a high-maturity, high-performing team stacked with A+ players who know how to do their roles well, are excellent at the needed hard skills, and collaborate as a team incredibly well; you should not treat them like 5 year olds playing soccer. Conversely, you should not treat 5 year olds playing soccer like a high performing team (e.g. explained nuanced optimization concepts, when they’re still struggling with the fundamentals).

This sounds obvious, but often people try to focus on team performance metrics, such as Scrum team velocity or first-call resolution, when they should realize the team needs a lot of work on the fundamentals (e.g. ensuring the team understands their purpose and context within the organization, understanding why various meetings are held, clarifying expectations of speed vs. quality).

I went to the eye doctor recently, after my eye was bothering me.  I had slept in my contact lenses for several nights (which I’m prone to do), and my eye started bothering me.  In the past, when this happens, I take my contact lenses out, throw them out, and take a few days off of contacts.  This time however, my eye was bothering me much more than usual, so I went in to see the eye doctor.  I’m glad I did — I had a corneal ulcer, where bacteria had been stuck inside my contact lens. The eye doctor got me a prescription for some antibiotic eye drops and explained how lucky I was, since the ulcer wasn’t on the pupil itself (which can cause people to lose partial sight the rest of their lives!!!)!

The doctor asked me “Do you know you’re not supposed to wear your contacts overnight?” and I explained that I certainly did, but I had no idea what the real risks were — I assumed eye doctors said that, but that my approach to taking a break when my eyes bothered me was fine.

This is a great reminder of how important it is to communicate risks in a tangible, clear way.  It’s easy to say “That’s risky” or “This is not a best practice” or “It’s better not to do that”; but if we don’t take the time to truly articulate the possible impacts, explaining both the likelihood of something happening and the impact (severity) if it does happen, very bad things can happen.

Edward Tufte’s book Visual Explanations provides a powerful case study of this concept:  Engineers recommended the Space Shuttle Challenger not be launched based on specific weather conditions, but the launch was approved due to a lack of clearly communicating risk.