Oscar Armas-Luy

The through-line

Across everything Oscar Armas-Luy says runs a single conviction: complexity is usually a surface phenomenon, and the job of revenue operations is to strip it back until only the things that can actually be managed remain. He arrived at that view from an unusual direction, having studied business and computer science and worked through the history of AI in coursework that started with seminal papers from the 1960s on simple classification models and ended at modern LLMs [1]. The lesson he took from that sequence was that "things that we as humans consider to be very complicated or very high-brow, usually have some type of simple underlying structure" [1]. The same instinct shows up in how he runs reporting at Garner Health, where the effort in 2026 is to cut dashboards back to the inputs and outputs of the growth machine, and in how he uses AI, which he treats as a pattern machine rather than a source of magic.

What has shifted is the scope of the tool rather than the philosophy. A year earlier he was dropping into AI at isolated points in a project, handing it a single task with no context and moving on, "sometimes useful, sometimes not" [1]. Now he uses the pro-series models with larger context windows at the inception of a project, at the task level, and again when planning how to operationalise and test the work, describing the change as moving from "someone that's going to help on individual tasks to really a thought partner throughout the entire life cycle of the project" [1].

On metrics tourism

Metrics tourism is his own coinage for the RevOps habit of building dashboards because a data point would be interesting to look at rather than because anything follows from it [1]. He accepts that the material often is interesting. The test he applies instead is whether a number is part of the growth machine: "what's going to drive your results is really what is your growth machine and then what is the telemetry? What are the inputs outputs of that growth machine and how can you manage them?" [1]. His goal for the year has been to get reporting in place so that it contains only those inputs and outputs, and nothing else [1].

He is explicit about why the permissive answer is wrong. The common error, as he puts it, is asking "what's the harm in having an additional dashboard or what's the harm in having some more data?" [1]. The harm is cognitive: "our brains just can't handle that many numbers, that many things to worry about, and you can't manage to it" [1]. Restraint is therefore not austerity but capacity. Staying laser-focused frees up the bandwidth to actually move the numbers that matter [1].

On AI as a pattern machine

His advice to people entering AI now is to understand where it came from, because the history makes the present less mystifying. Working forward from handwriting and plant classification models to LLMs gave him a frame he still applies: at the end of the day these are pattern machines [1]. The insight he finds hardest for people to absorb is that language itself has patterns. "We tend to think of language and writing and speaking as very creative endeavors, but at the end of the day there's clear mathematical patterns behind these things" [1]. Once you have seen how simple building blocks turn pixels on a screen into a recognised nine or seven, he argues, holding that in mind while using ChatGPT or any other LLM "can give you a different way to look at the sort of magic" [1]. The practical corollary cuts the other way too: models "can understand and intuit a lot more than we give them credit for" [1].

On building dashboards out of spreadsheets

The main thing his team does with AI is, in his words, "up-level our spreadsheet game" [1]. The reasoning is deployment. Ask an AI to code and it will often hand back a Python script that leaves you asking "Okay, like now what do I do with this?" [1]. Build the same logic into a spreadsheet and "it's already packaged, you can deploy it, it's a thing people and all of us know how to use" [1]. Every major spreadsheet platform lets you write code on top of it, from VBA in the Microsoft world to Google Apps Script, and he uses foundation models such as Claude, ChatGPT and Gemini to supercharge that layer [1]. The specific stack at Garner Health is Google Sheets, Gemini and Google Apps Script, with Apps Script connecting to Salesforce and other systems through their APIs [1].

The division of labour inside the spreadsheet matters to him. As much logic as possible stays in the cells and formulas everyone already understands, and he turns to Gemini only where those fall short, generating code that defines custom functions or puts a refresh on a nightly schedule [1]. The point of the whole approach is to get around the limits of Salesforce dashboarding and other dashboarding programs by building the reporting himself [1].

On who owns the reporting

There are no engineers on his team. It is made up of business people from RevOps or RevOps-adjacent backgrounds, and ownership of reporting follows ownership of the business area: whoever owns the area is responsible for their own spreadsheet being set up correctly and producing the output they need [1]. When someone gets stuck or cannot get anything useful out of Gemini, they ask, and usually another team member has a tip or a trick [1]. It is a model where the escalation path is peer knowledge rather than a specialist function.

On driving adoption by showing the art of the possible

He seeded adoption with one deliberate demonstration rather than a mandate. He picked a high-profile dashboard that was already causing pain, one that someone was updating manually every week at a cost of two and a half to three hours, and which was complicated enough that small errors always crept in no matter how hard that person tried [1]. He "got in the tank" with Gemini and ChatGPT, using two models, and automated it [1]. He had two objectives going in: show what was possible, and "create as much like reusable building blocks that people can steal" [1]. Adoption followed on its own, with the rest of the team automating their own work once they saw it done, and other departments beginning to ask questions [1].

On prompting, pressure-testing and confirmation bias

He uses deep research for two situations in particular: when he has a contrarian idea, something uncommon or against the mold, that he wants to pressure test, and when he is heading into vendor negotiations [1]. The method is to ask for the problem to be analysed from the counterparty's perspective, from a game theory perspective and from a finance perspective, producing a document of around fifteen pages that he prints and reads [1]. He is candid that the value is not extraction. "It's not like there's anything in that doc that I'm like oh, like I should use this. Like it's more like it gets the creative juices flowing. I'm like oh, I didn't really think about it this way" [1].

He is equally attentive to how much a single instruction can change output quality. His example is trivial by design: he photographs restaurant wine lists and asks ChatGPT what he would like, and after a run of poor recommendations he added one line, "If you don't see anything I'll like, don't recommend anything" [1]. The results, he says, skyrocketed [1]. The general principle is that giving the model permission to return nothing, and asking it to argue against you, is what stops it from telling you what you want to hear.

On what leadership actually expects

Asked what leadership expects of him around AI, he gives what he calls a boring answer, and means it as a corrective. AI is like any other tool: leaders expect results, and if you are running a budget they expect a reasonable return on it [1]. Nothing about that has changed. "AI is just what we're using to accelerate the results that our leaders already expect of us" [1].

Takeaways

• Coined "metrics tourism" for dashboards built because a data point is interesting rather than because it belongs to the growth machine, and is rebuilding 2026 reporting at Garner Health to contain only the machine's inputs and outputs [1]
• Rejects the "what's the harm in one more dashboard" argument on cognitive grounds: brains cannot hold that many numbers, so unmanageable reporting crowds out the metrics you could actually move [1]
• Builds reporting as Google Sheets plus Google Apps Script plus Gemini, connecting to Salesforce via APIs, because a spreadsheet is deployable and familiar in a way a generated Python script is not [1]
• Keeps as much logic as possible in ordinary cells and formulas, reaching for AI-written code only for custom functions, scheduling and anything the formulas cannot do [1]
• Seeded team adoption by automating one painful manual dashboard that took 2.5 to 3 hours a week and always contained errors, deliberately building reusable components others could steal [1]
• Runs reporting with no engineers: whoever owns a business area owns its spreadsheet and output, with peers as the first line of support [1]
• Uses deep research to attack contrarian ideas and vendor negotiations from the counterparty, game theory and finance perspectives, valuing the output as a prompt for new thinking rather than as usable text [1]
• Has moved from using AI on isolated tasks with no context to using pro-series models as a thought partner across project inception, execution, operationalisation and testing [1]