Skip to main content

The Developer

A platform is a product, and a product has a customer. For an internal agentic platform the customer is not "the org" or "engineering" in the abstract — it is a specific person, with a stack, a backlog, a pager, and a healthy distrust of tools that promise magic. You design every layer against her, or you build something technically impressive that nobody adopts.

Standardization via authority isn’t enough. You can point to the demonstrated leverage of partnering to use the platform-provided offerings instead of appealing to the authority of the architect, database administrator, CTO, or platform VP.

Platform Engineering, Fournier & Nowland — Ch. 1

You do not win "the organization." You win this engineer, one workflow at a time. So make her real.

MO
Maya Okafor
Senior Software Engineer · Ads Platform
8 years · JVM + Python · owns a server-side ad-insertion service on the serving path
I'll adopt anything that gives me back my Fridays. But the first time it confidently breaks ad serving at 2 a.m., I'm out — and so is my whole team.

Goals

  • Ship features without the test-scaffolding and boilerplate tax
  • Cut the time she spends as a human dashboard during incidents
  • Keep her brand-safety and latency guarantees intact, every change
  • Onboard to an unfamiliar service in hours, not weeks

Frustrations

  • The “why” lives in Slack threads, old incident retros, and two senior engineers’ heads
  • Generic AI tools hallucinate internal conventions and invent APIs that don’t exist
  • Every new service means re-learning how to boot, test, and deploy it
  • Reviewing an AI change she can’t see the reasoning behind is slower than writing it

What the platform owes her

  • Grounded context: her services, runbooks, and past incidents, retrievable
  • Gated autonomy she can trust — risk-scored, reviewable, reversible
  • A golden path that works on day one, not a box of parts
  • Observability: she can see exactly what the agent did and why
Maya is the customer. Every roadmap decision answers to one question: would Maya be upset if this disappeared tomorrow? If the honest answer is no, it does not ship.
A composite persona for an Ads Platform engineer. Concrete enough to argue with — that is the point. A persona you can't disagree with isn't doing any work.

Why design to one person​

"Build for developers" is too vague to make a decision with. "Build so Maya can onboard to a service she's never seen, in an afternoon, without paging anyone" is a spec. The persona converts a fuzzy mandate into testable requirements — and it keeps the team honest about who they are not optimizing for this quarter.

It also reflects how platforms actually get adopted. Maya is a professional skeptic, and rightly so; she has been burned by tools that promised leverage and delivered cleanup. You earn her not with a demo and a mandate but by sitting beside her, solving a real problem on her real code, and letting the result speak. Win Maya, and her team follows. Lose her trust once, and no roadmap recovers it for months.

Weeks → hours
onboarding to an unfamiliar service, once context is grounded
Fridays back
toil — tests, boilerplate, triage — handed to gated workflows
Every change
her existing gates (review, risk, CI, monitor) enforced for her
One surprise
is all it takes to lose her — reliability is an adoption feature
The platform's value, stated in Maya's terms. If you can't express a feature as something Maya feels on a Tuesday, it probably isn't a feature she'll adopt.

What she will not tolerate​

Trust is earned per workflow and lost in a single surprise. These are the moments that set adoption back months — design the harness specifically to make them rare:

✕

A confident wrong

the trust killer

An agent that breaks the serving path while reporting success. One of these and Maya turns the whole thing off for her team.

✕

A path she can’t find

discoverability

A golden path that takes a Slack question and three tries to start is, to Maya, no path at all.

✕

A black box

opacity

A change she can’t see the reasoning behind is slower to review than to write herself. No observability, no adoption.

Each maps to a defense in the harness: gated, reversible autonomy for the first; a paved day-one path for the second; runtime and process observability for the third.

Designing every layer to Maya​

The persona is only useful if it drives the build. Each platform layer exists to answer one of Maya's needs — read the table as her requirements, not the team's features:

Maya's need → the layer that serves itrequirements, not features
Stop the knowledge living in headsThe context layer grounds agents in her services, runbooks, and past incidents — RAG at org scale.
Take the toil, keep the gatesThe development workflows automate tests, PR pre-review, and deploy validation under the same gates she already trusts.
Stop being a human dashboardThe operational workflows triage incidents and correlate logs and metrics so she diagnoses from evidence, not from scratch.
Be productive on a new service on day oneThe standardized environment gives every engineer the same paved path, configured once.
Let her see what the agent didThe observability layer exposes the trace, the cost, and the rubric score behind every change.
Earn her trust, then her team'sThe adoption work — pairing, champions, treating friction as a bug — is how Maya becomes an advocate.
Bottom-up, this is the same advice the book gives for any platform: build the foundation your customer stands on before the features she'll notice.

Maya is not the only person at the table​

She is the primary persona, but a platform serves several, and the book is explicit that they want different surfaces — which is why you "start not with the single pane of glass but with the APIs." Keep these others in view so the golden path has the right escape hatches:

SK

The Skeptic

has been burned before

Wants proof, not a pitch. Converting the skeptic on a real task is what turns one team. Give him the trace and the eval numbers.

OC

The On-Call

2 a.m., tired

Needs the agent to narrow the search space and propose, never act unattended on production. Read-only first, gated writes later.

NH

The New Hire

week one

Measures the platform by time-to-first-value. The grounded context layer is her fastest path from zero to a shipped change.

ST

The Staff Engineer

sets the bar

Owns the gates and the golden path. Wants the platform to enforce a floor on every change without being a bottleneck on any.

Different personas want different surfaces — CLI, IDE, ChatOps, API. Start with the APIs and let each persona's interface ride on top, rather than betting everything on one pane of glass.

The throughline: an internal platform is a product, and a product is built for someone. Make that someone concrete, design every layer to her, earn her trust before her adoption — and the platform spreads on its own.