Advertise on podcast: You've Been Heard

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...

Christopher Childs, CIO of Evans Army Community Hospital, on why IT has to be in the business of healthcare and not the healthcare business, and why he tells leaders who text him about a broken computer that he is not the help desk. He walks through his four pillars of leadership and the Innovation Board he pushed for, built around one question: how do we get to right? The skill Christopher Childs credits most for his success has nothing to do with technical ability: listening more than he speaks and meeting people where they are. The CIO of Evans Army Community Hospital, speaking for himself, explains how a master technician can also become a master isolationist, and why he tells his branch chiefs to use IT as a force multiplier and a healthcare enabler. He describes telling his own leadership that he is not the help desk, why he asks every department for downtime procedures so nobody uses IT as a crutch, and the two questions behind his decisions: does it help deliver safe, quality care, and does it make the patient experience better. Then come his four pillars of leadership, compassion, passion, standards and discipline, and the Frankenstein IT you get when nothing is standardized. Chris also pushed for the hospital's Innovation Board, a bimonthly meeting where anyone in the organization can bring an idea to the experts who would have to deliver it. It brought IT to the table before decisions get made, and it runs on one rule: how do we get to right? He closes with how he sells standardization when the payoff is slow, using Vocera badges that let the hospital drop five contracts, and with the legacy he wants to leave. Key takeaways: Listen more than you speak. When someone seems distracted, offer to have a different conversation than the one you're having; Pick the framework your organization delivers on and run every decision through it. His: safe, quality care and the patient experience; When leaders treat you as the help desk, say so plainly, and send the call to the person whose job it is; Make every department keep downtime procedures, so a planned maintenance window doesn't stop the work; Standardize before you scale. Patched-together good ideas turn into Frankenstein IT that nobody can fix when it breaks; Give people a standing room to bring ideas, and steer the talk toward how to get to right, so a no costs nothing. Chapters: 00:00 Introduction: from the MLB draft to the Army 06:59 Listen more than you speak 14:04 Master technician, master isolationist 16:25 In the business of healthcare, and downtime procedures 22:13 "I am not the help desk" 26:36 Why technicians rarely get to learn leadership 33:21 Safe, quality care and the patient experience 38:17 Four pillars: compassion, passion, standards, discipline 42:14 Showing passion, and the Innovation Board 48:35 A seat at the table: how do we get to right? 55:12 Selling standardization, from Batman to Vocera badges 68:33 Words of wisdom: the legacy you leave

Jeremy Mayfield, Director of IT at National Sugar Marketing Cooperative, took the company from a legacy on-premise ERP to a fully SaaS platform in under 12 months, against a 14-month board approval, after a year of defining requirements and a vendor hit list that ended with "now you have to show us." He explains why an organization that can't tell you its requirements isn't ready for change, and why he thinks that 18 months from now IT leaders will be talking about what he calls the death of the data center. Jeremy Mayfield came out of school as a fresh engineer and fell into IT back when it was called MIS. As the only IT person at his first company, he taught himself everything, from Cat5 cables and phone-system punch-down blocks to databases, and at one point he was a SQL expert. A leader tapped him early, and he has spent most of his 30 years in IT in leadership while staying hands-on. In 1997 he ran a 3 meg internet link over a 17-mile wireless hop and negotiated free internet by letting the provider use the company's silo as a hop. At a global company of more than 90,000 people, he was a program owner for voice over IP and landline optimization across 1,600 North American locations, work that saved about $11 million in copper. Today National Sugar, which distributes sugar to companies across the US, runs completely serverless and fully SaaS, with a zero trust framework in place of VPNs. Its new ERP went live on May 1 in under 12 months, against a 14-month board approval, and finished well under the approved budget. It started with a year of defining requirements, including visits to the co-op's members and to 3PLs. A roughly 90-page RFP went to about 10 vendors, Tier 1 and Tier 2, with a hit list every one of them had to answer: anyone who couldn't come back with "here's how we'll do it" was disqualified, and the finalists heard "now you have to show us." Jeremy wanted a vanilla, canned app, which he sums up as configuration over customization, and he phased the rollout to keep scope creep out. National Sugar was formed from one of the co-op's members about 15 or 16 years ago, and that member was still running all of its IT, ERP hosting included, when Jeremy was hired and told, "your task is to modernize us." His first day on the job was the cutover from the member's Microsoft 365 tenant to National Sugar's own. He took a cautious approach to AI through the ERP project and the stabilization after go-live. Now, with shadow AI already in use across the company, he puts security first and has asked the CFO to realign the budget for business licenses the company can administer and secure. Asked what IT leaders will be talking about in 18 months, he picks the death of the data center, with data spread out like an atom, "all over the place but no place at the same time." Key takeaways: Nail down your requirements before you shop. If the organization can't tell you what they are, it isn't ready for change; Build a hit list around what only your business needs, like FDA and USDA requirements and lot traceability for a food grade business, and disqualify any vendor that can't answer with "here's how we'll do it."; Make vendors show you before they get time with your leadership team; Choose configuration over customization: a vanilla app, with pre-built connectors for what sits around it; Phase the rollout, with the high-value, high-impact pieces first, and keep scope creep out; Budget a stabilization period after go-live. He planned about six months before turning to AI. Chapters: 00:00 Cold open: not ready for change 00:43 Meet Jeremy Mayfield: the only IT person, self-taught 03:17 Still hands-on: a 17-mile wireless hop and $11 million in copper 11:54 Completely serverless, with zero trust instead of VPNs 13:57 SOC 2 and configuration over customization 18:32 Pre-built connectors, and an ERP live in under 12 months 20:59 How the co-op works, and a year of requirements 27:06 The hit list and "now show us" 30:37 Five ERP chan...

