470- Being 100% Correct Isn't Enough w/Devon Simmons

Chris Stierle, Chief Information Officer at TemperPack, has not found a viable use case for agentic AI in business process automation, and he explains why repeatable work and predictive models do not fit. He also gives CEOs the four things to understand before they hire an IT leader. Chris Stierle holds a four-digit CCIE, and he says the lab humbled him. What stayed with him is systems thinking: the value of any system is in the interconnects, not the entities. Phil puts it to the test with a game, asking him to explain a late collision to a CEO, then a network upgrade, then multi-factor authentication. Then AI. Chris treats it as the top abstraction layer on everything built over the last two to three decades, and says it will not scale without structured data. He has not found a viable use case for agentic AI in business process automation: agents are predictive, the work is repeatable, and the loops cost a lot of money. He is clear that this is about agentic AI for BPA, and that AI in manufacturing is a huge space. For the CEO hiring an IT leader, he names four pillars that connect: data architecture, cybersecurity, agile delivery and platform engineering. He uses agile data as a shield, not a sword, backs diversity of thought because he likes to win, and argues that the next move is to wrap bits around atoms. Key takeaways: Before you build an agent for a back-office process, check whether technology that has been around for five years already does it for less; Get your business processes in order first: you don't want to automate chaos; Build the structured data before you try to scale AI; agents without an enterprise data warehouse stay proofs of concept; When you interview an IT leader, ask about the things that are standard, and ask them to describe an ETL pipeline end to end; Consider a fractional executive when you need a new leader and want to see them in the role first; Use agile data to protect an overworked team and prioritize its backlog, not to go after people. Chapters: 00:00 Cold open 00:34 Meet Chris Stierle: the CCIE lab and big egos 04:04 The game: explain a late collision to a CEO 09:29 Systems thinking and why networks are the backbone 15:49 Not sold on agentic AI for BPA 23:43 The game reversed: network upgrade, integration, MFA 28:01 How a CEO knows they hired the right IT leader 31:29 The four pillars: data architecture and cybersecurity 36:21 Agile delivery: a shield, not a sword 44:48 Diversity of thought, because he likes to win 50:01 CapEx, OpEx and depreciation 54:38 Bits around atoms, and patience

Shane Froebel, Chief Information Officer, joined a hospital as VP while it was losing its computer systems for four to six hours every week, and decided on his first day that fixing it was squarely on him. He explains the memo that stopped unreviewed production changes, the meetings that got a 50-person infrastructure team talking, and why he offers to be the reference for anyone on his team who wants to leave. Shane Froebel is a Chief Information Officer with more than 15 years of IT leadership. On his first day as VP at a hospital, sitting in orientation as the only VP in the room, he heard that the hospital had a code black every week: the computer systems went down for four to six hours, and staff were told it was nothing to be afraid of. His reaction: "That's going to be squarely on me and that's something I have to fix." He walks through the fix. He met with every one of the 50 people on his infrastructure team, rebuilt rapport with the doctors and nurses, and asked what the hospital was trying to do. Then he sent a memo: "Dear staff, as of today, you're not to make any more production changes without my express consent." It slowed the team down for a while, and he was fine with that: "I'd rather have no outages than outages." He explains the standing meetings that got the network, server, project management and service desk teams talking in a set order, because "the network builds on everything else." He also tells the story from his first hospital of equipment that was signed off as implemented and turned up in the storeroom, in boxes, still not even opened. The last part is about people. Shane translates cloud and scalability into business terms, using COVID as the example: when the hospital needed staff working from home, the software was already in place. He says IT leadership doesn't have to be the most technical person in the room, and he tells his team that if they want to leave, he'll be their reference and help them build the skills for the job they want. "The benefit of that, by the way, is not for people to leave, it's for people to stay." Key takeaways: Put every production change through one review until the outages stop, and tell the team up front it won't be forever; In your first weeks, meet everyone on your team one on one and ask what they think the problem is and where it could improve; Before you buy anything, walk the inventory: list what was bought, then go find it and check it was really implemented; Run your team meetings in a set order, starting with the teams everyone else depends on, so each team hears what's coming before its turn; Give people a direct line to you when there's a problem, and treat the quiet as the goal: "If I don't hear from you, that means everything is going good."; When someone wants to leave, offer to be their reference and help them build the skills for the role they're after. Chapters: 00:00 Cold open 00:46 From a Tandy 1000 at age 2 to IT leadership 05:08 Code black every week, and his first three moves 12:51 Resiliency, survivability, scalability, and keeping it simple 20:23 "Dear staff": no production changes without his consent 23:45 Signed off as implemented, still in the boxes 27:32 Winning respect one win at a time 35:49 Four teams and three standing meetings 48:34 No judgment: why every leader needs a safe person 56:17 What CIOs get wrong, and why infrastructure comes first 1:09:58 Translating cloud and scalability for the business 1:14:50 The one promise: I'll be your reference

