Velocity's Edge Podcast

When leadership is struggling with organizational dysfunction that stems from resource constraints, they tend to see teams in conflict: product versus engineering, sales versus operations, etc. They might assume the solution involves coaching, restructuring reporting lines, adjusting compensation models, or hiring more diplomacy-minded managers. But as EPSD’s Nicko Goncharoff and Nick Selby have learned through years of organizational interventions, the biggest threat to mid-stage technology companies isn’t functional disagreement. It’s the personal resentment that calcifies when strategic pivots in the business force zero-sum resource allocation.The difference between companies that navigate growth challenges successfully and those that fracture into warring factions isn’t primarily about having better processes or more mature leadership. It’s about recognizing when strategic disagreements have crossed into interpersonal territory—and having the courage to address the human conflict directly rather than pretending it’s purely about roadmap priorities or budget distribution. Because when resources become scarce, it’s political skill, not engineering merit, that determines how they are allocated.“The people who are the best at what they do are not necessarily the same people who are good at politicking to get the resources that they need,” Nick says. This creates resentment and discord between leaders, and while their teams might not know the details, they’re keenly aware of the power dynamics. They take sides. Pretty soon, you have factions and internecine warfare.Factionalism doesn’t announce itself through org chart battles. It emerges quietly, through maneuvering, betrayal, pocket vetoes, and uncommitted commitments; it is cemented by managers who say “yes” in meetings then don’t follow through. By the time leaders recognize the pattern, teams have stopped collaborating entirely—and the interpersonal damage compounds the business consequences.In the season one finale of the Velocity’s Edge podcast, Nick and Nicko explore how mid-life technology companies can slide into factionalism and, more important, how to pull them back from the brink. They tackle essential questions: How do you distinguish between healthy functional tension and destructive personal conflict? What are the ground rules that enable successful mediation when key leaders have stopped working together? How do you translate personal grievances into organizational imperatives that both parties can commit to solving?The conversation reveals a fundamental truth: the companies that survive growth challenges aren’t those with conflict-free cultures. They’re the ones willing to confront interpersonal breakdowns directly, establish clear rules and objective metrics for collaboration, and recognize that the most passionate disagreements often signal the deepest commitment to the mission.Nick Selby is the founder and Managing Partner of EPSD, with a career spanning cybersecurity, law enforcement, and technology leadership. He has held key executive roles at tech companies, and created the information security practice at 451 Research (now S&P Global Intelligence). He served as Director of Cyber Intelligence and Investigations at the NYPD, and as both a paid and reserve Texas police detective specializing in investigations of child sexual abuse material and online investigations. He serves on the board of directors of the National Child Protection Task Force, and the advisory board of Sightline Security.As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

Many organizations hire CISOs expecting them to be security experts who can implement controls and prevent breaches. But as Dr. Pablo Breuer learned through 22 years in Navy cyber operations and leadership roles spanning NSA red teams to Fortune 50 financial firms, the fundamental challenge isn't technical — it's that most companies don't understand what they actually need from a CISO in the first place."The difference between a manager and a leader is, a manager comes in every day, and they look at the to-do list," Pablo explains. "The leader is able to look out a little bit further, and really anticipate what the challenges are going to be, and communicate those not as technical challenges, but as business challenges."The most effective CISOs don't function as organizational brakes — they operate as racing brakes, enabling companies to go as fast as safely possible. But this requires more than security expertise. It demands translating engineering requirements into business language, converting CEO vision into actionable technical architecture, and understanding that the first letter in CISO is "C" — meaning chief executive, with all the strategic leadership responsibilities that entails.In this episode of Velocity's Edge, Pablo and host Nicko Goncharoff explore what separates security management from security leadership. They tackle essential questions: How do you build a security-minded organizational culture when the solutions are fundamentally cultural, not technical? What questions should CEOs ask when hiring their first CISO? Why do the best CISOs spend their first 90 days listening rather than implementing changes? How do you maintain political capital and avoid the common pitfalls that lead to rapid CISO turnover?The conversation reveals why successful security programs aren't built by the most technically sophisticated leaders — they're built by those who understand that their primary client is the business itself, and their job is enabling growth while reducing risk.Dr. Pablo Breuer is an expert in cybersecurity and information warfare, with leadership experience spanning the military, government, and private sector. He has held top roles at U.S. Special Operations Command (he served as the United States’ first Chief Information Security Officer for coalition forces in Afghanistan), the National Security Agency, and at U.S. Cyber Command. He co-founded the Cognitive Security Collaborative and co-authored the DISARM framework, used internationally to combat disinformation. Pablo is also a sought-after speaker and educator in cybersecurity strategy.As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

