One thing I've noticed is that a lot of colleagues don't know how to give good situation reports. One common error, especially amongst engineers, is to start from first observations and work towards a conclusion. This is exactly how one should think about technical problems, but it's not a very effective way of communicating, especially when you're trying to relay information up a chain of command.
Here's how I learned to give a situation report during my brief stint in the armed forces:
1. "I am" (identify yourself & other parties involved; give location where appilcable)
2. "I see" (What is on your radar? What's the problem? What situation is developing? Which milestone have you reached?)
3. "I'm doing" (How are you responding to what you see?)
4. "I want" (How can your interlocutor help? What resources do you need?)
The mnemonic for this is rather funny: "I'm lost. I can't see shit. I'm doing fuck all. I want to go home."
I think it works rather well in civilian life, too: "I'm working on $FEATURE. I'm noticing that page load times have doubled. I'm caching the results to try to reduce that a bit. Could Bob have a look at the database indexes?"
This seems like good advice. This is pretty close to the "STAR" framework I've seen used(Situation, Task, Action, Result) - explain the context briefly, what you're doing, what you're doing to accomplish the thing you're trying to do, and what the end result of it all is.
> a lot of colleagues don't know how to give good situation reports.
Another thing that can help, both written and in face-to-face communication, is using the Inverted Pyramid. Let's say the person in your 1-1 has an emergency and you have to cut it short after 5 minutes. In those first 5 minutes you want to get the most important information across. In the next 10 minutes, you give supporting details, and in the final 15 you can geek-out on the nitty-gritty.
Beware of things that "work" in movies. I've been led astray by that too many times.
BTW, ever wonder why movies start out with an action sequence that often has little to do with the rest of the movie? It's to get your attention. Let's face it, you and I watch the first couple minutes of a movie to decide if we want to invest more time in it or click to the next Netflix movie. (Do we care who the director is? Nope.)
Mnemonics almost always imply an order. My point is the order is backwards, even though people naturally assume that the first step is introducing oneself. They naturally assume that their name is the most important thing because it is the most important thing to them.
But for other people, one's name is the least important thing, because of course what it most important to them is what affects them.
Once one realizes this principle, you'll see it in action everywhere.
Who is involved in what tends to be very high on the list of important parameters.
To your point, though, you'd of course tailor this to your audience. For example: you might say "marketing" or "the engineering team" instead of "Tom, Dick and Harry".
Agreed. I think your counterpart is too focused on the person's _name_ rather than the contextual _role_ that the person occupies.
If someone is coming to me with a question, it is extremely helpful to know up front who they are (with respect to their role, not so much their name) in order to immediately start narrowing down the relevant contextual parameters that will be framing my understanding of their problem and my response. I don't want to read a wall of text while thinking of how to respond from an engineering perspective, only to discover at the end that the person lacks technical aptitude.
Agree. But in my experience, you have to bring the ask/need/most important detail to the first line.
1. Greeting, of course
2. The ask or most important detail, standing on its own line. (The exec can rapidly say yes or offer feedback if they agree on the face of it, or read on for more detail.)
3. Then do the I see, I'm doing, I want, etc in more detail.
I think execs managing a tremendous workload appreciate if you can invert to this "thesis first before anything else" style—it took me a while to learn this, and I also appreciate it when partner teams who send stuff to me for review follow this style. I think boils down to time management, triage, and giving rapid yes/nos, but you still need to show your work, but if you make your email harder to action it'll get delayed in processing or even forgotten.
I think we're in agreement. To be clear, there is no expectation that these items arrive in any particular order. What is important is that they all be present. Ordering is situation-dependent.
So to your point, yes, this is typically how I would write an email. In fact, the "I am" part of an email is often adequately covered by the 'From' address.
On the radio, in contrast, I would explicitly say something like "This is four-two, actual" before proceeding with the rest.
I like the analogy of math proofs. It isn't an account of the discovery process; no reader of a math journal is after an account of the author's inspiration and thought process, save that for your bio. The proof is the finished product of all that work.
Execs only care about the proof. They're not asking out of curiosity.
I volunteer as a CERT (community emergency responder, green helmets) and this is how we're trained to relay information to the incident commander. It's been eye opening to see how much you can do with just a weekend of training. And how it fits into everyday life.
Summarizing up-front is hard because it works the opposite of how many peoples’ brain works; if you don’t have a summary drafted, one good way is to run through everything verbally and then summarize at the end. This also plays into the natural narrative-creating tendencies.
So it’s good to recognize that this is a cognitive habit and it might require practicing a different approach, or preparation.
Another military term I’ve heard for written comms is “Bottom Line Up Front” (BLUF) which translates to a proactive TLDR. Similarly, this is a very useful tool for helping people consume your written comms; it allows readers to figure out if the content is something they need to deeply engage with or skim, rather than forcing them to skim the whole thing to figure that out for themselves.
The common theme here is that there is lots of value in providing a concise summary, so that recipients have to do the minimum amount of work to extract the first level of detail of information. This allows the first level of detail to travel further in the org and means the org is going to be better equipped to make good decisions.
And if your email includes an ask of any sort from the recipient, be sure to make the ask in the very first line (and summarize it in the subject line).
Then spend the rest of the email with the details around the ask.
Here's how I learned to give a situation report during my brief stint in the armed forces:
1. "I am" (identify yourself & other parties involved; give location where appilcable)
2. "I see" (What is on your radar? What's the problem? What situation is developing? Which milestone have you reached?)
3. "I'm doing" (How are you responding to what you see?)
4. "I want" (How can your interlocutor help? What resources do you need?)
The mnemonic for this is rather funny: "I'm lost. I can't see shit. I'm doing fuck all. I want to go home."
I think it works rather well in civilian life, too: "I'm working on $FEATURE. I'm noticing that page load times have doubled. I'm caching the results to try to reduce that a bit. Could Bob have a look at the database indexes?"