Veteran CIO and US Air Force veteran Brian Ledbetter on why IT leaders who earn a seat at the table can still be seen as the person who fixed the printer. He walks through the six pillars of his LEAD IT framework and explains why developers who hammered out code all day will end up managing AI agents. Earlier in his career, at a small company, one of its leaders called Brian Ledbetter his CIO. Another called him his IT director. A third called him his IT guy. Brian, a veteran CIO and US Air Force veteran, says the title matters far less than how the organization sees you, and that perception is hardest to shift when you came up through the help desk at the same company. He walks through LEAD IT, the framework he built from lessons he learned the hard way: Lead, Elevate, Align, Deliver, Innovate and Transform. Former guest Bruce Otte joins to press on delegation, which brings out Brian's three-foot hole story and his test for who is ready to own an outcome. Later, Brian argues that whoever makes a technology decision should share the accountability when it fails. He explains how to answer a technical question and turn it straight to business impact, and why every AI conversation should start with the outcome. Asked what IT leaders will be talking about in 18 months, he picks the guardrails needed to tame AI, and he says companies are already hiring agent managers. Key takeaways: Answer the technical question, then turn it to business impact before anyone else speaks; Before handing someone an outcome, check whether they see the work around the task; Once you delegate, stay close and available without hovering. Delegation is not abdication; Whoever makes a technology decision should share the accountability when it fails; Start every AI request with the outcome you want. Pick the tool after that. Chapters: 00:00 Cold open: CIO, IT director or IT guy 00:43 Meet Brian Ledbetter, from the Air Force to a wall of certifications 03:59 Three titles for one job, and the printer problem 08:08 Where LEAD IT came from, and why Lead comes first 14:57 Letting go of the work, and leaving the code behind 18:12 Bruce Otte's questions on delegation, and owning the outcome 21:50 The three-foot hole guy 25:15 Building confidence, and room to fail 33:27 Peer groups, and who owns the decision 39:52 Speak the business, step zero and shared accountability 44:58 Governance is rules, and AI starts at the end 50:30 The 18-month prediction: developers, AI and agent managers

