Marketing at Wall Street English wanted to buy licenses for a platform that prints QR codes with trackable short links, for outdoor advertising and campaign tracking. It would have meant a recurring licence, a procurement cycle, a vendor relationship to manage indefinitely, for something that is simply encoding a test string in a QR code. I said give me forty-five minutes. That tool now sits behind every outdoor campaign we run, and all of our marketing short links, globally. Nobody has ever had to renew it.
I wrote earlier about the forward deployed engineer: someone with enough technical depth to build, enough commercial context to know what’s worth building, and enough communication skill to work at the boundary between the two. I described it then as a role AI companies are inventing for their enterprise clients. What I hadn’t shared yet is that a CPTO can do the same job for their own organisation, and probably should before asking anyone else to.
What I actually built
After the QR tool came dashboards. We kept reopening the same three reports and still couldn’t ask a new question of the data without asking someone to build a new report, waiting weeks for it, and getting in the way of whatever that team had actually committed to ship that quarter. That is the enactment gap again, just running inside an engineering backlog instead of a roadmap review. So I built a handful of small dashboards that pull straight from supplier APIs myself: one tracking spend across our AI tools, another on adoption of a specific platform, a third surfacing usage data a supplier already exposed but nobody had wired together. Each sits securely behind our existing login. The point was never to skip security. It was to skip the queue.
The clearest example is smaller than either of those. AI tools now generate HTML artefacts: small interactive microsites that are genuinely useful and almost impossible to share, because nobody attaches a webpage to an email. I built a tool that lets anyone in the business upload one and share it: company-only, with a named list of people, or with their group. It took two hours, and it is the one that is been used the most, because I wasn’t solving somebody else’s problem. I was solving mine, and I already had every piece I needed to solve it.
The next one is bigger. We run a global survey twice a year, hundreds of thousands of responses, and most of the effort around it has always been administrative: setting it up, tracking which countries were falling behind on responses, downloading and processing data and assembling the reports, before anyone gets to the actual conversation the survey exists for. I’m automating everything up to that conversation, which is the only part that will always need a person. Done properly, the survey stops running in waves and starts running continuously, and nobody’s job is to chase the admin around it.
The bottleneck isn’t skill
None of this required unusual engineering ability. What it required was three things most engineers on my team don’t have all at once: a working knowledge of how the business actually operates, the willingness to sit with someone using a broken workaround and ask what they’re actually trying to do, and, most importantly, access. I can create a subdomain, plug into our identity system, pull usage and supplier data, and ship something without asking six different owners for permission first. Most of my engineers have the first two. Almost none of them have the third.
This is the same argument I made about integration as a skill AI can’t replicate: the people who can move across a whole system, not just operate one part of it, are the ones who catch value nobody assigned them to catch. Access is what turns that breadth into something shippable instead of something merely observed. A generalist without access can diagnose the problem. Only access lets them fix it before the next planning cycle.
A CPTO’s Tuesday?
None of this fits how a CPTO is supposed to spend a Tuesday. The expectation, mostly unstated, is that you delegate, you review, you unblock, you do not personally open a code editor to solve marketing’s licensing problem. I don’t think that expectation survives the current moment. If you want a forward deployed engineer function to actually work inside your business, somebody senior enough to hold the access and the mandate has to prove the pattern first, in public, on real problems, before anyone else will trust the role enough to build a team around it.
That is also, honestly, the appeal. Designing a role by watching other people attempt it is a weaker version of designing it by attempting it yourself and noticing exactly where you got stuck. I know now that access is the constraint, not talent, because I hit that wall myself, repeatedly, on problems small enough that hitting it felt almost absurd.
Someone has to test which access barriers are load-bearing and which ones are just habit. Right now, I’m the only person with the keys to find out.
Leave a Reply