How do you recognise someone for sharing knowledge?

Point at what it prevented. A runbook is worth the incident somebody else could handle without waking its author; a document is worth the questions that stopped arriving. Praising it as well written says nothing about whether it worked.

Why do people stop sharing what they know?

Because it is slower for them every time and the benefit lands on somebody else. Showing a colleague how to do something takes longer than doing it, and if nobody notices the difference the rational choice is to just do it.

Is documentation worth recognising?

It is one of the most useful things anyone on a team does and one of the least thanked, because the payoff arrives later and lands on people who were not there when it was written.

How do you recognise the person who answers everyone’s questions?

Count it. “You have answered every question in that channel this quarter, usually within ten minutes” makes a workload visible that appears on no plan and in no review.

What kind of knowledge sharing is most undervalued?

Writing down what did not work. People document the solution and discard the four approaches that failed, which are the expensive part and the bit that saves the next person a fortnight.

Recognition messages

Recognising Knowledge Sharing: 10 Message Examples

Knowledge sharing costs the person doing it and pays everybody else, which is exactly the shape of contribution that goes unrewarded.

The economics are backwards

Showing somebody how to do something takes longer than doing it. Writing the runbook takes an afternoon that produces nothing shippable. Answering the same question for the fourth time is slower than the first three.

Every one of those costs the person doing it and pays the team. Without somebody naming it, the individual incentive points the other way.

Measure it by absence

A good document is worth the interruptions that stopped arriving. A runbook is worth the incident its author slept through.

None of that shows up anywhere, which is why the message has to say it out loud.

10 messages you can send

Thank you for the architecture doc. Three people have been onboarded on it and none of them had to interrupt you.
Manager, on documentation
Measures the doc by the interruptions it prevented.
You answered the same routing question from four different people this month with the same patience each time. I noticed the fourth one.
Peer, on patience
The detail about the fourth is what makes it real.
Thanks for the lunch session on the payment flow. Half of engineering understands it now and previously two of us did.
Manager, on teaching
A before and after, stated plainly.
Sofia wrote the runbook that meant somebody else could handle the incident she was not on call for.
Manager, on runbooks
Names the exact situation the work was for.
Thank you for recording the walkthrough. I have sent it to four people and will send it to four more.
Peer, on reusable work
Quantifies reuse, which is the whole value.
You keep saying “let me show you rather than do it for you”, which is slower for you every single time.
Peer, on teaching over doing
Names the cost of the better choice.
Thanks for documenting the thing you learned the hard way, including the part where it did not work. That saved me the same fortnight.
Peer, on honest documentation
Credits recording a failure, which most people omit.
Ravi has answered every question in #engineering-help this quarter, usually within ten minutes, on top of his own work.
Manager, sustained effort
Counts a pattern nobody was tracking.
Thank you for the comment explaining why, not what. I understood the code fine and I had no idea why it existed.
Peer, on code comments
A precise distinction that engineers will recognise.
You turned your own confusion into the FAQ everyone now uses. The usual thing is to get past your own confusion and forget it.
Manager, on generalising
Contrasts with the default behaviour without disparaging anyone.

What makes one land

Measure it by what stopped happening. A document is worth the interruptions it prevented, not its word count.
Thank the patience separately. Explaining something for the fourth time is a different act from explaining it once.
Recognise recorded failures. Documentation that says “we tried this and it did not work” saves more time than documentation of the happy path.
Say it publicly. Knowledge sharing costs the sharer and benefits everyone else, so it needs a public payoff or it stops.
Watch for the person who is always answering. Being the team’s search engine is a real workload and it appears on no plan.

Questions people ask

How do you recognise someone for sharing knowledge?: Point at what it prevented. A runbook is worth the incident somebody else could handle without waking its author; a document is worth the questions that stopped arriving. Praising it as well written says nothing about whether it worked.
Why do people stop sharing what they know?: Because it is slower for them every time and the benefit lands on somebody else. Showing a colleague how to do something takes longer than doing it, and if nobody notices the difference the rational choice is to just do it.
Is documentation worth recognising?: It is one of the most useful things anyone on a team does and one of the least thanked, because the payoff arrives later and lands on people who were not there when it was written.
How do you recognise the person who answers everyone’s questions?: Count it. “You have answered every question in that channel this quarter, usually within ten minutes” makes a workload visible that appears on no plan and in no review.
What kind of knowledge sharing is most undervalued?: Writing down what did not work. People document the solution and discard the four approaches that failed, which are the expensive part and the bit that saves the next person a fortnight.