Everyone's using ChatGPT on their own to save 30 minutes a day, and nobody will wait six weeks for a review, so Brandon Muncy, Director of Information Technology at PepperPointe Partnerships, wants to make the approved path fast enough that a shortcut isn't tempting. After building the dental service organization's in-house IT team from a fully outsourced start, he explains why onboarding broke even when everyone did their job and why he expects the next 18 months to be about identity and permissions for AI agents. Brandon Muncy's path into IT leadership wasn't a straight line. After an engineering degree he went into retail management at Verizon and AT&T to pick up the business side, then moved into research computing at the university. From 2018 to about 2021 he was the Linux person on a 10-node cluster, hundreds of VMs, a deep-learning machine and a VDI setup for researchers. PepperPointe, where he now leads IT, is a dental service organization in Lexington, Kentucky with hundreds of practices across a couple of states. When he joined in late 2022, its IT was fully outsourced, with no internal team. He has built a team of about seven people for upwards of 1,500 users. He found out that you don't change the perception by explaining it. Better decks didn't work, because nobody updates a belief based off a slide, so he works one visible win at a time, and onboarding is one of the vehicles. When a new hire starts on Monday and IT finds out Monday, everybody has a bad week, even though everyone involved did their job. Instead of blaming the office, which is busy running a practice, his team went to the office managers and, looking at onboarding from their chair, found a defining step that tells IT sooner. He also describes his real bad day: by 4 o'clock he has been useful maybe 11 times and hasn't moved a single thing forward. On AI, Brandon says that in healthcare it shows up as a governance question before it shows up as a capability question. People using ChatGPT on their own save 30 minutes a day and won't wait six weeks for a review, so he wants an approved path fast enough that a shortcut isn't tempting, even if the first version is half-baked. Only his administrators have access to Copilot, so the team can start working on DLP policies. His 18-month prediction is identity and permissions for non-human actors: if the tool touches patient data, it's a business associate, and he expects an enforcement story. Key takeaways: Make the approved path fast enough that a shortcut isn't tempting, even if the first version is half-baked.; Change how the business sees IT one visible win at a time, because nobody updates a belief based off a slide.; When onboarding breaks, look at the process before you blame the office, then give the office one defining step that tells IT sooner.; Keep Copilot to your administrators so your team can start working on the DLP policies.; Guard your strategic thinking time: a day of being useful 11 times can end with nothing moved forward.; Treat documentation as part of the process, because it loses the prioritization fight every time.

John Errington, Director IT/IS at Pengate Handling Systems, tells his teams something they hate to hear: turning the light off every day is the thing to automate, and their time belongs on why the light keeps going off. With more than 27 years in IT, he also explains how he learns a new business from the people with their boots on the ground, and how AI took three to four days of pulling major-incident data together down to a 20-minute process while his problem managers still checked it for accuracy. John Errington fell into IT by accident. A couple of years out of high school he was working in records management at a pharmaceutical company, where knowing how to turn on a computer made him the de facto local IT guy. At GSI Commerce, a Linux shop he joined in 2010, a new leader pulled him into IT leadership "kicking and screaming," and his own light bulb moment came when he got a script put on an alert his team kept clearing by hand. He often uses the light analogy with the teams he manages, and they hate to hear it: the light you turn off every day is the thing to automate, and the value add is fixing the core of the problem. Four weeks into a new job in material handling, he explains how he learns a business he doesn't know yet. It starts with the people with their boots on the ground. Here, that meant ride-alongs with the field service techs, the people who "keep the cash register open." John also gets into how silos breed a not-it mentality on outage calls, and the SWAT team approach John's operations teams used instead: everybody jumps in and stays until they're cleared. John sees AI the way he saw automation, as a tool that needs a human at the decision-making part. In his last job, AI postmortems of recorded major-incident calls took much of three to four days of work down to a 20-minute process, and his problem managers still reviewed all of it for accuracy. Key takeaways: If your team clears the same alert every day, automate it, then spend the time you get back on why it keeps going off.; Learn a new business from the people with their boots on the ground: ride along with them, then take what slows them down to whoever owns that process.; On a major-incident call, have every team report on its own area and stay on until you clear them.; Let AI draft the postmortem from the call recording, and have your problem managers check it for accuracy.

Technology leaders can contribute to business decisions when they understand what the company is trying to accomplish. Teresa Duran, chief information officer at Tree Top, joins Phil Howard to discuss the questions she asks in her first 90 days, her preference for five current priorities over a rolling five-year project list, and why technology strategy should follow company strategy. She explains how scattered company information limits decisions, how to decide what outside suppliers should build and what internal staff must maintain, and why a quickly built tool using artificial intelligence still needs a support plan. Teresa also recounts a biotech transformation during COVID: as plans changed from a first public stock sale to selling part of the business, her team built software and kept time-sensitive corneal tissue moving. They close on career learning, mentoring future technology leaders, and making technical presentations lead to decisions.

