Host’s opening address.

In this talk, Michael Lopp will tell you a story about stories. From almost 30 years of leadership, Lopp will not only tell you stories from Slack, Pinterest, Netscape, Borland, and that start-up you’ve never heard of, but also why the art of storytelling is integral to your leadership toolkit.

Key takeaways

• The reasons humans like to hear and read stories.
• Why stories work for leaders.
• The core parts of a good story.

Practical, repeatable inclusive-leadership patterns for global engineering teams—aligning assumptions on hierarchy, disagreement, and feedback using working agreements, inclusive meeting mechanics, decision recaps, and repair scripts to build trust and move faster.

Global teams don’t fail because people lack good intentions—they fail because they carry different assumptions about hierarchy, feedback, speed, and what “good work” looks like. Inclusive leadership across cultures is less about slogans and more about building shared operating agreements that make collaboration safe and predictable.

Drawing on my experience as the only African Joint Institute Student Ambassador in a UK–China AI institute partnership, and my leadership roles coordinating large technical cohorts in Nigerian higher education (including supervising/appraising 50+ technologists and leading a lab through external accreditation), I’ll share a practical toolkit for leading across cultural divides.

We’ll cover three common cross-cultural failure modes and how to fix them:

1. Silence vs disagreement — how to surface dissent without forcing confrontation.
2. Hierarchy vs challenge — how to invite “safe pushback” and avoid decision-by-deference.
3. Direct vs indirect feedback — how to give clarity without disrespect, and how to receive feedback without defensiveness.

You’ll learn lightweight mechanisms you can adopt immediately: a “Working Agreements” template, inclusive meeting patterns (pre-reads, async input, rotating airtime), a decision recap format, and scripts for repairing misunderstandings when identity and power dynamics are in play.

You’ll leave with repeatable patterns to help distributed teams move faster—with less friction, more trust, and more meaningful participation.

Key takeaways

• A Working Agreements template for cross-cultural teams (communication, decision-making, feedback norms)
• Inclusive meeting patterns that reduce time-zone and hierarchy bias
• Scripts for disagreement, feedback, and repair after a cultural misread
• A decision recap format that increases clarity and reduces “re-litigating” decisions
• Practical ways to turn representation into belonging (not just diversity metrics)

Mentoring isn’t coaching or teaching. Learn how to find mentors who genuinely invest in your growth, and how to mentor others by sharing real experience.

Last year, a recent graduate approached me at a tech conference. She was working at a convenience store kiosk, running their systems, handling post office services, and onboarding new staff. She wanted to break into tech but couldn’t get interviews. Within months of working together, she landed her first paid job in tech.

What made it work wasn’t magic. It was seeing transferable skills she’d dismissed as “just retail.” It was rewriting her CV to show what she actually did. It was being direct about which unpaid coding projects were worth her time and which were draining energy she needed elsewhere.

This is what mentoring actually is: sharing your lived experience to guide someone’s growth. It’s not coaching (asking questions), sponsoring (taking action on their behalf), or teaching (transferring knowledge). Early in my mentoring journey, I got this wrong. I kept asking coaching questions when someone needed practical examples from my experience. They disengaged. I learned that mentoring means being direct about what you’ve seen and done, not performing neutrality.

As an engineering manager leading a distributed team across three countries, I’ve relied heavily on my own mentors and connected team members with mentors outside our immediate group. I’ve seen what works from both sides.

This talk covers practical approaches to finding mentors beyond formal programs (peer mentors, next-level career mentors, reverse mentors) and how to build relationships that go beyond surface advice. You’ll learn how to mentor effectively: seeing potential others miss, sharing experience directly, and knowing when someone needs a mentor versus a coach. Through real stories from both sides, you’ll leave with concrete next steps.

Key takeaways

• Recognize the difference between mentoring, coaching, sponsoring, and teaching and know when each is needed
• Find mentors who genuinely invest in your growth, not ones checking boxes
• Mentor effectively by sharing lived experience directly, not hiding behind coaching questions

Sponsored by

Headlines claim AI is transforming software engineering overnight. Across more than 400 engineering organizations, we see patterns that challenge the hype and reveal what’s really working, and what isn’t, when AI enters the software development lifecycle.

In this talk, Justin Reock, Deputy CTO at DX, will share a data-driven “state of the union” on AI in engineering, grounded in both quantitative data from thousands of developers and on-the-ground observations.

You’ll learn:

• The current impact of AI, from benchmarks on the percentage of code authored, team PR throughput, and time savings
• Where AI adoption is creating real gains in throughput, and whether it introduces tradeoffs for quality and maintainability
• Insights and trends, including whether junior or senior developers are seeing bigger gains, the impact of structured rollouts, which tools are having the most impact, and the evolving definition of “developer”

The session will conclude with a practical framework for measuring AI’s impact, helping leaders cut through hype and understand the impact AI is having in their own organizations.

Key takeaways

Five key questions are used to highlight areas for you to focus your learning:

• Do we have the right team?
• Do we have the right technology?
• Do we have the right product vision?
• Do we have the right balance between innovation and liability?
• Do we have the right product <> market fit?

This talk is about the difference between being a manager, a manager of managers, and a manager of managers of managers.

Most management advice treats leadership as a linear ladder, but the reality is more like a series of “vibe shifts” that force you to reinvent yourself at every level. If you try to manage a Director the same way you managed a Junior Engineer, you’re going to fail—and probably burn out in the process.

In this talk, I’ll share what I’ve learned from the unique experience of moving up and down the management chain, from 1st-line lead to 3rd-line executive and back again. We’ll skip the theory and get into the messy reality of three distinct roles:

