4 ms·
Pretty good guidance, could be extended with a step 8 and 9. Step 8: emails that shouldn't be emails. For example, asking for a status update, whilst you have
by fleddr 4y ago
Pretty good guidance, could be extended with a step 8 and 9.
Step 8: emails that shouldn't be emails. For example, asking for a status update, whilst you have a status management system already in place. Complicated cross-department discussions being handled over email. And so on.
Step 9: optimizing the content of emails. Making sure they are relevant and actionable, indicate priority, give suitable context.
Personally, I find meeting optimization way more important though. Meetings destroy productivity. Even if you're a non-leader and have 3 or so meetings in a day, you have very little uninterrupted time, and the time blocks in between you'll probably spent on emails and chat or recovering from the meeting.
I find it puzzling how lax corporate management is in allowing every employee's calendar to fill up with meetings. Or maybe it's not that puzzling as they're often the source of the problem :)
- steveBK123 4y agoPeople need to learn the BLUF form of email. Further - management, who demands KPIs/dashboards/etc, should learn to actually use them rather than pinging people for status. The other death loop I've gotten in with new(er) managers is that they want "a weekly status report" and are very (VERY) fussy about the content, however they 1) never show you an example "good" one (assuming they must send one to their manager.. or not?) and 2) just iterate painfully over months&months where the only feedback is re: more tweaks to the format of the report (mostly in the negative form of dislike, rather than pointing in the direction of what they want) Usually this incentivizes me to send fewer and terser status reports & focus on delivery. If no report format is ever good enough.. why waste time on it vs just getting tasks done that will make users happy... which is ultimately what drives compensation in the mid/long term.
- mxuribe 4y agoHi @steveBK123 , would you kindly define briefly what the "BLUF form of email" is? I don't think I have ever heard of that.
- teddyh 4y agohttps://en.wikipedia.org/wiki/BLUF_(communication) https://en.wikipedia.org/wiki/BLUF_(communication)
- mxuribe 4y agoAh, thanks!
- steveBK123 4y agohttps://en.wikipedia.org/wiki/BLUF_(communication) https://en.wikipedia.org/wiki/BLUF_(communication) Bottom Line Up Front Lead with the summary (conclusions/recommendations, decision) OR statement in a single sentence what action are asking the recipient Then you can follow with supporting details at increasing levels of granularity It inverts the usual structure because most people feel compelled to give background, discuss options, offer costs-benefits, go into detail, etc .. all before coming to a conclusion/request about 75% down the email.
- mxuribe 4y agoAh ok, I'm familiar with this approach. But never knew it had an actual name. Thanks!
- fleddr 4y agoWhen you think about this more deeply, a well working status system is an existential threat to several layers of management. If all you do is collect metrics and reports to aggregate them upwards, the value added is minimal. Maybe there remains some value in exception management (risks, roadblocks)? Barely so in my experience. Because managers in tech have no clue what they're managing. So this is again just a report which next the team should resolve on their own.
- steveBK123 4y agoYes, but to be fair to managers in tech - no one else around them knows what they are doing either. Tech managers tend to have to wear too many hats filling in gaps in the product/project/program management layers and do some random assortment of people management & technical leadership.. depending on which firm/team and day of week. For non-tech companies, you'll often see a lot of non-technical stuff happening in the technical management hierarchy. At a high level all they care about is process, and at a low level all they care about is if a stakeholder is screaming right now. Nowhere in between do they care about what is actually being delivered. And by process I mean things like firm-wide cookie cutter agile mandates, all-hands calls, OGSM, OKR, etc. The last two shops I worked, the CTO spent a lots of time talking to investors about Cybersecurity/Resiliency/Cloud strategies, which are more attributes of a well engineered system, rather than a deliverable product. You wouldn't believe how many annual/quarterly CTO hosted events I've attended where either a Navy SEAL or Astronaut was the keynote speaker, lol.