The Ten Skills of the Revenue Architect
OpenAI's Revenue Strategy and Operations posting pays a base of $239,000 to $265,000 and describes a builder rather than a maintainer. We read that job as…
We wrote about that posting in May, when the compensation number was the interesting part. The number is no longer the interesting part. What holds up is the shape of the job: a builder and an operator, fluent enough in go-to-market work to design systems against it, accountable for the infrastructure the whole revenue organization runs on. Read with an engineer's eye, that stops looking like a role definition and starts looking like a specification. We decompose it into ten skills, each of which is a full job somewhere else. What follows is that decomposition, one at a time, held to the standard we hold ourselves to. A skill you cannot point to an artifact for is a skill you are claiming, not demonstrating. Before the list, name what is not on it. Nothing here is CRM administration, dashboard maintenance, or reconciling three teams on a shared definition of a qualified lead. That work still has to happen, and someone still has to do it. It is not what this seat is being paid for. Every one of the ten assumes the person holding it builds: scopes, designs, ships, hands over, and stays accountable for whether the thing gets used. A team scoped as a maintenance function does not become this team by trying harder. The job is different, with different inputs, different outputs, and different evidence of success. Scoping is the discipline of finding the places where AI improves speed, scale, or quality, and declining the places where it does not. Bad scoping is easy to spot. A team bolts a model onto every workflow it can reach, ships a portfolio of demos, and discovers most of them were never worth building. Many AI pilots never reach production, and not all of that is bad engineering. Some of it is competent work aimed at a workflow that should never have been automated in the first place. Someone without this skill produces a long roadmap. Someone with it produces a short one and a list of the things they refused. Agentic design is the work of composing agents, automation, and integrations into a path a real case can travel, including the moment the system stops and a person takes over. The handover is where most designs fail. A workflow that escalates by dropping an item into a queue with no context has not routed the case. It has hidden it, and the operator on the other end starts from zero. Our document classification system resolves most submissions in moments and sends exceptions to a person with the full context already assembled. The exception handover is the design. This skill changes the arithmetic of everything above it. When the person who scopes the workflow also ships it, the distance from decision to working system is measured in days, and the roadmap stops being a negotiation with another team's sprint. One architect here shipped 1.3 million lines of production code in twelve months using Claude Code and Lovable. Without this skill, the revenue organization files a ticket, waits a quarter, receives a version of what it asked for, and learns that the requirement moved while it was waiting. The queue is not a staffing problem. It is a design constraint on how fast the commercial system can change. Prototyping is not speed for its own sake. It is putting a working version in front of the operator early enough that their feedback can still change the build. The alternative is the quarter-long disappearance: requirements gathered in week one, a system delivered in week thirteen, and a room of people who now have to explain why it does not match how the work is actually done. During an AI studio buildout we shipped several products in twelve weeks, and the first classifier processed a real submission on day 18 of the engagement. Meeting production data that early is what keeps correction cheap, because the thing being corrected is already running. Fluency across sales, marketing, customer success, technical presales, systems, finance, and enablement is not diplomacy. Fluency is the difference between a system that gets adopted and a system that gets approved. Most conflicts that look political are structural. Finance forecasts from contracted commitments, sales sells from observed usage, and the two are reading different tables. Someone without this skill builds a technically correct system for one function that quietly breaks the reporting of another. Someone with it finds the shared data layer underneath the argument and builds that instead, which ends the conflict rather than scheduling the meeting where it gets managed. A workflow that works for one team is a result. A workflow that every team with the same problem can run is an asset. The skill is knowing what to generalize: the decision logic, the thresholds, the escalation rules, rather than the surface of the deliverable. Without it, an organization accumulates one-off automations that each require their author to operate, and the author becomes the bottleneck they were hired to remove. The test is simple. Hand the template to a team that was not in the room and watch whether it runs without you in the thread. Nobody brings you a specification. They bring you a sentence: this process is broken, this takes forever, we keep making the same mistake. The skill is turning that into something buildable without a month of discovery. A 3 percent error rate on 500 monthly transactions sounds like a rounding error in conversation. Written as a specification it is 15 errors at 45 minutes each, eleven hours of rework a month, and a defined trigger the system can catch. Without this skill the complaint becomes a meeting, and the meeting becomes a recurring meeting with a standing agenda item nobody can close. Guardrails are what make an autonomous system usable by the people accountable for its output. Confidence thresholds, reasoning chains, audit trails, and a rollback path are not compliance overhead. They are the reason a director agrees to let the system act without reviewing every case. The failure here is familiar and quiet: a system accurate enough to run, trusted by nobody, so every output gets checked by hand and the automation delivers none of the time it promised. Accuracy is what gets the system built. Auditability is what gets it used. Enablement is the difference between a system that keeps operating after you leave and one that decays. In practice it looks like training, pair-building, and documentation written for the person who will be on call at seven in the morning rather than for the person who wrote the code. Every firm claims to engineer itself out of a job. The mechanism is what separates the claim from the fact: a runbook the team can follow, sessions where they build instead of watch, and a final cycle they run alone while you are still reachable. Without the mechanism, the claim is a line in a proposal. The last skill decides whether the other nine compound. A person who takes tickets will automate the workflows they are handed, competently, one at a time. A person who can sit with leadership and argue about the operating model changes which workflows exist at all. Before Concentric Lab, I grew one Fortune 500 account from under $1M to $30M in annual recurring revenue over about eight years. The work started with the commercial model, not the automation. Without this skill you get a faster version of the structure you inherited. This is the work we do in Strategy engagements. We take execution authority inside a revenue organization for eight to sixteen weeks, and the engagement is mostly these ten skills applied in roughly this order, starting at the data and ending at the team. We take on a small number of engagements a year and say no to most. We publish the artifacts rather than the capability list, because the list is easy to write and the supply of people who can demonstrate all ten is thin. If you are building the function internally, the list works as a hiring rubric on its own. I respond within one business day of a written inquiry.