Not that long ago, I’d written about how I write an internal newsletter at work, as part of a wider piece on how to make sure that you’re being visible. This week’s post extracts a couple of the ideas that I’d recently been writing about internally and makes them suitable for a general audience.
The core theme of this article is around getting straight to the point. That phrasing can sound somewhat harsh, but it’s really important when people that you work with are busy, which is pretty much everyone, all of the time.
In a world of continual context-switching and distraction, if you’re able to make it as easy as possible for others to understand what you want, what the next steps are, and whether or not you have a strong preference, then you’ll find that your interactions are far, far better.
Let’s dig into those things a little deeper.
Make it clear up front what you want
Yes, it’s obvious. However, it’s surprising just how bad we can be at this. When interacting, make it crystal clear what you want from the other person.
Ideally, within the opening seconds of an interaction—written or verbal—the other person should know exactly what you want.
For example, something like:
- Can you review my pull request? You’ve written the code that I’m changing, and I want to make sure there’s no intended side-effects.
- We’ve written a design document which outlines two approaches, and we’re not sure which one to pick. Are you able to give us your opinion on them?
- I’m completely stuck trying to understand this code. Are you able to pair with me on it today?
You can read those messages and immediately understand what the person wants.
Sometimes when people talk to busy people—especially those that are senior—they make their messages increasingly long, formal, and difficult to parse.
I’m not sure whether this behaviour occurs because some people feel like they need to justify exactly why they’re asking something before they ask it, or because they’re worried about coming across too direct (or both), but it results in messages that are far too long and hard to comprehend—the inverse of the original intention.
What this fundamentally means is that the busy person is not going to read it immediately, or perhaps not even read it at all.
Here’s the thing: you and this other person are working together. You might not be on the same team, but you’re at the same company and you both want it to be successful.
You aren’t asking a family member or a friend for a favour, nor do you have to convince them that they should care. Just by proxy of working together, you’re on the same team and working towards the same goals. There’s no need to write an essay to persuade them.
The same is true of group meetings, especially presentations. For example, if you’re reviewing a project, you don’t need to give the backstory of the company and the team and the last project before you get to the actual review of the new functionality.
Start with the part that needs reviewed, and work backwards if more detail is needed. If you’re able to get the review done immediately that way because consensus already exists—then great—everyone can go and do something else, and you’ve just saved the company a lot of money.
Make the next steps obvious
Being clear isn’t always enough, as you should also make it clear exactly what you want the other person to do.
What is it that you want?
Is it a yes or no answer, an opinion, or an emoji reaction? Do you need someone to put aside some time to read a longer document and then give their recommendation on what should be done? Do you need just a few trivial lines of a pull request reviewed, or is it a large and risky system change?
If you’re able to frame what is needed from the other person up front, then they are better able to think about how to spend their time and triage their tasks.
For example, if it really is a trivial change, then they’ll perhaps take a look at it when they next have a break. If they know that you want to make a risky change, then they can put aside some proper focus time to spend on it.
For example, you could say:
- Can you review this pull request? It’s only a 3 line change and it adds some more telemetry around data fetches. We’d like to have this merged to collect data overnight.
- We’ve made three suggestions at the top of this document about how to proceed. Are you able to check them and tell me whether you agree? If not, what do you think we should change?
If the other person knows exactly what you’re after, they’re far more likely to prioritise it and take action. You’re making it so much easier for them.
If you already have a recommendation, say it
Often we come to each other to seek an opinion or some ratification. But if you already have a recommendation, say it up front.
You know what it’s like when you read a document or a message that doesn’t offer any kind of recommendation. As a new reader, especially one with less deep context, you can just come away feeling confused and wondering whether the other person doesn’t know which path to take.
Sometimes folks deploy an anti-pattern where they will already have a recommendation in their head, but they will get the other person to read their workings out to see if they then come to the same conclusion (“Yes, I knew I was right!”).
However, this is cruel and a waste of the other person’s effort. If you’ve already thought about a problem for a long time and come to a conclusion, then say it.
This primes the reader with a viewpoint that they can then interrogate, which is a much better use of their time, and allows them to prune their decision tree.
Sometimes you may be worried about revealing your recommendation because you might be afraid of being wrong in front of somebody else. But in fact, including it is a kind thing to do. If you’re unsure of your recommendation, then just say that you are.
But make sure you say it.
- The design document goes through a few different approaches. We’ve picked the approach we prefer at the top of the document along with our reasoning. Are you able to take a look and see if you agree? If you don’t, we’d love to hear why.
- We’re concerned that the current milestones are too big and the complexity might balloon out of control. We’ve recommended some smaller milestones in this document. Can we get your approval? The overall work is the same, it’s just in smaller chunks.
- We have an approach to fix the bug that was raised earlier, and the best way to show you was to raise a draft PR. Can you take a look and see if you agree with the approach? If so, we’ll tidy up the code and add some more tests.
This is especially potent in decision meetings of any kind. Always say up front what your recommendation is. It will transform the meeting.
I have had so many senior stakeholder review meetings in my career that spend 45 minutes building up the narrative, and then finally get to the decision point that requires discussion with no time to spare. Then, everything is rushed, the meeting overruns and nothing gets decided.
Instead, you have to flip this on its head.
In decision meetings, start with the proposed decision point, then open up the discussion and the others can go deeper if they need to.
- We’re proposing to build a new API endpoint to accept edits to dashboards. It will mean that users can overwrite their data, and we will store a log of changes so they can be reverted if needed.
- Our current data ingest speed is lagging behind real time and it will only get slower with time. We are proposing to sample events in the short term, and begin rewriting part of the pipeline in Spark, which we think may take around 3 months.
If you lead a meeting with your recommendation, then the real discussion can begin, and you’ll get what you want, quicker and easier.
Get straight to the point
Make other people know exactly what you want and get straight to the point. It’s the best way of being respectful of someone else’s time.
You should always:
- Make it clear up front what you want.
- Make the next steps obvious.
- If you have a recommendation, say it up front.
Try and wrap all of your interactions with this whenever you can. Chat messages, emails and meetings can all improve by orders of magnitude. That decision meeting might take 10 minutes instead of 2 hours.
You’ll be surprised how much faster you can get things done.