Podcasts about Incident management

In this episode, Jeffrey discusses Part 2 of the discussion on service management best practices. This focused on Incident Management.Each week, Jeffrey will be sharing his knowledge on Service Delivery (Mondays) and Service Management (Thursdays). Jeffrey is the founder of Service Management Leadership, an IT consulting firm specializing in Service Management, Asset Management, CIO Advisory, and Business Continuity services.  The firm's website is www.servicemanagement.us.  Jeffrey has been in the industry for 30 years and brings a practical perspective to the discussions. He is an accomplished author with seven acclaimed books in the subject area and a popular YouTube channel with approximately 1,500 videos on various topics.  Also, please follow the Service Management Leadership LinkedIn page.

In dieser Podcast-Episode spreche ich mit Lukas Grubwieser, Senior Solution Architect, und Leonie Hollstein, Global Account Manager, beide von Databricks, über das Thema DORA Compliance im Finanzsektor. Wir tauchen tief in die Herausforderungen und Chancen ein, die sich durch die neue Regulierung ergeben. 5 Highlights der Episode: Was ist DORA?: Wir klären, was der Digital Operational Resilience Act (DORA) überhaupt ist: Ein regulatorisches Framework, das IT-Risiken in Finanzinstituten adressiert und am 17. Januar 2025 in Kraft getreten ist. DORA zielt darauf ab, die Abhängigkeit von einzelnen Anbietern zu reduzieren und die Resilienz von IT-Systemen zu stärken. Herausforderungen der DORA Compliance: Wir diskutieren die größten Herausforderungen, die sich für Finanzinstitute bei der Umsetzung von DORA stellen. Dazu gehören das Management von Drittparteienrisiken (z.B. Cloud-Anbieter), der notwendige Change-Management-Prozess, der Umgang mit veralteter Technologie (Legacy-Systeme) und die Notwendigkeit eines ganzheitlichen Ansatzes, der alle IT-Systeme umfasst. Die Rolle von Databricks: Ich lerne, wie Databricks Finanzinstitute bei der Erfüllung der DORA-Anforderungen unterstützt. Databricks liefert nicht nur eine Plattform, sondern fungiert auch als Berater und hilft bei der Entwicklung von Prozessen und der Implementierung der notwendigen Technologie. Das Geschäftsmodell ist consumption-based, also erfolgsabhängig. Incident Management und Echtzeit-Monitoring: Wir beleuchten die Bedeutung von Echtzeit-Monitoring und -Logging zur frühzeitigen Erkennung und Reaktion auf Sicherheitsvorfälle. Databricks bietet hierfür Lösungen, die diverse Systeme integrieren und eine zentrale Übersicht ermöglichen. Das beinhaltet auch die Automatisierung von Prozessen. Governance und Open Source: Die Bedeutung von Daten-Governance und die Rolle von Open-Source-Technologien wie Spark und MLflow werden hervorgehoben. Databricks setzt auf einen hybriden Ansatz, der sowohl die Vorteile der Cloud als auch die Unabhängigkeit von einzelnen Anbietern berücksichtigt. Links in dieser Ausgabe Zur Homepage von Jonas Piela Zum LinkedIn-Profil von Jonas Piela Zum LinkedIn-Profil von Lukas Grubwieser Zum LinkedIn-Profil von Leonie Hollstein Zum Whitepaper zu Dora Die Liferay Digital Experience Platform Kunden erwarten digitale Services für die Kommunikation, Schadensmeldung und -abwicklung. Liferays Digital Experience Platform bietet Out-of-the-Box-Funktionen wie Low-Code, höchste Sicherheit & Zuverlässigkeit. Jetzt Kontakt aufnehmen.

Send us a textMy guest to day is John Lord, John is a Training specialist in Incident Management and a global leader in bringing attention and driving change in the fight against firefighter cancer.this is part of of a powerful six-part mini-series dedicated to one of the most critical issues facing our profession: firefighter cancer, protection, and decontamination.In this series, recorded around the Particulate, Protection & Decontamination Seminar held at Biggin Hill on March 27th, 2025, we dive headfirst into the hard truths and urgent conversations we need to be having — not tomorrow, but today. With input from survivors, health and safety leaders, mental health advocates, and operational experts, we unpack everything from current understanding of contamination-related cancer risks to real, practical steps departments are taking to reduce exposure and save lives.This isn't just about facts and figures — it's about impact. It's about learning from lived experience, sharing the latest research, and equipping firefighters and fire sector professionals with the tools to protect themselves and their crews. From the trauma of diagnosis to the innovations in kit and station design, we'll look at how our culture is shifting, what barriers still need breaking, and what true protection looks like in 2025 and beyond.Brought to you with the support of PGI — leaders in high-performance protective gear — this series aims to educate, inspire, and drive change. Because protecting those who protect others isn't optional — it's essential.Let's get into it.connect with John HEREACCESS THE PODCAST LIBRARY & EVERY EPISODE, DEBRIEF & DOCUMENT CLICK HEREPODCAST GIFT - Get your FREE subscription to essential Firefighting publications HERE A big thanks to our partners for supporting this episode.GORE-TEX Professional ClothingMSA The Safety CompanyIDEXHAIX Footwear - Get offical podcast discount on HAIX HEREXendurance - to hunt performance & endurance 20% off HERE with code ffp20Lyfe Linez -  Get Functional Hydration FUEL for FIREFIGHTERS, Clean no sugar  for daily hydration. 80% of people live dehydratedSupport the show***The views expressed in this episode are those of the individual speakers. Our partners are not responsible for the content of this episode and does not warrant its accuracy or completeness.*** Please support the podcast and its future by clicking HERE and joining our Patreon Crew

Recorded April 18, 2025 In this episode, the gang looks at the chaos and excitement surrounding commencement season in higher education. From the intricacies of AV setups to the humorous mishaps that can occur, our experts share their experiences and insights on managing these large-scale events. Tune in for a blend of technical expertise and light-hearted banter! We also sneak in a news discussion about the widespread Zoom outage and the ramifications thereof. If nothing else, all the work from home people had a new excuse why they didn't get anything done for a few hours. News: https://www.theregister.com/2025/04/17/zoom_outage_godaddy_blamed/   Alternate Show Titles: Lick his title I'm a little behind Weather channel radio thing Listserv debauchery I touched a lot of stuff Deans are always special Naturally, they try to cheat Yell at them! Fine, I'm out! Can't you meet bi-monthly? Tailgating Commencement It is a big show! He said festival, not carnival Johnny out on the quad Just in case there's a streaker   We stream live every Friday at about 300p Eastern/1200p Pacific and you can listen to everything we record over at AVSuperFriends.com    ▀▄▀▄▀ CONTACT LINKS ▀▄▀▄▀ ► Website: https://www.avsuperfriends.com ► Twitter: https://twitter.com/avsuperfriends ► LinkedIn: https://www.linkedin.com/company/avsuperfriends ► YouTube: https://www.youtube.com/@avsuperfriends ► Bluesky: https://bsky.app/profile/avsuperfriends.bsky.social ► Email: mailbag@avsuperfriends.com ► RSS: https://avsuperfriends.libsyn.com/rss Donate to AVSF: https://www.avsuperfriends.com/support

Send us a textWondering how to tackle incident response questions on the CISSP exam? This episode delivers exactly what you need, walking through fifteen essential incident management scenarios that test your understanding of this critical domain.Sean Gerber breaks down the fundamentals of incident management, exploring how security professionals should approach detection, response, mitigation, and recovery. From distinguishing between legitimate security incidents and routine activities to prioritizing response efforts based on severity, each question targets a specific aspect of incident management that CISSP candidates must master.The questions systematically cover the incident response lifecycle, highlighting the importance of proper processes rather than blame-focused reactions. You'll learn why activating the incident response team should be your immediate priority upon detection, how to effectively categorize and prioritize incidents, and what constitutes valid mitigation strategies versus ineffective approaches. The episode also emphasizes the documentation requirements for incident reports and the value of capturing lessons learned for continuous improvement.What makes this episode particularly valuable is how it reinforces the CISSP mindset—understanding not just the technical aspects but the thought processes behind effective security management. Whether you're preparing for certification or looking to strengthen your practical knowledge of incident response, these question scenarios provide the framework you need to approach real-world security events with confidence. Check out the special offer at CISSPCyberTraining.com to continue your certification journey with expert guidance.Gain exclusive access to 360 FREE CISSP Practice Questions delivered directly to your inbox! Sign up at FreeCISSPQuestions.com and receive 30 expertly crafted practice questions every 15 days for the next 6 months—completely free! Don't miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!

Send us a textCybersecurity incidents aren't a matter of if, but when. Are you prepared to respond effectively? Sean Gerber takes us through the complete incident response lifecycle, breaking down the seven essential phases every security professional must master. From developing comprehensive response plans to conducting effective post-incident analysis, this episode provides actionable guidance for both CISSP candidates and working cybersecurity practitioners.The stakes couldn't be higher for small and medium-sized businesses, with a staggering 43% of cyber attacks specifically targeting SMBs. Most lack adequate protection due to limited budgets and resources. Sean explores practical solutions including leveraging AI tools to develop baseline response plans, implementing critical security controls like multi-factor authentication, and establishing clear communication protocols for when incidents occur.What sets this episode apart is Sean's emphasis on the human element of security. "Every employee is a sensor," he reminds us, highlighting how proper training and awareness can transform your workforce into your first line of defense. He balances technical recommendations with strategic insights, including how to approach different types of incidents from ransomware to insider threats.Whether you're preparing for the CISSP exam or strengthening your organization's security posture, this episode delivers the perfect blend of theoretical knowledge and real-world application. The incident response process outlined here will not only help you pass certification exams but could mean the difference between a minor security event and a catastrophic breach.Ready to transform how you prepare for and respond to cybersecurity incidents? Listen now and discover why having a tested, comprehensive incident response plan is your best defense against the inevitable attack.Gain exclusive access to 360 FREE CISSP Practice Questions delivered directly to your inbox! Sign up at FreeCISSPQuestions.com and receive 30 expertly crafted practice questions every 15 days for the next 6 months—completely free! Don't miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!

​In this episode, we sit down with Doug Schuster, Operations Manager at Emergency Management Services International, Inc. (EMSI), a premier all-hazards, full-service, multi-discipline incident management and emergency management services provider. With over 30 years of experience in incident and event management, Doug shares insights into his emergency response philosophy and discusses EMSI's diverse work, including collaborations with the railroad industry.We delve into unique applications of the Incident Command System (ICS), such as managing a bedbug infestation at a jail and addressing a cesium release in a Seattle hospital. Join us for an enlightening conversation on innovative approaches to emergency management.​

