Why do we keep having the same conversation after a project?
We finish a project, talk about what went well and what we would change, and write it all down. Everybody agrees that next time should be different.
Then the next project starts. We are busy, somebody needs something quickly, and we go back to the same way of working. A few weeks later, we are having a very familiar conversation.
This is one of the gaps I talk about when teaching people to develop their craft. By craft, I mean the way you approach your work: the perspective, judgment, and reasoning you bring into it and how you refine those things over time.
Reflection is part of that. But there is another step we have to make room for: actually using what we learned.
What will I do differently on the next project because of what this one taught me?
And then, just as importantly, what happened when I tried it?
Pretty much every team I’ve worked with uses a retrospective/reflection phase of some point… and then they put that list into a file never to be seen again.
How do I turn a lesson into something I can use?
Start with one recent project. It does not have to be a disaster and you do not need a formal team retrospective already done. An ordinary task that left you thinking, “There has to be a better way to do this,” will work just fine.
Write down one thing you noticed. What happened? What decision or assumption in your approach might have contributed to it?
The important part is getting specific enough that you can change something next time. “Communicate better” leaves you with a lot to figure out when you are busy. What information needed to be communicated? To whom? At what point would it have helped?
You want to leave yourself with an action you can recognize when the next opportunity comes around.
Also, be honest about your control. If the problem was that leadership repeatedly changed the deadline, you cannot solve that by promising to be more organized. You might be able to raise the consequences earlier or ask for a decision about scope. The organization still has a responsibility to address the conditions it creates.
What could this look like in an everyday project?
For a hypothetical example, imagine you taught your team how to produce a monthly report. You explained the process, shared the instructions, and answered questions. The session seemed to go pretty well.
But afterward, people kept asking how to get started.
You reflect and notice an assumption: because the explanation made sense to you, and nobody raised concerns, you assumed people could use it independently. You never actually saw anyone try.
(also… a good place to recognize the importance of power dynamics in the workforce and how likely people will stay quiet so they don’t come across as inadequate in front of you or their peers!)
So your change for the next session is specific. You will leave time for people to work through a sample report while you are there, so you can see where they get stuck. As an example perhaps.
Put that activity into the session plan now. Decide what you want to observe: can people begin the task and which step still needs clarification?
When you run the session, perhaps they get started easily but struggle with one judgment call. That gives you a more precise improvement to make in the instructions. Or perhaps the exercise reveals that they do not have access to the information they need. Then you have found a different problem to address.
Sometimes even just sitting down and working on something new as a team, lets people build momentum off of each other too.
Either way, you have used the lesson and learned something further from applying it.
How do I make sure I actually follow through?
Keep the change close to where you will do the work. Add it to the next project plan, the checklist you open before starting, or the meeting agenda where that decision belongs.
I would keep this small. Pick one change you can realistically try, and make a note to revisit it after the relevant part of the project.
You can capture the whole thing in a few lines:
- What did I notice in the last project?
- What will I change, and why?
- Where and when will I use that change?
- What will I look for to understand whether it helped?
- After trying it, what should I keep, adjust, or stop doing?
You do not have to wait until the entire project is over. If you changed how you run a kickoff, reflect after the kickoff while you can still remember what happened.
The other thing I would do is before you do another retrospective, always start by bringing in your previous retro and reflections. You start the exercise reviewing what, since your last retro, got addressed (or not).
What if the change works, or teaches me something unexpected?
Both give you something to work with. If the change helps, keep it available for similar situations. If it does not, explore why before turning it into another rule you follow automatically.
And do this with successes too! If something went particularly well, ask what you did that helped and whether you could bring that into another project intentionally.
Your approach is allowed to evolve. You can keep the parts that are useful, revise the parts that are not, and discover that something works under different conditions than you expected.
That is how experience becomes part of your craft: you carry something useful from one project into the next, and keep paying attention to what the work teaches you.
