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?

Wise onboards 50 grads annually. AI helps them code fast, but batch size is causing real senior review fatigue. I’ll share how we use automated guardrails to maintain safety without burning out the team.

I’ve spent over a decade leading engineering teams and lately the industry has shifted. Companies are asking why they should hire juniors when AI can just do the work.

At Wise we take the opposite view. We continue to hire 50 graduates every year because we believe AI is a massive enabler for unlocking early careers talent.

However, this opportunity brings a new challenge. AI allows our juniors to move incredibly fast. Our power users are producing 37% more Pull Requests than their peers. This surge in velocity proves their potential, but it brings concerns about work slop and growing PR batch sizes. We simply cannot rely on human reviewers to catch every quality issue in this new volume of code.

In this talk, I will share what guardrails we have put in place to let them move at the speed of a start up. We have introduced systems such as automated canary analysis and engineering maturity checks. This isn’t just about preventing bugs. It is about giving juniors the psychological safety to ship to production and learn faster.

I worry that if we reject early careers now, we lose our next seniors. I’ll share real stories from our academy, like interns fixing production issues on day one. You will leave with a plan to turn the AI uncertainty into your biggest advantage, using guardrails to make high velocity hiring safe and scalable.

Key takeaways

• Strategies to handle the 37% PR volume spike and increased batch sizes caused by AI-assisted juniors.
• How to mitigate work slop using your own AI engineering hub.
• Moving from “Review Gates” to “Production Guardrails” using automated canary analysis.
• A practical guide for scaling a graduate pipeline by treating AI as a productivity asset, not a replacement.

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)

Burnout hits the engaged leaders who keep giving, not the ones who don’t care. Using the four-dimensional burnout model, this talk gives you (and your team) practical tools to recognize, prevent, and recover from burnout.

Here’s what surprised me most about leadership burnout: you have to burn to burn out. It’s not the checked-out managers who struggle – it’s the caring, committed ones.

For the past few years, leaders’ mental well-being has been my main focus. Through coaching engineering managers and navigating high-pressure leadership roles myself, I’ve built a practical framework based on burnout research – including, unexpectedly, parenting psychology.

Typical “just take a vacation” advice ignores why leaders burn out in the first place. Here’s what actually works.

The four dimensions of burnout – exhaustion, emotional distance, loss of meaning, and the gap between who you think you should be and who you actually are. Learn to spot each dimension in yourself and your team before it’s too late.

Resources vs. demands framework – a systematic way to map your emotional, physical, and mental loads against what you actually have available. Find the dangerous imbalances before they become crises.

Early warning signs – specific signals in yourself and your people that you can recognize before full burnout hits.
Action plans for each stage – what to do to prevent it, what to do with first symptoms, what to do if you’re already burned out. Different stages need different strategies.

Supporting others without burning yourself out – the do’s and don’t’s for helping your team and peers through their struggles.

Taking care of yourself is hard, especially for engineering brains that want clear systems. That’s why I built this anti-burnout framework – to turn well-being into something understandable and actually doable. Because the leaders we need most are the ones who care deeply – and we need you to stay healthy.

Key takeaways

• Four-dimensional burnout assessment – recognize exhaustion, emotional distance, loss of efficacy, and identity conflict in yourself and your team before crisis hits
• Resources vs. demands audit – map your emotional, physical, and mental loads to spot dangerous imbalances early
• Stage-specific action plans – different strategies for prevention, early symptoms, and full burnout with concrete next steps for each
• Early warning signals checklist – specific, recognizable signs you can spot in yourself and your people
• Support playbook – do’s and don’ts for helping burned-out colleagues while protecting your own well-being

When Meta’s senior engineers couldn’t explain ‘vibe-coding,’ we knew something broke. Traditional leadership tools failed, and we had to evolve. Learn how, at Meta, we changed how we hire, evaluate, and lead.

A while back, during one of Meta’s new hire orientations, a senior manager froze when new hires asked him about “vibe-coding.” He nodded politely but clearly had no idea what they meant. That moment exposed more than a generational gap, it was a warning; The gap between how fast technology evolves and how fast leaders adapt is widening, and we must do something about it. ASAP.

Junior engineers now arrive with AI superpowers. The competitive advantage shifted from raw technical skill to adaptation speed, from code quality to communication, and from knowing frameworks to catching AI hallucinations. This forced Meta to rethink how we hire, evaluate, and lead.

We built AI-native coding interviews that measure adaptation, not memorization. We learned to evaluate talent without the traditional technical signals, and shifted the skills we look for when hiring, promoting, and assessing performance.

We also changed how we lead: leaders have to use AI themselves before teaching their teams. They learn to adapt , rather than using specific tools, so they can evaluate whatever shows up next. They needed to learn how to leverage AI without the price of dependency. We realized AI accelerates junior engineers faster than any technology we’ve seen, but despite the panic about job losses, AI can help ambitious engineers break in and move up, but only if their leaders understand how to guide them.

In this talk, I’ll share what we learned, and the frameworks we developed. I’ll share the mistakes we made, and what actually works when there’s no playbook. You’ll leave knowing what skills matter now, how to evaluate talent differently, and how to lead when yesterday’s answers don’t apply anymore.