Have you heard about our new Podcast, Prepare, Respond, Recover? If not, you should watch this week's episode #4 with Todd Manns and his guest Jon Brown, Principal Engineer and President of Stockwell Engineers, as they discuss Project Management vs Incident Management. Join us every Thursday and be sure to like, comment, share, and subscribe!Visit the Blue Cell - https://thebluecell.com/index.html

In this episode of Ticket Volume – IT Podcast, Matt Beran is joined by Georgina Otubela, Service Delivery Manager at Vita Bank, to dive deep into service design, incident management, and the role of trust in IT services. Gabriela shares her insights on how IT teams can build strong relationships with users, respond effectively to incidents, and balance automation with human interaction to create better service experiences.Here's a sneak peek:1. Why trust is the foundation of great IT services.2. How to improve incident management by focusing on communication.3. The role of automation in freeing up IT teams—and when not to use it.4. Why transparency and accountability are key to service recovery.5. How to recognize when you've designed a truly great IT service.Tune in for an insightful conversation packed with real-world advice for IT professionals looking to enhance their service management approach. Don't forget to like, subscribe, and share your thoughts in the comments!#ServiceManagement #ITSM #IncidentManagement #Automation #ITLeadership #ITServiceDesign #CustomerExperience #ITTrust #TicketVolume #Podcast

JJ Tang is the co-founder and CEO of Rootly, a company redefining how organizations approach incident management and reliability. Rootly is powering 100s of customers like Figma, NVIDIA, Canva, and more. Top 3 Value Bombs 1. Solve the problem from many angles. Go out, source and find your customers where they are and work ruthlessly. 2. All good leaders need to be operators. If the CEO can't do it, you can't expect anyone to do it. 3. Efficiency is the best force and function for prioritization. Visit their website and get a free demo - Rootly Sponsor YT 100 Email JLD to learn more about making YouTube magic in 100 days: john@eofire.com

JJ Tang is the co-founder and CEO of Rootly, a company redefining how organizations approach incident management and reliability. Rootly is powering 100s of customers like Figma, NVIDIA, Canva, and more. Top 3 Value Bombs 1. Solve the problem from many angles. Go out, source and find your customers where they are and work ruthlessly. 2. All good leaders need to be operators. If the CEO can't do it, you can't expect anyone to do it. 3. Efficiency is the best force and function for prioritization. Visit their website and get a free demo - Rootly Sponsor YT 100 Email JLD to learn more about making YouTube magic in 100 days: john@eofire.com

Seit dem 17. Januar 2025 ist der Digital Operational Resilience Act (DORA) anzuwenden. Schonfrist gibt es keine. Doch wie ist der Umsetzungsstand im Finanzsektor und welche Herausforderungen gab und gibt es möglicherweise immer noch? Darüber sprechen wir mit Professor Dr. Patrik Buchmüller von der DHBW Villingen-Schwenningen und Johannes Haupt (DZ Bank AG). Unsere Gäste geben außerdem einen Ausblick, wie es im regulatorischen Umfeld von DORA in den nächsten Monaten weitergeht.

In this episode, Richard introduces basic concepts of Crisis and Incident Management. This is the first of a few episodes where Crisis and Incident Management will be discussed.

If you're keen to share your story, please reach out to us!Guest:https://www.linkedin.com/in/danielleleong/https://firehydrant.com/careers/Steel Thread article:https://www.rubick.com/steel-threads/Powered by Artifeks!https://www.linkedin.com/company/artifeksrecruitmenthttps://www.artifeks.co.ukhttps://www.linkedin.com/in/agilerecruiterLinkedIn: https://www.linkedin.com/company/enginearsioTwitter: https://x.com/EnginearsioAll Podcast Platforms: https://smartlink.ausha.co/enginears00:00 - Enginears Intro.01:15 - Danielle Intro.03:36 - FireHydrant Intro.07:51 - Build vs Buy?11:19 - Breakdown of components that are important to enterprise ready features.14:23 - How to focus on customer challenges to build technology and systems?23:00 - How to build software for enterprise ready features?27:20 - Mobilising the teams internally to build this software.32:26 - What is the direction for FireHydrant and the next 12 months?35:55 - How can people get involved?37:17 - Danielle & FireHydrant Outro.37:59 - Enginears Outro. Edited by: hunterdigital.co.ukHosted by Ausha. See ausha.co/privacy-policy for more information.

In this episode of Ticket Volume, Matt Beran sits down with John Gordon, Senior VP of HP Managed Solutions Division, to explore how preventative Incident Management is reshaping IT operations. With a vision for zero-incident environments, John shares strategies to move from reactive problem-solving to proactive prevention, helping IT teams reduce downtime and improve user satisfaction. Here's a sneak peek: 1. Why zero incidents should be every IT team's goal. 2. The role of telemetry and automation in proactive IT operations. 3. How redefining SLAs can drive a preventative mindset. 4. The challenge of measuring hidden ROI—and why it's worth it. 5. Lessons from HP's success with preventative strategies. Tune in to learn how preventative Incident Management can transform your IT approach and hear actionable advice from one of the industry's leading voices. Don't forget to like, subscribe, and share your thoughts in the comments!

В пересменке между техноконференциями собрались парой в шумной переговорке — я и Александр Быков, Head of Software Engineering, Diabolocom.com. Записали подкаст про Incident Management Process. Кто, как, почему, а как у них, а как у нас. Приводим примеры из области пожаротушения и спасательных работ в горах, упоминаем наши технологические компании (например, OZON). Разбираемся, зачем нужен писец и как правильно работать on-call. Обо всем этом и не только наш 327-й подкаст The Art of Programming — «Incident Management Process». Участники @golodnyj Александр Быков Telegram канал VK группа Яндекс Музыка iTunes подкаст Поддержи подкаст

Managing during a crisis event is challenging for even the most experienced incident managers. Incidents that happen in and around a port environment can be especially difficult to manage, proving daunting even for first responders and other seasoned crisis management professionals. Port environments encompass both land and sea-based risks, handle and store dangerous chemicals and materials and involve the operation of large handling equipment and machinery.

Key Takeaways:Catalysts drive AI transformation – Learn how Brice's 'catalyst' approach sparks cultural and technological shifts in organizations.AI champions fuel innovation – Discover how Moderna's Generative AI Champions Team amplifies AI adoption and engagement.Augment, don't replace – Brice explains why the goal is not to replace humans but to enhance their capabilities.Outdated habits are out – Embrace modern tools and innovative methodologies to stay ahead.Start with ‘Why' – Understand the importance of anchoring AI initiatives to purpose-driven objectives for lasting success.Moderna's website: Pioneering mRNA technology - Moderna00:00 Introduction to Brice Challamel and His Role at Moderna00:45 What It Means to Be an AI Catalyst02:30 Leadership in the AI Era: Moving Beyond Traditional Hierarchies06:10 Avoiding "Fred-like Behavior" in a Modern Workplace10:20 Augmenting Human Potential: The Five-Person AI Team14:50 How Moderna Manages 700+ GPTs Safely and Efficiently20:30 Democratizing AI: Why It's a Utility for Every Employee27:15 Using AI to Transform Personal and Professional Growth32:40 Frameworks for Incident Management in AI Integration39:15 AI's Role in Healthcare, Radiology, and Beyond43:30 The Generative AI Champions Team: GCAT in Action50:00 The Future of Work: Collaboration and Culture with AI01:03:27 Reflections on AI Adoption and Leadership Insights For more prompts, tips, and AI tools. Check out our website: https://www.beyondtheprompt.ai/ or follow Jeremy or Henrik on Linkedin:Henrik: https://www.linkedin.com/in/werdelinJeremy: https://www.linkedin.com/in/jeremyutley Show edited by Emma Cecilie Jensen.

In this Episode, we explore how adopting a managerial mindset can significantly enhance your CISM exam strategies. The CISM exam is not just a test of technical knowledge; it requires a strategic, managerial approach to information security. InfosecTrain's expert instructors will guide you through the four key domains of the CISM exam—Information Security Governance, Risk Management, Information Security Program Development, and Incident Management—while helping you think like a manager.

In this Episode, we provide essential guidelines for the CISM Exam, ensuring that you are fully prepared to crack the CISM Exam Strategies. The Episode covers critical guidelines on how to approach the exam's four key domains: Information Security Governance, Risk Management, Information Security Program Development, and Incident Management. These areas are crucial to the exam, and understanding them deeply will significantly increase your chances of success.

Summary In this episode of Five Minutes to Chaos, Steven Kuhr interviews Chief Bill Van Helden, who shares his extensive experience in emergency management and crisis leadership. The conversation covers Bill's career journey, the importance of spirituality in emergency services, and the emotional toll that crisis management can take on leaders. They discuss significant events like Hurricane Charlie, the need for courage and command presence in emergencies, and the importance of thinking the unthinkable. Bill emphasizes the necessity of humility in leadership, the risks of carbon monoxide after hurricanes, and the changing nature of emergency management in Florida. The episode concludes with reflections on the emotional impact of crisis management and the importance of pre-planning for emergencies. Takeaways The importance of crisis management in emergency situations. Leadership requires courage and the ability to make tough decisions. Spirituality can play a significant role in the lives of emergency workers. Understanding the emotional toll of crisis management is crucial. Planning for the unthinkable is essential in emergency management. The need for humility in leadership roles. Carbon monoxide risks increase after hurricanes due to generator use. Continuity of government is vital during emergencies. New residents in Florida may not understand hurricane risks. Pre-planning contracts for debris management can save time and lives. Contract Information bvhretiree2021@gmail.com

Summary In this episode of '5 Minutes to Chaos', host Steven Kuhr engages with Rich Pepe, a seasoned crisis management professional with extensive experience in law enforcement, emergency services, and corporate security. The conversation explores Rich's journey through the NYPD Highway Patrol, his volunteer firefighting experience, and the evolution of emergency services in New York City. They discuss the critical role of the Office of Emergency Management (OEM) in coordinating responses during crises, the intricacies of traffic incident management, and the implementation of contraflow strategies during evacuations. Rich also shares insights from his time at Deutsche Bank during the COVID-19 pandemic and his current role at Manhattan Beer Distributors, highlighting the importance of collaboration and communication in crisis management. Takeaways Crisis management is about real experiences and observations. Traffic incident management is crucial for emergency response. Combat parking helps ensure emergency vehicles can access scenes. OEM plays a vital role in coordinating emergency responses. Contraflow planning is essential for effective evacuations. Crisis management requires collaboration across agencies. The Deutsche Bank crisis management team was well-prepared during COVID-19. Effective communication is key in crisis management. Keeping the beer flowing is critical for Manhattan Beer Distributors. Takeaways Crisis management is about real experiences and observations. Traffic incident management is crucial for emergency response. Combat parking helps ensure emergency vehicles can access scenes. OEM plays a vital role in coordinating emergency responses. Contraflow planning is essential for effective evacuations. Crisis management requires collaboration across agencies. The Deutsche Bank crisis management team was well-prepared during COVID-19. Effective communication is key in crisis management. Keeping the beer flowing is critical for Manhattan Beer Distributors. Contact Information https://www.linkedin.com/in/nypdpepe/

