There were many things I appreciated about the Google development culture during my time at the company. The entire environment was set up to make it as easy as possible to share information between employees, facilitating visibility, discovery, and serendipitous collaboration. One of the practices that contributed greatly to this open culture was known as snippets, short lists summarizing what you worked on the previous week (including issues encountered or resolved) and what you plan to work on during the upcoming week.

For several weeks now, we've been collecting and publishing snippets. Team members submit their snippets each Monday, and they are published internally for all to peruse. There is no prescribed structure or process beyond that. Our tools support a few enhancements, such as separate Last Week/This Week sections and Markdown syntax, but a single block of plaintext will always continue to work.

As an example, here are my snippets posted on December 15, 2014:

Last week:

  • First 18F blog post: [Google & the US Gov't talk](https://18f.gsa.gov/2014/12/11/> large-scale-development-culture-change/)
  • Snippets: launched v3 (private by default); [preview tool](https://github.com/mbland/mbland-18f-utils/blob/master/> snippets/snippet-preview.rb); [updated guidelines](https://github.com/18F/hub/blob/master/pages/> snippets/guidelines.md)
  • Hub: made open-source; demo for PIFs; private pages; guest users; editable pages
  • Doc Working Group: weekly meeting
  • Began [team data validation tool](https://github.com/18F/> data-validator)
  • 18F Consulting: client assessment

This week:

  • Soft-launch the public Hub
  • Publish Snippets blog post; draft Hub, Working Groups posts
  • Doc Working Group: push doc organization strategy
  • git submodule follow-through (Dashboard, > data-validator)
  • 18F Consulting: protosketching

Many find writing snippets helpful for keeping track of their own activities, for evaluating progress towards quarterly goals, and for compiling self-assessments. They are often useful in refreshing one’s memory when asked to perform a peer review for someone else. Though the first audience of a set of snippets is the author, keeping them short and to-the-point increases the chances that someone will read them and discover something of value.

There is no mandate that everyone write snippets every week, nor is it expected that everyone read everyone else’s snippets. They are useful, however, for learning about individuals and projects in some degree of detail whenever the need or desire arises. Many of us frequently skim over others' snippets just out of curiosity. Such casual perusal fosters a sense of team cohesion, and sometimes sparks productive interactions.

There are many ways to collect and publish snippets. 18F's current process involves everyone submitting their snippets via a web-based form backed by a spreadsheet; each week's spreadsheet is then exported as a CSV file that is parsed by our publishing system. Google had a fully-automated system integrated into one of its internal applications. However, for a team of up to fifty people or so, one person can volunteer to collect snippets over email and copy the replies into a weekly report to achieve a comparable effect.

If you'd like to start publishing snippets for your team, don't let the perfect be the enemy of the good: Regardless of the tools at-hand, it's possible to put the idea into practice right away. There is always time to incrementally refine the process over time once people see the value, which isn't a function of how you collect and publish them; it's a function of the passion and creativity unlocked by increased transparency among team members.