People have written about staff work properly before. Commonly cited read: On Staff Work. It explains the formal discipline and mechanics better than I can.

This is the first of three posts collecting my accumulated advice on staff work. This one is about thinking through the issue, communicating it upwards and making a recommendation.

About staff work

“That’s just, like, uh, your opinion, man.” - The Dude

In my opinion, great officers are good at the small, large, short and long stuff. They can frame a difficult issue, answer a two-line query, prepare a useful deck and still notice that the wrong annex was attached. They make decisions easier to reach. Where there is a genuine controversy, they make the disagreement, trade-offs and consequences apparent enough for somebody to decide.

Here are some of my questions, advice I received from former bosses and habits learnt through corrections that I accumulated over the years. This post is about thinking through the work, communicating it upwards and making it easier for somebody to decide.

Graduating this from being uploaded on various SG Teams channels to somewhere more permanent on my blog.

This is written mainly for officers doing the work. Middle managers need to know the same things because they have to guide the officers under their care.

Let’s go.

A. Before you begin

Start with the actual problem

Before opening Word or PowerPoint, ask:

• What problem are we tackling?
• Who experiences it?
• What is causing it?
• Who can do something about it?
• What would improvement look like?

Many papers begin with a solution because somebody already wants to build something, buy something, change a process, or reorganize a team. The problem statement then gets written backwards to justify the proposed answer.

A useful problem statement should help us distinguish between the options. If every possible solution seems to fit, the problem is probably still too broad or vague.

Work out where the levers are

A paper can describe a lot of pain and still say very little about what anybody can do.

Who owns the policy? Who controls the budget, process or system? Which parts sit within our authority? Which parts require somebody else to move?

This matters because “we need to work closely together to sort out xyz” is often what remains after a paper has described a problem without identifying any levers. Sometimes coordination really is required. Quite often, it is a way to avoid saying who needs to decide or change something.

Add something of your own

Don’t be a postbox! Please contribute. Don’t ask subject matter experts for input, compile everything, add some fluffy words, arrange it in a nice deck and call that your work.

Your contribution should appear in the judgement. Which input matter? Where do they conflict? Is an important perspective missing? Are people answering different versions of the question? What do you recommend after considering everything?

A neat submission helps people read the work. It cannot perform the analysis for you.

Keep real disagreements visible

Sometimes the input don’t reconcile well.

It used to be common practice to make sure EVERYONE agree before we send something to bosses. And it was really bad form to disagree in a high-level meeting because it came across as disorganized.

But no more! Maybe everyone woke up to this fake kumbaya to prioritize robust debates and understanding the broad range of perspectives.

So nowadays we must explain where the disagreement sits and why it matters to the decision. Two teams may be using different assumptions. The disagreement may concern the acceptable risk rather than the facts. Everybody may want the same outcome while disagreeing over who should bear the cost or operational burden.

Of course, you can still make a recommendation. The decision-maker definitely should be able to understand the strongest case against it and what turns on the final choice.

Context, context, context

Policies and earlier decisions are usually made by people in some set of circumstances that made sense. Like everything in the world, circumstances surely change. But the policies and requirements survive really long after.

Ask what problem the rule was meant to solve and whether the assumptions still hold. If the ground has changed, explain it clearly enough for the policy owner to reconsider the position.

Some decisions are current and deliberate. Others have simply been copied from one review to the next because everybody started from “no worse off” and nobody went back to ask why the original requirement existed.

Think one question ahead

Try to think a few questions ahead. Just enough to avoid answering the literal question while missing the actual issue.

If you say something is urgent, be ready to explain what happens if it is delayed. If a position is defensible, know the precedent and where it may be challenged. If you recommend an exception, consider what it does to future cases. If you say there is no disadvantage, check whether the affected person would agree.

Read your recommendation as the person approving it. Then read it again as the person who has to carry it out. They may care about different things.

Of course, your boss may still ask something you didn’t anticipate. That’s because we’re different people who think differently and have different concerns. But if the first twenty minutes of the meeting are spent discovering basic gaps in the proposal, we probably didn’t think far enough ahead.