Devon Simmons, an IT manager, learned that a solution can be technically correct in every aspect and still stall without a business case the C-suite can get behind. He thinks back to a four-site move from MPLS to SD-WAN on Cisco Meraki that got approved once he came back with the outages and the ROI, and explains why he asks where the data is going before anyone picks the next AI tool. Devon Simmons once brought the C-suite a network overhaul that was "technically correct in every aspect." Four sites were moving off MPLS to SD-WAN, on Cisco Meraki, with the option of two ISPs at the cost of one and the redundancy the sites badly needed. The room understood it to a degree, but they were looking at the pricing on the paper. So he went back to the drawing board, put the ROI next to the upfront costs, and brought the outages: multiple a week, while the company spent thousands and thousands of dollars a month on MPLS. The project went ahead in phases, firewalls and switches first, once the business case was right. "That being 100% correct definitely isn't enough." He opens on AI and data. The first question he hears is which AI tool to use, and nobody asks where the data is going. With a standard ChatGPT Pro subscription, he points out, you have to go into the settings and tell it not to train on your data. He wants AI subscriptions run through IT and the identity provider, without restricting anyone from the tools. He also shares how he connected Claude to their NetSuite ERP over MCP, and how it found a bug across several script deployments in an afternoon instead of a few days. Then the path that got him here: shutting down every display computer at Cons Electronics as a kid, applying to Geek Squad from 16 in a button-down shirt and tie, and getting in at about 19 or 20 with half an A+ from trade school. He tells his own kids A+ first, "without a shadow of a doubt." He tells the story of an ERP module he had to abandon and why he's never a fan of buying on the promise of updates later, why he asks vendors for customer references, why security should be more than a line item, and his advice to his younger self: keep your ear to the ground and never stop learning. Key takeaways: Before the first meeting, put the upfront cost next to the ROI. A solution the C-suite can't digest won't get approved, however correct it is; Bring the outage numbers and what the old circuits cost every month. For Devon, multiple outages a week against thousands a month on MPLS was the argument nobody could fight; If the whole ask is too big, phase it. He started with firewalls and switches, and the project was approved once the business case was presented properly; Don't buy a product on the promise of updates later. Ask the vendor to send the hardware so you can test it, and ask for a customer who uses the tool the way you would; Before you pick an AI tool, find out where your data goes. Check settings like ChatGPT's training option, and run subscriptions through IT and your identity provider instead of blocking people. Chapters: 00:00 Cold open 00:52 Where is our data going? 05:24 Claude, NetSuite and MCP 13:27 Being 100% correct isn't enough 14:41 Four sites, from MPLS to SD-WAN 21:14 Back to the drawing board: outages and ROI 27:29 From Compaq Presarios to Geek Squad 32:25 A+ first, then pick a path 39:24 Pulling the plug on an ERP module 46:19 Security is more than a line item 54:16 Keep your ear to the ground 1:02:38 Proper planning, and learning to communicate

