Having done a slightly more technical post last time, it’s all “back to business” for me today. I’d like to discuss the concept of “synthesis” – an awfully corporate word – that describes the process of tailoring (often shortening) a statement so that it is appropriate for its audience.

Just before I gest started: I don’t think I’ve necessarily learned everything that there is to know about corporate synthesis yet, but I do wanted to do a post to write down what techniques I use so far, so that they are captured for others starting out.

Take the emotion out

If you are using words like “dramatic”, “considerable”, “exciting”, “notable” in your write up, then they can most likely be replaced with hard numbers or don’t really have any meaning. Emotional language is very helpful when you talk to your immediate team or when you’re looking to communicate a vision, next step, or change in strategy. When you are reporting about business achievements, then it’s important to quantify them and if they can’t be quantified you have more work to do.

Go through refinement cycles

I always find it easier to start with a long description of what happened and then go over it a few times, each time reducing repeated or unnecessary information. What’s unnecessary should be determined by what the level of the organization you are reporting out to needs to know.

Have backup notes

It can feel difficult to not share all the relevant detail of how a decision was made or how a result was achieved. You can mitigate that by linking to more detailed documents and or creating a briefing or Q&A document to back up the statement that you sent. If you use SharePoint or an equivalent file management system you can just link to this file. Even with a longer form document the first two points still apply. Just because you have more space, you don’t need to fill it.

Focus on the “Why”

It can be helpful to ask yourself why you are reporting out anyway. Is it just a regular business review? If so, what’s an achievement and what’s a status update? Can you separate the two and structure them clearly, so that people don’t need to search?

Focus on the “What”

Refrain from using different names for the same work stream or project. Agree early on a code name/project name and continue to use it. Use concise language to express what the team is doing and try and find similar language for similar activities across projects to avoid confusion about what is being done.

This is not a complete list

Like I said at the start, I’m still learning this myself, so as I find more techniques and tips I will likely write a second article about this topic. 🙂