Staff Work, Part 2: The Small Stuff Is Still Part of Staff Work

22 Jul 2026 / 13 min read
Staff work

This is the second of three posts on staff work. The first covers thinking through the issue and communicating upwards. This one is about producing the actual package: papers, emails, slides and records.

The small stuff is still part of staff work

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.

This post is about the actual package: papers, emails, slides, writing, records and the final checks before you send it.

Let’s begin.

A. Papers and submissions

Put the inconvenient stuff in the main paper

If a fact, uncertainty or trade-off could change the decision, put it in the main paper. Don’t hide it in Annex H because it makes the recommendation less tidy.

Background calculations, detailed correspondence and material that helps only when somebody wants to go deeper can sit elsewhere. The main paper should still tell the reader why the preferred option may fail, what disadvantage it creates and what assumption the recommendation depends on.

Nobody should discover on page 38 that the whole proposal works only if an untested assumption turns out to be true.

Same thing applies for slides, don’t bury small points in font size 12 in a fourth level indentation, when it’s a super important point. See the Columbia tragedy.

Use a cover note when the paper is hard to start with

A short cover note or executive summary helps when a submission is long, has moved through several levels, or changed a lot since the last version.

Tell the reader why it’s coming up now, what changed, what you recommend and where the difficult part is. Don’t produce a mini copy of the whole submission. The cover note is there to help the reader enter the paper at the right place.

Write the approval paragraph literally

If you need approval, state exactly what you want approved.

DS(P)‘s approval is sought for:

(a) the proposed six-month extension;

(b) the additional funding of $X; and

(c) the revised implementation date of Y.

People may copy the paragraph straight into the minutes or decision record. “Approval is sought for the proposed approach” is too vague if the approach contains several separate commitments.

I highly discourage (though I sometimes get lazy and do it) seeking approval for Para 5. Paragraphs often have multiple ideas and possible things to approve, so for the sake of clarity just always state clearly what the decision being sought is.

Be clear what kind of response you want

“Approval”, “information”, “endorsement” usually cover most situations.

Clearance is technically not really a thing, although I use it for the intermediate levels before final approval and most bosses know what it means. Different offices have their preferences. The important bit is that the recipient knows whether they are expected to decide, support, or just be aware.

B. Emails and clearance

Make the subject line do some work

A useful subject line should show the next person in the clearance chain, the final approving authority, any deadline and the actual subject.

For example:

