For eighteen months I ran technical program management for the internal GenAI platform: the layer every other engineering team reaches for when it wants to use these models. One way in, one set of credentials, one place where evaluation, support, and spend live. Most people never see it. They see the assistant in their editor, and the platform is what let that exist without each team building its own.
A TPM belongs on that layer for a specific reason. Almost nothing that blocked a team from shipping with these models was a modeling problem. It was whether they could get access this week instead of next month, whether the security reviewers had seen the design, whether anyone had agreed on what a good answer looked like, and whether there was a named human to ask when it broke at night. None of those get solved by a better model.
What a GenAI platform actually is
- A gateway. One way for every team to reach models, so a provider change does not turn into a separate migration for every team.
- Assistants and agents built on it. The products people touch, from chat assistants to agents that take multi-step action.
- Tooling that exposes existing services to agents. A backend team can offer what it already runs without rewriting it.
- Retrieval over internal knowledge. A model that knows the public internet and nothing about this company is a demo, not a tool.
- Evaluation and model operations. How you decide a change made things better, and how you keep it that way.
And what actually decides whether anyone can use it, which is nobody's favorite job:
- Access provisioning, and spend somebody answers for. Who gets in, how fast, who is allowed to say no, and who watches the usage.
- Identity for non-human callers. An agent is a caller. It needs a principal, and that principal is not always a person.
- A support model. The named path from a broken thing to a human who can fix it.
The operating model
A program that touches every engineering org has one recurring failure mode: it goes invisible. Work happens in more places than any one person can watch, decisions get made in private threads, and by the time a problem surfaces it has already been blocking someone for weeks.
- A recurring execution review on a fixed cadence. The open security and legal questions went on the agenda instead of sitting in somebody's inbox. Putting a question on an agenda gives it a date.
- An advocate network. I recruited people inside each org so the platform team was not the only channel into engineering.
- A monthly builders' session. Practitioners taught each other and the platform team mostly listened.
- A newsletter. The people who never attended anything still knew what changed.
Project Examples
Agent tooling infrastructure
I ran program management for the work that let backend teams expose services they already operated to agents, without writing new code. That meant driving a focused quality push before the interface stabilized, co-owning a weekly design forum where we settled interface questions, and keeping one shared status document current. The status document sounds trivial. Before it existed, each team maintained its own version of the truth.
Flagship use cases as an adoption strategy
I coordinated four flagship use cases in parallel, chosen to be deliberately unlike each other so most teams could see themselves in at least one. A flagship is a proof another team can copy, which makes the TPM job unblocking rather than building.
Access, identity, and spend governance
I owned the exception process for enterprise model APIs, account provisioning, spend monitoring, external partner access, and a move to more tightly scoped access. The agentic side raised identity questions that are genuinely new. An agent acting on a person's behalf is not the same principal as that person, and very few access-control systems in wide use were built with that distinction in mind. Those questions have no settled industry answer, so we made local decisions, wrote down why, and shipped.
A cross-org task force for data practitioners
I founded and led a task force for data practitioners, a group the platform had under-served because the tooling assumed a software engineer on the other end. I grew it into a cross-org group covering seven workstreams and wrote a dual-track framework that separated what the platform would fund from what the task force would prototype itself, plus a roadmap of tools for that group.
The Champions network
I ran the advocate network with roughly 40 advocates across six engineering orgs: a biweekly sync, a dedicated channel, engagement I tracked against targets I set with their managers, and a route that carried their feedback back into planning.
The builders' series and the newsletter
The builders' series ran as a monthly hour where engineers demoed what they built. It drew 75 to 300 attendees, and it is what the 900+ member community I founded earlier eventually became. Engineers will sit through a peer showing something rough far longer than a polished platform update, and the demos were where I heard about use cases we had not planned for.
Handing it over
I wrote a long-form handbook for the role and a second for the data practitioner program, then transferred every workstream to new owners. The handbooks covered the mechanics.
What I would tell a platform TPM
The bottleneck is almost never the model. It is access, evaluation, and whether anyone trusts the output enough to put it in front of a customer. The ask is usually a better model. The unblock is usually a provisioning path and an agreed definition of a good answer, and both of those are yours to drive.
Security review is a design input, and on agentic systems it is the design. What an agent may do, on whose authority, and with what audit trail are not constraints bolted onto a finished system. They determine its shape. Scheduling security late does not cost you a review slot, it costs you design decisions you thought were settled.
A falling adoption number is the most useful signal you will get. When usage of one tool drops because engineers moved to a better one, that is the roadmap telling you something you did not think to ask. The instinct is to defend the number, and it is wrong. I learned more from chasing where the users went than from defending where they used to be.
A platform team's actual product is other teams' velocity. Instrument that, not your own feature count. Shipping capabilities nobody adopts looks like progress on a status update and changes nothing. A quarter where you shipped little and other teams launched on you beats one where you shipped a lot and nobody did.
The parts of your program that only exist in your head are the parts that fail the week you are out. I found mine by writing the handbook while I was still doing the job rather than on the way out, which turns it from a record into a diagnostic. Every section that was hard to write was a section nobody else could have run.
Skills
Technical program management · GenAI platform and infrastructure · AI assistants and agents · Agent tooling and interfaces · Retrieval over internal knowledge · Model evaluation and operations · Access and identity governance · Spend governance · Security and legal partnership · Cross-org program leadership · Advocate and community programs · Developer enablement · Platform adoption strategy · Technical writing · Python · SQL