• Managing ICs: Learning to stop “doing” and start “enabling” without losing your technical edge.
• Managing Managers: How to coach for leadership instead of technical output, and how to tell if a team is healthy when you’re no longer in the day-to-day.
• Managing Organizations: Using organizational design and strategy as your primary tools when you can no longer rely on personal relationships alone.

Whether you’re eyeing your first lead role or you’re a seasoned Director, you’ll leave with a better understanding of how to adjust your “flight altitude” and avoid the trap of using yesterday’s skills to solve today’s problems.

Key takeaways

• Identify the “success traps” where habits from your previous level actually hinder your performance in a new role.
• Learn how to audit a team’s health through layers of abstraction without micromanaging your managers.
• Develop a framework for coaching leadership skills rather than just overseeing project delivery.
• Understand why moving “down” the ladder can be a strategic move to sharpen your perspective and long-term impact.

Many EMs and Directors struggle to understand how to drive their own career and personal growth, this session seeks to use the destination as a way to reverse engineer the path to personal growth.

Many EMs and Directors are type-cast into a single area of excellence, whether this is people management, technical operations, or some other thing. This can lead to an artificial ceiling on your own growth, you know how to do this one thing so well that you fall back on it too often, and you may find that roles that you aspire to evade your reach, that you’re overlooked in favour of others. In my experience this can be overcome by not asking what you need to learn, but instead asking what those who have those roles further in your career path are doing, and then to reverse engineer the path to that destination by looking at which skills gaps exist for you today.

I use a simple framework for this, a set of a few questions that will help show what other aspects of your current role you can start developing. To those managers I’ve mentored in the past, these questions have unlocked self-learning and drive, and helped accelerate their growth and steepen career trajectory, it’s all very accessible as a set of concepts, and applicable to any manager from those starting their people management career through to those at Director level, and I hope those above this level have already figured this out.

This talk is also applicable of Staff+ IC levels, as a lot of the basics are directly transferrable to IC leadership skills too.

Key takeaways

Five key questions are used to highlight areas for you to focus your learning:

• Do we have the right team?
• Do we have the right technology?
• Do we have the right product vision?
• Do we have the right balance between innovation and liability?
• Do we have the right product <> market fit?

The jump to Staff IC is a fundamental shift. It requires you to become both an exceptional problem-solver and an organisational direction-setter. Learn the framework to make this intellectual leap.

The transition to a Staff IC role is often vaguely defined, yet it requires a fundamental intellectual shift. You must progress from expertly solving assigned problems to rigorously defining and architecting the solution to the most critical systemic, high-leverage problems – thereby setting the technical strategy. This talk introduces a rigorous, actionable framework, derived from intensive research and deep-dive interviews with Staff+ leaders at Monzo, to codify the true intellectual shift required to reach senior IC positions.

The methodology is directly inspired by my own experience earning a PhD, where the necessary approach, drive, and passion for defining the *unsolved* problem are identical.

It focuses on the bias for action and proactive ownership of the intellectual pipeline.

I’ll talk to how I use this methodology to identify high-impact Staff work by pursuing an organisational playbook: a high-conviction, principled argument for systemic change. This involves navigating four distinct phases:

1. The Research Gap 🔎:

Systematically surveying the organisation (e.g., Operations) to find critical ‘open loops’ and opportunities that significantly impact the business.

2. The Conviction 💪:

Developing T-Shaped authority and cross-domain empathy to define the correct, often difficult, architectural solution, turning a simple problem into a strategic mandate.

3. The Validation & Alignment 🤝:

Gaining cross-functional adoption by acting as the technically accountable strategic partner (the “PM’s Best Friend”), proactively steering product and engineering decisions.

4. The Multiplication 🌳:

Scaling impact by executing the strategy through others and deliberately building a Coaching Tree of future Staff Engineers.Using a real-world case study, how we architected the solution to a critical scheduling ‘open loop’ in our Operations platform, we will provide practical lessons on turning deep technical insights into lasting organisational leverage.

Key takeaways

• Proactive Thesis Development: Learn how to systematically identify systemic “”open loops”” and use a bias for action to propose a principled, architectural solution (Conviction).
• T-Shaped Authority: Understand how to use core domain mastery, combined with broad product and engineering context, to build technical opinions that command influence.
• The PM’s Best Friend: Master the skill of cross-functional Validation & Alignment, ensuring your strategic proposals are adopted and proactively guide critical product decisions.
• The Multiplier Effect: Understand how to structure strategic work to explicitly foster the growth and technical leadership development of others as a core Staff responsibility.

Sponsored by

Selecting and rolling out AI tools is the easy part. Changing behaviour, and levelling up productivity across an organisation has always been hard, and still is with AI. This talk will describe how the right approach to learning can help enterprise organisations improve their AI abilities, and realise the promised gains in productivity.

Host’s closing remarks.

Sponsored by

Join us after day one at Boom Battle Bar (Upstairs @ The O2) to unwind with other attendees.

Expect a relaxed evening with games including darts, pool, axe throwing, and shuffleboard, plus a street food buffet.

A chance to switch off, have some fun, and continue the conversations from the day – without the slides.

Host’s opening address.

Small things going wrong can quickly snowball. The cascading failure is often a nightmare scenario for any system. An initial problem, which in isolation seems like such a minor problem, can kick off a chain reaction of ever-increasing failures, potentially leading to catastrophic results.

When a failure of a single component results in the failure of other connected elements, this is known as a progressive collapse. In this talk, Sam Newman looks at this phenomenon in more detail, and he’ll examine how it has manifested in major disasters. Based on lessons learned from other industries, Sam will share three key techniques that can be used to mitigate against the progressive collapse occurring in your own system.

This talk will help you understand how to architect your systems in such a way that small failures stay small.

