Everyday storytelling for engineers. The CAO Method.
There are not many things in the world that are as important as being understood. From my experience, most engineers are not natural storytellers. CAO method can help build structured and easily under
Software development is a collaborative effort. We work with engineers and other functions in the team. We work with different teams and functions in the organisation.
Dailies, presentations, product demos, etc. — engineers regularly need to present their work. Conveying technical information in a way that is understandable to both technical and non-technical audiences is paramount for engineers. On almost a daily basis we need to provide context, what was done or is going to be done, and what is the actual or desired outcome.
Interactions with clients, product managers and other teams — engineers need to understand the goals and motivations behind projects and clarify requirements. The ability to provide context and ask the right questions is what allows alignment on actions and desired outcomes. That’s what separates professional engineers from less experienced ones.
Tech designs and code reviews require engineers to communicate the context of a problem they are solving and the design choices they’ve made.
Behavioural interviews are all about structured stories about past experiences, actions we took and outcomes our actions led to.
There are many more examples. However, one thing should be clear — communication skills are among the most important and underrated skills in the tech industry.
The STAR Method
The STAR method is the most popular technique for answering behavioural interview questions.
It follows a simple and logical structure that’s easy to grasp and remember.
Situation: Describe the context or situation.
Task: Outline the specific task or objective.
Action: Detail the actions taken to address the situation or accomplish the task.
Result: Share the outcomes or results of the actions.
Similar Methods
While the STAR method is very popular and covers many cases, it is not always suitable. Sometimes, there is no objective or a task. The result is not always intentional. Not always everything goes as planned.
As a result, there are many similar methods.
SOAR: Situation, Obstacle, Action, Result.
CAR: Challenge, Action, Result.
PAR: Problem, Action, Result.
SAO: Situation, Action, Outcome.
CIRC: Context, Issue, Response, Consequence.
OAR: Objective, Action, Result.
As you can see, all of the methods are structured in a similar way, with some slight changes to better fit a story. However, the main concept is always the same.
Context
Situation or background, goal or objective, problem, issue, challenge, or obstacle. In any story, we need to provide some context first.
Action
What actions were taken or should be taken to achieve the desired outcome?
Outcome
The actual or desired result of the actions within the context.
Oh! Mom, look! I came up with yet another method — CAO (read /CHou/)
The CAO Method
The CAO method proposes a more abstract and simple way of thinking about a story.
CAO can be used to both tell what happened in the past and what you are working on right now.
CAO can be used for any engineering story.
CAO for behavioural interviews
Behavioural interviews are sets of questions about your past experiences. It’s all about understanding how you dealt with some situations in the past. Your answers will suggest to the interviewer how you will deal with similar situations in the future.
Your ability to tell the story is as important as the situation and how you dealt with it.
Read more about behavioural interviews here <LINK>
CAO for describing tools and/or techniques
Context: I’ve been trying to organise my daily to-do list. I’ve tried many different organisers, lists and reminders. It didn’t work.
Action: I’ve decided to try a simple calendar time blocking instead of a list of tasks.
Outcome: As a result, I was able to significantly improve my productivity as I not only knew what to do but also when.
CAO for tech design reviews
Context: motivation, goals, requirements, stakeholders
Action: HLD
Outcome: goals, timelines and implementation plan.
CAO for dailies
Context: I’m working on the project X.
Action and Outcome: Yesterday, I completed adding logs, so now we track what exactly is happening in the system.
Action and Outcome: Today, I’m going to work on creating a dashboard based on the logs, which will allow us to monitor the system more easily.
CAO for product demos and presentations
Context: We have a system that counts article views. Users can only read/view five articles a month for free. The problem was that users didn’t know how many articles were left to view this month. The paywall block surprised them.
Action: We’ve decided to add a banner that always shows how many articles are left to see + a button to buy more.
Outcome: We (expect to) see an increase in subscription purchases.
There are not many things in the world that are as important as being understood. From my experience, most engineers are not natural storytellers. CAO method can help build structured and easily understood stories with not much effort.
Give it a try. Tell me how it went.
Did you like the post?
♻️ Follow me on LinkedIn
CAO means "Fuck" in Chinese.. But I like it haha!