Key takeaways

• AI-native coding interviews: How we rebuilt coding interviews to evaluate adaptation and not memorization.
• New evaluation criteria: What skills actually predict engineering success when AI changes the competitive advantage
• Leadership frameworks for AI adoption: How to train leaders to use AI themselves and guide teams without creating dependency
• Data-backed insights on junior engineers: Why AI accelerates junior engineers faster than any previous technology and how to leverage that effectively despite job loss fears

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.

Your future leaders are already on your teams. They span every level from junior engineers to staff engineers, and they’re watching closely. They’re learning not just from what you say, but from how you lead, how you make decisions, and how you create opportunities for others.

So, how do we intentionally prepare individual contributors for leadership roles? How do we equip them with the skills, context, and confidence to step into leadership roles and succeed as top-tier managers within our organizations?

Because scaling teams doesn’t start with headcount or org charts. It starts with scaling yourself as a leader.

A practical playbook for empowering individuals and delivering complex technical products across distributed teams without sacrificing inclusion or autonomy.

In a world where teams are more distributed than ever, managers and senior ICs need to evolve their collaboration styles and step into the future of work. Gone are the days of huddling 10 people in a room with a whiteboard, dry erase markers, sticky notes and way too much coffee in the hope that somehow intellectual osmosis happens and we’re miraculously all aligned. That approach does kinda get the job done, let’s be honest here, but while we’re at the honesty bit, let’s also concede that eating a hamburger with a spoon also gets the job done with the same degree of efficiency.

Old-school collab can also lend itself heavily to the “get in that room and don’t come out til you’re done” vibe that not only strips autonomy and trust away from our most highly respected engineers but also creates ridiculously expensive meetings (hello, 6 staff engineers and 2 principals in one room). Don’t get me started on the impact this has on inclusion (and yes, I still care deeply about this, and you should too).

In my experience, some of the best technical decisions have been a byproduct of allowing folk to simmer over what was being discussed — to think asynchronously, sketch ideas in their own time, pressure-test assumptions, and come back sharper. The quieter, more pensive folk who aren’t the loudest in meetings tend to stare deeply into the Miro/Notion abyss… sometimes with a little help from modern tools that help them organise thoughts or explore alternatives — and then → lightbulb!

Inclusion isn’t giving someone your paint and letting them paint their own canvas. It’s allowing people to add colour to your monochromatic genius and, fam, this method we’ve been using to fuel some of our biggest projects in Pleo has resulted in some pretty spectacular technicolor masterpieces!

If you’ll have me, I have some A-M-A-Z-I-N-G tips and tricks to share about how to successfully build and launch technically complex features requiring cross-domain/cross-team collaboration with engineers, PMs and domain leads distributed all over this beautiful blue speck of ours (aka the Earth), while empowering our teams to be the best versions of themselves yet.

The next evolution of collaboration is human-led, AI-assisted, and designed to amplify thinking and level the playing field — so no one feels like they don’t belong.

Key takeaways

• A clear picture of what effective collaboration looks like in 2026 and beyond – moving past synchronous, room-centric rituals toward more inclusive, distributed ways of working.
• Why empowering engineers and cross-functional partners isn’t a “nice to have,” but a practical lever for higher engagement, better technical decisions, and faster, more sustainable delivery.
• Concrete patterns for enabling asynchronous thinking that give quieter voices space to contribute and improve the quality of outcomes.
• Real-world examples from complex, cross-domain initiatives showing what worked, what didn’t, and what we’d do differently next time.
• Actionable techniques attendees can apply immediately in their next project – from shaping collaboration norms to structuring work so teams can do their best thinking.

Engineers have Cursor; leaders play “Calendar Tetris.” This case study shows how to build a personal AI assistant using commercial tools. Learn to automate toil, manage high-volume context, and reclaim time for strategic impact.

The AI market is currently obsessed with the Individual Contributor. Tools like Cursor and Cloud Code have revolutionized the IDE, allowing engineers to ship features and crush complexity at record speeds. But as Engineering Leaders, we have been largely left out of this revolution. Our “IDE” isn’t a code editor; it is a fragmented ecosystem of calendars, documents, and messaging apps.

While our teams move faster, we find ourselves bogged down, playing “Calendar Tetris” and drowning in context switching. Since the release of ChatGPT 2.5, I have been on a mission to fix this imbalance. I wanted to answer a simple question: Can I build a personal AI assistant that actually understands the context of engineering leadership?

In this session, I will walk you through the architecture of my personal AI system built using existing commercial tools. We will move beyond basic chat prompts and look at how to automate the “heavy lifting” of management. We will cover how to use AI to:

• Streamline meeting preparation and context gathering.
• Stay on top of a high volume of conversations across multiple teams and projects.
• Reduce the manual toil required for operational data analysis.
• Act as a “strategic coach” to help you prioritize between short-term fires and long-term goals.

You will leave with a blueprint for building your own assistant—one that handles the noise so you can focus on the signal, the strategy, and your people.

Key takeaways

