I’ve heard about this one for so long, but have never really sat down to look at it in more detail. It’s actually quite simple, so I’m not sure why I waited so long to do this.

When needing to present to an audience, instead of rambling on about what you did, lightning-talk fashion, it’s best to put some structure around it.

STAR is an acronym, pioneered (I think) mostly by Amazon for handling job interviews. But I feel like it’s helpful for any kind of technical presentation or interaction.

It helps you set the stage and build up details to a final sense of completion.

I really like MIT’s take on all of this, so give that a read for additional information than what I have here.

Situation

Set the stage. What key details should people know when considering the initial context around what was later done?

My company had X repositories being built by XX build tool, which had become increasingly difficult to reason about.

Depending on who you’re talking to, you may want to provide some measurable data behind a statement like this. Anything you provide here will really showcase your final result that you’re building to in this conversation.

Task

What was your task in this situation? What were you assigned to do, or what did you determine needed to be done?

My company saw this as an issue and I was tasked with creating / onboarding us to a new build tool.

I want to make an important distinction here - being assigned a task is very different than you being the one to set the task.

The latter showcases leadership. You saw an issue and actively chose to provide a solution to it, while also aligning key stakeholders and actions on the work. Perhaps another topic to discuss in more detail!

Action

How did you take action? What did you do?

This seems to be the most important part to the STAR method (some say 60% of the conversation), but highlighting it after the previous two helps resolve the “questions” you’ve set up previously.

I researched the market, got the budget approved, and allocated some local instances of XX build tool. Then I onboarded teams to using it by writing a distributed migration action…

This also needs to be catered to your audience, of course. If you’re talking to a peer, perhaps you need to dive more into technical detail. Maybe even get into some whiteboarding if that’s helpful.

But if you’re talking to a manager, focus more on the big picture of what was done. Let them determine where you go into more detail, and have those items ready in case they do. It helps a ton to know your audience with this one!

Result

So…what happened? Did you finish the action? Did it work?

We got everyone onboarded to the new tool and improved our build times by X% and reduced our costs by $XX.

It helps to have measureable numbers here, too, because it helps to normalize the actions to your audience. How much a dollar is worth is subjective person to person, for example, but we all know what a dollar is.

My take is this: STAR lets YOU set up your own questions and answers!

That’s how I see it, at least. And since you (hopefully) have a lot of situations that can be modeled after the STAR method, picking which one(s) to highlight is also an important skill in and of itself.

It’s a bit psychological, I suppose, but if you’re trying to highlight you as a candidate or your project as a potential for funding, controlling the narrative in this way is probably your best bet to getting the outcome you want.