Every organisation has its speed limits. When more effort starts producing fewer results, you’ve likely hit one. What drives speed has shifted, and so must your approach.

In the early days of scaling, your organisation feels almost unstoppable. You think you may have cracked the code for success, and even start wondering if you should maybe write a book about it. But then the balance begins to shift. First slowly and almost imperceptibly, then faster and faster, until it feels like the whole thing is about to spin off the handle.

I have seen the same pattern repeat in very different environments. The details changed, but the slowdown always looked the same. At some point, execution just stopped being a convincing explanation. That’s when I came across systems thinking.

What I learned is that when issues keep repeating despite capable teams and good intentions, the problem is rarely people. It’s the structure of the system itself: the limits built into it, the stocks that quietly accumulate over time, and the feedback loops that shape behaviour whether we notice them or not.

In this talk, I will show how rising incidents, fragile systems, slower delivery and constant firefighting are often signs of hitting systemic limits rather than execution failure. We’ll look at how both your “good” stocks (product strength, customer base, team mastery) and your “bad” stocks (technical debt, team burnout, coordination complexity) are shaped by reinforcing and balancing loops, and why understanding what feeds those stocks, and what slows them down, can be critical to survival as you scale. I will also explain why pushing harder is almost always the wrong response to limits to growth, and how well-intentioned quick fixes can erode long-term resilience.

This talk helps make sense of why organisations behave the way they do as they scale. It shows how familiar problems often point to structural limits rather than execution gaps, and explains how to recognise when the system itself is shaping the outcome.

Key takeaways

• You can’t hire your way out of a system problem.
• Issues that keep coming back are usually structural, not something you can spot-fix.
• Every organisation has speed limits. Scaling works better when you recognise them instead of fighting them.
• Late or weak feedback isn’t feedback. It’s noise.
• In complex systems, cause and effect are far apart. By the time you feel the problem, you are already reacting to the past.

Replacing a 20-year-old system while remaining on-air is the ultimate engineering stress test. Talk shares ITV’s framework for visualising “invisible” technical debt to justify the modernisation of critical infrastructure, moving from gut-feel to data-driven decommissioning.

Every engineering leader fears the “untouchable” legacy system, the 20-year-old monolith that runs the core business but blocks innovation.
At ITV, this was our linear scheduling infrastructure, a critical system underpinning our broadcast channels, yet it was effectively difficult to maintain and manage.

We couldn’t afford a high-risk “big bang” rewrite, nor could we let the debt continue to accumulate. In this session, I will share the “Technical Debt Framework” that we used to derisk this modernisation.

We moved beyond the abstract by categorising debt (Visible vs. Invisible, Positive vs. Negative Value) to secure stakeholder buy-in on a modernisation strategy.

I will cover:

• The “Visible vs. Invisible” Matrix: How to map architectural decay against business risk to show non-technical leadership why a “working” system is actually closer to failure.
• A Case Study: The specific engineering trade-offs of modernising an old estate, including the decision to build tactical in-house microservices versus adopting third-party tooling.
• The “25% Rule”: The road we took to identify the operational reality of negotiating a fixed capacity for debt repayment to prevent the “spiral of reduced morale and productivity.

Key takeaways

• A Classification Framework: A practical model for categorising debt (Architecture vs. Code vs. Infrastructure) to make “invisible” drag visible to the C-suite.
• Modernisation Strategy: How to choose between a tactical in-house rebuild and third-party vendor adoption when replacing core legacy systems.
• Observability for Operationalising Repayment: How to implement a standard approach that allocates up to 25% of sprint capacity to debt servicing without derailing product delivery.

Sponsored by

AI agents are easy to demo but hard to deploy at scale – learn the engineering frameworks for reliability, observability, and safety that make production-ready autonomous agents possible.

Building AI agents that work in demos is easy – making them production-ready is hard. João Freitas, VP of Engineering for AI And Automation at PagerDuty, shares hard-won lessons from deploying autonomous AI agents at scale. Discover the complexities and risks that derail most agent projects, and learn practical frameworks for reliability, observability, and evaluation that separate successful deployments from failures. From multi-agent architectures to guardrails against prompt injection, hear the engineering realities behind AI agents that diagnose incidents, automate remediation, and operate safely in enterprise environments. These are essential insights for anyone building agents beyond the prototype stage.

Key takeaways

• Production vs. Prototype Gap: Building demo AI agents is straightforward, but production deployment requires robust frameworks for reliability, observability, and evaluation to handle real-world complexity and risk.
• Multi-Agent Architecture & Safety: Successful enterprise AI agents need carefully designed multi-agent systems with guardrails against threats like prompt injection to operate safely at scale.
• Practical Engineering Realities: Real-world agent deployment for incident diagnosis and automated remediation demands specific technical approaches that separate successful implementations from failures.

How Cash App built a culture of shared ownership in platform engineering–where empathy, collaboration, and visibility drive developer experience and delivery velocity.

Platform engineering often conjures images of large, specialized teams. But at Cash App, it began with volunteers–and eventually, with me as the first full-time Android Developer Experience (MDX) engineer. This talk explores how a grassroots, crowdsourced approach to platform engineering can scale from one motivated individual to an organization-wide culture of shared ownership and empathy-driven leadership.

Through real stories from Cash App’s Mobile Developer Experience and Release Automation teams, I’ll share how feature engineers contributed directly to developer tooling, while platform engineers stayed grounded by building product features. This created powerful feedback loops that improved collaboration, accelerated delivery, and increased build reliability across mobile teams.

Attendees will learn practical leadership patterns for enabling this kind of culture: embedding DX tooling in monorepos to lower contribution barriers, recognizing cross-team contributions publicly, running regular qualitative feedback sessions, and rotating engineers between platform and product work to build empathy and skill breadth.