In this episode of Detection at Scale, Jack speaks to JJ Tang, CEO and Co-founder of Rootly, about revolutionizing incident management in tech organizations. JJ shares his journey from practitioner to founder and emphasizes the importance of viewing incident management as a cultural and collaborative effort rather than just a tooling issue.    JJ touches on breaking down silos between security and other teams to enhance communication and reliability, and empowering security practitioners to take on educator roles within their organizations. He also offers actionable insights on creating a culture of reliability and improving incident response strategies!    Topics discussed: The importance of viewing incident management as a cultural shift rather than just a tooling problem, focusing on people and processes.   Strategies for breaking down silos between security teams and other departments to foster collaboration and improve incident response effectiveness.   The role of security practitioners as educators, helping other teams understand best practices and the importance of security in incident management.   The significance of collecting and analyzing data on repeat incidents to identify root causes and prevent future occurrences.   Insights on how to create a culture of reliability within organizations, making incident management a shared responsibility across teams.   The challenges faced during the transition from a practitioner role to a founder and CEO in the tech industry.   The impact of AI and automation on incident management, including how these technologies can improve response times and learning from incidents.   The necessity of having a clear governance framework in place to ensure data privacy and security during incident management processes.     Resources Mentioned:  JJ Tang on LinkedIn Rootly website

In this episode, Amit and Dheeraj dive deep into the transformative world of AI agents and enterprise workflows. They explore the concept of “AgentOS”—a platform enabling modular agents, each equipped with specific skills to tackle distinct challenges within workflows. Drawing parallels between AI advancements and real-world enterprise needs, Amit and Dheeraj discuss the importance of balancing both probabilistic AI-driven nodes with deterministic workflows to enhance efficiency without losing context or accuracy. Together, they examine industry needs, like reducing redundancy in incident management through vector databases, and predict the impact of AI agents on collaboration platforms, employee workflows, and customer support. This episode is a rich, thought-provoking journey through the latest in AI, where Amit and Dheeraj also offer their insights into enterprise AI adoption, future trends, and their forecasts for the next decade of AI-driven business transformation.Key Topics and Timestamps:The Rise of AI Agents [0:14]System 1 and System 2 Thinking in AI [1:50]Workflows in Enterprise Automation [3:51]Handling Context and Intent in Workflows [10:32]Incident Management and Reducing Redundancy [43:57]Collaboration Platforms' Future [49:13]Optimizing Enterprise Workflows with Agentic Systems [1:03:46]The Enterprise AI Landscape and Predictions [1:13:18]Share Your Thoughts: Have questions or comments? Drop us a mail at EffortlessPodcastHQ@gmail.com

Oct. 31, 2024 - In the wake of the devastation caused by Hurricane Helene, more than 200 state and local government employees from New York were deployed to help communities across the South. We talk about this experience with Adam Picket, Nick Johnston, and Erin Hanczyk, who are part of the state's incident management team and were deployed to North Carolina.

I'm Kevin Pannell, Host of the Hope is NOT a Plan podcast. I am an IT Healthcare Project Management Office leader with a background in Public Safety, Special Event planning, and Incident Management and disaster response. In this episode, Hurricane Helene SITREP as of 06OCT2024, I'm providing a numerical snapshot of the impact of Hurricane Helene, the importance of shifting operations and mindset from rescue to recovery mode, and three opportunities for improvement I've observed from afar as a former Planning Section Chief on an All-Hazards Incident Management Team (AHIMT).How you can help:General GuidanceContact the State Emergency Management agencyCash is kingShelf stable foodWaterVolunteerState Emergency Management ContactsNorth Carolina: https://www.ncdps.gov/how-to-donateSouth Carolina: https://www.scemd.org/news/hurricane-helene-cleanup-in-south-carolina/ Georgia: https://gema.georgia.gov/hurricane-helene Florida: https://www.floridadisaster.org/disaster-updates/storm-updates/ Tennessee: https://www.tn.gov/tema/updates/hurricane-helene.html Virginia: https://www.vaemergency.gov/recover/hurricane-helene Thank you to all those that stepped up and stepped into harm's way to help their fellow Americans. Godspeed to the survivors and the fallen. God bless America.

Join me as I talk with experienced Business Continuity Management (BCM), Incident Management, and Emergency Response specialist, Jennifer Park, as we discuss why organizations and leadership downplay the importance of BCM along with what it can offer organizations. During our discussion we touch on: 1. Defining BCM and resilience (Jennifer's view), 2. Viewing BCM as a short-term initiative, 3. 'Chicken little' syndrome, 4. Periodic rebuilding of programs, 5. Create and show value, 6. AI has the answers, 7. RTO misunderstandings, 8. Aligning BCM with IT, 9. Not understanding impacts and dependencies (it's not just the number of people using an application!), 10. Decisions, 11. Prioritization and reprioritization, 12. Tips to improve BCM visibility...and much more! Jennifer share some great insights on why organization leadership may not fully understand the complexity and benefits of a good BCM program, while also offer suggestions on how to improve our own if we aren't getting the traction we want. Enjoy!

A veteran of early Twitter's fail whale wars, Dmitriy joins the show to chat about the time when 70% of the Hadoop cluster got accidentally deleted, the financial reality of writing a book, and how to navigate acquisitions. Segments: (00:00:00) The Infamous Hadoop Outage (00:02:36) War Stories from Twitter's Early Days (00:04:47) The Fail Whale Era (00:06:48) The Hadoop Cluster Shutdown (00:12:20) “First Restore the Service Then Fix the Problem. Not the Other Way Around.” (00:14:10) War Rooms and Organic Decision-Making (00:16:16) The Importance of Communication in Incident Management (00:19:07) That Time When the Data Center Caught Fire (00:21:45) The "Best Email Ever" at Twitter (00:25:34) The Importance of Failing (00:27:17) Distributed Systems and Error Handling (00:29:49) The Missing README (00:33:13) Agile and Scrum (00:38:44) The Financial Reality of Writing a Book (00:43:23) Collaborative Writing Is Like Open-Source Coding (00:44:41) Finding a Publisher and the Role of Editors (00:50:33) Defining the Tone and Voice of the Book (00:54:23) Acquisitions from an Engineer's Perspective (00:56:00) Integrating Acquired Teams (01:02:47) Technical Due Diligence (01:04:31) The Reality of System Implementation (01:06:11) Integration Challenges and Gotchas Show Notes: - Dmitriy Ryaboy on Twitter: https://x.com/squarecog - The Missing README: https://www.amazon.com/Missing-README-Guide-Software-Engineer/dp/1718501838 - Chris Riccomini on how to write a technical book: https://cnr.sh/essays/how-to-write-a-technical-book Stay in touch: - Make Ronak's day by signing up for our newsletter to get our favorites parts of the convo straight to your inbox every week :D https://softwaremisadventures.com/ Music: Vlad Gluschenko — Forest License: Creative Commons Attribution 3.0 Unported: https://creativecommons.org/licenses/by/3.0/deed.en

Dr. Catherine Booth joined HM Prison and Probation Service in 1997. During her career she has worked with men, women and children in custody and currently works in HMPPS North West Psychology Services. Cath has been involved in the management of serious incidents in prisons for over 20 years as a practitioner and trainer. She acts as a Silver and Gold negotiation advisor (NA) and is involved in training prison officers and psychologists to become negotiators and negotiation advisors, respectively. Cath completed her doctoral research in exploring the experiences of prison officer negotiators. Dr. Carol Bond has been a forensic psychologist for over 30 years, spending most of her career working in prisons as well as practicing in secure psychiatric hospitals, working as a specialist member of the parole board and lecturing in academic settings. Throughout her career she has been involved in the management of serious incidents including training staff, advising negotiators and commanders during incidents, developing specialist training courses and working with other professionals involved in crisis management. She is the national lead for HMPPS negotiation matters and has recently completed her Doctorate exploring hostage incidents in UK prisons. Key references: McMains, M., Mullins, W., & Young, A. (2020) Crisis Negotiations: Managing Critical Incidents and Hostage Situations in Law Enforcement and Corrections (6th ed.). Routledge. https://doi.org/10.4324/9780429505225 Cialdini, Robert B. (2021) Influence, New and Expanded: The Psychology of Persuasion. New York: HarperCollins. Grubb, A. (2010) Modern day hostage (crisis) negotiation: The evolution of an art form within the policing arena. Aggression and Violent Behavior. 15. 341-348. https://doi.org/10.1016/j.avb.2010.06.002

Stephanie "Steph" Bishop currently serves as a Public Information Officer and member of the Command and General Staff of California Interagency Incident Management Team 4 (CIIMT 4), a Federal Type 1“All-Hazards” Incident Management Team. Stephanie serves as the lead managing and mentoring other Public Information Officers to establish and coordinate all media, community, and stakeholder relation information needs during an incident. In addition, she is responsible for establishing and maintaining positive interpersonal and interagency working relationships with local, state, tribal, and federal governments to ensure the right message is being delivered to those affected promptly and accurately.Before joining CIIMT4, she had a diverse and impressive background in various fields related to public safety, communications, and emergency response that gave her a unique perspective on the challenges faced in public relations. Stephanie was introduced to public information during her 18 years in law enforcement, specializing in child crimes and human trafficking, where she would assist in communicating with the media and public about ongoing investigations and high-profile cases.With over 25 years of experience and training, she has a wealth of knowledge and skills that she brings to her role as a Public Information Officer. She has a Bachelor's degree in Criminology from Regis University. She attended Purdue University, obtaining a Master's in Crisis and Strategic Communications and Strategic Management. Stephanie has a passion for sharing her experience with others through teaching and has been a subject matter expert in strategic communications. She is an instructor for the USFS and NPS in Region 5 S203 Public Information Course, L952 All Hazards Public Information, and assists in mentoring and coaching in Command and General Staff courses.Stephanies EmailThis Is PropagandaChallenging marketers' delusions about the cultural impact of our work. A WEBBY winner!Listen on: Apple Podcasts SpotifySupport the Show.This episode is sponsored by John Guilfoil Public Relations. From crisis communications to website development; visit our website JGPR.net or call 617.993.0003

