Your mentee arrives with a draft already open. Their team spent four months on a migration that was cancelled the week before launch, and nobody has explained why. They have written fifteen hundred words about it for their blog, and they want to know if it is good. You read the first paragraph and feel two things at once. It is well written, and it is going to cause trouble.
Do not start with the trouble. Start with what is good in it, because there usually is something. Writing about real failure is valuable, and the industry has far too little of it. If you open with be careful, they will hear that the instinct itself is wrong, and it is not.
Then help them find out what the post is for. Ask them plainly. Is this to help other developers avoid the same mistake, or is it to finally say what nobody at work will listen to? Both are human. Only the first one makes a good public post. The second belongs in a conversation with their manager, or in a notebook, or with you.
Read it together as a stranger would. Could a reader work out which company this is? Could a colleague recognise themselves in the person who made the bad call? Would your mentee be comfortable if their manager read it tomorrow morning, or a hiring manager read it in three years? Writing lasts much longer than the feeling that produced it.
Ask them to check what their contract and the company's social media policy say. Many companies are fine with lessons learned and much less fine with internal details.
Often the best version is the same lesson with the story taken out. Not here is what my company did wrong, but here are four signs that a migration is in trouble, and what I would do earlier next time. That post helps far more people, and it is the one they will still be proud of later.
If they decide to publish anyway, that is their choice. Your job was to make sure it was a choice and not an impulse.
Suggest they wait a week before pressing the button. A post that is still worth writing in a week usually is.
– Asael Shinder
