AI Second Brain for Engineering Managers

Marlon Vidal opened a recent BMad Code live session with a question that lands differently depending on your job title: how many meetings have you had today about having too many meetings? His answer was eight. The day before, twelve. This was not a complaint. It was a data point, and the system he spent the next ninety minutes demonstrating is his attempt to do something useful with that data.

Vidal is an engineering manager at Telus Digital and, by his own description, a person who spent years building the wrong solution to this problem before finding the right one. That arc matters, because the failure is as instructive as what eventually worked.

The First Attempt: The App That Became a Second Job

Before building what he now calls the Tech Manager OS, Vidal built a web application. It had team member profiles, task boards, one-on-one logs, and performance improvement plan templates. It was, by most measures, a well-designed tool for the problem it addressed. The problem was that using it required the same thing it was supposed to save: time.

"I wasn't building a solution," he said during the session. "I was building another level of work on top of the work that I already have."

There was a second problem. Engineering managers deal in sensitive information: performance gaps, compensation context, team dynamics, personnel decisions. Colleagues who tried his tool raised reasonable concerns about feeding that kind of data into a third-party system. Some stopped using it entirely. Vidal understood their objection because, when he moved to a new company and tried to use his own tool for onboarding into a new role, he hit the same wall. The application could not keep up with the actual velocity of the job.

He scrapped it and started over with different constraints: everything local, no GPT wrapper the company was already paying for anyway, and zero manual data entry as a precondition for the system doing anything useful.

What He Built Instead

The Tech Manager OS is an Obsidian vault with an opinionated folder structure, a CLI scaffolding tool, and a set of Claude-powered routing skills. It is available as an npm package at the project repository Vidal linked during the session. Installation takes two commands.

The core idea is simple enough to state in a sentence: drop processed meeting notes into an inbox folder, and let Claude route them to the right place. One-on-ones go under the relevant team member's folder. Team syncs go under meetings. Leadership discussions route accordingly. External contacts who show up in meeting attendee lists get auto-generated profiles based on their email address, which Vidal uses as the universal identifier across the vault.

That last detail is worth pausing on. First-name-only identifiers create collisions fast. Two people named Alex in a company of any size, and your backlinks become ambiguous. Email addresses are unique. Obsidian's double-bracket link notation turns them into clickable connections. Over time, the graph view of the vault starts to reveal who you actually spend time with, which projects are generating the most conversation, and where your attention is going.

The routing logic itself is deterministic by design. When you add a new team member or project, you use a CLI command rather than asking Claude to figure out the structure. The vault's CLAUDE.md file explains the folder hierarchy explicitly, so the AI knows the rules before it starts sorting. Vidal described this as intentional: "I love that this allows you to do commands so you don't always have to use your inference and rely on it getting it right." Structure first, intelligence second. That ordering matters.

The Granola Dependency

The intake mechanism is Granola, an AI meeting transcription tool that installs locally and records across whatever platform you happen to be using. It does not join meetings as a visible bot the way Fireflies or Otter.ai do. It captures audio from your machine, processes it, and produces structured notes with attendees, action items, and owner assignments. A Granola plugin for Obsidian then writes those notes directly into the inbox folder, creating the automatic flow that the original application required manual effort to replicate.

Here is the part that requires honesty: Granola recently encrypted local transcripts, and accessing them now requires a paid subscription. The free plan still works for manual copy-paste, but the automated pipeline that makes this system genuinely low-friction requires paying for it. Vidal was straightforward about the tradeoff during the session. Whether the time savings justify the cost depends on how many meetings you manage and how much that time is worth to you, but going in with eyes open is the right posture.

One architectural choice Vidal made deserves particular attention. He feeds Granola's processed summary into Claude, not the raw transcript. This keeps token usage low, keeps context windows manageable, and still surfaces the information that matters. The raw transcript URL lives in the note as a backlink for the rare case when you need to verify exactly what was said.

Where It Actually Pays Off

The most concrete demonstration came when Vidal described using the system for performance management. After months of meeting notes routed into individual team member folders, he had enough longitudinal context to write promotion cases grounded in specific examples rather than recollections.

"I grabbed a story of feedbacks received from a particular user," he said during the session, "from what he done in the project, what are contributions to the company in general," and applied a situation-behavior-impact framework to document outcomes. The promotions followed. For a manager responsible for a substantial team, the difference between having that documentation and not having it is not a productivity improvement. It is the difference between an argument you can make and one you cannot.

The same logic applies to performance reviews, performance improvement plans, and the ongoing one-on-ones that feed into both. The vault remembers things you will not. That is not a selling point for the tool so much as a description of what memory actually does at organizational scale.

The Setup Is Not Invisible

Before someone who manages people but does not write code decides this is the system they have been waiting for, a clarification is warranted.

Getting the Tech Manager OS running requires comfort with a terminal, npm, an Obsidian installation, Granola configuration, and editing a CLAUDE.md file when you add folders that fall outside the default structure. None of these steps is technically difficult. All of them assume a baseline familiarity with developer tooling that most non-technical managers do not have. The CLI scaffolding removes a great deal of ongoing friction, but it cannot remove the initial setup cost, and that cost falls entirely on the person installing it.

Vidal acknowledged another real constraint: the routing accuracy of the inbox skill depends heavily on how your company names its meetings. A meeting titled "sync" tells the router almost nothing. A meeting titled "Q3 backend performance review with Alex Chen" gives it everything. If your organization's calendar hygiene is poor, the automatic routing will be too, and you will spend time correcting it manually.

These are not disqualifying problems. They are the actual shape of what you are signing up for.

The Gap This Exposes

The interesting question sitting underneath all of this is not whether the Tech Manager OS works. It appears to work, and Vidal's account of using it to build promotion cases is credible evidence of real value. The interesting question is how wide the gap is between the people for whom it is accessible right now and the people who would benefit most from it.

Engineering managers who came up through software development will find the setup familiar. Non-technical managers in product, marketing, or operations, who arguably deal with the same meeting overload and the same people-management demands, face a meaningful barrier. The underlying idea, structured local storage plus AI routing plus automatic intake, is not inherently technical. But the implementation, as it stands, selects for a particular profile.

Whether that changes depends on tooling, not on the idea itself. The idea holds. What Vidal built is essentially a bureaucratic memory system: a place where the organizational context that currently lives only in your head, or in scattered notes across four different apps, accumulates into something searchable and structured. That is useful for any manager, not just the ones who are comfortable in a terminal.

My read: this class of system does not stay the province of developer-adjacent managers indefinitely. Obsidian's interface is already approachable. The CLI commands could become a setup wizard. The moment someone wraps this in a form-based installer, the technical barrier disappears. That will happen, probably sooner than most people expect, which is usually how these things go. What Vidal has done is document what it looks like when someone builds it for themselves before the wrapper exists.

Bob Reynolds is Senior Technology Correspondent at BuzzRAG.