In a world of AI and constrained resources, the ability to “do more with less” depends on trust, empowerment, and shared purpose. This talk shows how engineering leaders can intentionally cultivate those qualities–shifting platform engineering from a service function to a collective movement.

Whether you’re a tech lead, staff engineer, or manager, you’ll leave with repeatable strategies to:

• Seed a culture of shared ownership and psychological safety
• Encourage engineers to grow platform skills without burnout
• Ground platform work in product realities
• Recognize and sustain contributions visibly
• Lead teams that are human-first, not AI-first

Key takeaways

• How to build and sustain a culture of shared ownership in platform and developer experience work.
• Leadership practices to enable empathy, visibility, and trust across technical teams.
• Practical strategies to “do more with less” through collaboration and empowerment.
• Methods to ground platform efforts in real product needs and avoid abstraction drift.
• How to make human-first leadership a competitive advantage in an AI-first world.

Facing fragmented microservices, Duolingo launched a Golden Path to standardize development. By packaging best practices into templates with superior tooling and automated security, adoption followed organically, boosting velocity without mandates while empowering autonomous engineering teams.

After more than a decade of rapid growth, Duolingo’s microservice ecosystem was highly functional, but also highly fragmented. This technical diversity created significant friction, slowing down developer velocity and making consistent security and maintenance a formidable challenge. To address this, we initiated a “Golden Path” project to standardize how services are built and operated, but we immediately confronted a classic dilemma: how to drive adoption across autonomous engineering teams without affecting productivity. The traditional “stick” approach of enforcing mandates from the top-down felt counter to our culture, while a “carrot” approach required genuine value to development teams in order to gain long-term traction. For example, security, while its importance was universally acknowledged in principle, in practice it was often deprioritized by developers focused on shipping features.

Our breakthrough came from realizing that we could use our existing microservice templates as the central place to improve and commit standards, essentially treating repositories as updatable packages. Instead of prescribing standards from the top down, we systematically identified, refined, and codified the best practices and tools that had emerged organically within our engineering culture over the past ten years. We focused on making the Golden Path the path of least resistance by providing superior tooling, faster build and deployment times, and automated security that was seamlessly integrated and provided immediate benefits to existing microservices. This transformed security and cost controls from compliance burdens into free features. By standardizing our most successful homegrown solutions, we achieved widespread adoption not through heavy enforcement, but by offering a tangible competitive advantage that empowers our developers to build faster and more securely.

Key takeaways

• Top-down mandates can conflict with culture, focus on “carrots” not “sticks”
• Existing service templates can be treated as updatable packages to embed and evolve standards
• AI code migration tools work better for what is unique about a service, static tools work better for what is common among services
• Identify and codify homegrown best practices rather than a brand new set of standards if possible
• Make the Golden Path the easiest option to drive voluntary, rather than forced adoption

Many MCP servers are built out of curiosity rather than necessity. In this talk, we’ll see how the team at Multiplayer approached building a production-grade MCP server and the hard lessons learned along the way to get AI the right data at the right time.

Today, many MCP servers are built to “connect AI to your systems”, often exposing too much data, too little intent, or unnecessary security risk. In this talk, we’ll start with one of the core pain points: giving AI coding tools access to high quality, system-specific data that was previously too fragmented or costly to assemble.

From there, we’ll explore why solving the data problem requires rethinking observability practices, how to design MCP servers that don’t inherit this problem, and why data collection is only half the equation: you also need agents that can act on that data.

This session is a candid look at what it takes to move beyond hype and build AI tools that are both useful and safe. Where less is more, context beats
completeness, and AI workflows fit naturally into existing developer workflows.

Key takeaways

• Why “connect AI to everything” doesn’t work and the modern telemetry data problem
• What AI agents actually need to move from assistants to autonomous tools
• How observability practices must evolve (session-based collection, dynamic escalation, auto-correlation)
• Practical MCP design principles that account for data quality, user intent, and security
• The path to self-healing systems using AI agents to act on the “right data”

A reliable system isn’t just about your infrastructure. Learn to effectively leverage game days to train engineers and build resilience before real incidents force you to.

No one likes responding to incidents – but they’re also where you learn the most. Every outage reveals weaknesses across your systems and processes that you might not have found any other way.

The problem is, waiting for your biggest incidents isn’t a realistic strategy for building a more reliable system. You can introduce stress tests or extrapolate worst-case behaviours, but there’s an unpredictability to how systems and people behave in combination under real pressure that is hard to fully account for.

Game days are your opportunity to test that combination without frantic firefighting. If you’re not running realistic tests, your safeguards are theoretical: you don’t want to learn whether they work in a disaster scenario.

At incident.io, we use game days to train engineers, validate fixes from past outages, and build genuine confidence in our systems and response processes. Most recently, we ran game days to successfully validate that we would be resilient in the face of an AWS outage. Every time we run a game day, engineers are asking when the next one will be.

It’s easy to run a simple drill, but half the value of a game day comes from thorough preparation. Figuring out what’s actually feasible to break gives you confidence in the parts of your system that are solid. Finding the holes you *can* poke through gives you avenues to follow up, even before you’ve run anything. And preparing for the different response paths your engineers might take lets you create realistic pressure, making it feel like a real incident rather than a repetitive drill.

In this this talk, I’ll cover what we’ve learned running game days, and how you can get the most value out of them. Running a successful game day can make your systems more resilient, but you’ll also be building a culture of reliability in your organisation.

Key takeaways

