The evolution of the research repository.
cesar cardenas · research operations
a case study
My whole career has been operations.
I love to experiment and build, and operations keeps being the right home for it. Research ops is the intersection I was looking for: experimentation, connection, and impact, for the insights and ultimately the user.
first research ops hire at hinge · the 0→1 phase is my favorite place to build
Quick sneak peek: I build a lot of things.
That's the range, and the more projects tab has the tour. Today I'm telling one story. It has a real pivot in it, and it ended with one of Hinge's first internal AI tools.
Where we're headed.
Context
The repository nobody reached for.
Approach
Treating this pain point like a research project.
Complexities
The friction we worked through.
Implementation
Adoption, treated as a practice.
So what now?
Evolving today's system into something even more advanced.
Final reflections
What this chapter taught me.
Q&A
Your sticky notes, answered live.
every visual recreated · metrics relative only · no confidential insights anywhere
01 · context
An opportunity as old as time.
Repositories are a tale every research org knows. Getting them right is complicated, and there is no one size fits all.
era 01 · the filing cabinet
context · the original askThe ask: "our repo is half-baked. make it better."
Maybe move it to Confluence. Maybe a different repository. A completely reasonable ask, and the kind of project that usually ends with a slightly shinier filing cabinet.
spoiler: that is not what happened.
era 01 · the filing cabinet
context · the struggleThe struggle was real.
Underutilized
XFN rarely touched it. Insights landed in a drawer, not in decisions.
Time consuming
Manual on both sides: researchers hand-filing, partners digging.
Not sustainable
A growing team and function on a system that didn't scale with them.
No innovation
If I see a manual process, I am going to ask what we can do to give it some glam.
The need for improvement was clear. The path forward was not.
…yet. personally? this gap is my favorite place in a project. it's where most of what i've built has started.
Revamp the research repository so it is easily accessible, efficient to use, and sustainable.
02 · approach
Treating this pain point like a research project.
First: my Research Ops principles.
Human centered
I build systems where AI handles the repetitive stuff and people keep what matters most: empathy, ethics, and the tricky decisions.
Intentional collaborator
I proactively, openly, and dependably partner to drive outcomes.
Adaptive
I creatively adapt to help teams reach shared goals, balancing quality with constraints.
Impactful
I strategically elevate the workflows and impact of those around me.
How I ran it.
01 · Understand
Met with every researcher individually, and XFN across the org. Bottlenecks from every point of view.
02 · Establish success criteria
What I heard became the bar every tool we considered had to clear.
03 · Build conviction
I formed a recommendation, made the case across the team and leadership, and earned the yes.
The path to clarity ran through people.
Those conversations weren't only input. They were buy-in. You build WITH people, not FOR them: involved at the right moments, updated in between, never surprised at the end.
People who help shape a system show up ready to adopt it. That mattered enormously once we reached implementation.
Our success criteria: four questions.
Budget, honestly
What could we actually spend, in money and time?
Speed to value
A system that proves useful in weeks earns the patience for everything after.
Sustainable at scale
Will it still work as the team and volume grow? Who maintains it on a random Tuesday?
Measurable success
If we can't track engagement, we're guessing. Adoption should be a number, not a vibe.
I evaluated the market. Big players and small.
i scanned everything to make sure we found the right tool for exactly what we needed.
Countless contenders. One fit.
judged against the four questions, not the demos
The bet: an AI repository, before that was the obvious call.
I recommended HeyMarvin: an AI-powered repository, when that was still an unusual move.
Why it won
· Innovative, ahead of the market
· Affordable enough to build a real business case
· Small company: a direct line to the co-founder, our needs prioritized, and I helped shape the functionality our team needed
03 · complexities
The friction we worked through.
What pushed back.
×Product limitations.
The tool couldn't cite its sources, and one-shot answers meant no follow-up questions.
×How could we track success?
No analytics out of the box. Adoption needed to be a number, not a vibe.
×A new tool meant a new workflow.
Researchers, XFN, and every future new hire would need to come along for the change.
How we worked through it. Pain point by pain point.
× Product limitations
No citations, no follow-up questions.
✓ Made the partnership work for us
As one of their earliest customers, I held biweekly meetings with the co-founder. Citations shipped quickly, and the steady drumbeat of updates made the tool feel custom to our team.
× How could we track success?
No analytics out of the box.
✓ Built the measurement myself
Custom query reports generated for us, plus a Slack bot routing every signal straight to me for fast triage. Adoption became a number we watched.
× A new tool meant a new workflow
Researchers, XFN, and every new hire.
✓ Planned the rollout, short and long term
A real implementation strategy. Which brings us to the next chapter…
04 · implementation
Adoption is a practice, not a launch.
era 02 · the first ai bet
implementationHow we made it stick.
Research experts first
Working sessions until every researcher knew the system end to end. Owners and advocates, not users.
Roadshows, pod by pod
Hands-on with every pod, honest about what it does and doesn't do. Honesty bought trust.
Company-wide share
One big launch moment for the whole org, then the real work of keeping it alive.
Research 101 in onboarding
Every new-hire group: a tour of how daters think, then one live prompt. Adoption by default.
Three years of a system the whole company used.
of sustained, company-wide use. Not a launch spike: a habit.
growth in monthly query volume since launch
employee empathy score, now sustained at 85 to 90
researcher upkeep time: filing a study fell from ~14 minutes of manual work to under 2
The quiet metric: "do we know anything about…" started going to the repository before it went to a researcher's DMs.
What the numbers don't show.
✓One of the first internal AI workflows at Hinge.
Live for employees before ChatGPT enterprise access existed, built out of research ops.
✓Leadership still cites it.
Execs point to this work as a place Hinge was ahead of the curve on AI.
✓Our advocacy became product.
Citations, reporting, and more shipped because we pushed. The tool got better for every customer.
✓It became part of Hinge culture.
Every employee knows HeyMarvin: we wove it into Hinge onboarding 101, so the repository is naturally part of the company's infrastructure. Even researcher setup docs lived inside it.
From pain point to part of how the company works.
Watching a system become a normal, invisible part of people's workflows is the deep joy of research operations: building the things that shape how work gets done.
05 · so what now?
Every great thing evolves at the right moment.
era 03 · the connected brain
so what now · the turnTools, and the needs of our org, evolve quickly.
→The org's tool priorities changed significantly.
Center of gravity moved to Notion and Claude, and query volume began stalling.
→Marvin's MCP abilities remained limited.
I built workarounds through Zapier and API connections, but workarounds only carry you so far.
→My own fluency kept growing.
Technology experimentation was pushing me toward building an even stronger system.
So what am I building now? The LLM wiki.
Put simply.
An LLM wiki is... a living knowledge base. When we add a new source, the AI doesn't just store it for later: it reads it, extracts the key ideas, and integrates them into the wiki.
· it compounds: most AI tools search, answer, and forget. The wiki reads once, so the synthesis is already done when you ask
· keeps everything current, linked, and honest about contradictions
· lets us control the schema: the rules we give the AI for how to structure, ingest, and maintain the wiki
the idea: Andrej Karpathy, OpenAI co-founder
Why not the obvious paths?
×Stay on Marvin and wait for MCP.
That's betting our roadmap on a vendor's roadmap. Our own instrumentation said the org was moving now, not next year.
×Move everything into Notion AI.
Search over documents is not synthesis: no research-grade citations, no taxonomy, no learning loop. It answers, but it never gets smarter.
✓Build the wiki, own the map.
The synthesis lives in GitHub and ports anywhere. Answers show up where people already work. And the switching cost lands on me, not the org.
What this looks like in real life.
setting the proper guardrails is very important.
✓Ask a research question right in Notion.
The wiki mirrors into Notion, so every insight lives where the org already works.
✓Query an insight from Slack, or from Claude.
Answers arrive in the place the question happened.
✓Engineers reach it from Claude Code.
The repository is one tool call away while they build.
✓And the upkeep is automated.
The wiki is prompted to scrub everywhere insights get socialized at Hinge: insights teams, data science, customer support, research.
✓It's our most connected tool ever.
Built on Claude and GitHub: add a new data source, or a new place people want to ask from, and we control both.
Two things make that safe: the schema, the file of rules that tells the wiki how to ingest, and a human reviewer at the right moment.
early days, on purpose. the current repository works: this is how we keep elevating it. that's the experimentation.
The wiki, in one slide.
· Scales with the org: a system that grows as we grow
· Human in the loop: a daily Slack digest asks me what to ingest. Judgment stays with people
· Lives in GitHub: it compounds on itself, and eng can reach it straight from Claude Code
· Feeds our channels: drafts our research digest, styled on the design system, that I only lightly adjust
· Proactive: scans threads and flags where an insight could help someone right now
· Lints itself: like a code linter, it checks for contradictions, stale claims, and orphaned pages on a schedule
The honest limitation: it's only as good as the sources we feed it. Which is exactly why the schema, and the human reviewer, matter.
06 · final reflections
What this chapter taught me.
Lessons from the project.
The understand phase is crucial
Deep understanding of the pain point is what made the solution strong, and what got XFN on board.
Meet people where they are
Every solution asks people to change. The impactful ones land in moments that matter without extreme disruption.
Adoption is half the solution
A good tool is no good unadopted. Being creative in how you onboard people is huge.
One pain point. Three eras. Still evolving.
the tool changed twice. the operating system never did.
Questions? Thoughts? Stick them on.
Anything you wanted to ask and didn't: leave it here. Every note lands on my board tagged to the slide it came from, and the ones we don't get to live in the parking lot until I follow up.
Yes, this is a working intake system inside a presentation about building intake systems. It felt right.
tagged to: closing questions
thank you for reading · come say hi.
→ recorded questions · open the boardtagged to: …