Time management lives alongside prioritization and communication as the foundational skills for being an effective team leader. Team leads (alongside everyone else in most organizations) have more work than they can handle, so what work should they do and when? The key to these decisions is understanding the three levels of time management.

How long do you spend talking about your burndown chart during your sprint retrospectives? Burndown charts tell you so much more than if you finished all the work in the sprint or not. From these charts, you can learn:

• How well your team is estimating story points

• How many injections occur during the sprint

• How well your team is breaking down tickets

• Bottlenecks in your team’s software development pipeline

We’ll walk through a few examples of burndown charts in this article and discuss what we can learn.

Slack Analytics are a powerful tool for understanding the way your company communicates. How and where your team chats is a pillar of your overall team communication structure.

Your product will reflect the positives and negatives of how your company communicates. In this article, you’ll learn how to analyze the single most critical Slack metric and take action to improve how your company communicates.

Busy, busy, busy.

In any company (small companies especially), it’s easy for leaders to get busy. Rushing between planning meetings, standups, retros, and one-on-ones, then trying to squeeze in some dev work as well. The work adds up quickly and you can barely catch your breath.

So with all this work, how do you know that you’re making progress? What if you’re just running in place? Let’s take a step back and evaluate the difference between doing the right work and just good work.

When I was a backend team lead I would sometimes jump in and help during sprints by writing code or diving into operations. Occasionally I would even be the best person for the job because I had domain knowledge for that service or sub-system.

So why do I always prioritize dev work dead last on my list of to-dos?

I like to joke that every problem, at its core, is a communication problem.

It’s true more often than not, mainly when the problem involves well-meaning individuals.

Here’s a bit of a paradox: the better you are at solving SaaS production incidents, the harder each incident is to solve.

At first glance, this doesn’t make a lot of sense. Wouldn’t being better make solving production incidents easier? No. The trick is that once you get good at production incidents, you don’t get hit with the easy ones anymore: you solve them for good. That leaves only the new and challenging problems for you to solve. The average incident is more complex, but your reward is that the frequency of incidents goes way down.

I’d take that trade any day.

A little excitement in your job is usually a good thing. It could be learning a new development language, preparing to release a new feature, or taking on new responsibilities as part of a promotion. That’s great for most jobs, but not operations. Let me tell you why.

Production SaaS platforms require operations maintenance, support, tech debt payments, bug fixes, and more. This isn’t even counting the feature work customers, sales, and PM are asking for.

So with all this work to do, how can we manage what to do when? How can we as a team agree on our shared day-to-day priorities? This is a critical challenge to solve, especially now that remote work is so prevalent.

Planning is critical to running a successful War Game. One of the core goals is for the incident to feel real, so expect to spend 3-4x the amount of time planning the War Game as you spend running it.

In the first article of this series, we identified a few challenges of production incidents. They’re fast, filled with pressure, and are (hopefully) brand new failures. If the best-case scenario is a new failure (remember: repeated failures mean we never solved it the first time), how can we practice?

It’s 3 AM and your phone is ringing. There’s only one number you let ring through your Do Not Disturb settings. You open one eye and look at the first of 12 on-call notifications.

“Database down. Need help.”

It’s gonna be a long night.