• Why game days are one of the most effective tools for reliability and getting ahead of the next potential outage
• Learn to run efficient and worthy game days that can give you both confidence in your systems and a clear list of areas to improve, as well as a chance for your engineers to experience realistic pressure without risking production
• How to build a culture of reliability by making game days and incidents something engineers find valuable and want to repeat

We dive into the technical details of three areas in the context of shipping AI agents: security, reliability and performance.

This is a talk written by engineers, for engineers. At Gradient Labs we build AI agents for financial services companies. In this talk, we share techniques and best practices that we’ve developed in shipping AI agents in high-stakes environments. Specifically, we cover three areas, outlined below.

Security

We talk about how we apply the principle of least privilege to AI agents, as well as some specific practical examples where we’ve had to think through security (e.g. identity verification with voice agents).

Reliability

We talk about how we handle failures, rate limits, latency spikes, durable execution and retries, as well as how we protect our agent from external factors like spikes in load.

Performance

We talk about testing non-deterministic systems using production conversations as test fixtures, LLM-as-judge evaluation, and the metrics that actually predict customer satisfaction.

Key takeaways

• How to manage the risk of AI agents reading sensitive data and performing high-stakes actions
• How to ensure reliable execution in the presence of failures when working with AI agents
• How to test AI agents when traditional unit tests don’t work; synthetic evaluation pipelines, LLM-as-judge, and metrics that catch regressions before customers do

Host’s closing remarks.

Host’s opening address.

What tools and techniques do top-performing teams incorporate into their software delivery practices in 2026? In this talk, you’ll learn about ways to improve your DORA metrics to become an elite-performing team that can effectively leverage AI-assisted development, and how benefits compound exponentially from adopting the interlocking modern developer productivity and platform engineering stack.

You’ll see concrete, vendor-agnostic examples of teams gaining confidence in their delivery process through hermetic build artifacts, continuous delivery pipelines, feature flagging, observability, code ownership, blameless incident analysis, shared platforms/infrastructure, Service Level Objectives (SLOs), and chaos engineering.

Key takeaways

• How to build platform and structure platform teams
• Which platform practices to embrace in which order
• How AI changes (or doesn’t change) your dev workflows

Shipping your first LLM feature requires more than code. This talk explains how we navigated new strategic demands, from opt-in stances to evaluation workflows, to find a pragmatic path to production.

Even for mature engineering organisations, the first LLM-powered feature introduces a paradigm shift. The actual coding often feels like the easy part. The real challenge lies in a daunting list of new “supporting” activities. From defining evaluation frameworks and prompt versioning to deciding on customer “opt-out” stances and communication strategies, how do you decide where to focus your limited energy?

In this session, I will share the “battle scars” from our journey to production. I’ll break down our approach to the 80/20 rule: identifying the activities that required deep investment, those we found a “light” way to handle, and those we intentionally parked for later.

We will explore:

• The Effort Flip: How we restructured our workflow to move from “getting it to work” to “ensuring it’s good enough,” reallocating engineering time from writing code to context engineering and evaluation.
• Strategic Stances: How we tackled non-code needs like opt-in/opt-out policies, customer FAQs, and internal upskilling.
• Triage in Action: What we over-invested in, what I wish we’d done sooner (like early internal documentation on feature capabilities) and what we successfully deferred (like automation of evals).

This isn’t a prescriptive guide, but a look behind the curtain at how we defined our own “production-ready” standard. You will leave with a framework for auditing your own AI roadmap to ensure you’re focused on the activities that truly drive reliability and trust.

Key takeaways

• Evaluation First: Robust evaluation matters more for reliable AI systems than perfecting the initial code.
• Prioritising based on a North Star: We treated security and trust as non-negotiables, informing what to prioritise, including OWASP Top 10 reviews and data privacy decisions.
• Design the First Feature to Scale: The initial rollout can establish reusable patterns that accelerate every AI feature that follows.
• Manual Before Automated: Starting with human-in-the-loop evaluation saved time and helped us understand failure modes before investing in automated testing.

Software supply chain failures are no longer just technical or financial risks. This talk shows how everyday engineering leadership decisions can escalate into real-world harm, and why modern leaders must treat software as safety-critical infrastructure.

Software supply chain attacks are usually discussed in terms of CVEs, compliance, and financial risk. This talk deliberately shifts that lens. As software increasingly underpins healthcare, transport, energy, and public services, engineering leadership decisions now carry consequences that extend well beyond systems and balance sheets.

Drawing on real incidents: from healthcare outages and emergency-service disruptions to infrastructure and embedded-system attacks, this session explores how ordinary, well-intentioned engineering trade-offs can cascade into human harm. These failures rarely start with negligence or malice. They emerge from abstraction: dependency choices, build pipelines treated as “internal”, unsupported components accepted as normal, and risk framed as something to insure rather than prevent.

A key theme is that software supply chain attacks are not just another category of cyber incident. They are a force multiplier, enabling ransomware, data theft, sabotage, and cyber-warfare at scale. With modern applications composed mainly of third-party code (much of it unmaintained) engineering leaders are increasingly responsible for systems they do not directly control but whose failures they must still answer for.

This is not a tool-centric security talk. It is a leadership talk about responsibility, prioritisation, and the hidden blast radius of everyday decisions. Attendees will leave with a clearer mental model for evaluating vulnerabilities in context, recognising when technical debt becomes a societal risk, and understanding why engineering leadership is, in many cases, now safety-critical.

Key takeaways

1. Every-day engineering trade-offs can directly shape real-world outcomes, not just technical ones.
2. Supply chain weaknesses turn small decisions into large, downstream failures you still own.
3. “Risk” is a comforting abstraction that hides who actually gets hurt when systems fail.
4. You can delegate code and tools, but not responsibility for consequences.
5. Many software teams are now operating safety-critical systems–whether they realise it or not.