On the flipside, going too far will give you the kiasu, jumpy, over-staffing moniker. So exercise your judgement.

B. Communicating upwards

A lot of the advice here sounds simple and duh. It still goes wrong legit very often. It applies whether you are speaking in a meeting, sending a Teams message, writing an email or briefing from a paper.

Point first, history later

Don’t make your boss listen to the whole chronology before finding out why you are speaking to them.

Officers often explain an issue in the order they discovered it:

Finance wrote to us last week. We then checked with Legal, and Legal asked for the earlier correspondence. We found the email from last year, but there were some differences…

At this point, the boss still doesn’t know whether the project is delayed, somebody made a mistake, or a decision is needed.

Start with the point instead:

We need to delay the submission by one week because Finance and Legal disagree on whether the earlier approval covers this expenditure. I think Legal’s reading is safer, but it means we need fresh approval.

Then explain the history that matters.

Many books and tik tok videos teach this, check out Bottom Line Up Front for a start. For me, the practical advice is: tell me the answer, issue or recommendation first, then give me the reasons in the order I need them.

Give just enough information

Resist the temptation to unload all information and your woes on your boss.

It’s difficult to assess the situation and proposal on hand when there’s a lot of noise. On the other hand, it’s inefficient when there’s too little info and a lot of back and forth has to be spent on clarifications and reframing the situation. Not to mention there’ll be blind spots when the boss has to keep asking questions, some important details might not get the scrutiny they deserve.

Include the information that could change the view. This could be a relevant precedent, uncertainty in the evidence, a trade-off that’s not obvious, or why the no-brainer alternative doesn’t work.

To be fair, “enough” varies by issue and by your boss(es). Some people want more detail than others. Adjust your approach and communication to the person.

Know more than you say

You should know the second and third levels of detail without unloading all of them at the start.

Senior, experienced people usually can skip the story you prepared and go directly to the number, assumption or dependency that worries them. Sometimes it’s called being sharp. Keep the supporting material in your folios, annexes or hidden slides.

If you don’t know, say you don’t know, don’t have the info on hand, and say you’ll check. Don’t make something up and smoke your way through. You’ll be surprised how often certain ideas or examples stick around, you don’t want to create a lasting trail or misinformation.

Recommend something, please

After explaining the issue, say what you think should happen.

An example of what not to do: An officer spends several days gathering the facts, tells the boss everything that happened, and ends with:

So what should we do?

Super annoying! My slightly uncharitable reaction is: if I am going to listen to everything, work out what it means and decide what you should recommend, then perhaps I should earn your pay too!

You can be unsure. One missing fact may change your view. The final decision may properly sit above your authority. You can still give an assessment.

For example:

I think we should allow the exception. The request falls outside criterion X, but we have granted comparable cases before and the disadvantage here is significant. If we want a stricter position from now on, I suggest applying it prospectively rather than starting with this case.

Your boss can agree, disagree or point out something you missed. At least you have done the first round of thinking.

Tell your boss what you need

A briefing can end with everybody generally agreeing, then nobody does anything because it was never clear whether a decision was made.

Say what you need. Is a specific thing for approval? Do you need a direction before doing more work? Are you asking your boss to intervene with somebody? Is this just a heads up because the issue may blow up?

Especially important to be clear when you’re presenting.

Say when the work is already moving

Where the work is underway, say so.

I am checking the figures with Finance.

That tells the reader you are already doing something about it. “I will check the figures with Finance” sounds like the work begins after you send the email.

The continuous tense should reflect reality, of course. If you have not started, perhaps start before sending the update… or you’ll learn a lesson that makes you do it in future.

C. Before it goes up

Before sending something forward, I usually ask:

• Does it reflect what is happening on the ground?
• Have we answered the actual problem?
• Is our judgement visible?
• Did we put the point first?
• Does the person have enough information without being flooded?
• Have we thought about the obvious next question?
• Is any real disagreement or disadvantage apparent?
• Is the recommendation clear?
• Did we say exactly what we need from the recipient?