• The “”Leader’s Stack””: A walkthrough of the specific commercial tools and integrations used to build a low-maintenance, high-impact personal assistant.
• Managing Scale: How to use AI to summarize and track context across dozens of concurrent streams without losing the details.
• The AI Coach: Techniques for using LLMs to analyze your schedule and tasks, helping you enforce prioritization between the urgent and the important.
• From Toy to Tool: How to move past the novelty of LLMs and make it into a centralised IDE that help you become a more impactful leader?

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.

A knee injury turned me from player to coach. Watching from the sidelines taught me that understanding how people work matters more than technical skills alone.

Two years ago, a serious knee injury stopped me from playing sports. Instead of losing contact with my over-30s women’s football team whilst I recovered, I volunteered to coach from the sidelines—something I’d never done before. Suddenly, I was watching the same game from a completely different angle.

On the pitch, I’d naturally lead by example and being a good team player. From the sidelines, I started seeing the whole picture and all the people interacting with each other: Who goes quiet when they make a mistake versus who gets visibly frustrated? Who needs a confidence boost before they’ll attempt something challenging? Who plays better with direct instructions versus space to be creative? Who says they are fine but actually are struggling inside?

In my work life I’d focused on balancing teams with skills, experience and temperaments but hadn’t consciously considered the psychology of teams. When I started to do this with my sport team the parallels to motivating engineering teams hit me immediately.
Sports coaches often say “”the game is 80% mental and 20% physical.”” If you relate this to software engineering, we are saying that performance of a team is 20% technical skills and 80% mental skills. Yet in attempting to improve teams we are regularly focusing on the technical skills and process improvements.

This talk is about learning to “”read the game””—to observe your team as a whole and the individual parts at the same time, and the importance of them understanding about each other.

The best teams aren’t just technically capable—they understand each other.

Key takeaways

• Learn why observing behavioural patterns in your team members is important
• Understand why creating psychological safety for people to say “I’m having a tough time today” makes teams stronger, not weaker
• Discover practical techniques for helping team members understand each other’s stress signals, motivations, and working styles
• Learn why a plan should be aligned to the strengths and weaknesses of the team

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

Talk details coming soon…

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.

Engineering friction compounds across your organization, costing you velocity, quality, and talent. This talk provides a data-driven framework for measuring, prioritizing, and scaling DevEx improvements that deliver measurable business impact.

Your engineers spend hours waiting on builds, navigating undocumented systems, and context-switching between 12 different tools. That’s not just frustrating—it’s expensive. Every friction point compounds across your organization, costing you velocity, quality, and your ability to retain top talent.

As AI transforms software development, this problem is about to get worse. AI-generated code increases deployment frequency and system complexity. If your baseline friction is already high, AI won’t speed you up—it will amplify every bottleneck and create new categories of problems you haven’t seen yet.

This talk presents a systematic framework for identifying and eliminating engineering friction at scale. You’ll learn how to measure what’s actually slowing your teams down, build data-driven business cases for DevEx investment, and prioritize changes that deliver measurable ROI. We’ll cover how to scale improvements from a single team to your entire engineering organization, and why the teams that fix their DevEx foundation now will outpace competitors in the AI era.

You’ll walk away with practical frameworks, measurement approaches, and stakeholder templates you can use immediately—whether you’re making the case for investment, leading an improvement initiative, or scaling best practices across teams.

Key takeaways

• A measurement framework for quantifying engineering friction and connecting it to business outcomes (velocity, quality, retention)
• Proven stakeholder templates for building data-driven business cases that secure DevEx investment
• A scalable playbook for rolling out DevEx improvements from single teams to entire engineering organizations

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

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

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.

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

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.

Discover how the biggest e-commerce company in Turkey, used LLMs and automation workflows to boost engineering speed by 30%–improving tests, documentation, and delivery, while keeping production stable, developers confident, and AI adoption practical, measurable.

Every engineering leader wants AI-driven productivity–but few achieve it without chaos. In this talk, I’ll share how our teams integrated LLMs and automation tools like n8n, Cursor, A2A, and MCPs into a 2,000-engineer organization to deliver a 30% improvement in delivery speed while keeping production stable.

This isn’t a story about hype or magic prompts–it’s about engineering discipline, governance, and workflow design. You’ll see how we automated testing, documentation, and code reviews; built smart pipelines; and measured impact in ways that developers trusted. I’ll also share what didn’t work–over-automation, misaligned incentives, and cultural resistance–and how we overcame them.

Attendees will leave with practical strategies to safely scale AI adoption, boost team productivity, and blend human creativity with machine efficiency–all without breaking the systems or the culture that make great engineering teams thrive.

Key takeaways

Whether you’re AI-curious or already experimenting, you’ll leave with a playbook for:

• Learn how to integrate LLMs and automation without disrupting production stability.
• Discover practical methods to boost engineering productivity by 30%.
• See real examples of AI-driven testing, documentation, and code reviews.
• Understand how to build trust and governance for safe AI adoption.
• Take home a proven framework for scaling AI across large engineering teams.

Distributed teams don’t need more tools – they need shared spaces. This talk shares practical leadership patterns for rebuilding trust, visibility, and human connection through intentional social and collaboration spaces in remote engineering teams.

When teams went remote, we didn’t lose productivity or tools.
We lost the shared, informal spaces where trust, learning, and real connection used to form.