Sponsored by

Every AI coding tool can generate code. Very few can generate the right code for your organization, because they’re missing context. They don’t know why your team chose Redis over DynamoDB, what the team decided in a Slack thread from two months ago about the auth migration, or which architectural patterns your principal engineers actually enforce in review. This talk is a practitioner’s guide to building a context engine: the reasoning layer that continuously synthesizes organizational knowledge across disparate sources into unified, queryable understanding. I’ll walk through the problems you actually have to solve — reasoning across systems that don’t agree with each other, searching globally before you can reason, maintaining identity-scoped permissions so every user and agent only sees what they should, and personalizing results based on who’s asking and what they’re working on. These are the engineering challenges that make naive RAG fall short, drawn from real lessons building this at scale.

Accessibility is often seen as a velocity killer. I’ll share how giffgaff transformed our legacy monolith. We proved inclusive code costs zero extra time and unlocks the massive economic potential of the ‘Purple Pound’.

Accessibility is often treated as a compliance checkbox or a final cleanup phase. It becomes a form of exclusionary tech debt that teams fear. With the ‘Purple Pound’ (the spending power of disabled households) worth an estimated £446 billion in the UK alone, the business case is clear. Yet at giffgaff, we faced a hard reality with our legacy monolith. We had a daunting backlog, and it was feared that fixing it would destroy productivity and derail our roadmap.

In this talk, I’ll share how we turned this challenge into an opportunity to build a high-performing, inclusive engineering culture. We moved beyond reactive bug fixes to prove a controversial truth. Writing accessible code doesn’t have to take extra time.

I will demonstrate how we built an accessibility-first mindset by:

• Modernising the monolith and securing leadership buy-in by coupling accessibility standards with our technical migration to a modern tech stack.
• Scaling knowledge through documentation and training to empower developers, rather than relying on experts.
• Building culture by establishing an Employee Resource Group and hosting an ‘Accessibility Culture Day’ to shift our perspective from obligation to opportunity.
• Moving from a fix-it-later approach to an accessibility-first mindset, proven by a drop from 43 accessibility issues to zero in our new phones journey, without delaying release.

This talk is for leaders looking to move accessibility from the backlog to the definition of done, proving that quality, inclusion, and speed are not trade-offs.

Key takeaways

• Learn how to pay down accessibility debt by aligning it with technical modernisation.
• Discover how to quantify the impact of inclusion to secure leadership buy-in.
• Understand how to scale accessibility knowledge via documentation and tooling.
• Gain strategies to build a culture of empathy that shifts the mindset from compliance to opportunity.

How modernising our quality practices created a cycle of continuous improvement, transforming tools, processes, and culture, and ultimately delivering organisational change that achieved what had previously been considered impossible.

This talk shares how we introduced modern quality engineering into a legacy environment and in doing so reduced our lead time to deployment by 480 hours while also dramatically improving the developer experience. We’ll break down the technical, cultural, and procedural shifts that enabled faster feedback loops, more reliable deployments, and higher team confidence. From early test-automation efforts and the introduction of ephemeral environments, to standardising deployments and gradually replacing brittle manual steps, this is a practical, honest account of how meaningful change actually happens. Attendees will leave with a clear understanding of what quality engineering really looks like in practice, how to introduce it sustainably, and what timescales to expect when pursuing long-term ROI and organisational transformation.

Here’s what we’ll cover:

Background

• State of things when we started
• Issues this caused

First steps

• Introducing test automation to create faster feedback loops
• How we prioritised out test creation and determined what was the most valuable.

Unlocking deployments

• Introducing tooling and processes that standardised and automated deployments.
• Enabled more people to be involved, understand, and contribute to improving our processes.

Shifting left

• Improving development ways of working that enabled more testing, more often, and earlier in the process.
• Introducing ephemeral test environments
• What they are, how they work, and how they improved testing

Trust takes time

• A pause in discussing the improvements to focus on why its importnant to iterate slowly over time and build confidence gradually when making significant changes to processes and ways of working

Replacing manual with automated

• How automating those final manual steps allowed all the gradual improvements to come together

Summary

• Where did we end up
• What did we learn?
• How long did it take?

Key takeaways

• Explain what modern quality engineering looks like in practice, beyond traditional QA, and identify where to start in their own teams.
• Prioritise the right early investments (automation, feedback loops, workflow changes) to generate momentum and visible value.
• Design sustainable improvements using iterative change, gradual trust-building, and appropriate timescales for organisational ROI.
• Apply practical techniques for introducing test automation, standardising deployments, and using ephemeral environments to accelerate delivery.
• Recognise the cultural, technical, and process shifts needed to reduce lead time and improve developer experience across an organisation.

In established ecosystems, “Chaos Engineering” is a simulation. In Nigeria, it is a daily reality. Learn the “Zero-Trust” patterns and leadership strategies we use to build bulletproof systems when the infrastructure is constantly failing us.

In established ecosystems, engineering leaders obsess over “Chaos Monkey”, software designed to randomly crash servers to test resilience. In Abuja Nigeria, we don’t need Chaos Monkey. We operate on a national power grid that collapsed over 20 times in the last two years, amidst hundreds of fiber cuts and network disruptions.

For my team, failure isn’t a theoretical risk to be simulated; it is the default state of our existence.

This session explores the unique engineering discipline required to build world-class products in a “low-trust” infrastructure environment. I will share the war story of a Black Friday launch for our high-volume fintech platform where we faced the “Perfect Storm”: a major fiber cut took our office offline, our primary payment partner suffered a latency spike, and the power grid collapsed, all within an hour.