<For DD> [For PS' Approval by 18 Jul] ABC Pilot Proposal

If the paper is going to a forum, include that too:

<For DD> [For PS' approval, pls] ABC Pilot Proposal (for ABC Forum on 22 Jul)

“For approval pls” and “Update” become useless once the inbox contains several thousand emails with the same title.

Give PAs a complete request

When asking a PA for a meeting slot, say how long you need, what the meeting is about, who will attend, the venue and whether the meeting has already been approved. Add any timing constraint that genuinely matters.

Please be polite. A little goes a long way.

Say whether materials are coming

If there are materials for the meeting, say when they will be sent. If there are no materials, say that too.

Otherwise, the PA or meeting owner spends the next few days wondering whether something is late, then chases everybody the day before. Then nobody goes into the meeting prepared and we’re all wasting our time.

Learn the local house style

Different departments and bosses have different preferences. Learn the standard used by the people receiving the work instead of importing every convention from your previous posting.

This may cover:

  • whether to use official designations or names
  • paragraph numbering and indentation
  • how submissions are signed off
  • whether footnotes are acceptable in an email submission
  • font, size and spacing
  • date and time formats
  • abbreviations and how the clearance chain is shown
  • whether we use annexes in slides

Some of these are genuine language rules. Others are just local practice. There is no point fighting a holy war over Calibri 12 when the department has already decided what it uses.

Sign off submissions properly

Use the “prepared by” style or sign as the officer submitting the paper, depending on the house practice.

A formal submission usually doesn’t end in “Regards” followed by “Thanks boss”. Again, check what the office does before announcing that your former department’s format is the one true way.

(Then again, over the years it feels like this isn’t such a big thing anymore. And while I dislike it, it’s not something I’d throw a fit about so I usually let it slide.)

C. Slides

Slides are part of staff work. A nice-looking deck helps, although weak thinking still shows. A poor deck can definitely bury a useful argument.

Start with four questions

A few former bosses gave me versions of the same test. Every paper and presentation should cover:

  1. What problem are we faced with?
  2. What is causing it and how do we know?
  3. What would success look like?
  4. How will we solve it?

Too many decks begin at number four. We get timelines, workstreams and organisation charts before the room has agreed on the problem or what outcome we are trying to achieve.

These don’t need to become four literal slides. They should be somewhere in the argument.

Move from the big picture towards the detail

I usually think about the flow roughly like this:

  • Context
  • Principles/objectives
  • Problem
  • Research/Data
  • Solution
  • Trade-offs/assessment
  • Implementation/timelines

This is not a template to follow blindly. Sometimes the audience already knows the frame. Sometimes you need to begin with the immediate decision. The point is to avoid throwing people into a detailed plan before they know what they are looking at.

Make the title say something

“Scope”, “Background”, “Assessment” and “Implementation plan” tell the audience what category the slide belongs to. They don’t tell anybody what the slide says.

Try something like:

Current approval process adds six weeks without changing the risk

The body should contain the figures, reasoning or examples that support that point.

That said, adjust if your bosses have a preference. Some people like conventional section headers. Even then, the actual message should be obvious somewhere on the slide.

Read only the titles

Read the slide titles from beginning to end without looking at the bodies. You should still be able to follow the broad argument and see where the decision sits.

If the titles read like a table of contents, the deck may be organised by topic instead of by argument.

Every slide, so what?

Ask what the audience knows after seeing each slide that they didn’t know before.

Does the slide establish the problem? Does it compare the options properly? Is it there because somebody spent two days making it and now cannot bear to delete it?

A slide can contain accurate information and still contribute almost nothing to the discussion.

Every visual, why?

Do the same for every diagram, picture, table and chart.

Sometimes a sentence is clearer. Sometimes the visual is useful but belongs in the backup slides. The amount of effort already spent making it is not a reason to keep it in the main deck.

Try ten slides or fewer

One former boss used ten slides or fewer as a constraint for an elevator pitch. It forces you to work out the key messages before adding all the supporting material.

The number is not sacred (cmon the first and the ending already waste 2 slides). Once the basic argument works, add the detailed slides that the actual forum needs.

Ten slides doesn’t mean you know only ten slides

A shorter deck should still sit on top of much deeper knowledge.

You should know the supporting detail behind the figures, assumptions and recommendations. Senior people often skip the flow you prepared and ask directly about the one thing they care about, so keep backup slides or notes where they are useful.

How I usually explain a slide

I often use this rough sequence:

  1. Point.
  2. Elaboration.
  3. Example.
  4. Return to the point.

It doesn’t need to sound mechanical. It just stops me from reading every bullet, wandering around the slide and forgetting why the audience is looking at it.

Orient people before explaining the visual

This is a presentation tip. Before discussing a complicated table or diagram, tell people how to read it. What do the rows and columns represent? Where should they look? What pattern matters?

Give them a few seconds. Presenters sometimes start explaining the conclusion while half the room is still trying to find the correct box.

Watch the room

Body language tells you when people are lost, unconvinced, distracted or ready for you to move on. You don’t have to follow the prepared script when the room is clearly somewhere else.

Check the screens beforehand

Multi-screen arrangements create very stupid problems. The presenter may be looking at the laptop, the chair at another screen and half the audience at an older version of the deck.

Check what appears where before the meeting starts. I’ve seen people give a perfectly competent briefing while pointing at something that nobody else could see.

D. Writing and records

Use short sentences, but don’t write like a telegram

The full stop is your friend. A sentence carrying several separate ideas can usually be divided.

This doesn’t mean every sentence must be five words long. That becomes staccato and strange. Vary the length, keep related thoughts together, and don’t make the reader untangle the grammar before considering the substance.

Bold only what matters

Some departments like key sentences bolded in submissions. That can help, but once half the paper is bold, none of it stands out.

“First”, “Second” and “Third” are also perfectly fine when there is an actual sequence. There is no prize for hiding a list inside decorative prose.

Use simple tenses and active voice where possible

Simple past and present tenses describe almost everything well. Use it together with the active voice to say clearly who should do and own what.

SD(XXX) had said that it had been a case of…

Sentences like this make the reader work out the timeline before understanding the point. Use past tense for what happened and present tense for facts that remain true.

Check out digital.gov for a treatment of the subject, it’s applicable for everything, not just digital stuff.

Keep ROD verbs plain

For records of discussion and minutes, “said”, “replied” and “questioned” cover most situations. “Added” is usually fine.

To be clear, this is a super common thing in minutes I’ve seen, and it’s so common many bosses even vet/edit flowery language.

Truth be told, there is rarely a need to rotate through “highlighted”, “opined”, “queried”, “offered”, “shared” and “noted” just for variety. These words can also change the meaning slightly.

RODs are records, not creative writing.

A record is not a transcript

Capture what mattered to the discussion and decision. Correct factual errors, remove side chatter and leave out material that adds nothing. In practice, stuff that’s wrong get said all the time. You’ll need to decide if you omit it or add an afternote alongside the record to clarify the fact.

Use the ordinary word

Complex words rarely improve a submission. Use ordinary words even in formal papers. They are easier to read and force the writer to be very clear about the meaning to be conveyed.

My language peeves

Some of these are rules. Some are preferences.

  • Use “with regard to”, or just “about”. Don’t use “with regards to”.
  • Use “reply” instead of “revert” when you mean reply.
  • “The committee comprises five members.” It doesn’t “comprise of” five members.
  • “Apprise” means inform. “Appraise” means assess. Please don’t appraise Minister when you meant to apprise Minister.
  • You leverage something. You don’t “leverage on” it.
  • You can tap a person’s skills, but you don’t “tap on their skills”, because that means hitting something gently.
  • “I shared X with the meeting” means you told the meeting. “I shared X” means you distributed it.
  • I generally treat “input” and “money” as mass nouns in formal writing. Other people differ.
  • The “that” in “said that” can often be removed. Some people still prefer to keep it.
  • “Please kindly be informed” is too polite. Please stop.

Consistency stuff

Use one term for the same thing throughout the document. The same goes for abbreviations, acronyms, dates and times. Don’t switch between “Singaporean information landscape” and “Singapore information landscape”, or between 1900hrs and 7pm, halfway through.

Be clear when an organisation takes “the” before its name. If an abbreviation needs a possessive, put it after the closing bracket, for example Committee to Strengthen National Service (CSNS)‘s recommendation.

Use full words in formal submissions and emails to bosses. Keep “pls”, “pse”, “tks”, “don’t” and “shouldn’t” for informal messages.

E. Before sending

Read it backwards

For important work, read the document backwards sentence by sentence. It interrupts the flow and makes missing words, repeated phrases and odd sentences easier to see.

When you read normally, your brain is very helpful and fills in what you intended to write.

Try using Pair too. But be warned, Pair is far weaker than the commercial chatbots ChatGPT/Claude/Gemini. It’s weak at longer contexts and it misses much more stuff.

Leave it and come back

Take a short break or return a few hours later where time allows. You will see things that were invisible after staring at the same paper for half a day.

Even ten minutes spent doing something else can help for urgent work.

Check the actual package

Proofreading the source document is only part of the job. Before sending, check:

  • Is the correct version attached?
  • Are all the annexes there, in the right order?
  • Are the addressees and CC list correct?
  • Is the classification correct?
  • Do the page numbers and cross-references work?
  • Are the dates, abbreviations and meeting details consistent?
  • Did the PDF conversion break anything?
  • Are comments and tracked changes handled properly?
  • Does the chart legend say what you think it says?
  • Did you open the attachment from the draft email and check that exact file?

I’ve proofread the correct file and attached the wrong one before. The recipient doesn’t care which copy you checked.

— END OF POST —
© Zixian Chen