Desi Rodriguez, Director of Information Technology at Tilson Homes, says the IT leaders who get ahead learn how every other department works, so they don't come in like a wrecking ball. He explains how he answers vague AI requests with the question he once asked about SharePoint, and how he puts tech debt into hours of downtime for a CFO. Desi Rodriguez was eight years old, on a field trip to a sewage plant, when he got fixated on the bank of monitors in its NOC. From there he went through a Cisco Systems Network Academy pilot program in high school, an internship at AMD, a two-year degree from ITT Tech, State of Texas agencies and IBM, where he became a Citrix SME and spent six months in Bangalore training Citrix technicians. Then he answered a post for a systems administrator at Tilson Homes, a custom home builder in Texas, where he is now Director of Information Technology. It'll be 15 years in December. He has advised the company to hold its breath on AI until there are business justifications, from the executive committee or department by department. The requests he hears are very vague, and they take him back to SharePoint at the state: his bosses asked what it does, he asked what they wanted it to do, and nobody had a clear answer. On spend, he works from a daily dollar figure the accounting team and the C-suite worked out, what the company loses when it isn't running, and he puts tech debt into hours of downtime for the CFO. Respect is one of his top relational needs, and for him it means nobody keeps IT from knowing about an initiative and then expects his team to fix it when it doesn't work. His one lesson for other IT leaders is to learn how the other departments work and build relationships before you need them, down to talking trucks with a drafter at Home Depot. He closes with what he'd tell his younger self: be humble, and learn to say no respectfully and to the right people. Key takeaways: Learn how the other departments work before you change anything in them. You'll make smarter decisions about IT spend and direction, and ruffle fewer feathers; Build relationships before you need them, then ask the decision makers to help you pilot what's coming. You get more buy-in that way; When an AI request is vague, ask what they want it to do, and ask for business justifications before anyone buys licenses; Put tech debt into hours of downtime, so the business can turn it into money with its own daily figure; Tell other leaders, respectfully, that IT needs to know about an initiative before it's pushed through; Assume people may just not know. Give your team the reasons behind the rules, so they can say no with a clean, concise answer. Chapters: 00:00 Cold open 00:37 Meet Desi Rodriguez: from a NOC on a field trip to Tilson Homes 06:57 A resilient network for a seven-day-a-week shop 16:38 AI requests and the SharePoint loop 19:20 Cash flow, job costs and a first AI use case 27:51 Growing into new markets with a homegrown CRM 31:50 Relational values and "That's disrespectful" 40:17 Hiring for a passion for the industry 44:42 One talk for IT: learn how the business works 48:14 Getting past the fear: grace and a pink keyboard 51:14 Tech debt for a CFO: hours of downtime 54:33 Advice to his younger self: be humble, learn to say no