Most teams would have folded. Mine didn’t even pause.

I will detail the “Zero-Trust” framework that allowed us to survive, and how you can apply it to your own stack:

1. The Architecture of Distrust: How we moved from synchronous coupling to an aggressive asynchronous model. We assume every external API (Stripe, Twilio, AWS) will fail 50% of the time. I will show how we used Redis-backed persistent queues and the Outbox Pattern to allow our app to “hold its breath” for hours without crashing.
2. The “Air-Gapped” Developer: How we built “Offline-First” dev environments. By dockerizing our entire stack locally (including mocked third-party services), we empowered engineers to ship code even while tethered to 3G mobile hotspots, a lesson in eliminating cloud dependencies that speeds up any team.
3. Leading Through “Outage Fatigue”: Constant firefighting burns out engineers. I will share my playbook for psychological safety, shifting the culture from “Who broke it?” to “How did the system absorb the shock?”

Attendees will leave with a new perspective: You don’t need to be in Africa to face failure. By applying these “survivalist” constraints, you can build systems that are bulletproof anywhere.

Key takeaways

1. Organic Chaos Engineering: Why “simulated” failure pales in comparison to real-world constraints, and how to audit your system for “happy path” bias.
2. Asynchronous by Default: Implementing specific patterns (Circuit Breakers, Leaky Buckets, Outbox) to decouple uptime from third-party dependencies.
3. Psychological Safety in a Firefight: A manager’s guide to preventing burnout when the environment is constantly fighting against you.

Sponsored by

Discover how to close the trust gap and safely turn AI generated code into shipped software without compromising enterprise security.

AI agents hold incredible potential and now write the majority of today’s code to help teams build faster than ever. Yet enterprise shipping velocity remains bottlenecked. This happens because AI agents do much more than just generate text. They actively access private data, interact with internal systems and communicate externally. This new reality creates a massive trust gap where organizations must either cripple developer velocity with constant manual approvals or accept severe risk by letting agents run in YOLO mode. In this session we will explore how to provide the secure foundation needed to solve this problem. Learn how to grant developers true agent autonomy without sacrificing enterprise governance and finally turn 10x code into 10x shipped.

Key takeaways

• Understand the hidden security risks of autonomous agents accessing internal data and systems.
• Learn why manual tool approvals and “YOLO mode” both fail at enterprise scale.
• Discover how isolated execution environments grant true developer autonomy.
• Gain a framework for enforcing 360 degree governance without crippling velocity.

Replace fragile legacy scripts with cloud-native stability by mastering documentation, phased delivery, and knowledge transfer to eliminate single points of failure in your architecture.

Moving legacy systems to the cloud is often sold as a solution, but a “lift-and-shift” without a longer-term plan only relocates the problem. When mission-critical architecture relies on decades of legacy Bash and PL/SQL scripts maintained by a single person, that individual becomes a single point of failure. Their departure doesn’t just leave a vacancy; it leaves a “black box” monster that no one understands and everyone is afraid to touch.

This platform-agnostic session provides a survival guide for inheriting these systems. We will explore why the foundation of modernization isn’t code, but documentation and knowledge gathering. We’ll discuss how to audit undocumented scripts to build a source of truth before a single line of code is rewritten.

A key focus will be practical application of the strangler fig pattern. Instead of a risky “big bang” rewrite, we examine how to balance ongoing maintenance of the old system with the development of the new. You will learn how to establish realistic dates and deliverables that prioritize stability—such as replacing outer Bash wrappers first while letting complex but stable PL/SQL logic run until a later phase. This talk provides a blueprint for turning a fragile, person-dependent script library into a resilient, documented, and modernisable cloud asset.

Key takeaways

• Identify and mitigate “”Single Points of Failure”” by converting tribal knowledge into technical documentation
• Develop a phased “”piecemeal”” migration roadmap that prioritizes wrapping scripts over deep logic
• Balance the “”business as usual”” maintenance of legacy code with the development of new architecture
• Establish a framework for setting realistic deliverables and milestones during a high-risk cloud transition

After training and coaching 400+ tech leads, one thing is clear: their hardest problems aren’t technical. This talk explores the real blockers and what helps.

After training and coaching more than 400 tech leads across different companies, industries, and levels of experience, one pattern keeps repeating: when tech leads struggle, it’s rarely a technical gap.

In this talk, Anemari Fiser shares the most common challenges tech leads bring into coaching sessions and why “getting better technically” almost never fixes them. Instead, the real blockers show up as overload, unclear expectations, ownership confusion, and assumed alignment. These patterns consistently lead to slow decisions, delivery friction, and burned-out tech leads, even in teams with strong engineers and modern tooling.

Drawing from real coaching sessions, training group discussions, and concrete case studies, this talk explores where tech leads consistently get stuck. For each pattern, it looks at what the tech lead thought the problem was, what it turned out to be, and the small but meaningful shifts that helped them move forward: from rethinking 1-on-1s, to making expectations explicit, to letting go without losing trust.

This isn’t a talk about abstract “soft skills.” It’s about the invisible leadership work tech leads are expected to do without ever being taught how. Attendees will leave with concrete ways to spot people problems early, make expectations explicit, and reduce the load they carry as tech leads.

If you’ve ever thought, “I didn’t expect the role to be this hard,” this talk is for you.

Key takeaways

1. Why tech leads feel overloaded and how to reduce it at the source
2. How unclear expectations create self-doubt, even in experienced tech leads
3. How assumed alignment quietly creates friction and slows teams down – and what to do about it”

Host’s closing remarks.

Engineering leaders are caught in a worsening visibility crisis:

