This is the first entry documenting my personal journey exploring processes, concepts and tools to improve my content generation at work.
My goal is to be more intentional and leverage my research better when writing design docs (a.k.a. RFC), strategy definitions and other related engineering docs.
As a staff data scientist I constantly produce documents with a mix of research, direction and context to guide teams and projects in the intersection of software engineering and data science.
This series will help me to learn in public as I investigate methodologies and determine how they help (or hinder!) me in my goals.
When it comes to productivity and content generation there is a lot of material around PKM, Second Brain or Zettelkasten that promises to help knowledge workers in producing more and connect ideas better.
Between my current usage of these tools and techniques plus my work environment there are several considerations that frame this series. This means that I might be limited in the tools and methodologies available to me.
My work environment has several limitations around software, infrastructure and how to communicate concepts with the rest of the organisation.
- We use Google Workspace. Most of the content I create needs to be published in Google Docs and Slides to receive feedback, enable docs-driven collaboration and guide initiatives.
- We cannot have data in cloud providers. This rules out iCloud-based syncing, Roam Research, Notion, Readwise and any other solution that saves data in the cloud.
- We have network drives, Google Drive, internal Git and Mercurial repositories as options to sync documents online.
- I cannot install software with problematic licenses. AGPL in particular is a big no-no.
- I would prefer to use open-source tools but I’m not opposed to the alternatives.
- I cannot install most Chrome extensions. This means that web clippers and other tools to quickly capture data might be out of reach.
- There might be alternatives like Apple Shortcuts or forking Chrome extensions code to our internal repositories to vet them for corporate usage.
- My work environment is a mix of MacOS, Android, Ubuntu and iPadOS. This makes syncing drafts more complicated outside Google Workspace. For simplicity I might focus on MacOS tooling since my Ubuntu usage is done via SSH.
- We have a strong docs-as-code culture. Although as mentioned before, Google Docs/Slides are an essential output format, I have the freedom to publish documentation to our codebase.
There are certain areas of the organisation pushing to extend this to design docs which could help me work better with my tooling of choice.
- I have a strong bias towards Markdown-based tools. This is not surprising considering my post on “What’s so cool about writing in Markdown”.
Frameworks and Methodologies
My exploration focuses on content production rather than general productivity. I have a decent base to build upon and improve the steps required to be more intentional.
- I regularly achieve Inbox Zero and have a good grasp of task management. I adapted Getting Things Done and other productivity techniques to keep up with the regular information inflow at work.
- There might be things to improve around capturing useful information from emails (e.g. internal newsletters) for writing documents and formulate strategies.
- I enjoy using a mix of analog and digital note-taking. I’ve been a Bullet Journal user for 3+ years and it has done wonders to become more intentional about my work and distill information better.
- There is tension about mixing digital and analog note-taking and that’s something I’m planning to explore more. I’m not willing to let go of something that gives me pleasure and helps me reflect but it’s clear I need to change certain things if I want to achieve my goals.
- I’m able to carve irregular time for Deep Work. I’ve enjoyed the benefits of following Cal Newport’s concepts around Deep Work and they are key to produce more and better documents but I need to learn better techniques (and be more ruthless!) to reduce my meeting load and improve my time blocking so I can dedicate the right amount time to focus on my output.
- I haven’t explored writing nooks and other tips for writers. There are multiple recommendations from published authors around forming a writing routine that includes zen areas and other aids to achieve a flow state. I’m not bound to work at my desk so this is something I’m curious to explore more during my Deep Work hours.
- I need to understand the right transitions between drafting, early feedback and productive time. This might sound like a simple matter but doc-driven collaboration and the tension between Google Docs and other tools requires particular techniques to deal with the friction when producing iterations and addressing comments.
Information and Inspiration Sources
This blog post is being written after an initial investigation which has formed initial opinions to frame my journey.
- I’m wary of *productivity pr0n*. There is a lot of incredibly popular but misleading information created by influencers and productivity gurus.
This is a consequence of producing regular content to show the new ‘shiny thing’ or pander particular online courses since that’s their source of income.
This is not to say they don’t provide useful advice and pointers to explore but their application might be quite limited. Andy Matuschak has a eloquent note on the subject:
But most people who write about note-taking don’t seem particularly accomplished in their own fields, whatever those may be. In fact, most such writers aren’t applying their notes to some exogenous creative problem: their primary creative work is writing about productivity.
- I have limited exposure to personal knowledge management books. Beyond Ahrens’ book about Smart Notes I haven’t checked additional books around this topic and that’s a clear gap that might solve several blockers to increase my output.
Between books, parsing online sources, summarising the information and applying the techniques I have plenty of fabric to cut to find my right setup.
I want to make sure I limit the number of tools I test and focus on long trials that go deep into methodologies. I’m more concerned about the right framework rather than finding the best software and the tooling considerations I have mean I will be able to migrate between tools fast.
I’m partial towards the UNIX philosophy around Do One Thing And Do It Well meaning that I’m happy to use great single-focus tools connected via APIs, workflows and plugins instead of a single extensible tool that does everything.
Finally, in addition to documenting my journey, I’m hoping to apply a few techniques I learn with this blog and explore solutions beyond my work constraints to find new sources of inspiration.
Stay tuned for the next parts!