At the start of 2026 I moved from platform engineering into applied research. My programs used to have a shape I understood: a platform team builds a capability, engineers adopt it or they do not, and my job was to close the distance between those two things. A research organization does not have that shape, and it took me a while to stop reaching for the tools that used to work.
How research programs fail differently
A platform program fails by missing a date, and you can see it coming. The dependency slips, the launch moves a quarter. A research program almost never fails that way.
It fails by becoming illegible: nobody outside the group can say what is being worked on, what was learned recently, or what would be lost if the work stopped tomorrow. It is the more dangerous failure, because it stays invisible until someone senior asks and nobody can answer.
The scarce resource is compute, not schedule. On a platform team the constraint is engineering time, managed by sequencing. In research the constraint is what the group can afford to run, and adding people does not relieve it.
What a research team produces is knowledge before it is a product, and knowledge does not appear on a Gantt chart. A team can spend real time and arrive at "this approach does not reach the quality bar, and here is the evidence." That is a good outcome, and a reporting system built around shipped artifacts will quietly score it as a bad month.
How I run it
I spent the first ninety days inventorying what existed rather than improving anything. It felt slow. You cannot prioritize a portfolio you cannot see, and anything I fixed in week two would have been aimed at whatever was loudest that week.
Objectives and key results have to survive research uncertainty, which means writing them about questions rather than features. "Ship this capability" is not a promise a research team can honestly make in the first week of a quarter. "Determine whether this approach holds up at production quality and write down the answer either way" is, and it is still checkable at the end.
All of it lives in one written source of truth for the portfolio, with a research plan that says what is being tried and why. My test is whether a new person can orient without a meeting. If they cannot, the document is not finished, and the cost shows up later as meetings that exist only to explain it.
Selected work
Making an untracked portfolio legible
I took over a program running many concurrent workstreams with no shared tracking. Early on I produced a project inventory, a written research plan, a single place the group actually posts updates, and a planning cadence people would use. I own the ongoing objectives and key results reporting, which is what keeps the inventory from going stale.
Getting research into production workflows
I led the go-to-market for research tools from this group reaching production creative workflows: the launch plan, user-facing guides, a support runbook, an on-call rotation, and a support channel. The launch is not the durable part. The durable part is the template: a repeatable way to take something out of research and support it once people depend on it.
Getting separate teams onto one plan
Several data tracks had to land together, and the teams solving each piece had never shared a plan. I structured the tracks and got them onto one. Most of that was getting the groups to agree on what a word meant before agreeing on a date, which sounds like pedantry until you watch two teams discover in month three that they meant different things by the same noun.
Reframing a competitive evaluation as a collaborative one
Two teams were heading toward a head-to-head comparison of two approaches to the same problem. With the product manager, I reframed it as a joint experiment with a shared write-up, so the output was one document about what each approach is good for rather than a verdict about who was right.
An intake process for external creative partners
Requests from outside creative partners used to arrive as an email thread. I replaced it with a structured questionnaire, routing into a single channel, a script that generates a formatted review document per submission, and a notification workflow so a review committee could work async instead of meeting.
Building my own tooling
I built a pipeline that turns a large set of session recordings and documents into a narrated, animated video summary, using agentic coding tools, a text-to-speech engine, and a programmatic video renderer, with several coding agents working in parallel. I also run a scheduled daily briefing that assembles my day into one prep document.
What I would tell a TPM moving into research
Do the inventory before you fix anything. The inventory is the work, not the prelude to it. What makes this hard is that an inventory produces nothing anyone can point at for a long stretch, so you will be tempted to ship a small fix just to show motion. That fix will land on whatever was loudest, which is rarely what is most broken.
Research teams do not need more process. They need less ambiguity about what counts as done this quarter. When a research group looks disorganized from outside, the reflex is to add ceremony, and ceremony is exactly what makes them slower and less honest with you. What is missing is a shared definition of what a finished question looks like.
Compute is the real roadmap. What the group can afford to run decides what gets tried, and therefore what gets learned. Treating that as an infrastructure detail to sort out later is how you end up defending a plan that was never physically possible.
Build the thing yourself once. You will write a far better requirement afterward, and you will stop asking teams for things that turn out to be expensive for no good reason. Plenty of the requests I used to write casually had a hidden cost I could not see until I hit it myself.
Skills
Technical program management · Research program management · Engineering operations · Objectives and key results · Compute and capacity planning · Vendor evaluation · Go-to-market strategy · Launch and support operations · On-call and runbook design · Cross-functional coordination · Data pipeline coordination · Model evaluation · Partner intake design · Onboarding and knowledge management · Technical writing · Python
