A few years ago I was a senior engineer who was doing the job pretty well by the metrics that were visible. Shipping features, writing design docs, unblocking teammates. All the output was there.
What I was bad at — and only slowly becoming aware of — was the other 40% of the senior job. The part that doesn’t show up in a performance review as a discrete line item but that determines whether your actual impact is 1x or 3x. The org navigation. The influence. Knowing which conversations needed to happen before a proposal could move. Understanding why some technically good ideas got killed and others with obvious flaws survived.
I had a notebook I used for one-on-ones and a mental map of the org that I tried to keep updated in my head. Neither one worked well enough.
The Reorg That Made It Concrete
We went through a reorg. My team got split across two new organizations that had different priorities and different sponsors. Three relationships I’d spent a year building were no longer relevant to my current work. Two new teams I’d had almost no contact with were suddenly load-bearing for getting anything done.
I sat down to figure out the new map. Who were the connectors? Who had the real technical authority in each of the new organizations? Which of the new managers had strong sponsorship upward, and which were going to be squeezed by competing priorities?
I had all of this in my head from conversations and observations over the previous months. But it was unstructured, and when things changed, I had no good way to update it. I was maintaining a mental model of a system that kept changing faster than I could re-derive it.
I wanted to write it down. But I didn’t want to write it somewhere shared. An honest org map — one where I could note that someone was a blocker, or that a particular manager was unlikely to sponsor anything that crossed their reporting boundary — isn’t a document you publish. It’s a working map for your own use.
There was nothing that let me do this. There were org chart tools, but they were designed to represent the official hierarchy, not my read of the informal one. There were note-taking apps, but they had no structure for the relationships that actually mattered.
The Skill Prioritization Problem
Around the same time, I was trying to decide whether to invest time in learning Kubernetes deeply. It was clearly relevant to the infrastructure direction, there were interesting problems there, and a few of my peers had done it and found it career-useful.
The way I usually thought about skill investment: do I want to learn this? How long will it take? I’d set a vague goal, start learning, and either follow through or quietly deprioritize it six weeks later when something more urgent came up.
What I wasn’t doing was being honest about the real cost. Not just time-to-competence, but: how much does this cost me in focus while I’m learning it? Does this knowledge become relevant in 6 months or 18 months? What am I not doing because I’m doing this?
The optimistic goal-setting trap: you estimate how long something will take at your best-case pace, in uninterrupted time, with perfect motivation. The actual cost is higher on every dimension. The learning happens in fragments around everything else. The stress of context-switching is real.
I wanted a tool that forced me to estimate honestly before committing — not to track whether I hit a deadline, but to surface the actual tradeoffs before I decided to take something on.
What I Actually Built
VividMap is eight modules. I’ll be honest: not all of them are equally interesting.
The shadow org chart is the one I find most valuable. It has separate layers for formal authority (the official hierarchy) and informal influence (who actually gets consulted, who the load-bearing connectors are, who has expertise gravity in their domain). You can tag people — ally, blocker, sponsor, neutral — and add private notes. The key design constraint: none of this is visible to anyone else. It’s a working map, not a document you publish.
Skill cost estimation tries to break the optimistic planning habit. Before committing to learning something, you estimate: time-to-competence in hours, direct cost, and stress impact (how disruptive is this to current work?). You’re not setting a deadline — you’re doing a pre-mortem on the investment.
The AI assistant has access to your org chart, notes, skill state, and roadmap. I built it because I wanted to ask questions like “given what I know about the dynamics between these two orgs, how should I approach this proposal?” and get an answer that used context it actually had. Every other AI tool answers that question generically. The difference when it has your actual org map and your Second Brain notes is significant — not because it’s smarter, but because it’s not starting from nothing.
The Second Brain is a rich text note system with full-text search. For 1:1 notes, political context you need to remember but can’t put in shared docs, architecture decisions with the real reasoning that wouldn’t survive a design review comment thread.
There are four other modules: Maps (initiative tracking), Roadmap, a Pomodoro timer linked to initiatives, and a PostHog integration for product analytics on my own usage. The timer is the least interesting thing I built; I should have waited and put that time into the AI assistant quality instead.
What I Got Wrong at First
I underbuilt the onboarding. The “staff+ job” framing — shadow org charts, influence, skill cost estimation — isn’t intuitive to engineers who haven’t read Tanya Reilly or Will Larson. The concepts make immediate sense once explained, but the cold landing experience assumes prior context that not everyone has.
The skill cost estimation reporting is half-built. The module lets you input estimates, but it doesn’t visualize cumulative skill investment across your portfolio. That aggregate view — how much total time are you committed to, and is that realistic? — is the useful output. It’s not there yet.
I shipped the Pomodoro timer before the AI assistant was solid. Easy thing to build, satisfying to check off, doesn’t differentiate the product. Don’t do this.
The Privacy Constraint That Shaped Everything
The single most common feedback from early users is relief that the org map is private by default. People want to be honest about their read of the organization — who the blockers are, where the political landmines are — but they won’t do it if there’s any chance it becomes a shared document.
This shaped the architecture more than anything else. VividMap runs on a private VPS, not a shared SaaS database. Your org map and notes are yours. Nothing is trained on, aggregated, or visible to anyone outside your account.
I considered a fully local version — no server at all, everything on-device. The tradeoff is that cross-device sync requires a server somewhere. But the server can be opaque to me as the operator: user data is encrypted at rest, and the AI assistant sends queries to Claude’s API without me having access to the plaintext of your org map or notes.
What I’m Trying to Learn
The honest version of why I built this: I wanted these tools myself, and I didn’t find them. The less honest version would be “I identified a market opportunity.” The market question is real — whether other senior engineers feel the same gap I felt — but that wasn’t what started it.
What I’m most interested to learn from early users: whether the shadow org chart is legible to someone who’s never explicitly thought about informal influence before. Whether the skill cost estimation framing is useful or just adds friction. And whether the AI assistant, with context, is different enough from asking ChatGPT to be worth the setup.
If you’re a Staff or Principal engineer and you want to try it — or just tell me the whole premise is wrong — I’d rather hear both.