The ROIs Method

I'd like to introduce a new framework for communicating. Its one that will help you prioritize the right points, and deliver your message in the most efficient way possible. 

Engineers, in particular, are bad at writing very narrative-driven chronologies. There's almost a bit of a joke that you can pinpoint where someone is in their career based on how they write their emails.

Junior-Seniors are all chronological. Let's call it the "This" method for communicating: "I was doing this... when this happened, and so it made me think this...so I looked into it, and found out this. I then took a deeper look, and found this has happened for this many months...Can I ask that you do this?"

It takes as a long time. The important bits end up getting lost in the paragraphs - it's cognitively overwhelming, and it makes the recipient's attention wander.

The first time you get a direct report, your communication style shifts. You see the errors in your ways. You hear them take the "This" method and silently think: Please get to the point...

And that then you think.... there might be a better way.

That's where my method comes in that I'd like to introduce. I call it "ROIs" - like return on investments - because if you take the ROIs method, it'll pay off. 

If you know the STAR Method for responding to interview questions, this framework should look familiar - but in the ROIs case it's best used when you're communicating up the chian or along the chain.

ROIs stands for: Request / Outcome / Informational, situation

Whether writing an email, or chatting: pick R, O or I. You're only allowed one.

Requests are when you're making an ask. This is perhaps the most important time to use this format because you want to explicitely make it known that you are asking for something - you don't want the fact that you need something from the recipient to be lost.

Outcomes are when you are sharing the result of something you were asked to look into. You are closing the loop on something. For example, your boss asked you to look into a set of reports to find how many times a query took more than 2 seconds to return. State the full context so it's clear what you are saying.

Informational is when no action or follow-up is needed. If you're sharing something informational, a good rule of thumb to ask yourself: is this communication even needed? If no action is needed, if you're not providing an outcome, and everything is business as usual, then is it necessary? Your impulse may be to say "Of course! They're interested in this topic and would want to remain informed..." So, ask yourself again: "If I inform them, will they then wonder: 'Why are they telling me this?'" It's not to say you should never inform - but you shuold be selective. You should also adjust based on the recipient - some prefer to be more informed than others. But keep in the back of your mind: if a tree falls in a forest, and no one needs to do anything about it, does it really matter?

Finally, the 's' is for situation - intentionally lower-case because it's the least important part (but we often mistake it for the most important). It provides context, it provides details - but if you lead with the situation, you lose the immediacy of action. You also make the assumption that details are always needed - which, truth is, they're not. Situation should be brief, point-form, and just the facts.

So instead of:

I was digging around some log files trying to troubleshoot a bug, and I noticed a negative value in the total's amount for an invoice. So I looked at the code, and realized there's certain cases where a null value is triggering our invoicing to causes the total value to goes negative. If the line item was added and then later removed, it gets nulled out and then when the a discount is applied it dips below zero. So then, what happens is we run the payment processing at the end of the day and in some cases we've actually cut a check to some customers. I think you may want to escalate and discuss with finance - we'll want to determine whether we ask for the money back (in some cases it's really high), or if we want to fix the bug and the cut loss. I've already created the bug ticket and ask that the team prioritize the fix for our next sprint, but we'll need an escalation if we want it done sooner.

Try:

Request: Ask finance to reverse incorrect payments >$500 to customers

Situation:

• A bug is causing negative invoices, and we're issuing payments.
• Incorrectly paid more than $2,000 - the bulk is $10, but 5 cases are $200 or more.
• We are in the process of resolving, with an ETA of 2 weeks.
• Further details will be covered in an RCA.

It's intentionally sparse on details. Leave details for the RCA. If more is needed, it will be asked for.

If you have multiple items, then enumerate them - but keep it simple:

Request:

1. Ask finance to reverse incorrect payments >$500 to customers
2. Call a few key customers directly to avoid churn
3. Write-off payments <$200 (90% of cases)

Situation:

• A bug is causing negative invoices, and we're issuing payments.
• Incorrectly paid more than $2,000 - the bulk is $10, but 5 cases are $200 or more.
• We are in the process of resolving, with an ETA of 2 weeks.
• Further details will be covered in an RCA.

If you're sharing an Outcome you'll likely provide enough context in your outcome statement, so your situation should only be additional info:

Outcome: The logs revealed we have 80 queries that take more than 2 seconds.

Situation:

• 5 queries are high-frequency, and account for 10% of our database load
• 12 are used moderately but can be easily optimized with indexing
• 63 of the queries are one-off large reports which we can ignore

You may sometimes realize that your Outcome can sometimes be turned into a Request - in which case, by all means do so:

Request: Prioritize 17 queries for optimization

Situation:

• The logs revealed we have 80 queries that take more than 2 seconds.
• 5 queries are high-frequency, and account for 10% of our database load
• 12 are used moderately but can be easily optimized with indexing
• 63 of the queries are one-off large reports which we can ignore

As I said earlier, Informing should only be used in rare cases and you should adjust and calibrate with the person you're communicating things to. An example of an inform could be when you've had an accomplishment that you want to share:

Informational: The team increased throughput by 80%!

Situation:

• In last month's retro we realized we were losing time waiting for PR reviews.
• We agreed to add an ETR (Estimated Time to Review) to our commits
• Turn-around time for PR reviews decreased by 125%!

Now, I know you're probably wondering: do we really need that much structure to our communication? It's almost annoyingly robotic, isn't it? While you don't need to be 100% structured every time I'd adjust based on the severity and urgency of the matter.

If things are on fire, and you need immediate attention, this format works really well. If everything is stable and you have an ask you can be more conversational while still sticking to the format:

Hey John, 

Can you ask Finance to share the invoices from the previous 8 months?

I was looking into some reporting discrepancies, and I want to make sure everything is adding up correctly. I don't have authorized access, and was told the request would have to come from you.

So unless you're writing a post, stop providing narratives and get right to the point!