Feedback is a Gift: How to use project retros to improve our work
A cadence of regularly looking back and planning forward is a gift to future you. Welcome to retros at Alpaca!
Happy Monday, Alpaca!
Do you remember our Post-Day 1 conversation in Nashville? Of course you do — it was a big moment of honesty and trust about work that was going better, but still wasn’t going quite the way we wanted. We listened, we offered ideas, and then we went out and made Day 2 amazing.
In a way, what you experienced there was a very informal, but high trust, project retrospective. And that’s what we’re talking about today — Project Retrospectives!
Going forward, we’re going to build a regular practice of Project Retrospectives at Alpaca — simple, brief conversations where the team that worked on something comes together to talk about what happened, what we learned, and what we want to do differently next time.
We’ll be starting with Event Retros this week, and Kimberly will be showing you a simple template for these at this week’s All Hands meeting. So before we jump into that today, let’s get everyone on the same page about what these are, and why we do them!
What is a project retrospective?
A project retrospective (retro!) is a regularly occurring meeting that happens at the completion of a project or event. The attendees should include all active project participants and all project stakeholders and decision-makers.
A retro should occur as quickly after the completion of a project as possible, so as to maximize learning while it’s fresh.
Why do a project retro?
The goal of a project retrospective is to get the participants of a project together to build a common understanding of the successes and challenges of that work, so that everyone can learn and improve upon the next one.
To be succinct: the goals of project retros are twofold:
Shared ownership of a project’s result and
Shared understanding of how to improve future performance.
A good retro is a high trust engagement
To accomplish these two primary goals, retros need to be high-trust engagements.
Everyone in the room should feel able to talk candidly about what went well, and tell the truth about what happened. And everyone means everyone.
That means:
No blame games.
No defensiveness.
No pretending everything went perfectly.
At the same time, this doesn’t mean retros are soft or vague. They should be honest, thoughtful conversations about real work.
There should be room for celebration. There should also be room for accountability. Trust is what allows both to exist at the same time.
Guidelines for a high trust retro
Creating an atmosphere of high trust isn’t about holding hands and doing trust falls.
A “high trust” retro should be a rigorous review of the project, with participants taking clear ownership for execution that needed improvement, and with stakeholders taking clear ownership for changes to scope or expectations. There should be room for celebration, as well as accountability; learning, as well as clear planning for future success.
Here are a few things that will help everyone take the best next step.
#1: Always do them, and use the same exact format every time.
One of the best ways to create trust is to ensure that everyone knows what they’re getting into every time they walk into a retro. So, starting this week, we will do a retro for every event we attend and use the exact same format every time (you’ll find our event retro format on Alpaca Notion in the link).
It’s important to not just do retros when the result is less-than-ideal. Doing retros only if we missed a goal would have two results:
People will be afraid when a retro is called; and
Successful projects will not get proper celebration and learning, which is demotivating for everyone.
When it comes to asking the same questions every time, some of those questions will feel difficult at your first retro. But if you set it up as “hey, so some of these are hard questions, but they’ll get easier every time!”, you’ll see trust in the process.
#2: Say what you said!
In a retro, make sure there’s no revisionist history — like “we said we’d launch these 3 features, not all 5 of them — those other two were nice-to-haves.”
Clearly say what you said you’d do, and on what timeline, and how you objectively performed against those commitments. Try these three discussion questions:
What exactly did we say we would do?
What are our results against those commitments and timelines?
Did we accomplish anything NOT on our list of commitments?
#3: We’ll celebrate and improve at the same time
A retro shouldn’t be divided into a “celebration section” and a “problem section.”
The real story of any project is always mixed.
Great teamwork might exist alongside a confusing timeline.
A strong launch might happen despite some messy coordination.
So instead of separating those things, we’ll talk about them together.
We want to notice:
Who helped make something difficult easier
What we’re proud of
What we’d approach differently next time
#4: Retros are about the work - not individual performance
Retrospectives focus on how the project unfolded, not on evaluating someone’s job performance.
If someone on the team needs a performance conversation, that should happen privately and directly — not in a group retro.
The retro is about understanding the system around the work:
priorities
communication
timelines
expectations
resources
When we improve those things, everyone does better work.
#5: Listening matters as much as talking
People who were deeply involved in the project will naturally have more context to share.
People who were less directly involved may have a different role — often to listen, ask thoughtful questions, and help the team reflect.
One way to think about it is a talk-to-listen ratio.
If you were close to the work, you’ll probably share more.
If you were more removed, listening is often the most valuable contribution.
Ready to try it yourself? Here’s how.
I encourage you to try out a retro for an event, product release, Alpaca resource set, a team event, or sales campaign soon. You don’t need permission - just give it a try. To get started on building a retro for a project you own, here are some frameworks and questions you can try:
Five Great Retro Frameworks
Start, Stop, Continue: A straightforward method asking what actions to begin, cease, or maintain.
4 Ls (Liked, Learned, Lacked, Longed For): Promotes nuance by exploring what team members enjoyed, discovered, missed, or desired.
Sailboat (Speedboat): Uses a metaphor to identify what propelled the team (wind), what slowed them down (anchors), and risks ahead (rocks/pirates).
Glad, Sad, Mad: Encourages emotional reflection by categorized feedback into what made the team happy, disappointed, or frustrated.
ORID (Objective, Reflective, Interpretive, Decisional): A structured approach for facilitators to guide the team from facts to decisions.
8 Questions for Retros
What problem were we trying to solve with this project?
Do you think we set the right goals with this project, why or why not?
What are you most proud of in this project?
What is one thing you wish you’d known before this project started?
Who is someone who helped you during a challenging part of this project?
What is one thing you’ll ALWAYS do on future projects, and one thing you’ll NEVER do on future projects?
What is a resource you wish we had to help our projects work better?
Active project participants, what do you need from stakeholders? Stakeholders, what do you need from project participants?
One last thing
Occasionally, we’ll want to step back and retro the retros. So if you’re participating in some over the coming weeks, think about these questions:
Are they helpful?
Are the questions useful?
Is the format working for the team?
If something could make them better, say so and let’s adjust!
Like everything else we build at Alpaca, the goal is steady improvement.
Every project is a chance to create something valuable, but it’s also a chance to learn together. Retrospectives are simply our way of making sure we don’t leave that learning on the table.
Let’s get out there this week, Alpaca! 🦙
KB