I have a confession. For most of my career I looked at the *-ops word cloud: DevOps, SRE, NoOps, AIOps, DevSecOps, FinOps, MLOps, DataOps, GitOps, PlatformOps and assumed the argument was technical. Tooling. Responsibility boundaries. It took me an embarrassingly long time to notice it was never technical. It was an influence fight over who gets to name the work engineers do and decide what "good" looks like next quarter. The vocabulary was the battlefield.
Second confession while I'm at it: the site is mine. I registered devpsyops.com in 2023 as a dry joke about the *-ops inflation and put a unicorn on the homepage. Look closely and the joke stops being a joke, because psyops is a real discipline, the US Army publishes a field manual on it and every platform team, every DevRel function, every engineering director I've met is running an amateur version of it on their own staff. Badly. Without a map. And calling it culture.
So here's a thought experiment. You're a platform engineering lead. Your mandate is "drive adoption of the internal developer platform." You have a roadmap, OKRs, a Slack channel with a mascot. What you don't have is any of the vocabulary actual influence professionals use every day: target audience analysis, information environment, lines of effort, behaviour-based measures of effectiveness. You measure "adoption" in logins. And you wonder why, eighteen months in, the staff engineers you most wanted to convert are quietly running their own Terraform and your exec sponsor has gone quiet.
You're playing chess without a board. Again.
PsyOps is an old, boring, industrialised craft
A quick reality check first. In 1991, during Operation Desert Storm, coalition forces dropped roughly 29 million leaflets on Iraqi positions, iterating message and design based on A/B tests run on captured prisoners of war to see which variants actually produced surrender behaviour. Behaviour-based measurement of effectiveness, at population scale, on paper, thirty-five years ago. Product management, circa 1991, with a better feedback loop than most platform teams have in 2026. And Edward Bernays had already written "The Engineering of Consent" in 1947 he chose the word "engineering" for the shaping of publics because he knew exactly what he was doing and wrote the manual. This craft is older than software. We're the amateurs, not the pioneers.
Where the influence layer actually sits on the map
Here is the map everyone already draws.
Start with the user at the top - your own engineers, the people whose behaviour the platform team is trying to change. Below the user sits the need: "I want to ship without pain." Below that sit the visible components - CI, deployment, observability, service catalogue, docs - strung out across the Product and Commodity end of the axis, and most platform teams can tell you roughly where each one sits. Fine. That's the bit everyone draws.
Now drop one layer further, to the thing no-one draws: the narrative layer.
Internal comms, brown bags, the quarterly roadshow, the champion programme, the "bottom-up, top-down" PlatformCon talking points, the executive whisper network, the anonymous complaints in #random. That layer has a value chain of its own: target audience analysis, message design, channel selection, delivery, feedback, iteration. On the map it hangs beneath the tooling, holding it up - because it directly determines whether any of the kit above it gets used.
Now look at where that layer has landed on the evolution axis. Go on, track it back to the left edge of the map.
In almost every org I've seen, it sits in genesis. All of it. Hand-rolled. Bespoke. Undocumented. The platform lead is writing internal comms from a blank Google Doc on a Sunday night. The staff engineer with the "Right Hand" archetype, Will Larson's name for the one openly acting as political advisor to a VP, compared to the Hand of the King and Leo McGarry is doing target audience analysis in their head and calling it "reading the room." DevRel measures engagement in likes because nobody has taught them to define a behaviour-based MOE. The feedback loop is a retrospective where someone says "we need to do more internal marketing" and everyone nods. There is no doctrine. There is no playbook. There is barely a vocabulary.
Meanwhile, the vendors your engineers read every morning are operating the same layer at commodity scale. Gartner booked $6.3 billion in 2024, largely from the same vendors whose products it rates and when challenged in court, Gartner's successful defence was that the Magic Quadrants are "opinion", a legal win and a strategic confession in the same breath. IT Revolution runs the conference circuit and publishes the canon. Microsoft renamed Visual Studio Team Services to Azure DevOps on 10 September 2018 and walked off with the word the community had spent nine years building. That was not a product launch. That was a vocabulary capture operation. It worked.
This is evolution-axis asymmetry, and it is the most important feature of the landscape no-one is drawing. Your internal influence layer is in genesis/custom, fragile, personality-dependent, running on the unpaid glue work Tanya Reilly named so precisely. The vendor influence layer aimed at the same target audience is fully industrialised: analysts, conference tracks, certification programmes, sponsored benchmarks, practitioner books that use "marketing" where your team says "community". One side is hand-drawing on a napkin. The other side has an artillery battery. And the asymmetry is not weather it's a business model. Engineers pay the cognitive rent; vendors collect the attention rent. That is the economic relation underneath the word cloud, and it stays invisible precisely because the amateur version stays in genesis while theirs runs at commodity scale.
Doctrine versus gameplay, stop selling one as the other
The psyops frame forces you to separate doctrine from gameplay, and almost no-one does.
Doctrine is the universal bit. It applies whether you're a bank, a bakery, or a government department. "Know your user" is doctrine. "Define the behaviour you want before you measure anything" is doctrine. "Don't confuse engagement with effect" is doctrine. "Psychological safety is the precondition for everything else" is doctrine, Amy Edmondson wasn't writing context-specific advice. The SPACE framework treating satisfaction and communication as load-bearing dimensions of productivity doctrine. The DORA evidence that generative culture predicts delivery performance doctrine. A platform team that cannot state its doctrine in one page shouldn't have a budget.
Gameplay is the context-specific bit. "Rename your product Azure DevOps and walk off with the attention territory your competitors built" is gameplay. It worked for Microsoft in 2018. It would be idiotic for anyone else. "Mandate adoption from the CTO's office" is gameplay 36.6% of platform teams in the 2024 Humanitec survey are doing it, and roughly 40.9% can't prove value inside twelve months, which tells you something about whether the mandate is doing the work people think it is. "Pilot with three volunteer teams" is gameplay. "Hire an internal DevRel" is gameplay. None is right or wrong in the abstract. They are right or wrong for a specific landscape at a specific moment.
The consultant move and I mean the move, not the person is to sell gameplay as doctrine. "You need a platform." "You need a champions programme." "You need a golden path." These are gameplay options that depend entirely on where your components sit on the evolution axis. Offering them as universal prescriptions is the same category of error as selling one *-ops label regardless of context. Expensive prattle, and dressing it up in the language of developer experience doesn't change what it is.
The unseen landscape
So what's actually unseen? Three things, and if you map nothing else today, map these.
First, the target audience. Not "developers" as a generic noun a specific, segmented audience. The BICEPS-core-needs-aware staff engineer with scar tissue from the last platform migration is not the same audience as the new grad who'll happily use anything with good docs. You cannot run one line of effort at both. You know this in product. You've forgotten it internally. And remember the mascot on the homepage: in Gene Kim's Phoenix Project frame, unicorns were the mythical high-performing teams Netflix, Etsy and horses were the rest of us. The unicorn on devpsyops.com isn't the mascot of the discipline. It is the target audience of it. The whole internal influence machine is pointed at convincing the horses they ought to want to be unicorns, and the horses have noticed.
Second, the feedback loop. Every amateur psyop I've seen treats adoption dashboards as feedback. They are not. They are outputs. A real MOE asks: what behaviour changed, in whom, for how long, compared to what counterfactual? If your answer is "logins went up," you are measuring the wrong thing. DevEx research from Noda, Storey, Forsgren and Greiler already tells you the dimensions that matter feedback loops, cognitive load, flow state and none show up in a login count.
Third, the doctrine itself. Write it down. One page. What does your platform team believe about how humans adopt tools, about psychological safety, about mandates, about volunteer pilots, about the moral status of internal comms? If you can't write it down, you don't have one, which means every new hire is reinventing it on a Sunday night. That is custom-built. That is genesis. That is where your costs are hiding.
The humble close
I might be wrong about a lot of this. The mapping might not translate cleanly to your organisation. The doctrine I'd argue for might be a fluke of the three or four environments I've watched closely. Gameplay definitely varies what worked at one platform team will misfire at another.
But what I am not hedging on. The influence layer exists in your organisation whether you name it or not. Every engineering leader is already running a psyop on their own people with no vocabulary, no doctrine, no feedback loop worth the name, and a unicorn on the wall they haven't noticed is pointing at them. Naming the work as what it is influence operations on a knowable target audience, with doctrine you can teach and gameplay you invent is the honest version of the job the industry has been renaming for fifteen years to avoid admitting what it does.
Draw the map. Start with the narrative layer, not the tooling. Plot where your internal influence work sits on the evolution axis, then plot the vendors'. Look at the gap. Feel slightly ill. Write down your doctrine. Kill half your gameplay. Try the other half and see what breaks.
And before you close the tab: the unicorn on the homepage isn't looking at you. You are looking at it. Convincing horses they ought to be unicorns is the whole job, and you've been doing it unpaid, uncredited, without a map, for years. The amateurs ran 29 million leaflets past POWs in 1991 and called it doctrine. You can at least write yours down by Friday.
(Views in this article are my own.)