Alexandre Quinze, former CIO for Latin America at Philips, says that when IT isn't heard, it's usually IT's own doing, and the way back starts with understanding the CFO's pains. He explains how he picked just enough technology for a startup heading to Series C, how he turns cyber risk into dollars with FAIR, and why an unlimited budget would go to changing people's behavior. Alexandre Quinze studied engineering with a sandwich degree at Seattle U, lived through Y2K and the dot-com bubble in Silicon Valley, and went on to work in Brazil, Germany and Mexico, at Flex, and at Philips as CIO for Latin America, based in Panama. His starting point is blunt: "it's usually our fault." Walk into a room of C-levels and talk bits and bytes, and nobody follows. A professor taught him early that you only have to understand the CFO well enough to understand the CFO's pains, so as an IT executive he did internships in every area, FP&A included. He never discusses ERP versions with stakeholders: "They don't care about that." He brings the examples. A startup getting ready for Series C ran on a simple version of QuickBooks while investors asked for a consolidated balance sheet; he proposed a month-end close and an FP&A tool first, then a middle-ground ERP instead of an SAP project that would cost millions. At a waterproofing company in Brazil that served 800,000 small shops, he asked how rain affected sales and which shelves were empty, then started with simple inventory capture so salespeople could go where there was no stock. His question for his teams: "do you want to be a donut shop or are you going to be a trusted advisor?" On security, he uses FAIR (factor analysis of information risk) to put a dollar amount on risk, like a SCADA network at a mining company, and he classifies the crown jewels and tags the data so AI can be used without the sensitive data leaving. He says 75% of incidents come from humans, and one phishing campaign he ran had a click-through rate close to 90%, so with an unlimited budget he would invest in behavior change. He closes with the doctors who held back from new technology, the Viking boat, and the advice he would give his younger self: study psychology. His bicycle model: the rear wheel is people's needs, the front wheel is their desires. Key takeaways: Learn enough of the CFO's world to understand the CFO's pains, like a negative cash flow or no visibility into the cash flow projection, and start the conversation there; Spend time inside other functions. Ask the CFO if you can sit close to FP&A and learn how it works; Keep ERP versions and application comparisons out of stakeholder conversations, and size the technology to the company now and three to five years out: just enough; Put cyber risk in dollars: lost hours, lost revenue, the cost of the fix, set against the investment that avoids them; Classify your crown jewels and tag the data, so people can use AI with the data you can afford to share and nothing else; Budget for behavior change, beyond the training: find the belief behind the resistance and give people a reason the change works for them Chapters: 00:00 Cold open 00:42 Meet Alexandre Quinze: Seattle U, Silicon Valley and Philips Latin America 02:59 When IT isn't heard, it's usually our fault 05:37 Learn enough to understand the CFO's pains 08:03 Just enough technology: an ERP for a startup heading to Series C 14:09 Rain, stock-outs and 800,000 small shops 20:21 Donut shop or trusted advisor 22:18 Cyber risk in dollars with FAIR, and the crown jewels 29:29 What are you doing with your humans? 31:25 Unlimited budget: change the behavior 35:25 Doctors, Viking boats and changing minds 41:33 Psychology, the bicycle model and goodbye

Zack Miller, Director, Global Infrastructure at Catalent, walks into every new network with one request: show me the riser room. He explains tech debt as a town full of potholes, shows how he asks the business for its cost per hour so he can price the risk, and why his first question for a CFO is how much they want to spend on IT over the next three years. Zack Miller started at 13, watching his dad tinker with computers at the kitchen table, then fixing the neighbors' things. After high school he got a smart-hands job at Cisco, earned his CCNA, worked through a couple of MSPs and settled in biotech and life sciences, where a client hired him away. Consulting showed him the patient impact of the work: sitting with a client about a new biologic for cancer patients, he thought, "my keyboard strokes can help them." He built his career on VMware and Azure engineering and has done 11 data centers, "from literally nothing but dirt in the ground to fully functional GMP data center." Today he runs global infrastructure at Catalent, across four regions and over 60 sites. His framework starts at the door: "Go into a new environment. Show me the riser room. Where does it come in?" In shared buildings the handoff is often a 15-year-old Cisco WAN aggregation switch that serves every tenant, and the first problems are no UPS and a single WAN aggregate. From there the conversation repeats: what do you want to pay for, what level of redundancy, what capacity at the edge, whose firewall. "The technology is easy," he says. The hard part is getting people to believe you and give you their money. So he turns the network into a town, with neighborhood roads, stoplights, a fiber highway and an airport at the edge, then adds 15 years and 2,000 new residents until "that is tech debt." And he asks the business for the cost per hour and the EBITDA per day, so he can name the cost of the risk. In life sciences the rules come from the FDA and the DEA, with 21 CFR 210 and 211 as the main compliance set, and his advice is to involve IT before you source lab systems. With CFOs at early and growth-stage biotechs, he starts with one question, how much do you want to spend on IT in the next three years, then backs into what you can afford, including whether you can afford to exit it: "You don't have to start with the Ferrari." He also shares what he'd do differently with his own consulting firm (find a sales leader), why context switching is a skill to build, and the advice he'd give his younger self: anger is a six-second chemical reaction. Key takeaways: Start every new site at the riser room. Find out where the service actually comes in and whether the handoff is a shared WAN aggregation switch you don't control; Check the basics first: UPS, a single WAN aggregate, the physical security and the environmentals of the riser room and the data center; Ask the business what it wants to pay for before you design: redundancy, capacity at the edge and whose firewall all follow from that answer; Pull finance into your world. Ask for the cost per hour and the EBITDA per hour and per day, then state the cost of the risk; Ask your CFO how much the company wants to spend on IT over three years, then back into what you can afford, including the cost to exit; Involve IT before lab systems are sourced, so the next FDA audit doesn't find a computer system validation problem built in Chapters: 00:00 Cold open 00:47 Meet Zack Miller: from the kitchen table to Cisco smart hands 05:31 The network needs focus, across four regions and 60 sites 13:34 The plumbing, and who answers the door when the FDA shows up 17:01 Show me the riser room 23:48 The technology is easy, getting the money is hard 27:22 Tech debt as a town, and the cost of an outage 32:54 What AI is doing to the network 39:11 FDA, DEA and GMP: involve IT before you source 43:11 Running his own firm: find a sales leader 49:12 Align with the CFO: the Ferrari or the Corolla 54:26 Context switching, and advice to hi...