Distributed teams rarely fail loudly. They drift quietly.
Effort becomes invisible. New joiners miss context. Leaders sense something is wrong, but nothing is obviously broken.

In this talk, I’ll show how engineering leaders can intentionally rebuild those shared spaces in fully remote and cross-country teams. Not by adding more meetings, but by designing social and collaboration spaces that replace informal, in-between moments.

Using a simple metaphor of shared spaces, I’ll share practical leadership approaches for rebuilding trust, visibility, and human connection across time zones and cultures. All examples come from real experience leading distributed engineering teams through growth and structural change.

This is a practical, leadership-focused talk for managers who want their remote teams to feel connected, aligned, and human – not just productive.

Because culture isn’t lost in remote work.
It’s just no longer accidental.

Key takeaways

• How to design shared social and collaboration spaces that replace informal, in-office moments in remote teams.
• How to make work and effort visible without introducing micromanagement or extra meetings.
• How to maintain trust and human connection across time zones and cultural differences.
• How to intentionally scale team culture as distributed teams grow.

Practical lessons from handling 100 P0 production incidents over 20 years, focusing on system design, incident response, observability, and leadership decisions that reduce impact and recovery time.

Over the past 20 years, I have been directly involved in handling more than 100 P0 production incidents across large-scale, distributed systems. These incidents included full outages, severe performance degradation, and data integrity failures, often under significant time pressure and business impact.

This talk shares the most important lessons learned from being on the front line of those incidents. Rather than walking through individual war stories, it focuses on the recurring technical and organizational patterns that consistently shaped outcomes, both good and bad.

I will explain how early system design decisions, alerting quality, ownership boundaries, and operational practices influence incident severity long before anything breaks. The talk also examines what actually helps teams stay effective during high-stress incidents and what tends to increase confusion, delay recovery or lead to burnout.

Drawing from real experience as a hands-on engineer and technical leader, this session offers practical guidance on improving incident response, building more resilient systems and leading teams through P0 situations with clarity and confidence. The goal is not to eliminate incidents entirely, but to reduce their impact and help teams respond better when failures inevitably occur.

Key takeaways

1. Recognize recurring patterns behind high-severity production incidents.
2. Design systems and alerts that surface problems earlier and more clearly.
3. Improve incident response by reducing cognitive load during P0 events.
4. Run incident reviews that lead to meaningful system and process changes.
5. Lead teams through production failures without blame or burnout.

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”

When pressure hits, culture breaks. This talk shows how system design drives behaviour and how leaders can redesign environments so principles survive real delivery pressure.

Every engineering organisation has principles: Quality first. Sustainable pace. Radical ownership. Yet when deadlines loom or incidents hit, teams often behave in direct opposition to them.

This is not a failure of belief or competence. It is a system design failure.

Under pressure, organisations do not behave according to what they say they value. They behave according to what the system makes cheap, risky, or impossible. When shortcuts cost less than robustness, engineers are not breaking the culture. They are rationally navigating the environment they have been given.

Drawing from real incident reviews and delivery trade-offs, this talk explores Shadow Culture, the behaviour that emerges when principles collide with reality.For instance, in one incident review, we realised our Quality First principle collapsed not because teams did not care, but because our CI pipeline added over 30 minutes to every change. Fixing the system changed behaviour faster than any retro ever had.

Rather than treating culture as something to communicate or reinforce, this session reframes it as a product that must function under load.

I will introduce a practical framework for pressure-testing engineering principles using four product lenses:

• Viability: Does this behaviour support the business under real delivery constraints?
• Value: Does it genuinely reduce risk or improve outcomes?
• Usability: Is the right behaviour easier than the shortcut?
• Feasibility: Can teams realistically do this during incidents and deadlines?

Leaders will learn how to spot where principles collapse under stress and how to redesign the environment so the right decision becomes the default rather than a heroic exception.

Key takeaways

• The Shadow Culture Audit: Learn to read system signals (PR shortcuts, skipped tests) to see what your culture actually is.
• The Stress-Test Framework: How to apply product design constraints to your principles to ensure they hold under pressure.
• Environment Redesign: Concrete shifts in leadership levers from CI/CD friction to incentive structures—that make the right decision the default, not a heroic exception.

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.

A framework for transforming an engineering team from a ticket-churning “feature factory” into a trusted strategic partner using specific rituals, product-mindset shifts, and outcome-based metrics.

Many engineering teams fall into the trap of becoming a “Feature Factory.” We become highly efficient at shipping code but remain disconnected from the business value it creates. With the advent of AI and LLMs commoditizing code generation, this “order-taker” model is becoming obsolete. The future belongs to teams that provide strategic insight, not just faster syntax.

In this session, I will share my experience at one of UK’s major media organisations, where I led the transformation of a fragmented engineering team into a high-performing strategic partner for the Marketing department. We moved from a transactional relationship defined by urgent tickets to a collaborative partnership defined by shared business goals.

This talk is for any leader who wants to stop managing a service desk and start leading a strategic engineering function. You will leave with a playbook for building teams that don’t just write code, but build the business. This ensures your human talent remains indispensable in an AI-augmented world.

Key takeaways

