A weekly snippet is a short summary of the work accomplished during a week,
written as a self-assessment. It was created by TODO and popularized at Google
(albeit its use has been on the decline).
I’ve been writing weekly snippets for twelve years now. Here’s a slightly modified example of what I wrote recently;
Great week! <INSERT EMOJI>
# LUCI
- Met joe@, jane@: resolved contention about security aspect of Swarming
pools.
- Branstormed on Swarming Web UI UX with foo@.
- Paid tech debt on Swarming.
- Fixed long standing test case flakiness.
- Enabled cron job to delete old entities.
# Tricium
- Found solution with bar@ for multi-tenant; still in design phase.
# Other
- Wasted ½ day upgrading my workstation; I should have switched to a
chromebook.
- OOO Friday.
… but I’m getting a bit ahead myself. First, why write one? Then, why keep going?
Snippets serve two different purposes, each targeted to a different audience. Understanding this is crucial to enable using a writing style that simultaneously serves the needs of both audiences.
The first audience is personal: it’s you. The habit of writing snippets at the end of each week enforces a reflection point about your recent week. It’s importance is as much in the act than in the output. It forces you to recall the highlights of your week, and where time was spent efficiently, or not. This helps understanding your efficiency (or lack of). It’s a short moment to reflect on what you achieved.
One can see this as a personal log book but this is much more than that, because the process of writing is itself a forcing function to reflect on your priorities.
This trove of information can be very helpful at later times, either when you feel drowned in work and forgot what you achieved in the last 3 months, or during performance review. Having detailed information about the execution and purpose can help build stronger promotion case.
The second audience is your colleagues. I found two ways to consume snippets written by others: with a weekly digest or when looking back at what someone worked on.
A weekly digest should be generated automatically, and anyone should be able to specify who they want to include. I highly recommend being able to include all of a team, or all of a manager’s reports. This is useful as people join and leave the team, otherwise your list will become stale and lacks colleagues who joined recently.
As discussed in Deep Work, sometimes busyness is used as a proxy for work.
Weekly snippets can be a great complement to weekly stand ups. Snippets can be done asynchronously and leave a trail. On the other hand it’s publish-only, it’s not a good context to start discussions. The biggest difference is that snippets are not topical, the person talks about everything that they worked on, not only what is relevant to the stand up.
Let me show an example to clarify: as an individual contributor, you may work on a few projects; you have your main project, then you may have a side project that is maybe related, maybe not related to your normal work. So if I work on LUCI, but also work on periph.io, then in a weekly status report I will not talk about periph.io. On the other hand, I will write it down in the snippets.
That has two important effects.
First, the snippets cannot be collated and reported as a weekly status report to leadership. Because each individual contributor may work on seemingly unrelated tasks, it becomes an overwhelming amount of information to leads.
Second, because it is people focused and not project focused, it gives a much better view about what is happening in the team, even if it’s not directly related to the project people are under.
The snippet format is intentionally free form, as it can be adapted to each individual, and the format can change vastly from week to week. They are useful for both individual contributors (IC) and managers, but generally require a level of transparency, as at least at Google, snippets are readable by all employees. This (sadly) means that as managers climb the management chains, they often let go snippets as they can’t discuss their tasks due to contentious issues.
, usually in the format of a bullet list, categorized by products and may include short commentary. The language is specialized
Snippets shouldn’t feel like busy work. It must have intrinsic value, even if the process itself is also beneficial. It’s important to know why you do it, and aiming for speed helps staying focused and not wandering around.
It is easy to answer what you have done, but it is important to also answer why you spent significant amount of time on an action item. The least valuable form of snippet is a flat list of bugs and code reviews. These can mechanically be extracted in the future, so there’s no value in doing these manually. Explaining the purpose of how you spent your time is what you will like reading when looking back.
Your work is done as part of a team or at least a project, potentially multiple teams. Over the weeks, we should see a progression of the story, as you build higher up into the project. If you are down the trenches and constantly under fire, we should also see it, as this is an important pattern to observe so a corrective action (like increasing investment, changing the structure) can be done by management.
Most people will assume weekly snippets to be essentially a list of bugs worked on, and list of changes. But this couldn’t be further from the truth. What is most useful is ephemeral things that are not collected elsewhere. Did you have an adhoc whiteboard discussion with a colleague? Or lunched with someone in another team, discussing cross-functional issues? Did you get swarmed by emails, and what kind of emails did you reply most?
So for any meaningful communication, list who you communicated with, and the kind of communication it was; did you help, did you receive help, was is to commnuicate progress, or to brainstorm on a new idea?
I personally look in my Sents emails folder to recall the communications I had over emails. For IMs, this is much more complicated, especially that some systems intentionally discard content after short period of time. I don’t have much solution for this, except spend your time on IM wisely.
If you feel like s**t, that’s the place to state it.
Some weeks are extremely productive. Some are really bad. It’s good to say so, at the top, to keep a track of how you remember your productivity level. Note the difference with the previous section: state your optional one liner self assessment up front, but why it happened at the bottom.
As a team lead or a manager, it is good to know to see how a individual self-assess their performance as the weeks go by, without requiring a 1:1 to discuss about it. Furthermore, having it written down and broadcasted is extremely useful to look at patterns over time, which is lost when self-assessment is only done through 1:1s.
It is useful to list the fact that you were out of office for 2 days, spent half a day in training, kids were sick so you barely slept through the week, etc so that there are clear reasons why your productivity was lower, but this should come last. People have a tendency of putting it first: see why I didn’t do much, please don’t judge me!
But refrain from putting this upfront. State what you did first, why you didn’t do more last.
This is especially useful when working with teams in different countries to know who was in a holiday on which week, versus having to look up each person’s calendar.
Snippets can be implemented as a web service with a deceptively simple web UI, and some people use a Chrome extension or a chat bot to enable streaming items as the week progresses, instead of doing it all at the end of the week.
One could use a local notebook, or even a Google Document, but this defeat half of the purpose, the snippets are not published anymore.
A nice feature is to enable markdown format. The example I gave initially is in markdown. For those who master markdown, it permits nice formatting while still being very quick to write. The problem is that markdown may aleniate non-technical team members. You may be interested in adding a rich text format editor but be warry of this, this is getting one notch closer to becoming busy work, as people may feel compeled to do “nice” formatting and spend too much time on that.
One important point is to enable access control. For example the CEO or a in-house counsel lawyer may want to limit who can read their snippets.
TODO Ideas for improvements
Doing snippets is a valuable exercise to reflect back on the previous week and ensure that the team is focused on its purpose. This requires thinking on an higher level thinking and synthesizing the essence of what was done.
Do you do snippets at your company? How are they done, is that very different than at Google? Please send me your comment via twitter.com/marcaruel.
Thanks!