Hacker News new | ask | show | jobs
by derefr 4808 days ago
> but that everyone knows everyone else heard it.

How about simply having a company policy that everyone should MVCC their decisions based on received email "transactions"? I.e., if someone sends out an email, then everyone else MUST (in the RFC sense of MUST) read it and digest it before making any new decisions. It still operates asynchronously--you can finish whatever you were head-down working on before checking your email--but you have to check it before you move on to whatever comes after that.

Or, in more cynical terms: fire everyone who ignores these emails until the problem corrects itself.

2 comments

The problem to correct itself is all this bullshit TPS reporting hidden behind fancy new buzzwords and "methodologies".

My rule is: if something affects my work, put it in my TODO list. If I am a Devops engineer, reading emails or standing up in a circle (jerk) pretending to listen carefully and understand what designer X, mobile developer Y and product manager Z did the day before or plan to do today is a waste of my time and theirs.

Why are you in a stand up with people whose work doesn't affect yours? That's fundamentally not right. I think you're ascribing problems to daily standups that are more to do with your specific organisation.
No it's not. Because frequently, the things which are blocking you could be easily fixed by them changing something simple in their workflow, and vice versa.

Even just a heads up that something important is coming down the line can save you hours or days of work "Oh, I thought you were cc'ed in on that email..."

Now you have 50 status emails and 100 responses to those emails (and 50 responses to those responses...) that you MUST!!1! read and digest each day.

Plus other people have already made (bad) decisions and started working on stuff that (negatively) affects you because you were busy "head-down working".

These are the problems that stand ups are supposed to help fix.

It sounds like the problem there is that you have a "team" with 50 people on it. You don't need to know things that don't affect you; if everything affects you, your organization doesn't know how to compartmentalize its architecture.
Well, sure - every team starts with 10 people or so, but in pathological organisations you'll get a lot more people who need to give status reports, particularly around crunch time...