Issue Log Tips and Best Practices

Table of Contents:

What is the Issue Log and why is it valuable? 

The Issue Log is our primary application for recording our mistakes and learning from them. We use it to bring all problems to the surface, so we can put them in the hands of problem solvers to make systematic improvements. It acts like a water filter that catches garbage. Anything that goes wrong must be “issue logged” with the severity of the issue and who is responsible for it specified, so that it’s easy to sort through most problems. 

Issue logs also provide paths for diagnosing problems and the information pertaining to them. In that way, they also provide effective metrics of performance, as they allow you to measure the numbers and types of problems coming up (and identify the people who are contributing to them and fixing them). 

The Issue Log is a good example of a tool that changed habits and perceptions. A common challenge people had at first was openly pointing out mistakes, because some people instinctively viewed pointing out mistakes as hurtful to the people who made them. Once they got used to doing this, they realized the benefit of it and they got in the good habit of doing it. Now most people can’t do without it. 

What is the value of capturing and resolving mistakes / problems within the Issue Log?  

Problems are the fuel for improvement. So knowing your problems and diagnosing them to their root causes is critical to achieving your goals. We think of a mistake or a problem as a puzzle, and if you can solve the puzzle of what caused that mistake/problem, you will get a gem. The gem helps you consider what you might do differently in the future so that you don’t have that same problem. 

Problems are typically manifestations of root causes, so they provide clues for getting better. Most of the movement toward excellence comes from eliminating problems by getting at their root causes and making the changes that pay off repeatedly in the future. The Issue Log is an important tool for reinforcing a culture of mistake-based learning -- bringing all problems to the surface and putting them in the hands of the problem solvers to make systematic improvements.

How should I be using the Issue Log and what good outcomes can I expect to see through regular use?

The Issue Log is a tool that enables the surfacing and solving of problems to evolve people and machines. If all employees are issue logging regularly, and managers are reviewing issues in their area regularly to diagnose them, you should expect to see problems eliminated more quickly leading to more rapid improvements. 

What types of issues should I log?

You should log any and every issue that constitutes a “bad outcome.” See “What constitutes a bad outcome?”  

What constitutes a “bad outcome”? 

A bad outcome is an identified problem. A good example of this outlines the identified problem, who caused it i.e. the responsible party, and the impact, i.e. the “so what”. Bad outcomes don’t just happen; they occur because specific people make or fail to make specific decisions. Naturally, there are bigger and smaller problems and it’s up to your individual judgment what to put in Issue Log. Though, we believe the way the system works best is for everyone to make their own judgments about what is worth putting in the Issue Log rather than to overthink things. 

Remember, even small problems can point to systematic issues in your machine, so we’d encourage you to lean on the side of logging the issues you see without overfiltering and using the “severity” feature to share how important you think any problem is.

What does a good Bad Outcome statement look like?  

A good “Bad Outcome” statement describes exactly what the identified problem was, who you think may have caused it, and the impact. Try to avoid writing why you think it happened or what you think the solution is. Example: “John Doe did not enter interview feedback in time, leading to a delay in making a candidate offer. Severity 3.”

When should I log an issue versus entering a dot?

 A log is a record of a bad outcome / identified problem. It is outcome driven - you’re encouraged to log an issue when you have a perception of a bad outcome and might not yet know what the attribution is. A dot, to the contrary, is a record of your perception about a person with an attribution. An example of a log is when a Responsible Party misses an important client deadline. You may think that the root cause for the miss is a personal attribution around being organized and reliable so you may consider dotting them on those attributes, and yet there may be many other reasons that warrant a closer inspection. It’s really through the diagnostic process that you can get to an understanding of what about the process / design and the person responsible for it has led to the miss, and also agree on what changes need to be implemented. Log an issue when you want the group to be aware of the bad outcome and collectively explore.

How should I think about issue Severity?  

Use severity to indicate how big a deal you think a problem you are perceiving is and as the priority for which that problem should be addressed. Don’t overthink it - it’s more important that you get your perception out in the open so it can be dealt with than to analyze the precise severity. As a guideline, here are some of the severity definitions and examples to help you:

  1. Very low, e.g. Jeff was 10 mins late to an hour-long meeting that he was supposed to lead resulting in wasted time for others. Or Alessia was mistakenly left off the meeting invite where next steps for her book of clients was discussed causing an unproductive meeting.
  2. Low
  3. Medium, e.g. Kori communicated the wrong (later) date for an important client deliverable that caused last minute scramble / after-hours work for the team, and increased risk for errors in the manual analytics work required as part of the deliverable.
  4. High
  5. Terrible, e.g. The new release caused a major technical break resulting in the entire platform being unavailable for hours across multiple clients.