George Hicker, Vice President of Information Technology (IT) and Business Transformation at Ronnoco Beverage Solutions, joins Mike Kelley to explain what happens when AI lets employees build useful tools in hours. Fast results can hide weak security, missing instructions, unclear ownership, and problems that appear when more people use the tool. George offers a practical response: bring the technology team in early, write down the plan, have experienced developers check the code, test with safe data, limit access, keep backups, and make people responsible for the result. He also explains why skilled software designers and developers become more valuable as AI creates work faster.

Jeff Hobbs, Director of IT at SV Labs Corporation, joins Mike Kelley to discuss the leadership skills that matter beyond technical expertise. Jeff explains how he uses Copilot to tailor communication for different stakeholders, examine unfamiliar security questions, troubleshoot Intune issues, and help a small team close knowledge gaps. He also discusses the limits: AI output needs review, paid licenses need measures, and easy access to public tools creates data-protection risk. The conversation returns to one idea throughout: technical ability can get a leader noticed, but influence, relationships, and business judgment move the work forward.

Scott Holleran, CIO of Altus Fire & Life Safety, joins Phil Howard to discuss what gives technology leaders real influence inside the business. Scott shares lessons from the Army and three private equity-backed technology roles, including why leaders should walk the floor, ride with frontline teams, and map the full process before choosing a system. He explains how to frame difficult requests through cost, time, return, and tradeoffs; why business-specific data expertise belongs close to operations; how clear behavioral scorecards help teams perform; and why AI will strengthen specialists rather than erase the value of expertise.

Mason Herbel describes the shift from an AI startup to Parallel Systems, where the first questions were about governance and company data. Some employees already used AI. Others had barely started. His advice for IT leaders: give people a clear route to approved tools, then make that route easy enough to use at work. He suggests company enterprise plans, agreements about data handling, and a trial period for tools employees request. After the trial, check actual usage and whether another paid app already does the job. Blocking a website has limits when someone can reach for a personal phone. Mason puts it plainly: “So you may as well make it easy for people to use in a secured manner.” This is his proposed approach, rather than a report of a completed company-wide AI rollout. We also get into choosing infrastructure one workload at a time. Mason recounts moving an engineering firm away from aging local servers after checking its remaining applications and Microsoft licenses. At an AI company, he argued for examining owned GPUs as API bills grew. He describes that proposal and the conversations around it; he does not claim verified savings from a completed GPU deployment. For IT leaders trying to get a useful idea heard, Mason explains how he kept discussing the GPU proposal with a principal engineer. He also recalls asking to join a server installation early in his first job and learning by doing when the lead technician had to leave. The practical thread: ask how the work gets done, bring colleagues into the decision, and keep everyday IT needs covered while taking on new projects.

Jim Harden began his IT career in the Marine Corps, building tactical data networks from commodity gear before moving into corporate technology and leadership. Now CIO at Singleton Schreiber, Jim joins Phil Howard to explain how IT can move from break-fix support to business strategy. He shares why his team is giving lawyers one governed entry point for AI workflows, how infrastructure as a service cut new-office deployments from days to hours, and why growth requires two- and three-year technology plans. Jim also explains what he wants from specialist vendors, including a project that consumed about $40,000 before being scrapped, and why a strong project manager can be worth every penny. The conversation closes with lessons from bad leaders, useful feedback, humility, and the questions Jim asks at the end of every one-on-one.

Peter Vardaro started in biomedical equipment service, where unreliable connectivity and slow documentation often consumed more time than the repair itself. That frustration pulled him into low-code experiments, enterprise applications, medical-equipment logistics, and team leadership. In this conversation with Mike Kelley, Peter explains why applications must be designed for the business that may exist tomorrow, how repeated support tickets can point to features that help hundreds of people, and why leaders should measure and celebrate the time their teams return to the business. Peter also discusses vendor accountability, protected health information, AI governance, vibe-coded prototypes, and his belief that AI will make human judgment and relationships more valuable.