
The Dreaded Weekly Status Email - ryanlm
http://eleganthack.com/the-dreaded-weekly-status-email/
======
leroy_masochist
My personal view of status emails is that they are largely an artifact of
engineering-driven companies in which managers, who must possess a given level
of engineering competence in order to have supervisory credibility, often have
very poor social skills.

To be clear, I'm all for pushing stats to the central org. Every week when I
was a company commander in the Marines, for example, we sent our battalion HQ
a big Excel sheet with a summary of who was on light duty, who was going on
leave, weapons count, etc -- that kind of basic accountability is fine to put
in a weekly email IMO.

What is not fine is abdicating your responsibility as a leader by living
within a Potemkin supervisory framework that reduces or even eliminates your
need to have daily face-to-face (or telephone/VTC) conversations with the
people you have the privilege of supervising in order to figure out what
challenges are in their way and what you and the larger organization can do to
help.

The straightforward way to do it is not weekly status emails, it's limiting
the number of direct reports anyone has to a reasonable number and holding
them accountable for everything their portion of the org does or fails to do.
They in turn should be holding their people to a high standard of not letting
bad news age and being forthright about what's not working.

~~~
emmett
Status emails are not a "Potemkin supervisory framework". They're a scalable
way of communicating progress broadly in a way that can be referenced later,
rather than an ephemeral way to communicate to one person.

~~~
leroy_masochist
That's kind of the point I was trying to make when I said that sending weekly
stats is valid. I'm not saying that status emails are implicitly bad, I'm
saying that they're poorly implemented.

The problem is that status emails containing substantive subjective summaries
of the challenges faced by the person writing them are often used by
incompetent managers as a replacement for constructive dialogue between them
and their direct reports. At least, this was the case at the two companies I
worked at that had a required status email as part of the weekly drumbeat. And
I've heard a fair amount of anecdotal evidence from friends at other places
that the problem is widespread.

~~~
mikeryan
Isn't that the whole point of the linked article?

~~~
leroy_masochist
Not really, I think the article is basically a how-to guide for good status
emails and what I am saying is that even if they're well implemented they can
be an impediment to effective management and intra-company communication.

------
robert_tweed
Funnily enough this format is nearly identical to what I call the "scrum
email" which is something I've previously asked remote freelancers to send in
daily and found it works as well if not better than actual stand-ups. That
list of things to put in a sitrep is one of the things that Scrum gets right:

\- Brief summary of what was done since last report

\- What's next

\- Any blockers

\- Anything else important (optional)

The only difference is the inclusion of OKRs/KPIs, which makes sense if you
are using them. I tend to do something similar with project status reports as
well, which will usually have red/amber/green in the subject line and if the
status isn't green, the email _starts_ with the reason!

~~~
douche
I love the idea of the standup. Getting a read on what everybody is doing is a
great idea. It's idiotic to do it as a synchronous operation that stops the
world and frigs up everybody's day, though. This is one of those things that
would take five minutes to think about, write up, and post to someplace public
first thing in the morning, after which you could dig in and actually get some
work done.

~~~
kornish
Stumbled across this Slackbot the other day which conducts a "standup"
asynchronously - the best of both worlds.

