Reader situation
You’ve learned something useful at work: a process that worked, a mistake you won’t repeat, a better way to handle a common problem. It could help others, but your experience is tied to a specific team, company and moment. Sharing it in a way others can use takes some thought.
Central idea
Work experience becomes shared knowledge when you explain what happened and why it may matter elsewhere. Describe the situation, your reasoning and the observed result, then identify the conditions that limit its application.
Practical steps
- Situation. Describe the context briefly: your role, the type of organization, the problem and what was at stake. Readers need enough to judge whether their own situation is similar. Keep it to a few sentences and leave out names and details that could identify your employer or colleagues.
- Include what made the problem hard. A lesson about a simple problem rarely needs sharing. The difficulty, such as limited budget, competing priorities or a skeptical team, is often what makes the lesson relevant to others.
- Action and reasoning. Explain what you did and, just as importantly, why. “We moved weekly reporting to a shared dashboard” is a fact. “We moved it because managers were spending hours compiling reports no one read” is a lesson others can use, because it explains the reasoning they can test against their own situation. If you considered alternatives, mention them briefly. Knowing why you rejected an option can be as useful to others as knowing what you chose.
- Observed result. Describe what happened, as accurately as you can. Distinguish between what you observed and what you believe caused it. “Report preparation time dropped, and managers said they had more time for their teams” is an observation. “The dashboard improved management quality” is an interpretation. If results were mixed or unclear, say so. Mixed results are often the most useful to share.
- If you can’t share exact figures, describe direction and scale in general terms. Don’t invent precision.
- Contextual limits. Name the conditions that made the approach work, or might stop it working elsewhere. Team size, budget, culture, leadership support, regulation and timing all matter. “This worked in a team of 20 with a manager who championed it. I’m not sure it would survive in a larger organization without that support.” Limits make the lesson more credible, not less.
- Application question. End with a question that helps others apply or test the lesson: “If you’ve tried something similar in a larger organization, what was different?” This turns your experience into the start of a discussion. Replies from people in different settings often refine the lesson, showing where it holds and where it needs adjusting. Come back to the thread and acknowledge what you’ve learned from them.
Worked example
Fictional example
Clara, a project manager at an engineering consultancy, shares a lesson in a Circle for project leaders:
Situation: I manage projects at a 60-person engineering consultancy. Our weekly status meetings had grown to 90 minutes, and most people only needed five minutes of it.
Action and reasoning: We replaced the meeting with written updates on Monday and a 20-minute call on Tuesday only for issues that needed discussion. We chose this because the meeting was mostly information sharing, which works better in writing.
Observed result: Most weeks, the Tuesday call now lasts 15 to 20 minutes. Some team members said they felt less connected, so we added a monthly in-person session.
Contextual limits: Our team was already used to writing detailed notes. Teams that rarely write things down might find the change harder. It also depended on people reading updates, which took a few weeks to become a habit.
Question: Has anyone made a similar change in a team that prefers to talk things through? What helped?
Clara’s post is useful because it doesn’t present the change as a universal answer. Readers can see why it worked for her team, what it cost and where it might not fit. Two members reply with their own experience, and one explains that a similar change failed in her team because updates were too long to read.
Boundaries
- Remove details that could identify clients, colleagues or confidential projects.
- Describe your own part accurately. If a lesson came from a team effort, say so.
- Get permission before sharing a lesson that involves another person’s work or decisions.
- A lesson from one situation is a starting point, not a rule. Present it as experience, not as best practice.
One action to try with a professional peer
Write up one lesson from your recent work using the five steps. Ask a colleague in a different organization whether it would apply to them and why.
Discussion prompt
What’s a lesson from your work that you’ve seen apply in some places but not others?
