The STAR format is a framework for telling a story in a way that communicates the value to the listener. The STAR format is commonly used in job interviews to provide structure to a story and make it easier for the interviewer to understand the key outcomes.

Situation: Provide some background on the situation so everyone has a better understanding of why you went about this in the way you did.

Task: What were you asked to do in this situation, or what did you need to do?

Action: How did you go about the task, what decisions did you make? Break it down into steps if you can, frameworks make it easier for an interviewer to see your structured approach can be generalized to new situations.

Result: What happened? What was the outcome for the organization? Can it be quantified?

My example

So let’s pretend I’m in an interview and they’ve just asked me a question like “Tell me about a time you made a mistake at work, and what did you learn?”

Situation: When I was a new manager, I was driving an initiative to improve the quality of our disease ontology. Everyone in my department was contributing along with senior members of the data engineering team.

Task: A senior data engineer had output a list of a few thousand disease names for my department to review.

Action: Because this work was critical for the development of a new product feature, I had the whole team drop everything in order to get through the review. We spent 2 days doing a meticulous review of the list to hand back to data engineering. When we had finished, we found that the work actually required a much less thorough review that could have been done with 1 curator and 1 data engineer in a couple of hours. I apologized to my team about the miscommunication and wasting their time. I had another talk with the senior data engineer about where the miscommunication came from and we committed to setting better acceptance criteria for work that would be handed off across teams in the future. I told my boss about what had happened and he agreed with the approach we took to set better acceptance criteria.

Result: In the end, the feature was still ready on time, but it ended up costing 168 person-hours instead of 14. Even though this was an expensive mistake, it set the groundwork for us moving towards project management software, adopting Agile processes, and improving communication across teams. An expensive lesson, but in the end, it lead to us developing far more efficient processes that we’ve been using for years. Overall we’ve likely saved tens of thousands of person-hours in redundant work over the years.

Tying it all together

So my example doesn’t have a set framework for solving these types of issues. These situations are ideally the kind of thing you don’t need to solve often enough to have a patented 5 step process to improve. But if you can tell your stories in this format in interviews, they’ll have a better idea of how you think, and you’ll do a better job of selling your thinking process.