How to send progress updates | Hacker News Reader

How to send progress updates

spakhm.com

140 pointsnoch29 comments

Mostly good advice but there’s one bit that made me frown a little.

“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.”

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.

How will this pattern become obvious (assuming you also comply with point 15)?

It's not good if people start expecting a catastrophe as soon as you say "we may have a slight hiccup"

People adjust and you would be forced to be more and more positive if you want to just sound neutral.

Yeah, I think he’s close to a good point of advice there, but misses it. Instead, it is better to bring up unpleasant surprises when they become a possibility (call it a “risk” if you want to sound all businessy). If you do that, then people will be less surprised when you tell them that it has happened

I've heard this referred to as "catroofing", though it's probably a very localized expression or I'm not remembering it correctly since I can't find any references online.

In any case there's a good origin story:

There’s an old joke about a guy who went away for a long trip and asked his brother to take care of his 16 year-old cat during his absence.

A week or so into the trip, the guy calls home to check in. He knows his cat is elderly and he’s concerned about it.

“How’s my cat?” he asks his brother.

“Your cat’s dead,” his brother tells him.

The guy is upset. “This is how you break it to me?” he asks. “This is how you give someone bad news? How insensitive can you be?”

His brother is, of course, sorry, but can’t help asking: “What was I supposed to say? The truth is the truth.”

“That may be,” the former cat-owning brother says, “but there’s a way to give someone bad news more thoughtfully. You should have psychologically prepared me for it.

“When I called, you could have said, ‘your cat was crawling on the roof of the house when he fell, and I took him to the veterinarian. And then, next week when I called, you could have said, ‘your cat’s not doing so well’. And then the third week, you could have gently broken the news. That’s all it would have taken. Just a little bit of kindness.”

“I’m really sorry,” the brother say. “I’ll do better next time.”

“It’s OK,” says the other brother. “I’m just upset. I really loved that cat. Anyway, let’s change the subject. How’s our grandmother?”

“Well,” the brother says, “she was crawling on the roof of the house …”

Ref: https://www.thenationalnews.com/opinion/first-tell-me-about-...

It could be that they're saying you should artificially hold back part of the news to ease the shock, which I don't agree with.

But there are situations where a problem unfolds gradually, the sort of thing where you become more and more aware and certain that something is going wrong. For example, when a schedule slips. It's possible they're talking about that kind of situation.

In that kind of situation, there's some threshold where it gets bad enough to let people know. But you could also give people a warning some time before that, i.e. have an additional threshold and an additional earlier communication. So maybe the advice is to go ahead and do that additional communication.

Strong agreement for that approach in the second case. I like a good yellow flag.

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:

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.

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.

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.

What the hell?

Being charitable to the author, the wording might’ve been like “our engineers aren’t familiar with this domain” or “we lack staff-level engineers”. I doubt they literally sent out an email saying their engineers don’t know anything. That’s probably also why the author specifies “accidentally or on purpose.”

> 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.)

Underrated advice!

This advice has nothing to do with progress updates. This is advice on how to do marketing spin to influence people on some topic.

The bullet point about technical competence kinda left us hanging - if this is what you don't do, what do you actually do?

Context matters here. This sounds like corporate advice ("managing up"), rather than startup advice.

"Add a little randomness to the cadence. People think they want regular cadence, but they’re happier with bounded irregularity."

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.

"Within reason, deliberately engineer pleasant surprises so you can include them in your updates."

No. Do not waste your time "deliberately engineering" anything in an effort to look good. Do your job.

"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."

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.

Otherwise, my impression is the author has not questioned his learnings. For example, his other article, https://www.spakhm.com/bullshit-ratio, 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.

Communicating status has always been a pain point for me. This article was wonderful and timely.

Slava's other essays are here, for those curious: https://www.defmacro.org/

I wonder how I could apply those tips on a daily software engineer scrum meeting.

If you find yourself in a Scrum project the best move is usually to quit and/or burn the place down

Maybe I'm the minority but I like the daily check-in, everyone talking about what they actually accomplished yesterday compared to what they want to accomplish today, having just 2-3 weeks of narrowly scoped work to think about, etc.

I think it can be a very good environment in which to train juniors and mid-level folks provided they are shielded from all the PM/lead/manager type meetings that tend to go along with it.

I mean, there is the whole scrum shebang (along with “scrum masters”, charts, etc.), which I had an “opportunity” to try multiple times before and hate with passion.

And then there is just a daily eng standup with no bs involved, which I like and found it useful if done properly (aka no going on off-tangent stories that have little relevancy for everyone else). We just join the meeting, all give status updates, ask any questions or talk about whatever is needed to be discussed to move forward, and that’s it.

Super useful, fairly informal, no time wasted. For a team of 4, those daily meetings would take us 15-20 minutes at the very most, and that’s accounting for questions/discussions. Often enough, they would be under 10 mins.

I have found the usefulness of the "standup" goes down hill as more non-engineering members are included. Some companies keep it engineers only. Other companies add every PM and tangentially involved manager, director, VP. More than half of my standup is full people not directly working on the project who are just there for visibility. It's insane.

And because of company culture, these mostly-observers are asked for and provide updates. Most of them are not relevant.

Agreed with your take, which is why i specified eng-only daily standups.

If we need non-eng people in a meeting on our team, it would not happen in a daily meeting (barring very rare one-offs). If there are as many non-eng people in a standup as you say, I dont see it being as anything but an excruciating exercise in patience.

Luckily for my team, we dont have a companywide rule on how daily standups should be held (or whether they should be held at all; on my previous team within the same company we did them every other day). So as long as the team manager is fine with the engineers on the team in terms of how they want to run daily standups, there is no problem.

I've found you can say just about whatever you want during a scrum meeting. Most people are tuned out and barely listening. Try repeating what you said yesterday. Odds are nobody will notice. If they do, they won't call you out on it anyway.

I often worry about repeating something when I'm working on the same exact thing for days but at some point realized that while I am actually listening to what other people are saying, I'm not internalizing it or taking notes or anything, and it'd probably take 3-4 days in a row of exactly the same update from someone for me to actually notice. And even then it'd probably be more just nonspecific deja vu rather than "oh they repeated that point about that one project."

Cancel your daily meeting and have a single weekly update meeting. Have each project’s lead write down what progress they made last week, risks, problems, wins, and what they’ll expect to do next week.

Spend the first 10m of the meeting silently reading these updates. Then have each lead verbally give a condensed summary of their update (DONT ALLOW them to read verbatim) with a focus on the information that everyone on the team really needs to know, especially problems and blockers. Make sure they do verbally say what their next incremental unit of progress will accomplish and when they expect to have it done.

You can do “people” instead of “projects” for smaller team.

Oh, and keep all the notes and updates in a single shared doc that you add to the top of each week.

Doesn't rule 15 violate rule 8?

Reply on news.ycombinator.com