• Techniques to unify a fragmented team and establish strategic purpose and a culture of ownership.
• Methods to shift engineering focus from output (velocity) to outcome (business value) to future-proof the team against AI commoditisation.
• A framework for building trust with non-technical departments (like Marketing) to move from order-taker to advisor.
• Metrics that successfully demonstrate engineering maturity and impact to business leadership.

Post-incident reviews often focus on timelines and technology, limiting learning. This talk shows how applying the Social Psychology of Risk helps leaders surface hidden psychological and cultural factors, improving understanding, trust, and organisational resilience.

Post-incident reviews often converge on familiar outputs: a timeline, contributing technical factors, insights into system behaviour, and a set of follow-up actions – frequently centred on monitoring, alerts, or process changes. While valuable, these outcomes rarely deliver the deeper learning needed to improve long-term individual and organisational resilience. They focus on what happened in the system, rather than how people experienced the incident while operating in its inception, moment of impact and recovery.

To learn more effectively from incidents, engineering leaders must extend their practice beyond the physical language of systems, events, and actions, and intentionally explore the psychological and cultural dimensions that shape technical and non-technical decision-making and attitudes to risk. This talk demonstrates how the Social Psychology of Risk (SPoR) can be applied to post-incident reviews to achieve deeper, kinder, and more meaningful learning.

Using the lenses of Workspace, Headspace, and Groupspace, the session shows how leaders can build stronger connections with review participants and surface often-hidden contributing factors. Most incident discussions remain in Workspace: tools, constraints, signals, and procedures. By also exploring Headspace (what people noticed, believed, felt, and prioritised) and Groupspace (relationships, hierarchy, norms, and power dynamics), leaders gain insight into how risk was perceived, decisions were made, and why actions made sense at the time.

Through real incident examples, attendees will see how subtle influences – such as confidence, doubt, incident history, and organisational pressure – shape decisions long before any “root cause” appears on a timeline. The talk demonstrates practical techniques for asking better questions, listening more effectively, and creating the psychological safety required for people to articulate these factors without fear or blame.

The talk will include experiential learning via a simple group exercise and reflective discussion. Attendees will leave with concrete approaches for facilitating post-incident reviews that go beyond technical analysis, strengthen leadership effectiveness, improve decision-making, and build teams and systems that are more resilient because they are better understood.

Key takeaways

• What the Social Psychology of Risk is and why it matters in post-incident reviews.
• How to use Workspace, Headspace, and Groupspace to analyse incidents more deeply.
• Practical questioning and listening techniques that surface psychological and cultural influences without blame.
• How these insights improve leadership effectiveness, decision-making, and organisational resilience.

The systems we build always come with considerations and trade-offs. But are we considering the right ones? Let’s step through a system design process from start to finish with real world users in mind, iterating along the way to maximize effectiveness and minimize blast radius. There will be twist, turns, and threat models. What happens next is up to us.

Attendees will come away with different understandings of how to think about the systems they build, and practical knowledge of how to build their systems better to reflect those understandings.

Detecting anomalies sounds simple–until real client traffic enters the picture. I’ll share how we learned to spot volume and conversion dips that matter, tune out the noise, and turn detection into trust.

When we first started looking for anomalies in our payment metrics data, the goal was simple: catch issues before clients did. The reality, of course, wasn’t that simple.

Our first version looked only for “volume zero” – complete outages. It worked for big events, but we quickly realised most of the pain lived in the subtle dips: the 10% drop at lunchtime, the steady weekend decline, the provider that failed only for one type of payments or even device. None of that showed up in the old alerts.

So we built something smarter. We started calculating a predicted line for each client, based on the data we hold – recognising that every one of them has their own traffic rhythm. Then we added anomaly lines above and below it to capture what “too high” or “too low” really means in their context. It wasn’t perfect, but with every iteration, the framework got better at noticing the right things, not just everything.

This talk is about how we evolved the way we use our data: how we went from total outages to anticipating small dips, from arguing over false alarms to trusting our signals. I’ll share what worked, what didn’t, and how this journey taught us about technical patterns.

Key takeaways

• Start simple, then evolve with what your data actually teaches you.
• Predicting traffic wasn’t the hardest part; agreeing on what’s normal was and how to alert on proper anomaly.
• We learned to separate signal from noise by measuring burn rate and treating false positives as feedback, not failure.
• Collaboration between engineering and CSMs was key – alerts only work if the people closest to clients can understand and act on them.
• Building detection wasn’t just about models; it was about creating shared trust in what “an anomaly” really means.

At Cursor, we’re on the edge of the edge: we’re both builders and heavy users of AI-assisted development tools, which means we feel the gap between “it seems to work” and “we trust it enough to ship” more acutely than most. We’ve spent a lot of time trying to close that gap — building evals, interpreting usage data, and navigating the surprisingly tricky question of how to train and deploy models when your feedback signal is noisy and your users have very high expectations.

This talk gives an honest look at where we are: what our validation process looks like today, what the data from millions of engineering sessions has taught us, where it’s left us with more questions than answers, and what we wish we’d known earlier about the operational realities of running our own models.

If you’re building in this space and finding that the standard playbook doesn’t quite fit, this one’s for you.

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