Summary This episode features an insightful conversation with Petr Janda, the CEO and founder of Synq. Petr shares his journey from being an engineer to founding Synq, emphasizing the importance of treating data systems with the same rigor as engineering systems. He discusses the challenges and solutions in data reliability, including the need for transparency and ownership in data systems. Synq's platform helps data teams manage incidents, understand data dependencies, and ensure data quality by providing insights and automation capabilities. Petr emphasizes the need for a holistic approach to data reliability, integrating data systems into broader business processes. He highlights the role of data teams in modern organizations and how Synq is empowering them to achieve this. Announcements Hello and welcome to the Data Engineering Podcast, the show about modern data management Data lakes are notoriously complex. For data engineers who battle to build and scale high quality data workflows on the data lake, Starburst is an end-to-end data lakehouse platform built on Trino, the query engine Apache Iceberg was designed for, with complete support for all table formats including Apache Iceberg, Hive, and Delta Lake. Trusted by teams of all sizes, including Comcast and Doordash. Want to see Starburst in action? Go to dataengineeringpodcast.com/starburst (https://www.dataengineeringpodcast.com/starburst) and get $500 in credits to try Starburst Galaxy today, the easiest and fastest way to get started using Trino. Your host is Tobias Macey and today I'm interviewing Petr Janda about Synq, a data reliability platform focused on leveling up data teams by supporting a culture of engineering rigor Interview Introduction How did you get involved in the area of data management? Can you describe what Synq is and the story behind it? Data observability/reliability is a category that grew rapidly over the past ~5 years and has several vendors focused on different elements of the problem. What are the capabilities that you saw as lacking in the ecosystem which you are looking to address? Operational/infrastructure engineers have spent the past decade honing their approach to incident management and uptime commitments. How do those concepts map to the responsibilities and workflows of data teams? Tooling only plays a small part in SLAs and incident management. How does Synq help to support the cultural transformation that is necessary? What does an on-call rotation for a data engineer/data platform engineer look like as compared with an application-focused team? How does the focus on data assets/data products shift your approach to observability as compared to a table/pipeline centric approach? With the focus on sharing ownership beyond the boundaries on the data team there is a strong correlation with data governance principles. How do you see organizations incorporating Synq into their approach to data governance/compliance? Can you describe how Synq is designed/implemented? How have the scope and goals of the product changed since you first started working on it? For a team who is onboarding onto Synq, what are the steps required to get it integrated into their technology stack and workflows? What are the types of incidents/errors that you are able to identify and alert on? What does a typical incident/error resolution process look like with Synq? What are the most interesting, innovative, or unexpected ways that you have seen Synq used? What are the most interesting, unexpected, or challenging lessons that you have learned while working on Synq? When is Synq the wrong choice? What do you have planned for the future of Synq? Contact Info LinkedIn (https://www.linkedin.com/in/petr-janda/?originalSubdomain=dk) Substack (https://substack.com/@petrjanda) Parting Question From your perspective, what is the biggest gap in the tooling or technology for data management today? Closing Announcements Thank you for listening! Don't forget to check out our other shows. Podcast.__init__ (https://www.pythonpodcast.com) covers the Python language, its community, and the innovative ways it is being used. The Machine Learning Podcast (https://www.themachinelearningpodcast.com) helps you go from idea to production with machine learning. Visit the site (https://www.dataengineeringpodcast.com) to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show then tell us about it! Email hosts@dataengineeringpodcast.com (mailto:hosts@dataengineeringpodcast.com) with your story. Links Synq (https://www.synq.io/) Incident Management (https://www.pagerduty.com/resources/learn/what-is-incident-management/) SLA == Service Level Agreement (https://en.wikipedia.org/wiki/Service-level_agreement) Data Governance (https://en.wikipedia.org/wiki/Data_governance) Podcast Episode (https://www.dataengineeringpodcast.com/nicola-askham-practical-data-governance-episode-428) PagerDuty (https://www.pagerduty.com/) OpsGenie (https://www.atlassian.com/software/opsgenie) Clickhouse (https://clickhouse.com/) Podcast Episode (https://www.dataengineeringpodcast.com/clickhouse-data-warehouse-episode-88/) dbt (https://www.getdbt.com/) Podcast Episode (https://www.dataengineeringpodcast.com/dbt-data-analytics-episode-81/) SQLMesh (https://sqlmesh.readthedocs.io/en/stable/) Podcast Episode (https://www.dataengineeringpodcast.com/sqlmesh-open-source-dataops-episode-380) The intro and outro music is from The Hug (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/Love_death_and_a_drunken_monkey/04_-_The_Hug) by The Freak Fandango Orchestra (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/) / CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/)

By Adam Turteltaub The annual Navex Whistleblowing, Incident Management and Benchmarking Report provides valuable insights into what's going on across the corporate compliance landscape. To get the highlights we spoke with Carrie Penman (LinkedIn), Chief Risk & Compliance Officer for Navex. The 2023 data showed that reporting reached an all-time high, with 1.57 reports for every 100 employees, up from 1.47 the previous year. Substantiation reached an 11 year high at 45%, which indicates that compliance teams are getting both more and better reports out of the workforce. Anonymity remained dominant, with 56% of reports arriving that way. Substantiation rates for anonymous reports held steady at 33%, which is lower than the 50% for reports given by an identified individual. Accounting-related incidents accounted for 4.3% of reports, a relatively small number. However, they were notable because they had the longest period between the observation of suspected wrongdoing and reporting. They also were the least likely to be reported anonymously. Third party reporters were likelier to report on business integrity issues, such as human rights, bribery and conflicts of interest. Substantiation rates were similar to those of anonymous reports. So what should compliance teams be doing as a result of this data? First, she recommends continuing to build trust in reporting systems. Second, prepare for an increased number of reports. Listen in to learn more about what is going on in incidents and whistleblowing.

Send us a Text Message.What makes a Customer Liaison Officer indispensable during incident management? Join us as we tap into the expertise of Kat Gaines, who shares her invaluable experience and detailed examples to illuminate the crucial responsibilities of this role. Discover how effectively bridging the communication gap between incident response teams and customer-facing staff can transform your incident response strategy. Kat delves into the art of aggregating customer-reported issues and managing internal expectations, revealing why sticking to standard processes just won't cut it during high-stress incidents.Beyond the basics, we explore the nuanced tasks of real-time decision documentation and post-incident action auditing, essential for thorough reviews and continuous improvement. Kat also brings to light the often-overlooked mental health challenges in customer support roles, the pitfalls of heroism culture, and the necessity of setting clear boundaries to prevent burnout. Tune in for leadership strategies that foster a supportive and effective environment, catering to diverse work styles and ensuring your team remains resilient in the face of stress. Whether you're a seasoned professional or new to incident management, this episode promises to enhance your understanding and capability in handling high-pressure situations. I'd love your thoughts on this episode! Comment below, and like/love/share/support if you found this inspiring, thought-provoking, or useful!Support the Show.

Send us a Text Message.Mastering Incident Management - Part 2 of 6; with Kat GainesEmbark on an insightful expedition into the nerve center of incident management with Kat Gaines and myself, as we unravel the essentials of tailoring an effective process for your organization. We're not just bystanders in the realm of crisis resolution; we're the architects designing the blueprint. This episode promises to hand you the reins of your own incident management strategy, urging you to define incidents and their severities in a way that resonates with your business's unique pulse. As Kat shares her wisdom on building from the ground up, I draw from both our experiences and the well-oiled machine that is PagerDuty, ensuring you leave with a toolkit brimming with proactive solutions.Commanding the spotlight, the role of the Incident Commander is dissected to reveal the mastery behind maintaining clarity amidst chaos. Supported by an ensemble cast of deputies, scribes, and liaisons, we discuss the art of orchestrating an efficient resolution process. Discover how integrating tools like Slack's canvas feature can transform your documentation and communication strategies, enabling your team to make swift decisions and remain in control. It's about more than just the technicalities—it's about empowering your support leaders to assert their expertise without the looming shadow of repercussions.Finally, we emphasize the symphony of soft skills that harmonize with technical know-how to form the crescendo of incident resolution. Personal anecdotes underscore the delicate dance between listening and projecting confidence, especially when the stakes are high. We challenge the preconceived notions about non-technical roles, advocating for their technical savvy and pivotal role in customer communications. Tune in for a paradigm shift that will equip you to conduct a well-orchestrated incident process where clear roles and effective communication are the keystones to success.As part of this episode, Kat shares some awesome PagerDuty resources showing the structure of an Major Incident Response Team and the roles we discuss over this and the coming episodes:Different Roles - PagerDuty Incident Response DocumentationandComplex Incidents - PagerDuty Incident Response DocumentationSupport the Show.

Summary In this conversation, Steven Kuhr and Battalion Chief Jerry Tracy discuss the various units and operations of the New York City Fire Department (FDNY). They highlight the extensive experience and expertise of the FDNY in responding to complex emergencies and crises. They also discuss the formation and role of squad companies, which are specialized units that can respond to fires, hazardous materials incidents, and other emergencies. The conversation emphasizes the importance of training and preparedness in effectively managing and responding to emergencies. The conversation covers various topics related to firefighting and emergency response. Some key themes include the importance of backup and coordination between different departments, the impact of tragic events on changing tactics and procedures, the need for integration between EMS and fire operations, and the development of rapid intervention teams (RIT) or firefighter assistance search teams (FAST). Chief Tracy discusses various topics related to firefighting and emergency response. He shares insights on the challenges faced when dealing with high-rise fires and the importance of effective communication during emergencies. Chief Tracy emphasizes the need for clear and concise communication between different agencies and departments to ensure a coordinated response. He also highlights the significance of strategic communication in emergency management. The conversation touches on the importance of training and preparedness, as well as the need for continuous learning and improvement in the fire service. Takeaways The FDNY is the largest fire department in the United States. Squad companies are specialized units within the FDNY that are trained to respond to a wide range of emergencies, including fires, hazardous materials incidents, and technical rescues. The FDNY has a diverse range of units and resources, including hazmat teams, urban search and rescue teams, wildland fire companies, and mobile respiratory units. Training, preparedness, and collaboration with other agencies are key factors in the FDNY's ability to effectively respond to emergencies and protect the public. Backup and coordination between different departments are crucial in emergency response situations. Tragic events often lead to changes in tactics and procedures. Integration between fire and EMS operations can improve overall response effectiveness. Rapid intervention teams (RIT) or firefighter assistance search teams (FAST) play a vital role in firefighter safety. Firefighters continue to face challenges and make sacrifices in their line of duty. Buildings can be 'born sick and dying,' referring to new construction, renovations, and abandoned or demolished structures. Emergency responders must be prepared for any situation. Effective communication is crucial during emergencies. Incident commanders and responders should have clear channels of communication to ensure a coordinated response. The incident process system is a structured approach to incident command that helps relieve the incident commander of micromanaging tasks. It allows units to fall into place as they arrive on the scene. Strategic communication between police, fire, and EMS is essential for a unified response. Agencies should work together to develop a coordinated strategy. The importance of training and continuous learning in the fire service cannot be overstated. Firefighters should be knowledgeable about their responsibilities and be prepared to adapt to different situations. Contact Information https://www.linkedin.com/in/jerry-tracy-6749b127/

As CEO of SVT Robotics, A.K. Schultz leads the overall company vision and go-to-market strategies. A.K. has spent his career leading the design and implementation of high-profile automation projects across multiple industries and top Fortune 500 companies, participating in the deployment of over $1 billion in automation. That experience gave him a unique understanding of the technical solutions customers need to advance their business, and it provided the foundation to launch SVT Robotics in 2018.Nick Leonard is the SVP of Product at SVT Robotics. With extensive domain and software leadership experience, Nick ingeniously bridges the realms of business and technology, honed through his journey rising through project management and solutions architecture. At SVT, Nick shapes the overall product vision, ensuring the company remains at the cutting edge of robotic process automation. Beyond the office, Nick prides himself on being a mentor, tech enthusiast, and avid reader.SHOW SUMMARYIn this episode of eCom Logistics Podcast, broadcasted live from MODEX 2024 in Atlanta, the conversation dives into the heart of robotics, software, and connectivity within the logistics industry. Featuring interviews with Nick Leonard and AK Schultz from SVT Robotics, the discussion elaborates on the revolutionary software solutions SVT Robotics provides, aimed at enhancing interoperability, automating processes, and ensuring seamless connectivity across various logistic operations without needing physical robots. Their software acts as a central nervous system in logistics, enabling quick and efficient data monitoring and utilization. The episode further explores real-life applications and challenges solved by SVT Robotics' innovative connectivity solutions, emphasizing the critical role of data in optimizing logistics and the importance of easing the integration burden on IT departments and automation integrators.HIGHLIGHTS[00:01:01] Meet the Minds Behind SVT Robotics[00:01:25] Nick Leonard's Journey in Automation[00:02:40] AK Schultz on Solving Interoperability in Robotics[00:06:26] The Philosophy of Connectivity and Integration[00:13:16] Customer Success Stories with SVT Robotics[00:16:19] The Future of Automation: Monitoring and Optimization[00:18:01] Real-Time Incident Management: A Customer Story[00:19:42] Advanced Logging and Fault Analysis[00:20:43] Exploring Orchestration in Robotics and Automation[00:23:40] The Future of Open vs. Closed Ecosystems[00:25:07] Bridging Technology Gaps with Connectivity[00:27:18] Partnering with Tier One Systems for Integration[00:29:11] Empowering IT and Integrators with Advanced ToolsQUOTES[00:06:37] "The machines are really executing what the software is doing and the magic is in the software, right? And so that's number one. Number two, we connect to software or robotic software is basically automating and making things faster and it doesn't necessarily need to involve a machine. It doesn't have to have an articulated arm robot. It can just be a mechanical system, right? So really what it's about is unlocking sensor data and putting it into this, what we see is us being the central nervous system."[00:16:39] "So the first thing I think a lot of people misunderstand is. Now we're connected. What's the next challenge we have to think about? We're going to maintain that system's health, right? Because now we're running an automation facility and you were talking about 120, 140 picks an hour from your baseline. Okay. Now I have that ROI, that clock's ticking. I need to make sure that we're at that 100 to 200, 124 picks all day long. And a lot of automation systems, it's making sure that silent failures aren't happening in your system. So a lot of times maybe you're a bad data from a wrong order structure or something like that. One system doesn't like the data that's being exchanged. A lot of times that's happened. That's silently failing in the background."Find out more about A.K. Schultz and Nick Leonard in the links below.A.K. Schultz's LinkedIn Profile: https://www.linkedin.com/in/a-k-schultz-9b5b899/Nick Leonard's LinkedIn Profile: https://www.linkedin.com/in/nickleonard/SVT Robotics Website: https://www.svtrobotics.com/SVT Robotics Library: https://atlas.svtrobotics.comThis episode is sponsored by G&P Construction. If you're in need of top notch, all-inclusive Material handling solutions for logistics and commercial real estate, look no further than G&P Construction. Be sure to visit www.gandpconstruction.com to discover your one-stop shop for turnkey MHE integrations.

In February 2023, Chief Brian Nardelli of the Brockton Fire Department in Massachusetts found himself at the helm of one of the most complex operations a chief can face: a hospital fire requiring a full evacuation. The eight-hour incident at Brockton Hospital involved a nasty electrical fire, 91 ambulances, 162 patients evacuated and transferred, 26 pieces of fire apparatus, and resulted in zero deaths and injuries. Chief Nardelli, the incident commander that day, joins the podcast to take us through the incident, including what worked, and lessons learned (2:50). Then, on a new Code Corner, NFPA electrical expert Corey Hannahs, in honor of electrical safety month, talks about how electrical safety is achieved through the use of NFPA codes and standards (38:04).

In this episode, Courtney Nash, a researcher focused on system safety and failures in complex sociotechnical systems, discussed the latest edition of the VOID report. Topics covered included: incident management and the role of automation, working effectively within socio-technical systems, and the value of collecting and analyzing system metrics in the good times and the bad. Read a transcript of this interview: https://bit.ly/3Q46y0k Subscribe to the Software Architects' Newsletter for your monthly guide to the essential news and experience from industry peers on emerging patterns and technologies: https://www.infoq.com/software-architects-newsletter Upcoming Events: InfoQ Dev Summit Boston (June 24-25, 2024) Actionable insights on today's critical dev priorities. https://devsummit.infoq.com/conference/boston2024 InfoQ Dev Summit Munich (Sept 26-27, 2024) Practical learnings from senior software practitioners navigating Generative AI, security, modern web applications, and more. https://devsummit.infoq.com/conference/munich2024 QCon San Francisco (November 18-22, 2024) Get practical inspiration and best practices on emerging software trends directly from senior software developers at early adopter companies. https://qconsf.com/ QCon London (April 7-9, 2025) Discover new ideas and insights from senior practitioners driving change and innovation in software development. https://qconlondon.com/ The InfoQ Podcasts: Weekly inspiration to drive innovation and build great teams from senior software leaders. Listen to all our podcasts and read interview transcripts: - The InfoQ Podcast https://www.infoq.com/podcasts/ - Engineering Culture Podcast by InfoQ https://www.infoq.com/podcasts/#engineering_culture - Generally AI Follow InfoQ: - Mastodon: https://techhub.social/@infoq - Twitter: twitter.com/InfoQ - LinkedIn: www.linkedin.com/company/infoq - Facebook: bit.ly/2jmlyG8 - Instagram: @infoqdotcom - Youtube: www.youtube.com/infoq Write for InfoQ: Learn and share the changes and innovations in professional software development. - Join a community of experts. - Increase your visibility. - Grow your career. https://www.infoq.com/write-for-infoq

Host Luke Barrett is joined by the Incredible Burk Minor, WILDLAND FIREFIGHTER FOUNDATION Co-founder & Executive Director. Burk has been caring for and supporting the wildland community, since the Storm King fire, in Colorado in 1994. Burk is the frontline responder for the Foundation whenever an incident arises. Burk is an expert at crisis management and is counted on by the wildland community for his knowledge, awareness and resources. A master relationship builder, fundraiser and strategist, his influence has created a thriving foundation, excellence among top tier charities and countless awards and recognition. His true colors shine when working with Incident Management teams and the Honor Guard to provide recognition to the fallen and injured. Burk has dedicated thirty plus years in wildland fire and is a voice for the boots on the ground and in the air.

Mastering Incident Management - Part 1 of 6; with Kat GainesUnlock the secrets to seamless service as we navigate the critical world of incident management with the expertise of Kat Gaines from PagerDuty. Prepare to be armed with a deeper understanding of the complexities that define an incident, and why this knowledge is a game-changer for teams committed to providing uninterrupted excellence. Kat's seasoned perspective will guide you through the layers of incident severity and the essential preparedness for the unexpected. This episode isn't just a conversation; it's a toolkit for anyone in the support and development trenches, laying the foundational strategies for robust incident response.  Embark on a journey through the collaborative core of incident management, where the role of support engineers is reimagined as a pathway to career growth and the position of an incident commander becomes the linchpin of crisis resolution. With a focus on the symbiosis between structured protocols and the agility to adapt, we dissect how cross-functional cooperation and continuous process refinement are the cornerstones of an organization's resilience. From prioritizing responses to managing bugs, this dialogue with Kat is more than just an exploration—it's an invitation to evolve your practices and prioritize your customers in the face of adversity. Join us for an eye-opening series that promises to redefine your approach to incident management and elevate your team's capabilities.Support the Show.

Introduction Art Powers is the Senior Principal for Emergency Preparedness & Response at ExxonMobil. He is a past coordinator of the ExxonMobil Americas Regional Response Team and has worked in various leadership roles in ExxonMobil's US Pipeline and Distribution operations over his 25 years with the company. Art is an IAEM Certified Emergency Manager and obtained a Master of Science in Emergency Management in 2008 and a Bachelor of Science in Marine Transportation in 1993, both from the Massachusetts Maritime Academy. Over Art's career, he has been part of the Massachusetts Army National Guard, worked in shipping in New York Harbor, spent time as a petroleum inspector, and has moved around the US six times, living in Massachusetts twice, Buffalo NY, Chicagoland, and Northern Virginia, before ending up in Texas in 2014. Art spends his time traveling for work or spending time in Mauritius with his wife. He has one son, two stepsons, and a stepdaughter. Contact Information https://www.linkedin.com/in/art-powers-cem-38549012/

This New Stack Makers podcast co-hosted by Alex Williams, TNS founder and publisher, and Adrian Cockcroft, Partner and Analyst at OrionX.net, discussed Nvidia's GH200 Grace Hopper superchip. Industry expert Sunil Mallya, Co-founder and CTO of Flip AI weighed in on how it is revolutionizing the hardware industry for AI workloads by centralizing GPU communication, reducing networking overhead, and creating a more efficient system. Mallya noted that despite its innovative design, challenges remain in adoption due to interface issues and the need for software to catch up with hardware advancements. However, optimism persists for the future of AI-focused chips, with Nvidia leading the charge in creating large-scale coherent memory systems. Meanwhile, Flip AI, a DevOps large language model, aims to interpret observability data to troubleshoot incidents effectively across various cloud platforms. While discussing the latest chip innovations and challenges in training large language models, the episode sheds light on the evolving landscape of AI hardware and software integration.Learn more from The New Stack about Nvidia and the future of chip design  Nvidia Wants to Rewrite the Software Development Stack Nvidia GPU Dominance at a Crossroads Join our community of newsletter subscribers to stay on top of the news and at the top of your game.  

Today's guest is Jason Walker, Chief Innovation Officer at BigPanda. BigPanda is a California-based software developer whose AIOps-powered platform helps businesses improve their service support and incident management systems. Jason joins us on this week's podcast to discuss what financial leaders need to know to drive the IT infrastructure necessary to take advantage of new, emerging, data-heavy use cases we're seeing in generative AI. Later, he and Senior Editor Matthew DeMello discuss GenAI tools that can help streamline IT workflows. If you've enjoyed or benefited from some of the insights of this episode, consider leaving us a five-star review on Apple Podcasts, and let us know what you learned, found helpful, or liked most about this show!

In this episode, we welcome Nora Jones, Founder and CEO of Jeli, which PagerDuty acquired in 2023. We talk with Nora about expanding incident response into incident management and learning from incidents to improve reliability.

In this enlightening episode of "Chemical Reactions: The Hidden Layer of Workplace Safety," we delve deep into the often-overlooked aspect of EHS (Environmental, Health, and Safety): the intricate role of body chemistry in workplace incidents and safety incentive programs. Join us as we explore how neurotransmitters and hormones such as serotonin, oxytocin, cortisol, adrenaline, and more, influence not only individual responses to workplace accidents but also overall employee engagement in safety practices. With insights from a seasoned EHS professional boasting over 20 years of experience, we uncover the physiological underpinnings that drive diverse reactions to safety incidents, from heightened alertness to stress-induced anxiety. This episode doesn't just stop at identifying problems; it offers practical, innovative strategies for integrating an understanding of body chemistry into the design of safety incentive programs. From peer recognition systems that boost serotonin and oxytocin levels to stress reduction workshops aimed at lowering cortisol and adrenaline, we discuss how these approaches can foster a positive, supportive, and ultimately safer work environment. Whether you're an EHS officer, HR professional, or someone interested in the psychological aspects of workplace safety, this episode will equip you with the knowledge to see safety through a new lens. Discover how tapping into the power of our body's chemical messengers can revolutionize safety practices and create a culture of well-being and proactive safety engagement.

In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Vanessa Huerta Granda Manager of Resiliency Engineering at Enova. Read a transcript of this interview: https://www.infoq.com/podcasts/incident-management-resilience/ Subscribe to the Software Architects' Newsletter for your monthly guide to the essential news and experience from industry peers on emerging patterns and technologies: www.infoq.com/software-architects-newsletter Upcoming Events: QCon London (April 8-10, 2024) Discover new ideas and insights from senior practitioners driving change and innovation in software development. qconlondon.com/ InfoQ Dev Summit Boston (June 24-25, 2024) Actionable insights on today's critical dev priorities. devsummit.infoq.com/ QCon San Francisco (November 18-22, 2024) Get practical inspiration and best practices on emerging software trends directly from senior software developers at early adopter companies. qconsf.com/ The InfoQ Podcasts: Weekly inspiration to drive innovation and build great teams from senior software leaders. Listen to all our podcasts and read interview transcripts: - The InfoQ Podcast www.infoq.com/podcasts/ - Engineering Culture Podcast by InfoQ www.infoq.com/podcasts/#engineering_culture Follow InfoQ: - Mastodon: techhub.social/@infoq - Twitter: twitter.com/InfoQ - LinkedIn: www.linkedin.com/company/infoq - Facebook: bit.ly/2jmlyG8 - Instagram: @infoqdotcom - Youtube: www.youtube.com/infoq Write for InfoQ: Learn and share the changes and innovations in professional software development. - Join a community of experts. - Increase your visibility. - Grow your career. www.infoq.com/write-for-infoq

Imagine being caught in a home emergency, your heart racing and mind scattered — would you know what to do? This episode is a must-listen for every homemaker as I sit down with Elizabeth Dillard, a paramedic firefighter with a wealth of field experience, to arm you with the knowledge and skills for effective crisis management in the home. Together, we dissect the fine line between fear that paralyzes and fear that mobilizes. Elizabeth shares empowering wisdom from scripture to fight paralyzing fear AND some practical knowledge for preparing your response and assessing  life-threatening situations. In this episode:

Robert Ross, CEO and Co-Founder at FireHydrant, joins Corey on Screaming in the Cloud to discuss how being an on-call engineer fighting incidents inspired him to start his own company. Robert explains how FireHydrant does more than just notify engineers of an incident, but also helps them to be able to effectively put out the fire. Robert tells the story of how he “accidentally” started a company as a result of a particularly critical late-night incident, and why his end goal at FireHydrant has been and will continue to be solving the problem, not simply choosing an exit strategy. Corey and Robert also discuss the value and pricing models of other incident-reporting solutions and Robert shares why he feels surprised that nobody else has taken the same approach FireHydrant has. About RobertRobert Ross is a recovering on-call engineer, and the CEO and co-founder at FireHydrant. As the co-founder of FireHydrant, Robert plays a central role in optimizing incident response and ensuring software system reliability for customers. Prior to founding FireHydrant, Robert previously contributed his expertise to renowned companies like Namely and Digital Ocean. Links Referenced: FireHydrant: https://firehydrant.com/ Twitter: https://twitter.com/bobbytables TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Developers are responsible for more than ever these days. Not just the code they write, but also the containers and cloud infrastructure their apps run on. And a big part of that responsibility is app security — from code to cloud. That's where Snyk comes in. Snyk is a frictionless security platform that meets teams where they are, automating application security controls across their existing tools, workflows, and the AWS application stack — including seamless integrations with AWS CodePipeline, Amazon EKS, Amazon Inspector and several others. I'm a customer myself. Deploy on AWS. Secure with Snyk. Learn more at snyk.co/scream. That's S-N-Y-K-dot-C-O/scream.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. And this featured guest episode is brought to us by our friends at FireHydrant and for better or worse, they've also brought us their CEO and co-founder, Robert Ross, better known online as Bobby Tables. Robert, thank you for joining us.Robert: Super happy to be here. Thanks for having me.Corey: Now, this is the problem that I tend to have when I've been tracking companies for a while, where you were one of the only people that I knew of at FireHydrant. And you kind of still are, so it's easy for me to imagine that, oh, it's basically your own side project that turned into a real job, sort of, side hustle that's basically you and maybe a virtual assistant or someone. I have it on good authority—and it was also signaled by your Series B—that there might be more than just you over there now.Robert: Yes, that's true. There's a little over 60 people now at the company, which is a little mind-boggling for me, starting from side projects, building this in Starbucks to actually having people using the thing and being on payroll. So, a little bit of a crazy thing for me. But yes, over 60.Corey: So, I have to ask, what is it you folks do? When you say ‘fire hydrant,' the first thing that I think I was when I was a kid getting yelled at by the firefighter for messing around with something I probably shouldn't have been messing around with.Robert: So, it's actually very similar where I started it because I was messing around with software in ways I probably shouldn't have and needed a fire hydrant to help put out all the fires that I was fighting as an on-call engineer. So, the name kind of comes from what do you need when you're putting out a fire? A fire hydrant. So, what we do is we help people respond to incidents really quickly, manage them from ring to retro. So, the moment you declare an incident, we'll do all the timeline tracking and eventually help you create a retrospective at the very end. And it's been a labor of love because all of that was really painful for me as an engineer.Corey: One of the things that I used to believe was that every company did something like this—and maybe they do, maybe they don't—I'm noticing these days an increasing number of public companies will never admit to an incident that very clearly ruined things for their customers. I'm not sure if they're going to talk privately to customers under NDAs and whatnot, but it feels like we're leaving an era where it was an expectation that when you had a big issue, you would do an entire public postmortem explaining what had happened. Is that just because I'm not paying attention to the right folks anymore, or are you seeing a downturn in that?Robert: I think that people are skittish of talking about how much reliability they—or issues they may have because we're having this weird moment where people want to open more incidents like the engineers actually want to say we have more incidents and officially declare those, and in the past, we had these, like, shadow incidents that we weren't officially going to say it was an incident, but was a pretty big deal, but we're not going to have a retro on it so it's like it didn't happen. And kind of splitting the line between what's a SEV1, when should we actually talk about this publicly, I think companies are still trying to figure that out. And then I think there's also opposing forces. We talk to folks and it's, you know, public relations will sometimes get involved. My general advice is, like, you should be probably talking about it no matter what. That's how you build trust.It's trust, with incidences, lost in buckets and gained back in drops, so you should be more public about it. And I think my favorite example is a major CDN had a major incident and it took down, like, the UK government website. And folks can probably figure out who I'm talking about, but their stock went up the next day. You would think that a major incident taking down a large portion of the internet would cause your stock to go down. Not the case. They were on it like crazy, they communicated about it like crazy, and lo and behold, you know, people were actually pretty okay with it as far as they could be at the end of the day.Corey: The honest thing that really struck me about that was I didn't realize that CDN that you're referencing was as broadly deployed as it was. Amazon.com took some downtime as a result of this.Robert: Yeah.Corey: It's, “Oh, wow. If they're in that many places, I should be taking them more seriously,” was my takeaway. And again, I don't tend to shame folks for incidents because as soon as you do that, they stopped talking about them. They still have them, but then we all lose the ability to learn from them. I couldn't help but notice that the week that we're recording this, so there was an incident report put out by AWS for a Lambda service event in Northern Virginia.It happened back in June, we're recording this late in October. So, it took them a little bit of time to wind up getting it out the door, but it's very thorough, very interesting as far as what it talks about as far as their own approach to things. Because otherwise, I have to say, it is easy as a spectator slash frustrated customer to assume the absolute worst. Like, you're sitting around there and like, “Well, we have a 15-minute SLA on this, so I'm going to sit around for 12 minutes and finish my game of solitaire before I answer the phone.” No, it does not work that way. People are scrambling behind the scenes because as systems get more complicated, understanding the interdependencies of your own system becomes monstrous.I still remember some of the very early production engineering jobs that I had where—to what you said a few minutes ago—oh, yeah, we'll just open an incident for every alert that goes off. Then we dropped a [core switch 00:05:47] and Nagio sent something like 8000 messages inside of two minutes. And we would still, 15 years later, not be done working through that incident backlog had we done such a thing. All of this stuff gets way harder than you would expect as soon as your application or environment becomes somewhat complicated. And that happens before you realize it.Robert: Yeah, much faster. I think that, in my experience, there's a moment that happens for companies where maybe it's the number of customers you have, number of servers you're running in production, that you have this, like, “Oh, we're running a big workload right now in a very complex system that impacts people's lives, frankly.” And the moment that companies realize that is when you start to see, like, oh, process change, you build it, you own it, now we have an SRE team. Like, there's this catalyst that happens in all of these companies that triggers this. And it's—I don't know, from my perspective, it's coming at a faster rate than people probably realize.Corey: From my perspective, I have to ask you this question, and my apologies in advance if it's one of those irreverent ones, but do you consider yourself to be an observability company?Robert: Oh, great question. No. No, actually. We think that we are the baton handoff between an observability tool and our platform. So, for example, we think that that's a good way to kind of, you know, as they say, monitor the system, give reports on that system, and we are the tool that based on that monitor may be going off, you need to do something about it.So, for example, I think of it as like a smoke detector in some cases. Like, in our world, like that's—the smoke detector is the thing that's kind of watching the system and if something's wrong, it's going to tell you. But at that point, it doesn't really do anything that's going to help you in the next phase, which is managing the incident, calling 911, driving to the scene of the fire, whatever analogies you want to use. But I think the value-add for the observability tools and what they're delivering for businesses is different than ours, but we touch each other, like, very much so.Corey: Managing an incident when something happens and diagnosing what is the actual root cause of it, so to speak—quote-unquote, “Root cause.” I know people have very strong opinions on—Robert: Yeah, say the word [laugh].Corey: —that phrase—exactly—it just doesn't sound that hard. It is not that complicated. It's, more or less, a bunch of engineers who don't know what they're actually doing, and why are they running around chasing this stuff down is often the philosophy of a lot of folks who have never been in the trenches dealing with these incidents themselves. I know this because before I was exposed to scale, that's what I thought and then, oh, this is way harder than you would believe. Now, for better or worse, an awful lot of your customers and the executives at those customers did, for some strange reason, not come up through production engineering as the thing that they've done. They are executives, so it feels like it would be a challenging conversation to have with them, but one thing that you've got in your back pocket, which I always love talking to folks about, is before this, you were an engineer and then you became a CEO of a reasonably-sized company. That is a very difficult transition. Tell me about it.Robert: Yeah. Yeah, so a little of that background. I mean, I started writing code—I've been writing code for two-thirds of my life. So, I'm 32 now; I'm relatively young. And my first job out of high school—skipping college entirely—was writing code. I was 18, I was working in a web dev shop, I was making good enough money and I said, you know what? I don't want to go to college. That sounds—I'm making money. Why would I go to college?And I think it was a good decision because I got to be able—I was right kind of in the centerpiece of when a lot of really cool software things were happening. Like, DevOps was becoming a really cool term and we were seeing the cloud kind of emerge at this time and become much more popular. And it was a good opportunity to see all this confluence of technology and people and processes emerge into what is, kind of like, the base plate for a lot of how we build software today, starting in 2008 and 2009. And because I was an on-call engineer during a lot of that, and building the systems as well, that I was on call for, it meant that I had a front-row seat to being an engineer that was building things that was then breaking, and then literally merging on GitHub and then five minutes later [laugh], seeing my phone light up with an alert from our alerting tool. Like, I got to feel the entire process.And I think that that was nice because eventually one day, I snapped. And it was after a major incident, I snapped and I said, “There's no tool that helps me during this incident. There's no tool that kind of helps me run a process for me.” Because the only thing I care about in the middle of the night is going back to bed. I don't have any other priority [laugh] at 2 a.m.So, I wanted to solve the problem of getting to the fire faster and extinguishing it by automating as much as I possibly could. The process that was given to me in an outdated Confluence page or Google Doc, whatever it was, I wanted to automate that part so I could do the thing that I was good at as an engineer: put out the fire, take some notes, and then go back to bed, and then do a retrospective sometime next day or in that week. And it was a good way to kind of feel the problem, try to build a solution for it, tweak a little bit, and then it kind of became a company. I joke and I say on accident, actually.Corey: I'll never forget one of the first big, hairy incidents that I had to deal with in 2009, where my coworker had just finished migrating the production environment over to LDAP on a Thursday afternoon and then stepped out for a three-day weekend, and half an hour later, everything started exploding because LDAP will do that. And I only had the vaguest idea of how LDAP worked at all. This was a year into my first Linux admin job; I'd been a Unix admin before that. And I suddenly have the literal CEO of the company breathing down my neck behind me trying to figure out what's going on and I have no freaking idea of myself. And it was… feels like there's got to be a better way to handle these things.We got through. We wound up getting it back online, no one lost their job over it, but it was definitely a touch-and-go series of hours there. And that was a painful thing. And you and I went in very different directions based upon experiences like that. I took a few more jobs where I had even worse on-call schedules than I would have believed possible until I started this place, which very intentionally is centered around a business problem that only exists during business hours. There is no 2 a.m. AWS billing emergency.There might be a security issue masquerading as one of those, but you don't need to reach me out of business hours because anything that is a billing problem will be solved in Seattle's timeline over a period of weeks. You leaned into it and decided, oh, I'm going to start a company to fix all of this. And okay, on some level, some wit that used to work here, wound up once remarking that when an SRE doesn't have a better idea, they start a monitoring company.Robert: [laugh].Corey: And, on some level, there's some validity to it because this is the problem that I know, and I want to fix it. But you've differentiated yourself in a few key ways. As you said earlier, you're not an observability company. Good for you.Robert: Yeah. That's a funny quote.Corey: Pete Cheslock. He has a certain way with words.Robert: Yeah [laugh]. I think that when we started the company, it was—we kind of accidentally secured funding five years ago. And it was because this genuinely was something I just, I bought a laptop for because I wanted to own the IP. I always made sure I was on a different network, if I was going to work on the company and the tool. And I was just writing code because I just wanted to solve the problem.And then some crazy situation happened where, like, an investor somehow found FireHydrant because they were like, “Oh, this SRE thing is a big space and incidents is a big part of it.” And we got to talking and they were like, “Hey, we think what you're building is valuable and we think you should build a company here.” And I was—like, you know, the Jim Carrey movie, Yes Man? Like, that was kind of me in that moment. I was like, “Sure.” And here we are five years later. But I think the way that we approached the problem was let's just solve our own problem and let's just build a company that we want to work at.And you know, I had two co-founders join me in late 2018 and that's what we told ourselves. We said, like, “Let's build a company that we want to work for, that solves problems that we have had, that we care about solving.” And I think it's worked out, you know? We work with amazing companies that use our tool—much to their chagrin [laugh]—multiple times a day. It's kind of a problem when you build an incident response tool is that it's a good thing when people are using it, but a bad thing for them.Corey: I have to ask of all of the different angles to approach this from, you went with incident management as opposed to focusing on something that is more purely technical. And I don't say that in any way that is intended to be sounding insulting, but it's easier from an engineering mind to—having been one myself—to come up with, “Here's how I make one computer talk to his other computer when the following event happens.” That's a much easier problem by orders of magnitude than here's how I corral the humans interacting with that computer's failure to talk to another computer in just the right way. How did you get onto this path?Robert: Yeah. The problem that we were trying to solve for it was the getting the right people in the room problem. We think that building services that people own is the right way to build applications that are reliable and stable and easier to iterate on. Put the right people that build that software, give them, like, the skin in the game of also being on call. And what that meant for us is that we could build a tool that allowed people to do that a lot easier where allowing people to corral the right people by saying, “This service is broken, which powers this functionality, which means that these are the people that should get involved in this incident as fast as possible.”And the way we approached that is we just built up part of our functionality called Runbooks, where you can say, “When this happens, do this.” And it's catered for incidents. So, there's other tools out there, you can kind of think of as, like, we're a workflow tool, like Zapier, or just things that, like, fire webhooks at services you build and that ends up being your incident process. But for us, we wanted to make it, like, a really easy way that a project manager could help define the process in our tool. And when you click the button and say, “Declare Incident: LDAP is Broken,” and I have a CEO standing behind me, our tool just would corral the people for you.It was kind of like a bat signal in the air, where it was like, “Hey, there's this issue. I've run all the other process. I just need you to arrive at and help solve this problem.” And we think of it as, like, how can FireHydrant be a mech suit for the team that owns incidents and is responsible for resolving them?Corey: There are a few easier ways to make a product sound absolutely ridiculous than to try and pitch it to a problem that it is not designed to scale to. What is the ‘you must be at least this tall to ride' envisioning for FireHydrant? How large slash complex of an organization do you need to be before this starts to make sense? Because I promise, as one person with a single website that gets no hits, that is probably not the best place for—Robert: Probably not.Corey: To imagine your ideal user persona.Robert: Well, I'm sure you get way more hits than that. Come on [laugh].Corey: It depends on how controversial I'm being in a given week.Robert: Yeah [laugh].Corey: Also, I have several ridiculous, nonsense apps out there, but honestly, those are for fun. I don't charge people for them, so they can deal with my downtime till I get around to it. That's the way it works.Robert: Or, like, spite-visiting your website. No it's—for us, we think that the ‘must be this tall' is when do you have, like, sufficiently complicated incidents? We tell folks, like, if you're a ten-person shop and you have incidents, you know, just use our free tier. Like, you need something that opens a Slack channel? Fine. Use our free tier or build something that hits the Slack API [unintelligible 00:18:18] channel. That's fine.But when you start to have a lot of people in the room and multiple pieces of functionality that can break and multiple people on call, that's when you probably need to start to invest in incident management. Because it is a return on investment, but there is, like, a minimum amount of incidents and process challenges that you need to have before that return on investment actually, I would say, comes to fruition. Because if you do think of, like, an incident that takes downtime, or you know, you're a retail company and you go down for, let's say, ten minutes, and your number of sales per hour is X, it's actually relatively simple for that type of company to understand, okay, this is how much impact we would need to have from an incident management tool for it to be valuable. And that waterline is actually way—it's way lower than I think a lot of people realize, but like you said, you know, if you have a few 100 visitors a day, it's probably not worth it. And I'll be honest there, you can use our free tier. That's fine.Corey: Which makes sense. It's challenging to wind up-sizing things appropriately. Whenever I look at a pricing page, there are two things that I look for. And incidentally, when I pull up someone's website, I first make a beeline for pricing because that is the best way I found for a lot of the marketing nonsense words to drop away and it get down to brass tacks. And the two things I want are free tier or zero-dollar trial that I can get started with right now because often it's two in the morning and I'm trying to see if this might solve a problem that I'm having.And I also look for the enterprise tier ‘contact us' because there are big companies that do not do anything that is not custom nor do they know how to sign a check that doesn't have two commas in it. And whatever is between those two, okay, that's good to look at to figure out what dimensions I'm expected to grow on and how to think about it, but those are the two tent poles. And you've got that, but pricing is always going to be a dark art. What I've been seeing across the industry. And if we put it under the broad realm of things that watch your site and alert you and help manage those things, there are an increasing number of, I guess what I want to call component vendors, where you'll wind up bolting together a couple dozen of these things together into an observability pipeline-style thing, and each component seems to be getting extortionately expensive.Most of the wake-up-in-the-middle-of-the-night services that will page you—and there are a number of them out there—at a spot check of these, they all cost more per month per user than Slack, the thing that most of us to end up living within. This stuff gets fiendishly expensive, fiendishly quickly, and at some point, you're looking at this going, “The outage is cheaper than avoiding the outage through all of these things. What are we doing here?” What's going on in the industry, other than ‘money printing machine stopped going brrr' in quite the same way?Robert: Yeah, I think that for alerting specifically, this is a big part of, like, the journey that we wanted to have in FireHydrant was like, we also want to help folks with the alerting piece. So, I'll focus on that, which is, I think that the industry around notifying people for incidents—texts, call, push notifications, emails, there's a bunch of different ways to do it—I think where it gets really crazy expensive as in this per-seat model that most of them seem to have landed on. And we're per-seat for, like, the core platform of FireHydrant—so you know, before people spite-visit FireHydrant, look at our pricing pitch—but we're per-seat there because the value there is, like, we're the full platform for the service catalog retrospectives, Runbooks, like, there's a whole other component of FireHydrant—status pages—but when it comes to alerting, like, in my opinion, that should be active user for a few reasons. I think that if you're going to have people responding to incidents and the value from us is making sure they get to that incident very quickly because we wake them up in the middle of the night, we text them, we call them we make their Hue lights turn red, whatever it is, then that's, like, the value that we're delivering at that moment in time, so that's how we should probably invoice you.And I think that what's happened is that the pricing for these companies, they haven't innovated on the product in a way that allows them to package that any differently. So, what's happened, I think, is that the packaging of these products has been almost restrictive in the way that they could change their pricing models because there's nothing much more to package on. It's like, cool there's an alerting aspect to this, but that's what people want to buy those tools for. They want to buy the tool so it wakes them up. But that tool is getting more expensive.There was even a price increase announced today for a big one [laugh] that I've been publicly critical of. That is crazy expensive for a tool that texts you and call you. And what peo—what's going on now are people are looking, they're looking at the pricing sheet for Twilio and going, “What the heck is going on?” Like, I—to send a text on Twilio in the United States is fractions of a penny and here we are paying $40 a user for that person to receive six texts that month because of a webhook that hit an HCP server and, like, it's supposed to call that person? That's kind of a crazy model if you think about it. Like, engineers are kind of going, “Wait a minute. What's up here?” Like, and when engineers start thinking, “I could build this on a weekend,” like, something's wrong, like, with that model. And I think that people are starting to think that way.Corey: Well engineers, to be fair, will think that about an awful lot of stuff.Robert: Anything. Yeah, they [laugh]—Corey: I've heard it said about Dropbox, Facebook, the internet—Robert: Oh, Dropbox is such a good one.Corey: BGP. Yeah okay, great. Let me know how that works out for you.Robert: What was that Dropbox comment on Hacker News years ago? Like, “Just set up NFS and host it that way and it's easy.” Right?Corey: Or rsync. Yeah—Robert: Yeah, it was rsync.Corey: What are you going to make with that? Like, who's going to buy that? Like, basically everyone for at least a time.Robert: And whether or not the engineers are right, I think is a different point.Corey: It's the condescension dismissal of everything that isn't writing the code that really galls, on some level.Robert: But I think when engineers are thinking about, like, “I could build this on a weekend,” like, that's a moment that you have an opportunity to provide the value in an innovative, maybe consolidated way. We want to be a tool that's your incident management ring to retro, right? You get paged in the middle of the night, we're going to wake you up, and when you open up your laptop, groggy-eyed, and like, you're about to start fighting this fire, FireHydrant's already done a lot of work. That's what we think is, like, the right model do this. And candidly, I have no idea why the other alerting tools in this space haven't done this. I've said that and people tend to nod in agreement and say like, “Yeah, it's been—it's kind of crazy how they haven't approached this problem yet.” And… I don't know, I want to solve that problem for folks.Corey: So, one thing that I have to ask, you've been teasing on the internet for a little bit now is something called Signals where you are expanding your product into the component that wakes people up in the middle of the night, which in isolation, fine, great, awesome. But there was a company whose sole stated purpose was to wake people up in the middle of the night, and then once they started doing some business things such as, oh I don't know, going public, they needed to expand beyond that to do a whole bunch of other things. But as a customer, no, no, no, you are the thing that wakes me up in the middle of the night. I don't want you to sprawl and grow into everything else because if you're going to have to pick a vendor that claims to do everything, well, I'll just stay with AWS because they already do that and it's one less throat to choke. What is that pressure that is driving companies that are spectacular at the one thing to expand into things that frankly, they don't have the chops to pull off? And why is this not you doing the same thing?Robert: Oh, man. The end of that question is such a good one and I like that. I'm not an economist. I'm not—like, that's… I don't know if I have a great comment on, like, why are people expanding into things that they don't know how to do. It seems to be, like, a common thing across the industry at a certain point—Corey: Especially particularly generative AI. “Oh, we've been experts in this for a long time.” “Yeah, I'm not that great at dodgeball, but you also don't see me mouthing off about how I've been great at it and doing it for 30 years, either.”Robert: Yeah. I mean, there was a couple ads during football games I watched. I'm like, “What is this AI thing that you just, like, tacked on the letter X to the end of your product line and now all of a sudden, it's AI?” I have plenty of rants that are good for a cocktail at some point, but as for us, I mean, we knew that we wanted to do alerting a long time ago, but it does have complications. Like, the problem with alerting is that it does have to be able to take a brutal punch to the face the moment that AWS us-east-2 goes down.Because at that moment in time, a lot of webhooks are coming your way to wake somebody up, right, for thousands of different companies. So, you do have to be able to take a very, very sufficient amount of volume instantaneously. So, that was one thing that kind of stopped us. In 2019 even, we wrote a product document about building an alerting tool and we kind of paused. And then we got really deep into incident management, and the thing that makes us feel very qualified now is that people are actually already integrating their alerting tools into FireHydrant today. This is a very common thing.In fact, most people are paying for a FireHydrant and an alerting tool. So, you can imagine that gets a little expensive when you have both. So, we said, well, let's help folks consolidate, let's help folks have a modern version of alerting, and let's build on top of something we've been doing very well already, which is incident management. And we ended up calling it Signals because we think that we should be able to receive a lot of signals in, do something correct with them, and then put a signal out and then transfer you into incident management. And yeah, we're are excited for it actually. It's been really cool to see it come together.Corey: There's something to be said for keeping it in a certain area of expertise. And people find it very strange when they reach out to my business partner and me asking, okay, so are you going to expand into Google Cloud or Azure or—increasingly, lately—Datadog—which has become a Fortune 500 board-level expense concern, which is kind of wild to me, but here we are—and asking if we're going to focus on that, and our answer is no because it's very… well, not very, but it is relatively easy to be the subject matter expert in a very specific, expensive, painful problem, but as soon as you start expanding that your messaging loses focus and it doesn't take long—since we do you view this as an inherent architectural problem—where we're saying, “We're the best cloud engineers and cloud architects in the world,” and then we're competing against basically everyone out there. And it costs more money a year for Accenture or Deloitte's marketing budget than we'll ever earn as a company in our entire lifetime, just because we are not externally boosted, we're not putting hundreds of people into the field. It's a lifestyle business that solves an expensive, painful problem for our customers. And that focus lends clarity. I don't like the current market pressure toward expansion and consolidation at the cost of everything, including it seems, customer trust.Robert: Yeah. That's a good point. I mean, I agree. I mean, when you see a company—and it's almost getting hard to think about what a company does based on their name as well. Like, names don't even mean anything for companies anymore. Like Datadog has expanded into a whole lot of things beyond data and if you think about some of the alerting tools out there that have names of, like, old devices that used to attach to our hips, that's just a different company name than what represents what they do.And I think for us, like, incidents, that's what we care about. That's what I know. I know how to help people manage incidents. I built software that broke—sometimes I was an arsonist—sometimes I was a firefighter, it really depends, but that's the thing that we're going to be good at and we're just going to keep building in that sphere.Corey: I think that there's a tipping point that starts to become pretty clear when companies focus away from innovating and growing and serving customers into revenue protection mode. And I think this is a cyclical force that is very hard to resist. But I can tell even having conversations like this with folks, when the way that a company goes about setting up one of these conversations with me, you came by yourself, not with a squadron of PR people, not with a whole giant list of talking points you wanted to go to, just, “Let's talk about this stuff. I'm interested in it.”As a company grows, that becomes more and more uncommon. Often, I'll see it at companies a third the size of yours, just because there's so much fear around everything we say must be spoken in such a way that it could never be taken in a negative way against us. That's not the failure mode. The failure mode is that no one listens to you or cares what you have to say. At some point, yeah, I get the shift, but damned if it doesn't always feel like it's depressing.Robert: Yeah. This is such great questions because I think that the way I think about it is, I care about the problem and if we solve the problem and we solve it well and people agree with us on our solution being a good way to solve that problem, then the revenue, like, happens because of that. I've gotten asked from, like, from VCs and customers, like, “What's your end goal with FireHydrant as the CEO of the company?” And what they're really asking is, like, “Do you want to IPO or be acquired?” That's always a question every single time.And my answer is, maybe, I don't know, philosophical, but it's, I think if we solve the problem, like, one of those will happen, but that's not the end goal. Because if I aim at that, we're going to come up short. It's like how they tell you to throw a ball, right? Like they don't say, aim at the glove. They say, like, aim behind the person.And that's what we want to do. We just want to aim at solving a problem and then the revenue will come. You have to be smart about it, right? It's not a field of dreams, like, if you build it, like, revenue arrives, but—so you do have to be conscious of the business and the operations and the model that you work within, but it should all be in service of building something that's valuable.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where should they go to find you, other than, you know, to their most recent incident page?Robert: [laugh]. No, thanks for having me. So, to learn more about me, I mean, you can find me on Twitter on—or X. What do we call it now?Corey: I call it Twitter because I don't believe in deadnaming except when it's companies.Robert: Yeah [laugh]. twitter.com/bobbytables if you want to find me there. If you want to learn more about FireHydrant and what we're doing to help folks with incidents and incident response and all the fun things in there, it's firehydrant.com or firehydrant.io, but we'll redirect you to dot com.Corey: And we will, of course, put a link to all of that in the [show notes 00:33:10]. Thank you so much for taking the time to speak with me. It's deeply appreciated.Robert: Thank you for having me.Corey: Robert Ross, CEO and co-founder of FireHydrant. This featured guest episode has been brought to us by our friends at FireHydrant, and I'm Corey Quinn. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that will never see the light of day because that crappy platform you're using is having an incident that they absolutely do not know how to manage effectively.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Incident management is the process of managing and resolving unexpected disruptions or issues in software systems, especially those that are customer-facing or critical to business operations. Implementing a robust incident management system is often a key challenge in technical environments. Rootly is a platform to handle incident management directly from Slack, and is used by The post Cross-functional Incident Management with Ashley Sawatsky and Niall Murphy appeared first on Software Engineering Daily.

For Topic Tuesday, the guys dive deeper into subscriptions for options. Will we all end up paying for features we don't use, but are already embedded in the vehicle? The debate is for William R. in FL, who wants to get out of lame CUVs and into something fun. Social media questions ask if PHEV's have a future once EV infrastructure improves, how will future vehicle development cycles be affected, and what's the most ridiculous thing someone's said about a car? Seasons 1-11 are available on Amazon Prime and Vimeo worldwide. Please rate and review us on iTunes, and the TV show on IMDB and Amazon. Write to us with your Car Debates, Car Conclusions, and Topic Tuesdays at everydaydrivertv@gmail.com or everydaydriver.com. Share the podcast with your car enthusiast friends!