When Peat Bakke sits down for breakfast with engineering leaders, the conversation inevitably turns to the same frustrating pattern: talented people leave, and with them goes critical context about why systems work the way they do. Not just the technical details—those live in the code—but the reasoning behind architectural choices, the problems those choices solved, and crucially, the alternatives that were deliberately rejected.This isn't a staffing problem masquerading as a documentation problem. It's an organizational memory problem that compounds as companies grow. As Peat explains from 25 years of helping organizations through transitions and hypergrowth, "What you didn't decide to do—that's the organizational lore that gets lost when people move around."The solution isn't just writing more things down. Decision records only create value when they're accessible, digestible, and tied directly to the tools teams use every day. The most effective organizations treat decision context as infrastructure, not paperwork. They understand that the goal isn't comprehensive documentation—it's ensuring that when someone inevitably gets "called in when a company is going through hypergrowth" or when they need to "reduce expenditures in painful ways," the reasoning behind past choices is available to inform new ones.In this episode of Velocity's Edge, Peat and host Nick Selby explore how to build decision records that actually help teams move faster rather than creating bureaucratic overhead. They tackle essential questions: How do you determine when a decision is significant enough to document? What's the "after-the-fact test" that reveals whether your documentation is genuinely useful? How can AI help make years of accumulated decision records searchable and actionable without introducing hallucinations into critical business decisions?The conversation reveals a fundamental truth: the companies that scale successfully aren't those that document everything—they're the ones that capture decision context so future teams can make informed choices about what to change and what to preserve.Peat Bakke is a seasoned engineering leader with over 25 years of experience helping companies navigate significant transitions including reorganizations, mergers and acquisitions, hypergrowth, and cloud migrations. He has held senior engineering roles at eBay, Kickstarter, and Peek, where he led a team of 70 engineers through a Series C funding round. Peat is the founder of Refactor Management, specializing in helping engineering leaders build high-performance teams through systems thinking and psychological safety.As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

Most engineering leaders think institutional knowledge loss is an inevitable cost of growth. They see departing employees take critical context with them—why certain processes exist, what problems they solve, how trade-offs were evaluated—and assume the solution involves better handoff documentation or knowledge transfer sessions. But as Thomas Dullien and Chris Swan learned through building and scaling organizations, the biggest risk isn't losing people; it's losing the reasoning behind the decisions those people made.The difference between organizations that scale smoothly and those that constantly rehash the same choices isn't primarily about retaining talent longer. It's about capturing decision context before it walks out the door. When teams inherit processes or systems without understanding their origins, they either follow them blindly like cargo cults or abandon them entirely—often recreating the same expensive mistakes that led to those processes in the first place."At the moment you find yourself repeating something for the second or third time, it's time to put it in writing," Thomas explains. Decision records aren't just about documentation; they're about preserving the why behind important choices and recognizing a fundamental truth: institutional memory is strategic infrastructure, not administrative overhead.In this episode of Velocity's Edge, Thomas, Chris, and host Nick Selby explore why decision records have become essential for scaling teams. They tackle essential questions: How do you quantify the ROI of maintaining decision records when your time is already stretched thin? Why might documenting decisions actually accelerate execution rather than create bureaucratic drag? How do decision records help both technical architecture and business operations?The conversation reveals why the most resilient organizations aren't necessarily those with the lowest turnover—they're the ones that understand how to capture decision context so future teams can make informed choices about what to change and what to preserve.Thomas Dullien, known as Halvar Flake, is a security and efficiency expert with deep expertise in reverse engineering, vulnerability research, and cloud economics. He founded a malware analysis company acquired by Google, where he later contributed to research on Rowhammer. He also co-founded a firm focused on system-wide performance profiling, later acquired by Elastic. His work explores the intersection of computing efficiency, economics, and sustainability.Chris Swan is a technology leader specializing in cloud, security, and software architecture. He is an Engineer at Atsign, working on privacy-focused solutions that put users in control of their data. Previously, he held CTO and R&D leadership roles at DXC Technology, UBS, and Credit Suisse. Chris is also a Google Developer Expert in Dart and co-hosts the Tech Debt Burndown Podcast.As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