Fletus Poston III, Director of IT and Cybersecurity at 3D Systems, says IT and security leaders now have to be bilingual: talk business first, then introduce the tech. He shares the elevator test he gives the people he mentors, then translates a network upgrade, tech debt, automation and a scattered data platform into language a board can act on. Fletus Poston III has worked in IT officially since 2006. He was an IT auditor at Wachovia before 13 years at Duke Energy, where he helped grow the security engineering team from 5 to 15. At his next company he built out the security program and left as acting deputy CISO. Today he is Director of IT and Cybersecurity at 3D Systems, with a team of 30, and he teaches an AI business cybersecurity class at Appalachian State. His rule for the C-suite: "I talk business first and then I introduce tech." Executives want the return on their investment and the effect on EBITDA, and they don't need to know you're blocking and tackling with firewall rules. He gives the people he mentors an elevator test. A C-level turns to you in the elevator and asks what you do for the company, and you have 10 to 15 seconds to answer in terms of business value and business change. He also explains why board members and senior leaders have told him some deputy CISOs will never be CISO: they see them as operational leaders who can't yet walk into a room and just talk finance. And he shows how attackers come in through your providers, from the caterer to the HVAC company. Then comes a game: hear the tech speak, translate it for the board. Fletus turns "we need to upgrade the network" into a business impact and a request to start at the small sites, and compares tech debt to the monthly subscriptions and gym memberships nobody looks at. He closes with the habits he relies on: come in with a problem and a solution, never go to the board asking for money, make friends with whoever has the checkbook, and don't make up an answer when you don't know. His last word: "Be a mentor, find a mentor, be a mentee." Key takeaways: Lead with return on investment and the effect on EBITDA, then the tech. Bring three to five slides and expect to cover one or two; Have a 10-to-15-second answer to "What do you do for my company?" built on the business value and business change you drive. If they want more, they'll ask; Meet your CFO between board meetings and hand over an appendix and quick notes, so the CFO can answer the board's questions; Keep a risk register of the five things that should keep the company up at night, and let some of them sit outside cyber, like a natural disaster where your suppliers are, or losing people you need to keep; Come in with a problem and a solution, and lay out options A, B and C with the one you want them to choose; When the board asks something you can't answer, don't make it up. Say you'll get back to them, and name when. Chapters: 00:00 Cold open 00:47 Meet Fletus Poston III: from a Commodore 64 to 3D Systems 03:20 Teaching AI to business students, and securing what citizen developers build 15:06 Be bilingual: talk business first, then tech 17:57 Keeping the CFO ready, and attacks through your providers 20:06 Risk registers and what keeps the company up at night 23:39 Co-owning projects, triage and healthcare 29:36 When a C-level loses their voice, and human-centric security 38:31 The elevator test 41:39 Why some deputy CISOs plateau 46:03 Translate it for the board 50:06 Habits that land, and be a mentor