[https://geekbot.io/](https://geekbot.io/)

No affiliation, just seems like a cool product. Probably wouldn't be hard to
whip something similar up if it's not already on GitHub.

~~~
harlanlewis
My team adopted Geekbot as we transitioned from in-office to primarily remote.
We tried a handful of tricks and tools early on, with Geekbot the stickiest.
Spending 30 seconds submitting my report while getting up to speed each
morning is an easy routine. Nowadays, I prefer Geekbot to in-person standups
(and definitely don't miss the interminable ramble that they too easily fall
into).

I think you're right to wonder about alternatives, though. The aspects of
Geekbot we use would be fairly easy to replace with a bot of our own. Geekbot
pricing has a very narrow sweet spot, which I imagine varies significantly by
team.

------
cel1ne
> "List last week’s prioritized tasks, and if they were achieved."

In theory this sounds good, but that is an emotionally charged and negative
way of saying it. "Tell me what you promised to do and if you actually did
it." You would not use such a construct in a negotiation except to intimidate
the other.

In certain people, this destroys motivation, even when they didn't achieve a
prioritised task because they found a better way or reprioritised for good
reasons.

~~~
eric-hu
That's one way to interpret it. Here's another: be honest and open about what
you committed to.

If it was done, great. If it wasn't, do you understand why? Did you
underestimate? Did something block you? Was it deprioritized? How will this
not happen again, or why is it now okay?

If someone is less motivated by honest discussions about productivity, I'm not
sure they can improve their productivity and collaborate with others long
term.

~~~
dkrich
I don't understand the point of this. So the goal is to get better at
estimating? In my experience tasks vary in difficulty from one to the next,
and it's very difficult if not completely useless to formulate an estimate for
the time required to do it. The only time work estimates are useful, IMO, is
when you are estimating an exact fixed amount of labor which you have
completed under similar circumstances at least a few times.

I think if you badger employees about their estimates and not getting things
done that they promised, that will lead to those employees overestimating the
amount of time required, just to be sure that they don't end up not meeting
the estimated timeline. That seems like a net loss for productivity. Rather
than encouraging people to stretch themselves and get more done, you're
leading them to believe that it's much more important not to miss self-imposed
deadlines.

~~~
repeek
Sounds great in theory, but most companies need to have some level of
confidence of when things will get done and how much it will cost.

Estimating is important because it gives management the ability to deploy
resources strategically and manage expectations. Bad managers think estimates
are a promise/guarantee. Assuming the estimates were arrived at with as much
clarity as possible (planning poker), good managers understand that estimates
are a tool to aid decision-making.

~~~
engi_nerd
To support your point:

For many companies, having a defined degree of confidence in estimates is a
requirement of doing business. Any DoD contract in excess of $25 million USD,
for example, must be performed by a company with a DoD certified Earned Value
Management plan. You had better get your estimate process right there, because
you're held accountable for it.

~~~
dkrich
As a person who has worked for several years with two major government
contractors, several agencies, and countless projects, this is humorous to me,
because I have never, not once, seen a large project estimate end up anywhere
close to reality.

Typically the process is that the contractor has an internal pricing team that
figures out how much to bid on a contract. After the contractor wins the bid
(assuming fixed price), they then staff it with some combination of employees
with various rates to meet the bid cost. Then those employees write up a
detailed set of requirements (keep in mind that this occurs _after_ the bid
has been accepted), and then the project begins and things really get screwed
up. Life happens. People leave the company. Clients are waaaaaaaaaay slower
than anticipated taking care of required administrative work like approving
user access and granting PIV cards. Clients change their mind or didn't
account for several important considerations that may or may not involve huge
amounts of work.

So how do the companies remain profitable through all this? It's usually that
as the due date moves closer and closer, employees are expected to just work
more hours to account for the missed estimate.

This may come off as cynical, but the truth is that there is not a soul on
Earth who could accurately estimate how much time will be required on a
multiyear contract given how many variables are involved. So, I'm back to my
original point- estimates are largely worthless and a waste of time. Yes, they
are a means to an end, but are in no way a reliable indicator as to how much
time or effort is actually required to complete the work.

~~~
engi_nerd
I've never seen a large project be close to the original estimate, either. But
that doesn't stop the customer from thinking that estimate is what's going to
happen.

As an employee of a huge contractor myself, you aren't wrong.

The contracts people will always want to see the EVM plan. The contractor's
budget people will compare the estimate to prior actuals and somehow come up
with an estimate they think is good. And then you will run over, and the
government will try to hold you accountable, even though the causes of your
overruns may be requirements changes from the customers.

I apologize if my original post presented this rosy picture that estimates are
wonderful and always work. I guess some recent training came through a little
too much.

------
SmellTheGlove
I'm a director. I developed an easy test for whether my status reports
mattered. One week I simply stopped sending them. It was mentioned to me once,
about 3 months later, so I sent one that week. And then never again, for about
the past year at least. It's not like I didn't have weekly 1x1s with my boss,
in addition to our hallway conversations, so what we were doing was already
communicated.

The only time I asked members of my team to write them was when I needed
certain individuals to really think about their work and focus on what was
important vs low priority. We talked about it, but then I had them write
status each week for a while mostly to force them to stop and think about the
connection of their work to the larger business objectives. I really value
developers who have some level of business acumen and ability to understand
the "why" of their work at a more strategic level - and if someone doesn't
have that I'm going to coach it. That's just one way that works for some
people. More of a coaching tool than an actual status report, though.

~~~
overcast
First rule of email, no one is going to read your email. Keep it incredibly
short, I mean one line if you can. Then maybe a small percentage of recipients
might glance at it.

~~~
SmellTheGlove
If no one is going to read it, I'm not going to take the time to write and
send it. That's my first rule of email. I really don't like to do things for
appearances, and while I am professional I also do what I can to cut out the
things that truly don't need doing - for myself and for my teams. I'd like to
think I'm a good manager in that regard.

------
elgoog1212
Google has "snippets". You basically write up what you did last week. They
aren't mandatory, but encouraged. I have found them useful because I can then
just go through them and pick the things I want to write in my performance
review. Before I started keeping snippets, I had a hard time digging up a
sufficiently meaty list of accomplishments, because I'd just forget most of
them. And you can subscribe to other people's snippets as well.

------
philip1209
We have replaced our in-person team retros every week with LatticeHQ.com's
weekly check-ins, where every employee answers 4 basic questions (the defaults
on Lattice):

1\. What did you focus on this week?

2\. What are your plans and priorities for next week?

3\. What challenges or roadblocks do you need help with?

4\. Is there anything else on your mind you'd like to share?

Managers then can review and comment on each part of the check-in. That
happens the same day, which means that it doesn't feel like a waste of time.
Even just an emoji as a comment can provide positive feedback.

I like this process because it's efficient. I also enjoy a log of what I have
done in past weeks to reinforce that we are progressing. Lattice is primarily
a goal-tracking app, so tying goal updates to weekly check-ins makes the
process easier.

This works for us, but we're a small team. Weekly status emails sound like a
different beast relating to tiers of tiers of teams.

I suspect that part of the difficulty of the "weekly status email" is keeping
track of updates from memory. As the author describes the Zynga framework,
it's clear that it's easy because it asks for fairly objective things - like
OKRs. It sounds like scaling a solution like Lattice to larger companies would
ideally prepopulate reports with data - like "Closed these 7 goals . . . ,
closed these 8 pull requests . . . , analytics shows goal X did Y" \- then
allow the manager to edit and provide context.

~~~
prawn
I could see this being useful for families too. Third question could get
people help when they might be reluctant to ask about moving furniture or
getting time without kids to catch up on work, etc.

------
lawnchair_larry
I'm not sure what it is, or if it's justified, but I've always hated having to
explain what I'm doing and why. I think that I will involve people as needed
and when needed, and assume others will do the same. Most senior engineers
I've worked with have been this way.

Are there effective teams who don't do anything like this at all?

~~~
adrianratnapala
I often have this feeling -- but it is because it's impossible to explain a
mass of technical background to connect my current work to buisiness goals
(assuming there even is such a connection).

That's a process problem. Teams I was on with this problem needed to get
better at spreading such background knowledge (e.g. by having code review).

------
wiradikusuma
What's missing is a Concrete Example of the "status report that's enjoyable to
read because important information laid out in a digestible format." Sure, she
lists down the format, but would be great if she can put some samples.

~~~
op00to
I'd love to see what HN folks can come up with. Me, I'll just start spamming
my coworkers in IRC about what I want to get done in the morning.

------
cyphunk
This article and much of the conversation here-in reminds me of THX 1138.
There is a disconnect between how-to-manage and how-to-be-productive
discussions on HN. Definitely daily mails, and also probably weekly's with
intense liability attached to them in the name of "quality" seem to go against
promoting human _e_ productivity.

Perhaps there are projects that require this level of management and
communication, and perhaps there are people that work well with it. But there
are also probably many projects that do not need such management overhead and
where some types of people do not work very efficiently in. So, what I'm
saying is that I think this management style shouldn't be an assumed default.

~~~
clifanatic
My experience is that this works well in an IT infrastructure sort of
environment where you're assigned tickets that takes a couple of hours on the
average. It sort of works in a project-based product development effort where
programmers are implementing features and fixing bugs, but breaks down
horribly on anything that involves any sort of research and experimentation
(you know, the sorts of things that actually create breakthroughs and make
money?) And God forbid you ever try to learn anything new: "Yesterday: read 50
pages of the ElasticSearch manual. Today: read 50 more pages of the
ElasticSearch manual. Tomorrow: get fired for not having anything immediately
profitable to put on status report."

------
engi_nerd
At one job, our management asked us to write a status email to be sent in
every Friday afternoon by COB. After about six months, the management decided
that it couldn't be bothered to sift through 30 emails from engineers each
Friday afternoon. Therefore, they requested that we put our weekly status into
a single Word document stored on a Sharepoint site.

You can guess what happened next -- someone would check the document out of
Sharepoint, locking it for everyone else. Then that person would inevitably
get interrupted and go handle the latest crisis. Meanwhile everyone else was
unable to enter their status into the shared Word document.

Eventually management gave up and returned to having us send emails.

Fortunately I don't work there anymore.

~~~
pavel_lishin
> _After about six months, the management decided that it couldn 't be
> bothered to sift through 30 emails from engineers each Friday afternoon.
> Therefore, they requested that we put our weekly status into a single Word
> document stored on a Sharepoint site._

Would they have/did they bother to go through the Word document either? To me,
it seems like a fun new way to test a Markov chain generator.

~~~
engi_nerd
They didn't have us update the Word document in place -- meaning each status
didn't take the place of the previous week's status. So you can imagine that
the document quickly grew quite long. Managers started complaining that they
couldn't see what was happening quickly enough because they had to scroll too
much.

------
iamleppert
"Send me your status in an e-mail" is a way for a lazy, un-engaged manager to
dot his i's and cross his t's. If you're doing a good job managing your direct
reports, you'll have a good pulse of what they have been up to at a resolution
of at least one week, without being a micromanager.

~~~
vacri
What was your underling doing seven weeks ago? Thirteen weeks ago? Didn't they
mention a particular issue five weeks ago?

What about reviewing the data for long-term trends, rather than gut feelings?

------
swsieber
I actually liked the linked article about the art of OKR more. While I've been
exposed to SMART goals (Specific, Measurable, Actionable, Realistic,
Timeframe?) as a missionary, for some reason it didn't ever really carry over
into the real world.

I do feel like OKR has a fair amount in common with GTD as well, though I'm
not actually familiar enough with GTD to assert that, though from the outside
they are similar.

------
brlewis
I've been using 15five, which is a weekly report format with the usual
done/to-do/blockers questions, but every other week asks for suggestions to
make your team/role better. It sends reminders, tracks your longest streak of
completing reports, and has a public/private comment system with likes. This
is a referral link: [http://ssqt.co/m5blUWz](http://ssqt.co/m5blUWz)

------
pzh
It's much better to have a weekly status email than a daily standup. Status
emails can simply be scheduled with a cron job if one is not disposed to write
them in the accorded time...

~~~
infinite8s
How would you write it automatically? I suppose you could just have it pull
your commit messages for the past week, but that would be manifestly missing
the point, which is a quick high level summary of what was done and plan for
following week. Otherwise the reader of the status email could just pull the
commits directly.

------
bitshaker
At our remote company, we use [http://Jell.com](http://Jell.com) which was
built for this purpose.

------
PapaSlug
[https://home.idonethis.com/](https://home.idonethis.com/) for remote teams.

------
ktRolster
Trust your employees enough that as soon as something goes wrong, they will
let you know. Don't expect them to wait until the end of the week to alert you
of something, that makes no sense.

~~~
true_religion
In my experience, people find something is going wrong then enter a temporal
vortex where they only focus on fixing this problem. They will then emerge on
a Friday at 4:30pm, to tell everyone.

But joking aside, plans that rely on trusting everyone to act in a certain
unwritten way aren't very reliable. It's like how one study showed that
mistakes during surgery went down by a significant degree if doctors simply
compiled a checklist of what they were going to do beforehand---even if they
had done the procedure hundreds of times before.

People, in the middle of working on hard tasks are not very reliable. That's
not to say they're not smart, or professional, or lack care for their
coworkers. It's just a fact of human nature that we solve problems in whatever
organically directed way _makes sense at the time_ , and not what the 'best
over many averages' way would be.

~~~
ktRolster
_In my experience, people find something is going wrong then enter a temporal
vortex where they only focus on fixing this problem. They will then emerge on
a Friday at 4:30pm, to tell everyone._

If you're a manager, then the reason they do that is because you intimidate
them. They're afraid to tell you when something goes wrong. This is YOUR
problem.

 _plans that rely on trusting everyone to act in a certain unwritten way aren
't very reliable._

That's the only possible plan that can work, because you can't write
everything down. At some point you have to trust.

~~~
true_religion
If I were speaking as a manager, I would have already done something about the
issue.

But no, I'm talking about people that I have worked with, but not managed.

And these aren't 'dysfunctional' teams by any objective measure. These teams
were formed from reasonably competent individuals, typically turned in their
work on time, and had comfortable social dynamics.

Yet on the rare occasion that a problem cropped up.... ah we didn't always
take the best approach to problem solving.

\----

There's a story I heard about firefighters. They did a study on veterans to
find out how people operated under pressure. The researchers thought in the
face of a burning building, surely the fire-fighters wouldn't be able to do an
in depth search of all possible solutions, so they'd just compare the top-two
that they thought of.

Seems reasonable.

In reality, the they just went with the very _first_ solution that they didn't
imagine had fatal errors.

That's how people are... under pressure, we go with the first thing that might
possibly work, not the best thing. That's why we need to think about problem
solving techniques, before problems actually occur.

------
hga
For me, when handled well when working for a good boss, starting the week with
one was an excellent way of organizing that week. I'd remember, think about,
and memorialize what happened last week (and enough times there's a large
portion of "what happened" vs. "what I did", i.e. putting out fires), and then
planning what to do in the next 5-6 days (6 for crunch mode: 6 days x 7 hours
of real heads down work in each, which I could sustain for a number of weeks).

Sure, "No plan survives contact with the enemy", but I've always found the
_process_ of planning to be _invaluable_.

As others are noting, all this is very subject to abuse, but it _can_ be a
very good thing.