Most engineering leaders think velocity problems are technology problems. They see slow deployments and assume the solution involves better CI/CD pipelines, more developers, or migrating to microservices. But as Sarah Wells discovered during her transformation of the Financial Times, the biggest constraints aren't in your codebase—they're in your org chart.The FT's journey from 12 releases per year to over 20,000 wasn't primarily a technical achievement. It was an organizational one. Their Saturday deployments weren't happening because of architectural limitations; they were happening because of change advisory boards, separate QA teams, and decision-making processes that treated every release like a potential catastrophe."If you don't get those things right, you can't move fast," Wells explains. The shift to microservices enabled zero-downtime deployments, but the real breakthrough came from dismantling gatekeepers, empowering cross-functional teams, and recognizing a fundamental truth: velocity is a cultural and business issue, not a technical one.In this episode of Velocity's Edge, Sarah and host Nicko Goncharoff explore why successful digital transformation requires organizational change alongside technical evolution. They tackle essential questions: How do you assess whether a company can make the cultural shifts required for velocity? What communication channels and forums do engineering teams actually need? How do you measure progress on transformation that goes beyond technology?The conversation reveals why the fastest-moving organizations aren't necessarily those with the best technology stack—they're the ones that understand how to eliminate decision-making dependencies and build cultures that allow teams to move with autonomy.Sarah Wells is a recognized leader in software engineering, with a focus on microservices, DevOps, and engineering enablement. A frequent speaker and the author of Enabling Microservices Success, Sarah brings extensive industry knowledge and hands-on experience in building high-performing engineering teams. As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

When everything's on fire, most organizations make a critical mistake: they treat the crisis as the exception rather than the expectation. They burn out their teams in marathon response sessions, fail to automate routine failures, and never learn from the incidents that keep repeating. The companies that survive and thrive are those that understand a fundamental truth: if your business is growing, crises aren't anomalies—they're predictable outcomes of scale.Crisis engineering isn't about heroics. It's about recognizing when manual intervention becomes unsustainable and building systems that handle failure as a normal operating condition. As Carla Geisser puts it: "The incidents that actually matter to how people interact with technology are not security incidents…They are: they can't log into their bank account, they can't buy their Taylor Swift tickets, they can't get on an airplane." The question isn't whether you'll have incidents, but whether you're consuming your entire organization's capacity fighting fires that should be routine.In this episode of Velocity's Edge, Carla, Chris Swan, and Nick Selby explore the discipline of crisis engineering. Their conversation tackles essential questions: When does manual intervention become a resource problem that demands automation? How do you get out of incident mode as quickly as possible without leaving critical work undone? Why do organizations need to treat predictable events—Black Friday, tax day, major product launches—as declared disasters in advance? Most importantly, how do you build organizational memory and muscle for handling crises without burning out your teams?Carla, an EPSD advisor and partner at Layer Aleph, pioneered Google's SRE principles, led the effort to rescue Healthcare.gov during its 2014 crisis, and guided Fastly's recovery from their global outage. Chris, an EPSD advisor and Engineer at Atsign, brings CTO experience from UBS and Credit Suisse. Nick, EPSD's founder and Managing Partner, has led crisis response across law enforcement and technology, from the NYPD to fintech and insurance companies.As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

