Deliver - Telling A Good Story

CARL framework

• Context: The overall context of what was happening, including how you were involved. This is the combination of Situation and Task.
• Actions: The concrete steps you took to address the task, what you did, how you did it, and why you chose that approach.
• Results: The outcome of your Actions, what changed, what impact you made on the business.
• Learnings: What you learned or your reflections on the choices you made.

Context

Include:

1. Compnay context
2. Team/role relevant to the story
3. Problem or opportunity that kicked things off
4. The stake: Why the problem matter
   • Stake matters: because
     • Weak: "I worked on a performance project"
     • Better: "We needed to improve performance for users"
     • Best: "Our checkout flow had a 40% abandonment rate, costing us an estimated $2M per quarter"

Context need to be 30-45 seconds long: DONT SPEND 1-3 minutes on this

Context mistakes to avoid

1. Project history lesson — how the project is form, we dont need this
2. Unnecessary org chart — who report who
3. Explain technology that interviewer already knows – kubernetes is container orchestration …

Actions

• Keep uisng "I"
• Include both technical and non-technical
• Be specific
  • Not "I talked to the stakeholders" – "I shceduled sync with PM and write pager to share with director"
  • Not "I debugged the issue" — "I added distributed tracing and identify that Redis connection pool was exhausted during peak traffic"
• Show repeatable behaviors:
  • Show the "how" not the "what"

Value of detail

1. Make your story understandable
2. Establish your credibility
3. Provide the detail mostly in actions
   1. The alternative i've considered
      • I evaluated three approaches: microservices, a modular monolith, or refactoring our existing monolith...
   2. The reasoning
      • "I chose the modular monolith because our team of 8 couldn't support 15 microservices..."
   3. Specific technical decisions
      • "I implemented a hexagonal architecture pattern with clear boundaries..."
   4. How you navigate chlelnges
      • "When the VP questioned the timeline, I created a phased rollout plan..."
   5. Collaboration and influence
      • "I paired with our Principal Engineer to validate the approach..."

What action to include

1. Designing: product/architecture decisions, alternatives considered
2. Aligning: building concensus, stakeholder management, negotiation
3. Communicating: document, presentation, difficult conversations
4. Implementing: Technical execution, resource allocation, risk mitigation
5. Testing & Debugging: QA processes, problem diagnostics, optimisation
6. Releasing: deployment strategies, monitoring, post-launch support
7. Thinking & Deciding: cognitive work, analysis and strategic choices

Result

• Business impact: revenue, cost saving, efficiency
• User impact: reduced friction, new capabilities
• Team impact: velocity improvement

Quantify when possible

When you dont have metrics

• Compare before and after states
• Use qualitative feedback
• Reference time or effort
• Describe what became possible

Learning

• Go beyond the obvious
  • "Learning communication is important" is generic
  • Better: "I learned that when working with a remote team, i need to over-document decisions because hallway conversation dont happen"
• Be honest about mistakes
  • "I should have pushed back on scope early. I knew we couldn't hit the deadline with all those features but didnt want to be the person say no. I've since learned to raise timeline concerns the moment that I see them"

Adapt to the question

Emphasise the part that the question is asking for

Adapt to the audience

Watch for signs you're losing them

• Eyes glazing over
• Not asking follow-up questions on technical bits
• Seeming to wait for you to finish
• Unmuting themselves on the call or opening their mouth to try to speak
• Looking like they're thinking to form a question
• Stopping note taking
• Saying "yeah" or "hmm" frequently. This sounds like active listening in a normal conversation, but in an interview it probably signals they want to shift topics

Include only enough detail to establish credibility

Telling complex story

Long stories hard to deliver and hard to listen to. In this case, list your actions as a table of contents, so the listener know what is coming

For example:

1. This project happen in three phases: first getting alignment on the approach; second, the technical implementation and third roll out and measurement. Let me walk you through each

Or

• I contributed in four key ways: establishing the technical architecture, mentoring 2 junior engineers through the implementation, managing stakeholder expectations across three terms

Prepare for followup questions

"What would you do differently" — depth of understanding and awareness of mistakes. The "Learning" part in carl
"What was the hardest part?" — technical depth
"How did you measure success?" — the result part
"What happened after?" – Does project still have lasting impact, is it still running?