Building reliable systems is a core tenet of good engineering. Yet, when reliable components are glued together, deviant behaviour often emerges. These can manifest as tricky bugs that take significant time and effort to identify, or broader incidents that hamper availability. Reliability needs to be considered across the sum of all parts rather than in just individual components.

The Monzo engineering teams have built the UKs largest digital bank from scratch over a period of many years. In this talk, Matej discusses lessons learned and the properties engineering organisations need to have to build and maintain reliability at the core.

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.

Regardless of if someone is going through hypergrowth, just onboarding their first customers, or has already scaled ten times over, this talk will cover how to not let perfect get in the way of good when on a tight timeline, and how “more time” needs to be paired with removal of bias towards existing patterns, continuous cross-functional advocacy, and strong metrics and milestones to drive success.

“If you build it, they will come” works great for sports fiction, but the reality is we don’t start out building for scale – we build to see if it works first. For some, the scale never comes. For one telehealth company, the scale came pretty much overnight – and we fumbled it pretty hard.

In this talk, we’ll follow the story of how to prepare for high scale (and the gotchas that got us) with a scrappier approach in a seven-day timeframe, and how having more time alone didn’t guarantee us the win next time around. We’ll dive into the playbook for scaling the architecture while operating it in parallel – not only the services and tools, but also the larger technical strategy and cultural shifts that were required to break us out of our structural slump and help us score a major scaling goal.

When approaching scaling challenges (or any large system-wide architectural challenge):

• Start somewhere – don’t let perfect be the enemy of good
• More time does not mean better outcomes on its own
• Understand your critical path and follow it from start to finish
• Find your guiding metric/north star and measure against it regularly and consistently

We will discuss load testing tooling, automation approaches, system benchmarking, as well as organizational/technical strategy elements.

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

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.

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

Incident response processes can disproportionately disadvantage neurodivergent engineers. This talk shows how small, intentional changes to incident management can reduce cognitive load, support neurodivergent engineers, and improve reliability for everyone.

When incidents happen, on-call engineers are expected to reason about complex systems under intense time pressure, ambiguity, and social stress. Yet most incident management practices quietly assume strong working memory, rapid context switching, comfort with implicit rules, and emotional resilience under impact escalation. Those assumptions disproportionately disadvantage neurodivergent engineers.

ADHD responders pay heavily for context switching and memory load. Autistic responders are forced to infer implicit expectations under stress. Anxious responders face amplified threat perception when escalation, severity, or stakeholder expectations are unclear. The current processes also increase operational risk for teams as a whole. Unclear ownership, emotional escalation, misunderstood decisions, mistaken actions, fragmented communication and missed handoffs are not just human problems; they are systemic problems.

This talk reframes incident management as a designed system, not just a runbook. If anything, the more complex and detailed a runbook is written, the quicker it gets out-of-sync, becomes inconsistent, and too overwhelming to read. Drawing on real incident patterns and leadership experience from various organisation sizes and structures as a neurodivergent engineer, this talk explores how cognitive load, ambiguity, and emotional pressure show up during incidents and how leaders can redesign response processes to be more predictable, explicit, and humane without slowing teams down.

Attendees will learn practical, low-cost changes they can make immediately: reducing cognitive complexity in runbooks and alert descriptions, making expectations explicit, eliminating backchannels (with a caveat), narrating visuals and metrics, defining severity by impact rather than emotion, allowing emotional processing (separately from execution), permission to slow down/have a break/hand over, designing clearer on-call and recovery practices, and building the incident management muscle memory through trainings, game days/hours and shadowings. These changes improve inclusion, decision-making, and system reliability at the same time.

Key takeaways

• A new way to look at incident management as a socio-technical system with cognitive constraints
• Concrete practices to reduce cognitive load during incidents
• Leadership tools for building incident response skills across diverse teams and brains

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”

Every architecture tells a story, and most tragedies begin with messy data. This talk shows how clear ownership, contracts, and events can turn complexity into clarity and evolution into design.

We often blame the shape of a system for its troubles: “It’s the monolith,” or “We moved too slowly to microservices.” In practice, the rot sets in earlier and deeper. It begins when anyone can write to any table, when cross-domain joins sneak into hot paths, when lifecycle and retention rules are inconsistently applied, and when teams share a database but not a vocabulary. The result is a system that erodes from the inside out. Not because it is a monolith, but because ownership ends at the code and never reaches the data.

This talk argues that data must be the structuring force of architecture. We will journey with Penultimate Markets, a global marketplace that scaled from a single deployment to a distributed platform, and see how disciplined data ownership shaped every step. In the monolith phase, aggregates anchored transactional boundaries; write logic lived inside the owning domain; other teams consumed contract-based read models rather than reaching into tables. Architectural fitness functions made these rules executable: blocking cross-domain joins, enforcing expand/contract migrations, and validating event and read-model contracts continuously.

As the platform expanded, different domains began to pull outward. Search needed low-latency regional scaling; tax required immutable records and long retention; payments demanded isolated failure domains and stricter SLAs. Instead of a flag day, the same data-first discipline guided decomposition. Seams defined by aggregates, events, and read models became extraction boundaries. Autonomy followed data ownership; duplication became intentional; consistency was managed with explicit choreography or orchestration rather than sprawling transactions.

