Mostly good advice but there’s one bit that made me frown a little.<p>“Second, deliver negative news in 2-3 escalating phases. For example, start by softly expressing the possibility of a problem to give people time to adjust. The next time, state the problem as fact.”<p>Your audience is (hopefully) smart. This pattern will be obvious by the third time you use it and you’ll lose trust because it’ll seem like you’re trying to cushion the bad news.
This is generally good advice with depth, but I would add a disclaimer: organizational practices and idioms should be taken into account. A few examples where these points would need some adjustment in my org:<p>We're not crazy about irregular cadences for project update communications. Why? Because there are many projects of complex size and shape going on. The stakeholders of my project care about many of those other projects as well, and they plan their schedules expecting to consume your update at that time.<p>Another case how we operate: the unpleasant surprise. Don't sugarcoat it, and bring things to attention as soon as possible. Rip the bandaid off, as we say.<p>As for tone and content, we focus on the purpose and delivery on that purpose. This is established early in the project, and our stakeholders understand both before the project ever takes off. We anchor our updates on those aspects, as it gives stakeholders an understanding of progress, no matter what the project update includes.
> 8. Don’t insult anyone, accidentally or on purpose. I once wrote an update that said something along the lines of “our engineers don’t know anything and therefore can’t ship, we need better engineers”, and sent it to everyone including the engineers themselves. It was factually true, but crude and unnecessary. Don’t do this.<p>What the hell?
> 10. Many people (correctly) worry they’re being personally evaluated by their updates, so they sanitize every sentence to death. Don’t do this. Make it all about the work, not about you, and leave the evaluating to others. (I visualize myself in a third-person view physically separate from the work, and pretend my character is writing the update.)<p>Underrated advice!
"Add a little randomness to the cadence. People think they want regular cadence, but they’re happier with bounded irregularity."<p>No. I get periodic updates from my staff, and I receive periodic internal communications. "A little randomness to the cadence" would add nothing. Would a little randomness to a weekly magazine add something - Tuesday one week, Thursday the next? Would a little randomness to the quarterly earnings call - three interceding months one time, four months the next - add anything? No.<p>"Within reason, deliberately engineer pleasant surprises so you can include them in your updates."<p>No. Do not waste your time "deliberately engineering" anything in an effort to look good. Do your job.<p>"For example, start by softly expressing the possibility of a problem to give people time to adjust. The next time, state the problem as fact."<p>So you're saying there is a problem, but first just "express the possibility" of a problem? That is, lie? No.
Like others said, the good advice here is mixed in with not-so-good advice and maybe even bad advice. I think if he stated his confidence on each point, I can calibrate my trust better.<p>Otherwise, my impression is the author has not questioned his learnings. For example, his other article, <a href="https://www.spakhm.com/bullshit-ratio" rel="nofollow">https://www.spakhm.com/bullshit-ratio</a>, basically re-describes "cost/benefit" as "bullshit/commit", which could have worked for him, but seems too specific, if not unrealistic, to apply elsewhere. I would have expected more research or review (from others) prior to posting to a wide audience.
Slava's other essays are here, for those curious: <a href="https://www.defmacro.org/" rel="nofollow">https://www.defmacro.org/</a>