The answer should not require an excavation
Turning business priorities into messages people can understand—and act on.

- Role
- Senior Communications Consultant
- Organisation
- 20,000+ employees
- Work
- All-hands and hackathon reports, colleague interviews
- Also
- Learning and development, pulse research
- Platforms
- SharePoint, Teams, Adison, an in-house publishing tool
At Microsoft (via partner), I wanted communication to help people get on with their work. This sounds like a modest ambition until you have tried to establish whether a message is an announcement, an instruction or something everyone is expected to understand by Thursday.
I kept returning to a few practical questions. Could an engineer find the current answer? Understand why a decision had been made? Tell whether a response was required?
If not, publishing another update was unlikely to improve matters. There was already an update. There were, in some cases, several candidates.
Respecting attention meant doing more of the work
I asked communicators to provide context, explain the reason and make the next step explicit. If no action was required, I wanted that to be clear too. People should not have to read a message twice to discover that neither reading had been necessary.
For me, respecting engineers’ attention meant more than keeping things short.
A brief message could still leave someone searching for the background, checking whether a decision applied to them or trying to locate the policy to which it referred with such touching confidence.
I worked to make current information easier to find and use. I did not want employees piecing together company policy from a conversation history, like historians working with an unusually enthusiastic archive.
The editorial task was usefulness: doing enough work before publication that the reader had less to do afterwards.
The meeting ended. The communication did not.
I published reports from the organisation’s hybrid all-hands, along with hackathon reports and other event updates.
With all-hands reporting, I wanted to carry the substance beyond the meeting: what had been discussed, why it mattered and what people needed to know afterwards. Being unable to attend should not have meant depending on a colleague’s recollection, especially one beginning, “I think the main thing was…”
Hackathons offered another kind of story. I wanted to make the work visible beyond the people who had participated—to give others a way into what colleagues were exploring and building.
An event report could establish that something had happened. I wanted mine to explain why someone who had not been there might care.
That distinction mattered to me. The calendar already knew the event had taken place.
Behind the job title
Some of the work I cared about most involved interviewing colleagues.
I wanted to know them better: to get beyond the title and the approved description of the work to something more particular about the person doing it.
The purpose was recognition, both personal and professional. I wanted people to feel seen, their contributions to be understood and their experiences to offer something to others.
That required more than attaching “passionate” to a job description and allowing everyone to return to their day.
I looked for the details that made a story belong to that person. What drew them to the work? What did they want others to understand about it? What might encourage a colleague reading their story?
I wanted recognition to have enough substance that the person recognised could recognise themselves.
The platforms were not the point
I worked across SharePoint, Teams, Adison and an in-house publishing tool.
Each was a means of reaching people. None relieved me of the obligation to make the information worth reaching.
I cared about where something lived, how someone would find it and whether they could tell what to do once they arrived. A piece was not useful merely because it had been published successfully. That was an achievement for the publishing tool.
My work also included supporting learning and development and pulse research. These brought another dimension to the same concern: understanding what people needed, not simply deciding what to tell them.
Communication could not be all output. I wanted to pay attention to the experience on the other side of it.
What I wanted the work to do
Looking back, I see the reporting, interviews, platforms and learning support as parts of the same effort.
I wanted people to spend less time hunting for answers. I wanted decisions to arrive with enough explanation to make sense. I wanted colleagues’ work to travel beyond the immediate circle of people who already knew about it.
And I wanted employees to feel that communication respected both their attention and their contribution.
I was not trying to make every message memorable. Some messages had a perfectly respectable future as something read once, understood and never thought about again.
Others could introduce a colleague, spark an idea or help someone see their place in the organisation a little more clearly.
Knowing the difference—and giving each the care it needed—was the work.