Jeff Posluns, CIO of Traffic Tech, a logistics company with about 40 offices around the world, wants to be the Department of Risk: an unreasonable request goes to a risk assessment, and the business decides which consequences it will accept. He explains why a project without a business owner should not start, and why anything that pulls a person off a high-priority project gets logged and decided by the business. Jeff Posluns runs the tech part of Traffic Tech, a third- and fourth-party logistics company with about 40 offices around the world and about 1,200 people. In his view, a project without a business owner should not start, because the business owner defines the outcomes. He applies the same thinking to funding: most organizations fund projects, the team disbands after go-live, and technical debt stays invisible until something fails, so he advises persistent funding of business capabilities, with lifecycle and run costs approved at the same time as the build. Technology risk is business risk, and the business should own it. When ownership is unclear, risks get accepted by default because nobody made a decision, so he puts technology risk on the enterprise risk register with named business owners. A new initiative starts with the named business executive, the number and the date, and he decides up front how progress will be measured and at what point in the spending to ask whether the project should be stopped and shelved. He also argues that a CIO still needs real technical depth, or ends up approving decisions they can't evaluate. When a request is unreasonable, he answers as the Department of Risk: a risk assessment from the GRC team, and the list of what the business has to accept. Spend a day changing the color of a baby puke green button, and you might lose two loads of melted Hershey Kisses and have to make an insurance claim. His priorities come from a meeting every two weeks, with five high-priority projects that have delivery dates and five medium ones with target dates, and his one-line advice for technologists is to learn to hate the right things. Key takeaways: Don't start a project until a business owner has defined the outcomes they're looking for; Approve lifecycle and run costs at the same time as the build, so technical debt is visible and the total cost of ownership gets discussed before anyone signs off; Put technology risk on the enterprise risk register with named business owners, so every deferred decision becomes an explicit risk acceptance; Start an initiative with the named business executive, the number and the date, and decide how you'll measure progress and at what point you'd stop and shelve it; Keep five high priorities with delivery dates and five medium ones with target dates; anything that pulls a person off a high priority goes through a formal change register and the prioritization committee; Answer an unreasonable request with a risk assessment and what the business will have to accept, and keep your technology team out of the meetings about button colors. Chapters: 00:00 Cold open, and the tech part of Traffic Tech 03:59 No business owner, no project 07:23 How technology gets funded, and technical debt 09:16 The three-month ERP, and technology as a business decision 14:29 Technology risk is business risk 20:20 The business as internal customer, and three SOCs 26:00 The named executive, the number and the date 32:04 Technical depth, and saying no with credibility 36:35 Five high priorities, five medium, everything else 40:59 The Department of Risk and the baby puke green button 47:44 Diagram fatigue and Clean Language 53:04 Learn to hate the right things

Jennifer Terrill, CIO of Sperber Landscape Companies, says IT often gets labeled as Mr. No and calls that a big myth, because IT really is innovation technology. She explains why technology has to work the way people already work, and why she won't hand AI a blank check as costs shift from SaaS subscriptions to tokens. Jennifer Terrill started as a programmer with a computer science degree and calls her career a jungle gym: fintech, internet banking, retail, where she was CIO of True Religion Brand Jeans, payments, and a cemetery and mortuary company she took from paper to digital. For a little over a year she has been CIO of Sperber Landscape Companies, which has about 3,500 employees and branches from coast to coast, including Hawaii, and she reports directly to the CEO. Her superpower, she says, is solving problems, and it starts with embedding herself in the business. She explains why technology is secondary for crews out in the field, where a screen that takes 10 clicks is too much, and how IT gets into the conversations it's left out of: ask to sit in on the meeting. On AI, she describes an experimental phase built on a prompt library and brain files, and she explains why tokenomics needs watching as costs shift from SaaS subscriptions to tokens. She closes with her game plan for the first 90 days in a new organization, which starts with an assessment and a day in the life. Key takeaways: Ask to sit in on business meetings to learn how the business runs. If you're in that room, you can help solve the problem; Design for the way people already work. If a SaaS screen takes 10 clicks for a crew in the field, it's too much; Give the business options, from the cheap and cheerful solution to the Ferrari, and let them pick based on the impact and the money; When you consolidate tools, have the people who use them build the scorecard, then let them pick the winner; As costs shift from SaaS subscriptions to tokens, keep an eye on tokenomics, and put a semantic layer and permission layers in place before people start calling APIs; When you join a new organization, start with an assessment of applications, infrastructure, cybersecurity and vendor data privacy, do a day in the life, then present what needs fixing right away with its cost and three options Chapters: 00:00 A jungle-gym career from programmer to CIO 04:10 Her superpower, and don't make me think 07:31 Telling the story, and making it easy for them 12:49 Herding AI cats, and the Mr. No myth 15:04 Solving problems, and the conversations you're not in 21:16 A day in the life and the Innovation Council 24:19 AI in the experimental phase 27:38 From SaaS to tokens, and no blank checks 30:30 Hiring for curiosity, and a softer place to land 37:02 When the team makes the wrong call 39:19 The first 90 days 42:55 Be fearless, and the business acumen gap

