Why you should NOT be writing weeknotes

Thoughts and considerations on why you should probably not be writing (or reading) weeknotes.

“I would have written a shorter letter, but I did not have the time.”
Blaise Pascal

I believe a big part of my job as a delivery manager is to maximize the amount of work not done. The more I can save money by not doing work and still producing a desired outcome, the better. A important part of this is to constantly challenge what I do and if I can’t find a good reason for it, I try a little experiment: I stop doing it. Then I inspect and adapt.

I have worked in government long enough to appreciate the importance of being concise. We like a good document around here you see, and riding on this trend comes the weeknotes, regular reports sent by departments, teams and people high in the chain aimed at sharing updates and news with stakeholders and the wider organization. Some places like them so much they have dedicated Slack channels for “broadcasting” them.

Personally, I feel that writing or reading weeknotes is akin to watch paint dry and I encourage my teams not to write them. If they really feel they need to, so have them as short as possible, ideally using a similar format every time, so that the audience knows what to expect and where to find what they need.

What’s the point of weeknotes?

People I spoke to gave several reasons to justify reading/writing weeknotes:

1) Promote awareness of tasks & progress within/between teams
2) Provide a useful record for formal delivery reporting
3) Practice clarity and brevity in communication skills
4) Publicise events and news
5) Praise successes and achievements
6) Looking sideways

All valid reasons that in my view should be addressed — most of the time — through different channels. This is why:

1) Promote awareness of tasks & progress within/between teams
Agile teams already (should) have multiple ways of radiating information — daily stand ups, a working board, sprint planning, reviews, releasable product increment, emails, slacks, … You do not need weeknotes. Weeknotes are non-standardized, lengthy and may not report on what your audience needs to know. Plus, you cannot be sure you are reaching the right audience.

2) Provide a useful record for formal delivery reporting
Weeknotes are informal by nature and bad medium to report on progress as I’ve explained above. There is minimum commonality between different weeknotes, sometimes even within the same team, making hard to mine what is useful or not. Also, they might not be centrally stored or shared online so it is difficult to compare and track the “progress” they aim to report.

*A lot of content does not mean a lot of output…*

3) Practice clarity and brevity in communication skills
Some weeknotes are like War and Peace and could be trimmed down to 1 page. Concision takes time and is a skill that has indeed to be practiced and mastered but not at the expense of the reader.

4) Publicise events and news
There are way more dynamic and appropriate channels to share those. Blogs, calendars, email groups, Slack, real boards down the hall… On weeknotes important messages are easily be buried within walls of texts and not get the required level of attention they deserve.

5) Praise successes and achievements
As above. There are way better ways for doing that. Praising people and teams face to face is one of them.

6) Looking sideways
This is a good reason for writing weeknotes and I totally get it that for high management weeknotes are a great avenue to communicate and share what is happening in and outside of the company. The problem is that weeknotes are mostly a one way street and again, many times only shared via e-mail making it hard for others to follow and even compare progress (and promises) from previous weeknotes.

Further issues with weeknotes

7) It encourage “Skype management” and distant relationships
When busy stakeholders and managers receive weekly reports they are less likely to engage directly with the team. You should foster face to face communication within your workplace.The best way to know about the progress and problems of a project is to talk directly to the ones involved with it.

8) It erode trust (or flag mistrust)
Weeknotes can be used to “protect” a person or a team. “If I wrote it, nobody can dispute it or claim not to remember the conversation” scenarios where scope and participants mind’s change so often that one feels they need to constantly preserver words and discussions to shelter themselves. Weeknotes can also be used as a way to “sneak in” complicated topics that people rather not talk face to face, such as project delays.

Weeknotes do not necessarily bring transparency or create an environment of honest, open and direct communication.

9) “Weeknotes is where issues goes to die”Issues should be raised and act upon by talking to the people you need to get them sorted. Issues should be made visible on a wall and constantly chased. Issues should also be dealt over beer, coffee or your preferred beverage of choice.