Most organizations think of security communications as crisis management: what to say when something goes wrong. But waiting until an incident occurs to build relationships, establish trust, and create communication channels severely limits your response options. Security communications isn't episodic. It's strategic. Every interaction with security researchers, every statement about your security posture, every decision about transparency, builds or erodes the credibility you'll need when it really counts. The companies that emerge stronger from incidents are those that have been building trust and influence long before anything goes wrong.In this episode of Velocity's Edge, Melanie Ensign explains why proactive security communications is a business imperative. She and host Nicko Goncharoff explore critical questions: How do you build the relationships and political capital you'll need during an incident? Why do security teams need influence beyond their reporting lines? How can incidents actually become opportunities to demonstrate credibility?The challenge isn't just external communications. It's internal too. Security teams must develop the skills to negotiate and lead across departments, understanding what matters to their colleagues and how security objectives align with broader business goals. As Melanie puts it: "In order to call a friend, you have to have a friend."Melanie Ensign is an EPSD advisor and founder of EPSD partner Discernible, a security and privacy communications firm. She has led security communications for Facebook, Uber, and AT&T, and ran DEF CON's press operations for a decade. She knows how to communicate when the world is watching, helping teams build credibility and influence with business leaders through her expertise in high-risk incident communication.As in all our episodes, we speak in plain, executive-summary business terms, framing complex business and technology strategic challenges in context, using language that makes them more accessible and actionable.

If you're leading a profitable, cash-flow-positive business, you've probably watched technical debt pile up—those accumulated consequences of choosing quick fixes over well-designed, long-term solutions. Maybe your teams built features fast to hit the market, taking shortcuts along the way.Some executives think tech debt is like healthy corporate debt with low interest. It's not. It's more like credit card debt that compounds aggressively. That's why tech debt isn't just an "IT issue," it's a business strategy problem. And unless you know what to look for, how it manifests can be pretty mysterious.In this episode of Velocity's Edge, Huw Rogers frames the strategic challenges that lead to unhealthy levels of tech debt. He and host Nicko Goncharoff dig into key questions: Why does tech debt cause system fragility, and information security issues? Why does it delay product releases?Addressing or even identifying these issues isn't straightforward. Tech debt is a necessary byproduct of innovation, but it leaves a chain of consequences. You really have to dig deep to find the root problems.There are different flavors too. Conscious tech debt happens when teams deliberately build something they know they'll need to rebuild later, taking documented shortcuts with explicitly accepted risks.Unconcious tech debt can be inadvertent—the byproduct of unrealistic deadlines that force engineers to make their own choices. This gets particularly messy when multiple teams work in parallel on inconsistent components. Sometimes it's just ad-hoc decisions where someone faces two paths forward without fully appreciating the risks and rewards of each.Huw Rogers has spent two decades driving technology transformation in fintech, specializing in electronic markets technology, FX, equities, derivatives, and crypto. He has successfully led teams and projects across multiple regions, delivering scalable solutions that create tangible business impact.

In the debut of Velocity's Edge podcast, host Nicko Goncharoff speaks with Engineering Effectiveness Lead Consultant Sarah Wells about the importance of strategy to engineering effectiveness. Sarah is a recognized leader in software engineering, with a focus on microservices, DevOps, and engineering enablement. She played a pivotal role at the Financial Times, where she helped scale deployments from 12 to 20,000 releases per year. A frequent speaker and the author of Enabling Microservices Success.Sarah has worked in a lot of places where it's been very hard to understand what the strategy is,  and posits that,  if you were to ask the average engineer in the average company, even in places where there is a technical strategy, you'd find that most employees don't know what it is. That's because companies - especially tech companies - often don't share their strategy  enough internally so that people know exactly what it is. If you want to have autonomous teams that are able to make their own decisions, you want that autonomy to be what people at Spotify call "aligned autonomy." So we are all at least going in the same direction. What you don't want is the case in which every team is autonomous but they're all pulling in completely different directions, so you're not moving with purpose in the direction that the company needs you to move. This 20-minute episode uses plain business English to describe the business impacts of technology implementation, and the technical impacts of business decisions that don't consider their effects on velocity.