• The player-coach pull: AI is pulling managers and directors back into technical contribution, compressing time for the 1:1s, skip-levels, and thinking that actually gives you a read on your org
• The throughput flood: AI-augmented teams produce more, faster, flooding channels with information, while previously-useful metrics become less informative
• The noise layer: On top of it all, a growing layer of strategic noise: AI hype, board pressure to show ROI, and shifting expectations about what teams should deliver, and how

The result: You have less time to see, more things to see, and more noise obscuring what matters. Most leaders juggle more and more, feel constantly behind, and don’t even have time to think about how to handle all this better. So how do you shift gears and get from noise to clarity? What can you put in place to get the visibility and confidence you need, without relying on heroic efforts or micromanaging everyone? How do you spot issues and course-correct quickly when your capacity for sensing is shrinking?

Let’s change that, together. You’ve built observability systems for your software. Now it’s time to build one for your organization. From this session run by a seasoned senior leader, you’ll take away concrete ideas to start exactly where you and your org are at right now, improve your organizational observability, and get a kit to help you evolve from there.

Connect with folks over shared experiences

Everyone’s journey into leadership is tough, but folks who are underrepresented in tech often face their own unique set of challenges. And that can lead to people feeling isolated in their experiences. 

Come to the community representation groups, where you’ll be able to connect with folks who might have similar backgrounds and experiences to yours, and where you’ll be able to build a peer network for support throughout your journey.

Connect with folks over shared experiences

Everyone’s journey into leadership is tough, but folks who are underrepresented in tech often face their own unique set of challenges. And that can lead to people feeling isolated in their experiences. 

Come to the community representation groups, where you’ll be able to connect with folks who might have similar backgrounds and experiences to yours, and where you’ll be able to build a peer network for support throughout your journey.

Have a startup idea? Join SF-based Heavybit investor Dana Oshiro to craft your narrative as a technical founder; discuss what investors actually evaluate at pre-seed and seed; learn how dilution works over time; and build a pragmatic capital strategy.

Connect with folks over shared experiences

Everyone’s journey into leadership is tough, but folks who are underrepresented in tech often face their own unique set of challenges. And that can lead to people feeling isolated in their experiences. 

Come to the community representation groups, where you’ll be able to connect with folks who might have similar backgrounds and experiences to yours, and where you’ll be able to build a peer network for support throughout your journey.

Connect with folks over shared experiences

Everyone’s journey into leadership is tough, but folks who are underrepresented in tech often face their own unique set of challenges. And that can lead to people feeling isolated in their experiences. 

Come to the community representation groups, where you’ll be able to connect with folks who might have similar backgrounds and experiences to yours, and where you’ll be able to build a peer network for support throughout your journey.

If you’re inspired by a talk, want to learn more, or just want to chat about it with other folks, head to our Office Hours area where our speakers will be waiting for you.

Watch or participate in free 1:1 coaching with Mathias Meyer.

Learning new information is always great, but sometimes solutions can feel too one-size-fits-all for your specific circumstances. How can advice be applied to a team of 10 or a team of 10,000?

On the other hand, coaching is directly tailored to your specific challenges and the specific environment they exist in. Mathias will be hosting one-on-one coaching sessions with attendees to get into the nuts and bolts of the challenges they’re facing. Come and have a conversation, or peek into the challenges other leaders are facing.

Quiet quitting. Rage quitting. Disengagement, burnout, mental health breaks. Stalled careers, unclear expectations, slanging matches, stolen credit, and betrayal. Poisoned relationships, broken promises. Politics.

There are endless stupid ways we can accidentally lose our best people, or turn them into our worst – this is a session to share some of your people-related mistakes, and hear about the worst mistakes of your peers.

Supported by Ceri Newton-Sargunar, a behavioural scientist and skilled senior leadership coach, you’ll also get some understanding along the way, of why things go as badly as they do – so you can take steps to make sure they, and you don’t fall into the same traps (again).

Comparing notes on shared challenges that come with your role has never been easier. Peer Hangouts are 30-minute, casual networking sessions for folks to talk through their experiences and challenges with peers who understand the context they’re working in. Drop in and join a conversation!

Watch or participate in free 1:1 coaching with Mathias Meyer.

Learning new information is always great, but sometimes solutions can feel too one-size-fits-all for your specific circumstances. How can advice be applied to a team of 10 or a team of 10,000?

On the other hand, coaching is directly tailored to your specific challenges and the specific environment they exist in. Mathias will be hosting one-on-one coaching sessions with attendees to get into the nuts and bolts of the challenges they’re facing. Come and have a conversation, or peek into the challenges other leaders are facing.

Watch or participate in free 1:1 coaching with Mathias Meyer.

Learning new information is always great, but sometimes solutions can feel too one-size-fits-all for your specific circumstances. How can advice be applied to a team of 10 or a team of 10,000?

On the other hand, coaching is directly tailored to your specific challenges and the specific environment they exist in. Mathias will be hosting one-on-one coaching sessions with attendees to get into the nuts and bolts of the challenges they’re facing. Come and have a conversation, or peek into the challenges other leaders are facing.

LGBTQIA+ and BIPOC communities, neurodivergent, disabled people, and women have long been grossly underrepresented in tech, and even more so at senior management levels, where being “the first [insert your identity here]” in your company at your level is a common experience. We want to create this space specifically for you to connect and find community. During the session, you will receive guiding questions to discuss with your peers and a space to get to know, learn from, and celebrate each other, together.

Who this is for: We welcome any senior managers (Director and above) who are members of underrepresented groups in tech. We want to create a space for the many groups with little representation at those levels, so if you belong to a group that isn’t specifically mentioned here, please join and let the hosts know. You don’t need a DirectorPlus pass to attend.

Bring a book and get it signed, or just have a chat with the author.