What do I do if I am logged? 

First, ask yourself whether you are the Responsible Party (RP). If not, and/or if you have questions or concerns, reach out to the person who logged the issue, and open-mindedly seek to understand their reasoning for including you as the RP. If you agree that you are the RP, start by reviewing the issue details and ensure you’re in sync. 

For issues of severity 1 or 2, we recommend performing a quick self-diagnosis by filling out the details / questions in the Issue Log. For issues of severity 3 or above, get in sync with your manager and the logger to identify a diagnoser and SLA for the diagnosis. Then, set up a meeting and participate in the diagnosis!

What is diagnosis? 

Diagnosis is the process to understand the root and proximate causes of a bad outcome and help determine who should do what differently. A good diagnosis typically takes between fifteen minutes and an hour, depending on how well it’s done and how complex the issue is. It involves speaking with the relevant people and looking at the evidence together to determine the root and proximate causes. If done well, it always gets to the level of determining what it is about the people and/or designs involved that led to the bad outcomes (and who needs to do what and/or what needs to be changed going forward). 

How should I approach diagnosing an issue? 

At the highest level, the most important questions you’re ultimately trying to answer when diagnosing are:

  1. Is the outcome bad
  2. Who is responsible for the outcome? 
  3. If the outcome is bad, what does that say about the Responsible Party and his/her performance in their role, and/or is the design bad?

If you keep these big questions in mind and anchor back to them, you should do well. As you’ll see in the app, the diagnosis fields facilitate this process by leading you, as the diagnoser, to ask a series of questions that reveal the proximate, and ultimately, the root causes of a bad outcome. 

When and why should I do a full diagnosis vs. a quick or a self-diagnosis? 

Diagnosis should just be part of your day to day behavior. A common misconception is that diagnosis is a formal process. Instead, managers need to be constantly looking at dots in their area and probing their people and machines to ensure problems are being diagnosed and solved. Managers are ultimately responsible for understanding the causes of the issues in their area and how those causes connect to what their people are like. So connecting outcomes to your machine - i.e. failures of the people or design - should be happening regularly through formal and informal conversations. 

Once I diagnose an issue, how can I ensure that the learnings lead to evolution (of people and designs)?

The diagnosis process allows responsible parties to determine what it is about the people and/or designs involved that led to the bad outcome. From there, the next step is to determine who needs to do what differently and/or what needs to be changed going forward. 

The changes can come in the form of new machine designs, thoughtful guardrails on people’s weaknesses, and development plans for people.


  • The synthesis of root causes leads immediately into a conversation about who should do what differently, and how machines/people should evolve. Those “solutions” to the problem address the root causes, proximate causes, and original problem, and there is a clear plan for how those solutions get implemented, and people discuss learnings from the diagnosis that inform their personal development moving forward.


  • Not coming up with a solution at all
  • Coming up with a solution but not setting up a plan to implement it (tip: set milestones or clear next steps for implementation)
  • Solutions that fail to address both the design and the personal root causes
  • Leaving developmental opportunities on the table

As a manager, how should I manage issue logs in my area?

Below is a proposed approach for managers on issue log management:

  • As a manager, you should ensure that all logs are addressed within their associated SLAs (i.e. an agreement on timelines for addressing varying issue log severities). Depending on the log severity, some will require a diagnosis (severity 3 and above), while others will auto-close or can be addressed through a quick self diagnosis (severity 1 and 2). While each organization can develop its own set of SLAs, we recommend the following:
    • Sev 1: Auto close in 5 business days, if no one engages on the log
    • Sev 2: Auto close in 10 business days, if no one engages on the log
    • Sev 3: Diagnose within 10 business days, otherwise will be marked as ‘past due’
    • Sev 4: 20 business days then ‘past due’
    • Sev 5: 20 business days then ‘past due’


  • Managers are responsible for the health of their areas - in the practical, this translates into reviewing and either diagnosing or closing the logs in their area. While many logs (especially severity 1 and 2 logs) may only require a quick self-diagnosis and are not so important in the particular, it’s still important to remain informed to identify patterns through time. Hold your direct reports accountable to capturing diagnosis notes and learnings in the tool. Even though you may not be directly involved in a log, it’s important to keep a pulse on what’s happening in your organization. Look into how your direct reports have diagnosed / closed out issues and from there, probe into specific areas and pull “any suspicious threads,” e.g. asking why someone closed out a log with a quick self-diagnosis vs. conducting a proper diagnosis. 

Was this article helpful?