10) They take a stupid amount of time to prepare
Weeknotes can take a week to write! Imagine the collective cost that all weeknotes require to be produced and consumed by an organization!

And finally and more importantly,

11) Working software over comprehensive documentation
Weeknotes deliver nothing but text. They do not contribute towards a product increment. Let your deliverables — or lack of them — speak for itself. I can write you 5 pages about my past week when in practical terms we have made no progress towards a product increment.

Should I be writing weeknotes?

The vast majority of weeknotes can be replaced by the standard agile ways of radiating information, regularly recorded Show & Tells, blog posts, project reports — against goals and KPIs — and regular face to face communication.

To find if you need to write weeknotes follow the simple test I have created:

If you are not writing them, do not start.
If you are writing them, stop.
And wait.
And observe.
And when “they” ask for it, get to the core of the question. Not what is it that “they” want but what is it that “they” (really) need.

Most often than not your audience do not want a 3 pages document. They want to know if you have done what you said you would and if there are issues they should be aware of. Are you on track? Are you late? Should I be worried? Can I help?

Wishes and needs might not go hand in hand

“What is it that you need?” and “What problem are we trying to solve?” are key components of the Weeknotes Test and will help you to go a long way in producing the right material for the right people.

The power of Acronyms

“The single biggest problem in communication is the illusion that it has taken place.”
George Bernard Shaw

Sometime ago an old memo from Mr. Elon Musk on the overuse of acronyms on SpaceX made headlines. I don’t know Mr. Musk but I can certainly relate to his pain. I have being working in IT and Government projects long enough to know a thing or two about acronyms.

Consider that we have dozens of Ministerial and Non-ministerial departments, mostly with an acronym associated to them. Add to that agencies, public bodies, the hundreds of different groups, teams, projects, systems, platforms, networks, environments, databases most of which are referred through an acronym, or codename, and you start to have an idea of the kind of cryptic communication one can come across from time to time.

Departments also have their own vocabulary and another list of acronyms and jargons has to be mastered or you might feel people are not really speaking English.

To make things more interesting the same acronym can mean different things and some things are called by different acronyms by different people. It can be hard to know when something has fundamentally changed or it is in fact only a “rebranding”.

Sadly, things don’t get any better in the private — and personal — sector. Who has never come across those long email/Linkedin signatures portraying a long list of meaningless acronyms referring to titles and certifications? VP, PO, PMP, CSP, EA, EMEA, CT, … all for the sake of SEO?! 🙂

So let’s start with my standard question: What problem are we trying to solve?

A software or on a broader scope a “project”, is nothing but the expression of (several) conversations. When those conversations are hard “to get”, you are unlikely to reach a good outcome.

In general people use acronyms as a way to save time. Acronyms can also improve memorability. There are also those who feel insecure at work and think acronyms make them look professional. It gives some kind of credibility, like a dialect for the initiated, “yo G, I’m from the gang”!

For the ones who are not part of the gang, they can distract, confuse, impare, alienate, obliterate, and generally f* up a conversation.

You want to improve quality? Start by improving your conversations.

So here are a few ideas on how to escape the DBA, deal with acronyms and improve communication at your workplace.

Challenge who ever say it

Challenge, ask, confirm what does the acronym mean. Even if you already know. Be sure you are all talking — and understanding — the same thing. This is specially important on meetings where you have people from different areas or levels of expertise.

Challenge who ever hear it

Confirm during your conversations that everybody in the group knows what the acronym that is being used really means. People will often let it slip without asking because they “an understand the context”. My old history teacher always used to say that “if you can’t explain what is it, you don’t know what it is”.

Acronym Free Day

Fun challenges at your workplace to spend a whole day — or week — without using acronyms!

Acronyms Quiz

This is a good idea for team and company events.

Acronym Glossary

Do you really needed? If so, go ahead but make sure people are aware of it, that they use it and maintain.

Are acronyms an issue where you work? How do you deal with it?