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).
At the recent 2019 Capability Counts conference, hosted by the CMMI Institute, I presented a session related to Enforcing Quality with DevOps Pipeline gates, where I provided an introduction to the concepts and technologies of DevOps, and how to use the concepts of Continuous Quality to improve software quality earlier and throughout the application lifecycle.
Here are the slides, published on SlideShare, if you’re interested.
A dedicated employee who will work harder, with a greater sense of urgency (and maybe some extra hours when needed) is great. But what’s much more valuable than someone with that work ethic, is someone who can see when working harder isn’t going to work, and they need to change their approach.
Think about someone using a dull saw to cut a huge pile of wood to build a house — they’ll look at the schedule and say “I don’t have time to sharpen my saw”, which is ridiculous to think about. But we do it all the time when we try to shift into a higher gear and work harder to “dig out” of a busy season/project instead of thinking about what should we change.
It is so valuable as a leader to determine when a situation can be surged over, and when you need different resources/capacity/people/tools to overcome the situation. Years ago, I was helping a Project Manager whose team was continually well below the needed velocity to get to the project’s finish line on time. He kept trying to work nights and weekends to get back on the track, but simple math made it very clear that he could not single-handedly get the project back on track. So we had to investing in both a technology and some additional people to help his team finish — it was easy to easy for those investments on his project; but it was much better to ask for them early in the project’s life as opposed at the end when he would be doomed to fail.
Think about if you need better processes/checklists, or a tool (e.g. software application) to help you be more efficient), or more people on your team, or something else. Take the time to step back and think about how to change the game you’re playing so you can actually win.
There should be a word for people who have the annoying tendency to point at problems and talk about them, instead of trying to actually improve the situation (or maybe there is, and I just don’t know it). I don’t know if you’ve been in a meeting with one of these people, but it’s so frustrating to listen to someone pontificate on and on about some problem and how it’s SO horrible, without trying to come up with any ideas, or asking someone to help them solve the problem, or just stop talking about it so someone else can try to solve the problem.
I’m not saying you should wait to bring a problem to your boss until you have a solution — for some teams/problems that’s a good idea, and for others that’s a horrible idea, and you need to get help for problems. But what I am saying is that you should focus your attention and energy on fixing the problem, or removing the problem, or getting around the problem, or changing the situation so it’s not a problem anymore, or something else productive.
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.
I’m no expert, but here’s some baby advice for anyone about to have a child:
- Read the book “Baby Bargains” — it will pay for itself many times over with saving you money on what to register for and what to buy (it keeps it simple with a value recommendation and a luxury recommendation in each category
- What “Happiest Baby” DVD, because it will save you countless hours of sleep when you have a newborn, and no one with a newborn has the time to actually read the book
- The Baby Owner’s Manual book looks little silly, but it’s funny and has some great content — I really love how they explain bottle feeding for the dad
- You should know — newborn diapers have a stripe that changes color from yellow to blue or green to show when they have a wet diaper
- Take one of those 2-4 hour classes at your local hospital on how to diaper and other essentials (unless you’re already a baby expert)
- Ask other parents for suggestions on baby registry — there are so many things people register for that you don’t actually need
- Have someone professional trained double-check your baby seat installation — I hope you never have a car crash with a baby in the car, but if you do; you want to make sure it’s correct. Most local police or fire departments offer this service scheduled every month or so
- As you get closer to your due date, don’t wait too long to have your home setup and your “go bag” packed and by the front door — we’ve had several fronts whose babies have come very early (1-2 months), so you don’t want to wait until the last minute
- Don’t buy used cribs or car seats — the safety of a new, modern item is well worth the cost of those new
- Sleep Sacks are so amazing — it’s good to learn how to swaddle your baby like a tiny burrito, but as they get bigger, sleep sacks save so much stress
I recently chatted with Tom Cagley on the Software Process and Measurement Podcast (SPaMCAST) about some of my experience helping scale operations at Halfaker using best practices from various business books (e.g. Good to Great), frameworks (e.g. CMMI), techniques (e.g. Agile Scrum), and tools (e.g. JIRA). I really enjoyed our discussion on why I was excited to JIRA, a tool that is not very opinionated, so we could configure it in some specific ways for individual Halfaker departments and projects.
The SPaMCAST is a great resource for learning more from great thought leaders in the Agile, Process Improvement, and Software Engineering world. Check out the interview at:
And if you’re looking for a Podcast app recommendation, check out Castro for iPhone/iPad. It has this great “Inbox” concept (works like an Agile backlog, where you can accept things into the backlog and then prioritize/re-prioritize them.
Early in my career, I was a leadership development conference (through Lockheed’s great Engineering Leadership Development Program), where we played a game called Gold of the Desert Kings — it was a group game, in a big event space ballroom packed with engineers from all over the country. I don’t remember the rules of the game, but I do remember that it was a powerful reminder of how important it is to plan before you start working.
It’s easy to say we should plan before we start doing work — people say things like that all the time:
- Look before you leap
- Measure twice, cut once
- Cal Newport made this point on Ramit Sethi’s blog a while back
- Agile Scrum “forces” people, every few weeks, to stop and assess where they’ve been (sprint demo), where they’re going (sprint planning), and how they could improve (sprint retrospective)
But while we talk about this often, most people often regress back to a tendency of “jumping in” under pressure, instead of taking a breath and investing the energy of actually building a plan.
At the individual level, people are very quick to start working, trying to “make progress” and “feel productive” without investing the time to validate that they’re working on the most valuable thing. When groups of people (teams) are involved, we’re even worse at this — not only does the team want to jump in to avoid the plan of group planning and not feeling productive, everyone wants everyone else on the team to be productive (busy) so they feel they’re not the only one working hard. This creates this nasty culture where the team is trying to keep everyone busy (Instead, Goldratt’s The Goal teaches that we need to optimize the entire system, not at the individual person or machine level).
Yes the plan will change, but it’s not the first version of the plan is not the valuable part — it’s the exercise of pulling together all the different pieces of a project and thinking about them together that is valuable.
While making progress on some new task feels more rewarding and productive than building a plan, whether it’s an Agile backlog; a resource-leveled Microsoft Project file; and/or a few quick PowerPoint slides summarizing major activities, schedule, resources, and budget; INVEST the time to make a plan — make sure before you start sprinting in some direction that you’ve actually checked to see if that’s where you should be running.