Erich Gazaui, Chief Information Officer at Papa, says AI makes it look as if typing and writing are the only skills you need, and when you leave a gap in a prompt or a design, AI is going to fill that gap very quickly. He explains the intent engine he wrote about, why systems do not automatically know the finish line, and how his team built AI-driven playbooks into almost every department. Erich Gazaui's first computer was an Apple II, and his mom put him in a computer class to learn BASIC. He was pre-med until organic chemistry, graduated in economics, and learned DOS batch scripts in the dorms so he could play Privateer. In college he and two friends started a company whose first customer was the university: a survey tool for a political science professor, then a computer lab to run it. That company later became a security firm he ran for 15 years. He went on to be a senior director at TrueCar with "a really big hand in the security side, the governance and compliance", was recruited to Beachbody by its CIO, and was head of IT at ZipRecruiter, where vetting job posters made marketplace safety a competitive advantage and procurement ran "janitorial all the way through AWS". Today security, IT compliance and enterprise apps sit under him at Papa. His warning about AI: "When you leave a gap in a prompt or in a design, AI is going to fill that gap very quickly." The output looks so professional that you won't know what was filled, and the miss may only show up when it is very expensive to change. He compares it to firing a laser pointer at the moon, where being off by a fraction of a millimeter means you miss it. His answer is what he calls an intent engine: a central source of truth for what the company believes. One request at ZipRecruiter to "make sure that marketing is included" in an event shows why: even the head of marketing came back with a question. Then the other end of the work: the success criteria, the definition of done. Using mean time to resolution as the example, he explains why "systems do not automatically know the finish line" and keep refining past the state you wanted. He talks about the political capital he spent with his CEO and president to build AI properly, how restrictive his team was about which AI features to enable while they built a central knowledge store, and the playbooks that now run in almost every department, including the day the CEO asked to take his old laptop for personal use and the system handled it with no human interaction. His rule for his own meetings: "Everybody has a voice and it's equal. You leave the title at the door." Key takeaways: Give every AI system and automated playbook its finish line: write the success criteria and the definition of done, or it will keep refining past the state you wanted; Instruct the models to identify gaps rather than fill them, and decide upfront which gaps are intentional; Before you switch AI features on, build one central knowledge store with the goals, processes, teams and names; disable or downgrade the tier on tools that can't point at it yet; Test your definitions on something small. "Make sure marketing is included" turns into who goes on the list, who maintains it and who writes the rules; Put a gate on every action an AI-driven playbook can take, and keep it supervisory until you trust it; Use the visibility IT has. Procurement and governance let you show the board and the audit committee where security and compliance drive revenue Chapters: 00:00 Cold open 00:42 Meet Erich Gazaui: an Apple II, a 286 and a computer camp 03:15 Pre-med, Privateer and a first company in college 07:21 TrueCar, Beachbody and a workout at orientation 09:52 Beyond the cost center: governance at Papa 14:28 ZipRecruiter: marketplace safety and company-wide procurement 21:22 The missing skills: AI will fill the gap 26:12 Make sure marketing is included: the intent engine 31:43 Start and finish: systems don't know the finish line 39:21 A beautifully wrong sys...