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.
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.
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.
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.
Interrupting me with daily face-to-face/telephone conversations would just make me quit. I prefer to communicate by email (or rather by async chat e.g. Slack). If there's something you need to hear I'll tell you that; credit me with that much professionalism.
I think async comms are fine. I even think that talking with some people predominantly over email rather than face-to-face is OK in some cases; what is not OK is reducing the manager-direct report feedback cycle to a fill-in-the-blank framework that, for the person filling it out, often becomes an exercise in instilling the impression that one is creating value.
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!
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.
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.
We use this aty company, even though we're a small team of 6. We have enough people working from home that it helps keep us in sync every day.
There are a few others to try. I don't think any has a distinct advantage, just varying levels of polish. But I would recommend using it, especially for (semi-)remote teams.
We have something similar internally as well. Everyone messages the IRC bot their yesterday + today + blockers, and it sends out an email midday to the team. Much more efficient.
I started cooperating with external freelancers recently, and after 2-3 weeks of less-than-perfect communication, decided for GeekBot as well. I'm curious how will it play out in the long run, because first results are pretty promising.
This is very cool! We use HipChat (migrating to Slack soon) and Assembla (which has a standup module). We have coded a bot which checks who has not added their standup in Assembla and reminds them on HipChat.
I feel like the point of a stand-up isn't just to get people to say what they're doing, it's to get everyone else to listen. That's why it should be as tight as possible, to ensure people stay engaged.
If you replace the standup with written reports, I doubt anyone but the manager will actually read them. I know I wouldn't, regardless of how valuable it seems in the abstract.
Standups, when done with discipline, bring in a lot of insight and prove helpful for everybody in the team. I use Assembla at work which offers a standup module, which asks the three customary questions. My problem is getting my team to regularly fill those up. I have personally reminded them several times. I have created an automated bot which checks who hasn't added a standup for the day and reminds them on HipChat. Despite that, people just don't do it with regularity. I should think this is a common enough problem that most teams/organisations face. I'm interested in what they use to tackle it.
Daily, repeated form-filling is hard for creatives. Never heard of Assembla but if you were my manager and you were repeatedly needling me to fill out some form, every day, when I'd rather just give you a few words over chat (or in person)... I would most definitely push back.
I understand what you mean. However, if you personally have to ask every individual every day 1) what they did, 2) what they will do next, 3) and what impediments they have, and you can't get them to do it without your having to ask (in my experience, they'd do it for a few days, slow down, and then stop again), the more efficient way seems to me is to automate it.
Of course, in my case, I didn't wake up on the first day and put this in place. I spent a few months trying to get people to send in their standups every day, but realised that I can't possibly do it everyday with an expanding team and it didn't make for the best use of my time. Because filling in your standup is a quick part (quick because it shouldn't take you longer than five to ten minutes to fill it up) of the process that needs to be followed, the most efficient alternative was to create a bot to remind those who can't remember to do. Plus, the number one reason I got from people who failed to do it was that they simply forgot.
Is it really micro-managing? Isn't it the point of standups in Scrum, to find out what an individual in a team has been working on and what issues they are facing in order to make more efficient use of their time and skills as well as to clear impediments in their way? The end goal is to improve the team's performance.
If I was telling them what to do, what results to expect _and_ how to do it, then I would be micro-managing.
Ideally, what people are doing should be obvious, if they are actually doing work. Check-in messages, issue tracker activity, etc, gives a more real picture of what is actually happening than the copy-pasted no-information answers presented through stand-ups generally.
Don't Lumbergh your way through it - "So, Peter, what's happening? Aahh, now, are you going to go ahead and have those TPS reports for us this afternoon?"
Micromanaging includes closely observing, and not just controlling, an employee.
If the point of standups in scrum are to find out what an individual has been working on, every day, then this could feel like micromanaging to some people.
That is an interesting observation. For me, closely observing would translate to nagging individuals several times a day about what they are doing as well as how they are doing something.
The end goal of standups, the way I understand it, is to figure out what people in your team are doing and what they are stuck at in order to:
* align people towards individual goals in the sprint that require collaboration;
* remove impediments that are beyond the control of team members and that may cause delays;
* improve task and load distribution, so that some members aren't overburdened while others are slacking off (if you run a short sprint and give team member autonomy to work, tasks that require collaboration from several team members can tend to become bottlenecks, as I have experienced).
I suppose you could well call it micro-managing if these standups were used to manage individuals instead of the process. In my view however, standups help you gather data to manage and improve the process, so as to make things favourable for the team.
I'm very much in agreement with the other posts that you can get most-if-not-all of this information by keeping your ears to the ground (listen to your team's chatter) and paying attention to activity notifications.
If you have to closely observe or repeatedly needle your team for information, something is wrong. Programmers are largely introverts doing high-focus activities; we need to be left alone.
We (as in my team) don't strictly follow formal practice, though we have standups and I try to follow LEAN. Our git server sends email notifications with each push and I find these are wonderful for peering into what other people on my team are up to.
Have the bot revoke access to the things people do instead. Reset LDAP credentials or something. As long as it's a very quick and easy process to get access restored.
I manage two small (5 people) teams where everybody works remotely, and we have daily "stand-ups" using hangouts. They usually last just 10 minutes, and I find them very useful not just because of the info sharing, but because they help getting better team cohesion - which is difficult with remote work. They're well worth the small disruption of development activities.
Theoretically stand-up was supposed to be a quick activity taking no more than 15 minutes of your day, and on average taking less than 5 minutes. Teams were supposed to be small, and people were only supposed to talk for about 30 seconds unless there were quick questions to be answered.
That's why it was called stand-up, in order to emphasise that you stand while doing it so the meeting simply can't be long since everyone is psychologically incentivised to get to the point so we can all go to break room, sit down and work, or get coffee.
Of course it didn't work out that way in many places, and now 'stand-up' is a 1 hour long daily meeting complete with minute notes, rules of proceedings, and slide-shows.
Why the hell don't more people do this? I sit on lengthy stand-ups where people gripe or lecture with no expected resolution, meanwhile all I have to say is "business as usual" and I don't need anyone else's status, and could skim over updates in a few seconds, and even catch up with them later if need be.
I'm not a big fan of standups. I should be able to glance at the plan/burndown chart/backlog/whatever and know everything I need to know: Which tasks were finished lately? Which tasks are in progress? Who is working on which task? Which tasks are blocked? What is our goal for the next week/2 weeks? How close are we to meeting that goal?
If you don't have a tool or an easy to update document that shows this at a glance, then you have a problem. If you are asking people to give you all this information and then trying to collate it, then you have a problem. If people are not very simply causing this information to be visible as part of their normal workflow, then you have a problem.
Meetings are not the solution to any of these problems. What meeting are good for is: Human contact. People often find that if they don't interact directly with someone that the other person might have important information that isn't being shared. The longer the time between contact, the more that irrational feeling grows. Not everybody feels that way. I don't and it took me years before I realised that it is hugely important for other people.
The best thing I can say is that, if you don't have a short meeting where people can fist-bump, eventually someone on your team is likely to go crazy and cause huge problems. Usually that person is your manager, as it turns out.
My advice is to treat any substantive conversation in standup as being something to be fixed. You don't want that. You want people to show up, complain about how boring standup is and disappear. Every time you find important information showing up in standup, ask yourself how it could have been shared more easily as a normal part of the work flow. Keep working at it and eventually standup will be all fist-bump and no content.
If the people don't take the meeting seriously, you'll never hear anything either way, so you'll never know whether there is something you should be hearing about or not.
You know what perpetuates people not taking the meeting seriously? Having a 10 minute meeting every day just for fist-bumps.
Thanks for posting this. This is the best perspective & concrete advice on DSU I've seen. I'm not a big fan of going through the motions, but understanding why we go through the motions changes my outlook.
Agreed. Hearing about the minutiae about someone's task is tedious. To me the daily scrum is like getting home and asking your significant other "how was work today?". Boring question, boring answer.
I definitely prefer the asynchronous approach. That way if I don't care about what you're working on (or vice versa), we don't need to waste time standing in a room together.
My take is that if the work other people are doing isn't interesting, you shouldn't be at the same meeting.
If you can't learn from what they're saying, don't need to know it, and can't contribute, then you shouldn't be there. This is why we use feature crews as a subset of the team.
It's not that I'm not interested. It's just that I respect their time too much to interrupt their important work for the selfish purpose of satisfying my curiosity. I'll have a chance to ask them casually when the time is right, or if I am dying to know, I'll take a look at their check-in messages.
If part of my work depends on theirs, or requires specific coordination, I'll use whatever mutually agreeable medium to exchange the information that is needed.
I've never really felt like I didn't know what people on the team were working on, despite not having a daily meeting or weekly status.
I don't get the blockers thing either. If I'm blocked, you're getting an email or IM immediately. I'm not going to wait until the weekly status email, or even the next day, to tell you. And I'm not going to bother the people who can't do anything about it.
If you spoke more openly about what you did, maybe briefly about any challenges you faced, someone may ask you about that. They may realize you solved a problem they were having. Maybe your team lead would be able to notice, "oh, you were struggling with that? So was your other teammate, you two should talk!"
But understand the hesitation. And if someone is blocked, agreed, it should result in a quick email or IM. Of course, if you spent all day yesterday trying to figure something out but are just feeling kind of stuck, standup call is a great place to say, "hmmm, I can keep working on this, but if someone has some time, I could sure use a second brain to help."
I find standup useful exactly because it's synchronous. It's like a checkpoint, and keeps the project running smoothly, with everyone's goals aligned, nobody blocked, etc.
(We work in teams of 4-6 and standup is never more than 10 minutes. I've also had the "30-minute standup" which not really a standup...)
Sync standup are for teams that lack the self discipline for async. Every team i have been in starts sync and switches to async when the most senior or fearless person decides to stop carving out sync time
OKRs generally last a quarter (or a month) and are higher level than tasks. So weekly is a good timing but referencing them daily is overkill. OTOH if you do scrum type status, weekly isn't frequent enough. So in practice, "virtual" stand-ups and OKR inspired status emails are often distinct.
> "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.
It doesn't sound good to me, even in theory. If I'm becoming aware of what is or is not getting done on my teams via an email once weekly, I'm really not doing my job. I should have a general sense of where things are at a more granular level than that, and be able to synthesize that information through the regular communications of my teams so as to not impose administrative burden (which takes time away from their work). Assuming I'm doing that, I can be the one that writes about it if someone else really wants that from me. That's part of my managerial responsibility to keep shitwork away from my folks.
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.
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.
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.
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.
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.
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.
Even for experienced people, being off by a factor of 2 or 3 appears to fairly normal. That means, the correct answer to "How will this not happen again?" is to say that it will happen again, and that that isn't preventable. At least, no one seems to have succeeded at preventing it.
My experience has been that the only questions management should bother with are usually the issues that managers can actually fix. That tends to be a surprisingly limited set of things.
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.
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.
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.
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.
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.
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.
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?
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).
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.
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 humane 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.
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."
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.
> 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.
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.
"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.
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.
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
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...
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.
Everywhere I've worked has made up for it by demanding both a weekly status e-mail and a daily standup (and a daily status e-mail and a twice-a-year performance review).
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.
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.
Apparently the real takeaway from the checklist research was that other people, usually lower status employees like nurses knew that the doctor was about to amputate the wrong leg or whatever, but the dysfunctional working relationships made it very hard for them to point out idiotic mistakes being made by the big shots without endangering their careers.
The checklist is only there as a public contract that "if I don't do X, then anyone who points that out is doing the right thing".
This is both more frightening, and more insightful, than the "people forget to do stuff" lesson (though that is true too).
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.
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.
There's also a potential cultural issue, where someone may feel like asking for help, or pointing out an obstacle, but thinks it may reflect poorly on them.
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.
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.