The point is not to romanticize monoliths or glorify microservices. It is to show that architectures endure when teams align on data lifecycles, not just APIs. If you can define, defend, and evolve data boundaries, your monolith will remain modular longer, and your inevitable decompositions will be evolutionary, not traumatic. You leave with pragmatic techniques you can adopt on Monday: encode ownership, publish contracts, verify them in CI, and make migrations safe by design. Do this, and your system will grow with your business rather than against it.

Key takeaways

• How to treat aggregates as transactional boundaries and keep writes local to the owning domain
• How to replace table access with contract-based read models to decouple evolution
• How to use events and process managers to coordinate cross-aggregate workflows without big transactions
• How to enforce discipline with architectural fitness functions focused on data, not just code
• How to recognize when data lifecycles and governance push you beyond the monolith and how to decompose along existing seams”

A case study on taming extreme tech sprawl of 90 K8s clusters, 11 databases technologies, 4 SDLCs. I’ll share how our ‘One PR, One YAML’ tool, Orchestra, created one golden path to operational leverage.

How does tech sprawl happen? You wake up one day to find your organisation is running 90 Kubernetes clusters, supporting 11 different database technologies, and trying to manage 4 distinct, incompatible SDLCs. That was our reality. This is the case study of Dojo’s journey from chaos to centralisation.

The cost of this sprawl was enormous: disparate security implementations and reliability practices, and a developer experience full of friction. This talk details our “”Platform Leap”” on a strategic initiative to centralise by building the Dojo Creator Platform and treating our internal platform as a first-class product.

The catalyst for success was Orchestra: our ‘One PR, One YAML’ workload specification and CLI. This single, self-service abstraction became our “”golden path.”” It allowed us to enforce reliability, quality, and security standards by design, not by committee.

This platform leap solved our sprawl problem and delivered immense operational leverage. By enabling true self-service, we allowed our engineering organisation to scale, delivering more features with less friction and without a linear increase in platform team overhead.

Key takeaways

• Learn how to quantify and communicate the high cost of tech sprawl (e.g., “90 clusters”).
• See how a ‘One PR, One YAML’ abstraction (Orchestra) can drive platform adoption and developer self-service.
• Understand how to enforce “golden paths” to consolidate sprawl and measurably improve reliability and security.
• Gain a blueprint for achieving true operational leverage and scaling your engineering org efficiently.

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.

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.

Sponsored by

AI tools now write the majority of code at incident.io. Every engineer uses them, and the acceleration is real. But getting here was harder than anyone expected, and the hardest parts had nothing to do with the tools themselves.

I’ve spent the last year watching this shift across our engineering team. We went from early skepticism to a messy middle–some engineers seeing huge productivity boosts while others barely engaged–to eventually getting the whole team on board. It took real investment to get there, and just installing the tools was the easy part.

How do you maintain engineering standards when AI writes most of your code? How do you onboard new engineers when leaning on AI too early means they never learn the system? What do you do when half your team is flying and the other half feels left behind?

The ROI of almost all typical software tasks needs to be reconsidered. For example: we document our codebase more thoroughly than ever, because AI can’t follow conventions nobody wrote down. We’re codifying standards we kept in our heads for years so we can automate review. And we’ve learned that the time AI frees up might be its most valuable output — not to ship more, but to spend more time with the product, testing and scrutinising what’s being built rather than rushing to the next thing.

In this talk, I’ll share what worked, what didn’t, and what we still haven’t figured out. You’ll see how we closed the adoption gap across our team, the cultural norms we built around responsible use, and the uncomfortable trade-offs that come with going all-in. Everything you need if you want not only to go fast, but to keep going.

Go deeper on the leadership challenges that matter most right now

DirectorPlus workshops are designed for senior engineering leaders who want more than surface-level discussion. In these focused, highly interactive sessions, you will work alongside peers facing similar organizational, technical, and people challenges. Together, you will pressure-test ideas, explore real-world scenarios, and exchange candid perspectives drawn from lived experience.

Guided by seasoned engineering leaders, these workshops create space for practical problem-solving, honest reflection, and shared learning. You will leave with concrete takeaways, sharper decision-making frameworks, and strategies you can confidently apply back at work.

Tackle tough leadership challenges with your peers

An essential part of the conference experience is networking and learning new things. However, opportunities for problem-solving can be limited. Join our Director+ roundtables and engage with your peers, learn from one another, and collaboratively address some of the most pressing challenges you face in your roles. 

Hear what strategies have been effective and which ones have not, and gain valuable insights and knowledge that aid your decision-making.

Join fellow DirectorPlus leaders for a relaxed networking coffee designed for real conversation. This is your chance to connect with peers, swap stories, and discuss the realities of leading at scale, all in an informal, pressure-free setting.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

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.

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

Building great software comes with unique challenges in every industry, and often, the best insights come from others who are in the same boat. Join our relaxed sessions where you can meet peers working in similar domains to share ideas, collaborate on challenges, and exchange solutions.

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

With great change comes great uncertainty. Sadly, the resulting pace + pressure combination often means well-intended feedback derails even our best people. When it goes catastrophically wrong, the whole team is affected – seriously risking our ability to deliver quality at speed, in the exact moments we need everyone at the top of their game.

