Maintaining Context as a Manager Part 1
How I built a second brain to capture, connect, and retrieve what matters.
In a previous post, I wrote that information gathering is one of the day-to-day activities of managers. Today, I’m sharing my approach to storing and recalling information.
The larger your scope as an engineering leader, the less you can rely on your memory to manage it. When your scope is small, you can wing it. But as your responsibilities expand and your area of influence broadens, remembering everything in your head becomes impossible.
Every meeting, 1:1, conversation, interaction, and Slack thread leaves you with context you need to remember. Relying on sheer memory to store and track it all is one of the most common leadership failure modes.
It’s not only overwhelming but also doesn’t scale; sooner or later you become disorganized and forgetful. Having a system (a second brain) that helps you remember, recall, reference, or zoom in on any details you need, when you need them, is crucial for leading effectively and freeing mental space for other work.
Beyond keeping you organized, a good system develops your situational awareness: you spot patterns earlier, act faster, and lead with clarity.
In the first part of this post, I’ll share my workflow for gathering information, maintaining context, and building a second brain, and the second part will cover how I incorporated AI into the mix.
Deciding Information to Gather
When it comes to gathering information, the most important thing is knowing what information is relevant and needs to be preserved. Capture too much information, and you end up with a bloated knowledge base you rarely revisit, which doesn’t make you more effective in your day-to-day work.
To avoid this, I run every piece of information through a simple 3-part test. I store notes that serve at least one of these three jobs:
There are three jobs captured information typically does for me:
1. It enables a future action.
Some information is worth capturing because it will help you take an action later, even if you don’t need to act on it now.
A good example is understanding the current state of a project, team, or a problem. Suppose you’ve inherited a service as part of a reorganization. You need to understand what it does today, the problems it has, and where the product is heading. Capturing that information gives you the context needed to eventually develop a technical strategy or plan to move the service from its current state to its desired state.
Another example is something you need to do but don’t have time for now. You might capture something like “Review technical design doc on performance created by XYZ (link) on 2026-01-15”
Both examples above are valuable because they help and enable a future decision or action.
2. It reveals patterns or trends over time.
Some information becomes valuable only when connected with past context.
This is particularly useful for anything that changes over time: people, teams, products, features, experiments, or projects.
For example, if you’re supporting a direct report’s growth, an observation at one point in time may not tell you much on its own about how far they have grown since you started managing them. But when you observe over time with the feedback provided, you can easily see whether a behavior is improving, stagnating, or getting worse. That becomes particularly useful during performance reviews or growth conversations.
The same applies to a product or feature. Capturing important decisions, learnings, and changes allows you to look back later and understand how something evolved and whether the changes you’re making are actually producing the desired outcome.
3. It helps someone else to do their job well.
Not all information I capture is always for my own consumption. Sometimes I come across something that could make another person or team more effective, but I don’t have the time to immediately digest, contextualize, and share it.
I could find a blog post about a problem a team member is working on. Or I discover something another team is doing that could influence my team’s work. Capturing such in my knowledge repository now ensures that I don’t forget and allows me to refine it later and share
The rule of thumb is: don’t capture everything, but only stuff that allows you to take action, show trends, or create leverage for others.
Organising Information
Gathering information is only half as useful if it’s not consolidated, organized, and available for use to help you manage effectively, grow the people you need, and access them when you need them.
I experimented with a few note-taking apps before settling on Logseq. What I like most about Logseq is that it lets you link information and pages together as a graph. I often use it to intuitively build relationships between pieces of information rather than simply storing them. It also has a journal feature that lets me jot down thoughts and capture information as I go about my day. You can capture something quickly and connect it to an existing page or node.
There are a few information-gathering workflows, such as PARA and CODE. You can use whatever works for you. I organize my notes around Project, People, Tasks, and Misc. This doesn’t necessarily mean folders but rather an independent node in my graph that serves as a top-level topic.
Projects
Every engineering project has a name. You can have a page (an independent node) for each project you’re leading. The rule of thumb is that it contains all the noteworthy information you need about the project. I would often collect my own thoughts on the project, which may include strategy, assumptions, questions, and clarifications to link to the project for later consumption.
For example, if someone raises an important concern during a meeting about a specific project, I might capture it in my daily journal and link it to the project for follow-up later.
Over time, each project page becomes a rich history of the project itself as it evolves. This makes it easy to spot patterns and trends, and to identify actions that need to be taken. I can see what we were thinking about when we started, what problems we encountered, what decisions we made, what changed, how the project lifecycle evolved, and what my own contributions were.
People
There is often noteworthy information from people you’ll interact with or work closely with daily. I often start building a knowledge graph the first time I have something noteworthy to remember about a person. This could sometimes be an idea I need to share with someone, a TODO, observation, feedback, or just prep work to do before meeting with the person. You might also use this to capture meeting notes for your own personal consumption.
Personally, this is handy for performance evaluation and helps in understanding people’s contributions over time. I might notice that someone on my team handled a problem particularly well and capture it immediately so it’s easy to remember later. The same information can become useful during performance reviews. Instead of trying to reconstruct someone’s performance from memory at the end of a six-month or twelve-month period, you’ll have a record of specific examples from throughout that period and link to important artifacts.
You might also capture feedback you provide to individuals you work with. As a manager responsible for people’s development, you want to be able to track how people grow over time. Often when you go back to look at this, it can give you an idea of how an individual has grown since you started managing them.
There is one thing I haven’t solved yet: managing documents that need to be shared with someone. I sometimes default to Google Docs for capturing 1-on-1 notes, quarterly performance feedback, and any information that needs to be shared with someone.
I would share how AI and LLMs have allowed me to centralize all this and create a single knowledge repository.
Task Management
You won’t only manage your team but also manage yourself. One aspect of managing yourself is being able to capture your work items, manage incoming requests, and track work in progress. Logseq supports capturing to-do items. Each TODO item can remain attached to the context where it originated from, while still being surfaced in a central task view.
I constantly refer to my TODOs and manage statuses.
As I handle my day-to-day TODOs, I check them off, which makes it easy to see what is done and what’s not.
Misc
Misc is a node for all things not related to projects, tasks, or people. I use Misc for ideas for future projects, drafting a blog post, or anything that has no connection to a project, task, or people I work with.
As I write this post, my approach to information gathering includes AI agents in the loop, but the overall system remains the same. I have a setup that allows AI agents to go through different conversation channels, notes, and design docs, figure out what matters to me, and digest it in a format that works intuitively with Logseq. In the second part of this post, I’m going to share my setup and specific AI skills I have created.