So let’s have a serious conversation about how we fix feedback in high-stakes environments.

Led by Ceri Newton-Sargunar – neuroscientist, experienced senior leadership coach and team dynamics specialist – this session offers you a unique opportunity: invaluable facilitated peer exchanges, informed by in-the-moment crucial insights from behavioural science and neuroscience.

You’ll leave the room with a clear understanding of exactly why feedback conversations go wrong, and how to guard against it. And you’ll walk into your next conversation confident, better-equipped to stop things falling apart, and keeping your team focused on the goal rather than the drama.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

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.

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

Building great software comes with unique challenges in every industry, and often, the best insights come from others who are in the same boat. Join our relaxed sessions where you can meet peers working in similar domains to share ideas, collaborate on challenges, and exchange solutions.

Budgets are strapped. Spend is fixed. Every penny has to be signed off in a process that can take weeks – so how on earth do you motivate people to do well, without using a financial reward?

This solution swap will explore exactly that: tips and tools from your peers, plus insights from behavioural science to help you find the options that are best for you, your people, and your organisation. We’ll look at motivation, accountability and ownership, preventing disengagement and “quiet quitting” so you understand what helps create engagement – and what might trip you up.

Facilitated by Ceri Newton-Sargunar, experienced senior leadership coach, behavioural scientist and team dynamics specialist, You’ll walk away with a page full of notes, your head full of ideas, and some practical steps to take when you get back to your team.

Your team has been working flat out for the last 4 months delivering a set of projects for your company. The projects are taking longer than originally expected and tensions are beginning to rise, particularly with the Sales and Customer Success teams.

You are spending more and more of your time getting asked about when the projects are going to be delivered.

In your 1-1 with your CEO, they open the conversation by telling you that they need you to get your teams to deliver these projects faster.

How do you respond?

As Engineering Leaders, many of us will recognise this scenario from similar situations that we have encountered in our own careers.

In this session, we explore the different ways that you can respond. We will think about how to turn a conversation like this into an opportunity to build trust, clarity and transparency.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Sponsored by

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

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

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

Building great software comes with unique challenges in every industry and often, the best insights come from others who are in the same boat. Join our relaxed sessions where you can meet peers working in similar domains to share ideas, collaborate on challenges and exchange solutions.

You are approached by a member of your team who says that they think that they deserve to be promoted to be a manager position. You don’t think that they are ready to make this change yet. You are worried that, if you did promote them, that they and the team that they managed would suffer.

What do you do next?

As Engineering Leaders, many of us will recognise this scenario from similar situations that we have encountered in our own careers. In this session we explore how we can turn a conversation like this into an opportunity to build trust, clarity and transparency.

Members of your team have been complaining, for some time, that ‘technical debt’ is making it harder and harder for them to work on your code base. You have spoken to your leadership team about slowing down development so that you can pay off some of this ‘technical debt’ on a number of occasions but are always told that you must prioritise the new features that have been committed to on the product roadmap.

You are worried that the experience for your team is only going to get worse and feel powerless to change this dynamic.

What will you do to improve the situation?

As Engineering Leaders, many of us will recognise this scenario from similar situations that we have encountered in our own careers. In this session we explore the different ways that you can respond to a situation like this and how to turn it into an opportunity to build trust, clarity and transparency.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

Join facilitated conversations and dive into key issues facing engineering teams

There’s never a single silver bullet for any problem and often you’ll need to combine the ideas of multiple people to find the perfect solution for your team. We’ll be discussing some core issues in the Table Talk sessions, hosted by a group of engineering leaders who are on hand to provide their perspectives and help guide the conversation. You can dip in and out of discussions depending on what interests you the most.

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.

Connect with folks over shared experiences

Building great software comes with unique challenges in every industry and often, the best insights come from others who are in the same boat. Join our relaxed sessions where you can meet peers working in similar domains to share ideas, collaborate on challenges and exchange solutions.

Trade tactics for tackling everyday challenges

Sometimes it can feel like every problem has only one answer – but the truth is, in leadership there’s never a single solution. But when you’re in the thick of a problem, it can be hard to get the headspace to see other ways to tackle a challenge. 

In our solution swap sessions, attendees will get the chance to say how they’d tackle a common issue and compare their ideas with how other leaders would confront the same problem. Our coaches will give direct feedback about the possible consequences (both positive and negative) of the ideas – and will ask the key question – if you were to do this, and then this happened – what would you do next?

Trade tactics for tackling everyday challenges

Sometimes it can feel like every problem has only one answer – but the truth is, in leadership there’s never a single solution. But when you’re in the thick of a problem, it can be hard to get the headspace to see other ways to tackle a challenge. 

In our solution swap sessions, attendees will get the chance to say how they’d tackle a common issue and compare their ideas with how other leaders would confront the same problem. Our coaches will give direct feedback about the possible consequences (both positive and negative) of the ideas – and will ask the key question – if you were to do this, and then this happened – what would you do next?

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.

Dedicated sessions on how to take the next step in your career for tackling the role of a Tech Lead

Dedicated sessions on how to take the next step in your career for making the leap to Engineering Manager