A welcome from the host.

What we measure shows what we value. The metrics dominating the AI conversation — token spend, AI-generated lines of code, PR count — tell us that we value speed and volume from individual developers. But leaders want organisation-wide change with AI, challenging themselves to move beyond AI-as-automation and instead integrate AI into organisational workflows and decision-making. There’s a gap between what we’re counting and what we want to achieve.

Drawing on industry research, Laura Tacho explores how leaders should shift their approach to measuring the ROI of AI tools, moving from output-based metrics toward frameworks that capture what AI actually makes possible: better decisions, faster learning, and expanded cognitive capacity across teams.

You’ll walk away with new mental models for thinking about AI’s impact on your organisation, pragmatic guidance for evolving your measurement approach, and a clearer picture of what the organisations seeing real results are doing differently.

AI-assisted development increases code generation speed faster than teams can fully understand or reason about systems, creating a new form of technical debt driven by accumulating complexity, inconsistent abstractions, and loss of design intent.

This talk explores how AI shifts software failure modes and why traditional safeguards like code review and architecture governance struggle under high-velocity generation.

Attendees will leave with practical approaches to mitigate AI-driven debt, including strengthening system boundaries, improving review signals, and building feedback loops that preserve architectural coherence at scale.

For years, shipping AI products meant relying on a narrow group of specialists — data scientists, ML engineers, researchers. At GetYourGuide, we made a different bet: with the right platform and the right enablement, regular software engineers can build production-grade AI products too.

In this talk, Mathieu Bastian, Principal AI Engineer, shares the journey of building an AI Platform that shifts AI development into the hands of the broader engineering organization. He’ll walk through the programs put in place to enable this shift, the cultural and technical challenges along the way, and the honest learnings from leading this transformation.

For the past decade, platform engineering has helped organizations manage the complexity created by cloud computing, microservices, containers, and Kubernetes. While these technologies increased engineering productivity, they also introduced new layers of operational and organizational complexity. Platform teams emerged to help organizations absorb that complexity safely through standardization, self-service capabilities, and shared infrastructure.

AI is creating a similar shift, but at a fundamentally different scale.

For the first time, software artifacts, infrastructure definitions, workflows, documentation, and even architectural implementations can be produced faster than organizations can fully understand, govern, and operate them. As AI dramatically lowers the cost of creating software, it also lowers the cost of creating complexity.

The challenge facing engineering leaders is no longer simply how to deliver software faster. It is how to prevent complexity from growing faster than the organization’s ability to absorb it.

This talk explores why complexity absorption is emerging as one of the defining engineering challenges of the AI era. Drawing on lessons from platform engineering, it examines how traditional approaches to ownership, architecture governance, and operational control begin to break down when implementation becomes nearly effortless.

The session introduces a practical framework for understanding organizational complexity and argues that platform teams are uniquely positioned to help organizations address it. Attendees will learn how platform organizations can make complexity visible through service catalogues and ownership models, use AI agents to improve architectural understanding and operational knowledge, establish guardrails that limit unnecessary complexity, and develop new mechanisms for evaluating the long-term operational impact of technical decisions.

Rather than focusing solely on helping teams build software faster, platform engineering must evolve toward helping organizations maintain clarity, ownership, and trust in increasingly complex systems.

Attendees will leave with concrete ideas, practices, and platform capabilities they can apply immediately to help their organizations scale safely in a world where creating software is becoming easier than understanding it.

Darragh Curran has spent over a decade building Fin’s engineering culture, and he knows what it takes to ship quickly while keeping things running smoothly. As CTO, he leads the teams behind hundreds of deployments a day across thousands of hosts and clusters. Before Fin, he built his experience at companies ranging from early-stage startups to Amazon and IBM, so he has seen speed and scale from every angle. Darragh doesn’t just talk about shipping fast, he built the systems that make it possible. Hear what he has to say in his talk, Acceleration with AI.

How we scaled review quality across 200+ engineers with AI instead of more reviewers — the build-vs-buy call, company-specific rules, the cost story, and the adoption fight.

Code review doesn’t scale linearly with headcount. At 200+ engineers it becomes the single biggest delivery bottleneck — senior engineers burning a third of their time on the same repeated comments, and a handful of domain experts becoming gatekeepers for whole feature areas. This is the case study of how we scaled review quality with AI instead of more reviewers.

It’s a leadership story as much as a technical one. We start with the build-versus-buy decision: we evaluated four AI review tools, and the honest twist is that our formal evaluation’s winner wasn’t what we shipped — the eval was right about features and wrong about what mattered in production. From there: building a custom integration layer when no off-the-shelf tool fit, encoding our own security and architecture standards into the AI so its feedback earned trust, and running the whole thing at roughly $200/month against $40–80K/year SaaS quotes.

The hardest part wasn’t the technology — it was adoption. I’ll cover how we measured whether the AI’s comments were actually helpful (a simple feedback loop), and the moment we knew it worked: another team adopted the system on their own, with no mandate from leadership. Attendees leave with a practical framework for introducing AI into their review process — what to automate, what to keep human, how to measure it, and how to drive adoption across an organisation that’s seen plenty of tools come and go.

Key takeaways

• A build-versus-buy framework for AI code review — and why the “best” tool on paper may not be the one you ship.
• How to encode your own security and architecture standards into AI review so engineers actually trust it.
• How to run AI code review at scale for ~$200/month instead of $40–80K/year.
• How to measure whether AI feedback is genuinely helpful, with a lightweight feedback loop.
• What organic, un-mandated adoption by another team tells you about a tool’s real value.

For decades we’ve celebrated and emphasised deep focus work, and have documented countless downsides of multi-tasking. The AI era is flipping this, we need to find sustainable ways to get ahead.

For decades we’ve celebrated and emphasised deep focus work, and have documented countless downsides of multi-tasking. The AI era is flipping this. In a world where we can kick off several parallel agents, the bottleneck moves from execution to context-holding, and the skill of being able to multi-task and switch context deliberately rather than reactively is becoming increasingly important.

As Engineering Leaders, some of this is a natural part of the role. Holding a dozen threads at once, stealing minutes between back-to-back meetings to pick up action items, trying to balance the cognitive load of thinking about too many things with active listening in our 1:1s. Some of us are wired for it, some of us have learned the hard way. The job that used to look like distraction is starting to be leverage, and, it’s a skill we should be developing on purpose rather than discovering under pressure.

In this talk, I want to share what I’ve learned from years of doing this work across multiple product areas: how to chunk time, how to switch context deliberately rather than reactively, how to load and unload context quickly, and, how to leverage the tooling we have at our disposal in the AI Era to get really good at this.

Key takeaways

• A reframe of context-switching as a deliberate skill, not a productivity cost.
• A practical toolkit for managing context across many threads: how to chunk time, switch deliberately, and load and unload context fast.
• A new appreciation for the workarounds you’ve built driven by necessity, and why they’re turning out to be critical skills.

When a production AI agent hallucinated, the true crisis wasn’t technical—it was organizational. Discover the battle-tested governance playbook we built to map accountability and safely deploy high-stakes automation anywhere.

Every engineering leader has shipped something that kept them up at night. In most industries, a bad release means a degraded UI or a temporary drop in conversion metrics. In healthcare, it means something else entirely.

This case study details the rollout of AI agents into clinical workflows handling prior authorizations, discharge summaries, and medication triage across more than 2 million patient interactions annually. Built on AWS Agent Core with Agent Squad orchestration across specialised clinical agents, the architecture was sound — the ownership model was not.

Three weeks into production, a discharge-summary agent hallucinated a medication continuation instruction. No patient was harmed, but the fallout was immediate: clinicians lost confidence, overrides skyrocketed, and our engineering teams entered a finger-pointing loop. Platform engineering, ML, and clinical operations had all assumed someone else held final escalation authority. Nobody did.

This talk shares the operating playbook we built to pull our AI system out of crisis and back into production safely — and more importantly, to make sure we never ended up in that room again. We’ll cover how we drew strict ownership boundaries for agentic systems where no single service owns the full outcome, how we engineered human-in-the-loop patterns that preserve genuine accountability without becoming rubber stamps, and how we rebuilt clinical trust through review structures that gave humans meaningful control rather than the illusion of it.

The governance framework that came out of this incident has since been adopted by two teams outside healthcare entirely — because it turns out, regulated AI is just a more honest version of the AI governance problem every engineering leader is quietly avoiding.
You do not need to work in healthcare for this talk to matter- this is a blueprint for any leader deploying high-stakes automation.

Key takeaways

• A reusable playbook for defining escalation authority before an incident forces the conversation.
• A decision-ownership model for agentic systems where multiple specialised agents share a workflow but no single service owns the final outcome.
• A governance structure for regulated AI that gets systems out of endless pilot phases and back into production with organisational sign-off.
• A trust-rebuild framework for restoring stakeholder confidence after a high-stakes AI incident — applicable far beyond healthcare.
• A human-in-the-loop design pattern that preserves genuine clinical accountability without collapsing into rubber-stamp override behaviour at scale.

We build systems to scale, evolve, and survive failures – but rarely to tell us when they are ready to die. This talk explores why “letting go” should become a strategic engineering capability.

Modern engineering organizations are incredibly good at creating software. We can spin up services in hours, generate code with AI, and track growth through sophisticated KPIs. But most organizations still have no mature way to answer a much harder question:

“How do we know when something should stop existing?”

For years, the software industry optimized for growth. Today, many organizations face a different reality: shifting markets, flatter structures, shrinking capacity, and increasing operational pressure. Meanwhile, AI is lowering the cost of generating code faster than we can sustainably maintain it.

The result is an uncomfortable asymmetry: we create software faster than we can build the capacity to understand, operate, simplify, and retire it.

At XING, this tension became impossible to ignore as we tried to sustain a legacy ecosystem while simultaneously reducing complexity across the organization. We uncovered a cultural blind spot: we nurture systems to scale, evolve, and survive failures — but rarely to tell us when they are ready to die.

Systems quietly become immortal. Operational burden becomes invisible.

AI didn’t create this problem, but it made the gap impossible to ignore. As software creation accelerates, we are suddenly forced to ask questions our systems were never designed to answer:

How sustainable is this long term? What is the real cost of keeping it alive? How do we know when complexity outweighs value?

These shouldn’t be reactive questions asked only during organizational pressure. They are questions we should design our systems and organizations to answer from day one.

In this talk, I’ll share the technical, operational, and emotional realities of treating “letting go” as a core engineering capability: what worked, what failed, and how we started shifting our culture to see simplification, retirement, and reduction as necessary parts of sustainable engineering.

This is not a talk about deleting software. It’s about creating systems that can tell us when they are no longer worth carrying.

Takeaways:

• The uncomfortable realization that your organization may already be carrying more software than it can sustainably understand, operate, or retire
• Practical signals that systems, services, or platforms are becoming “immortal”
• Ways to make simplification, retirement, and lifecycle thinking part of sustainable engineering culture
• The psychology of “less”: how to counter emotional attachment to systems, reframe retirement as capacity creation, and reward simplification instead of accumulation

Discover how building an AI platform and driving cultural change helped Personio go from flashy hackathon demos to shipping reliable AI products

The gap between a flashy demo and a reliable AI product is full of work nobody talks about. At Personio, we discovered this the hard way.

Our VP of Data gave us a mandate to embed AI into how we work. We ran a hackathon, shipped 5 MVPs of internal AI products, and got genuine excitement from stakeholders. Six months later, adoption was near zero, and the projects that did get used led to an unexpected spike in LLM token spend.

As a Staff Data Scientist leading AI and data product development at Personio, with no direct reports, I had to find a way to drive change without authority.

I will share what we actually did: building a shared AI platform so the team could build on each other’s work rather than starting from scratch, embedding agent evaluations in the team’s workflow, and increasing the org velocity through experimentation.

Key takeaways

• What it takes to go from flashy AI demo to a finished product your users will love
• How to influence your org for deeper AI investment through early imperfect projects
• Practical techniques for evaluating AI products against business value

Organisations conflate three definitions of “good” engineering management: what’s rewarded, what works, and what’s ‘right’. Telling them apart builds careers resilient across business cycles, and explains why the AI shift feels so disorienting.

“Good management” has always been a debate in the technical community, but the rise of AI-driven redundancies has put a spotlight on middle management and non-technical leadership. When Big Tech makes dramatic shifts, other organisations are tempted to follow suit, sometimes without considering their individual context.

AI is forcing a step-change across technical ways of working with cultural implications. Leaders need to reconsider what “good management” means, or risk the definition happening to them; changing workflows, team structures, and fundamental expectations about technical leadership. However, this isn’t the first time… what counts as good management shifts with business cycles, not because of moral evolution, but because business needs change.

In the early 2000s, good managers navigated organisational politics and left engineers alone. In the 2010s when money was cheap, good managers stopped coding to focus on attracting and retaining talent. In the 2020s, as cheap capital dried up, good managers are expected to be hands-on again as organisations flatten for efficiency. Now some suggest software engineering itself may become more like ‘agent management’, looking less like traditional development and more like coordination.

Each era ended up creating a philosophy that explained why these approaches mattered. The 2010s framed delegation as “empowering engineers is fundamentally good,” not “capital is cheap, hire aggressively.” The 2020s frame technical depth as “bureaucratic management has made us stale,” not “funding ended, cut costs.” These narratives can become leadership identities rather than operating models, making it harder to see what’s actually driving change.

The confusion comes from conflating three types of “good”:

• Performative good – what gets rewarded right now, or by your company.
• Contextual good – what works given current reality, often specific to your org.
• Moral good – what *you* believe is right, often internalised narratives from your formative era.

The AI shift compounds this challenge. While business cycles are cyclical, technological complexity only accumulates – Cloud, distributed systems, AI – each raised the baseline for what understanding systems means.

This talk provides frameworks for distinguishing what’s actually happening from the stories we tell ourselves, identifying which skills are foundational versus era-specific, and building careers resilient across inevitable future shifts.

Key takeaways

• The three-goods framework (what’s rewarded, what works, what’s right) reveals where your context and your values are out of sync.
• Your management instincts are calibrated to the era you trained in, not necessarily the one you’re operating in now.
• Distinguishing era-laundered habit from genuine conviction requires naming the conditions under which you formed each belief.
• Conflicts about “”good management”” often reflect era mismatches, not skill gaps; your peer may simply be right about a different context.
• How to identify which skills compound across eras, so you invest your development time where it survives context change.

How to find real human candidates in the hackstack of AI applications.

I never thought I’d miss the days of reviewing terribly designed and grammatically lacking resumes for engineers, but in 2026 here I am. AI has offered great efficiencies in hiring – but it’s become impossible to differentiate good candidates from bad ones, let alone humans from AI bots. Our hiring pipelines have become AI against AI, and no one is winning. If you’ve struggled to hire, or even interview, a real person, I invite you to learn from my strategies of how to recruit, filter, and find real people to join your engineering teams. I’ll present real ATS data of trying to hire a Principal Engineer in 2026, share tips for helping human candidates punch through the application noise, and present strategies on how to monitor changes in patterns of AI verbiage as they evolve. (looking at you, emdash)

Takeaways:

• Understanding how AI has impacted the hiring landscape
• Building empathy for candidates trying to find work
• Gaining strategies to filter and interview real candidates
• Resources to give to non-technical recruiters to help with screening

This talk reframes burnout as a systems failure and applies SRE principles to design sustainable, high-performing engineering teams.

Is your team’s health as observable as your software?

High-performing engineering teams are celebrated for their velocity and “whatever it takes” commitment. Yet, these same traits often make them the most vulnerable to a predictable, systemic failure mode: burnout.

This isn’t a lack of individual grit; it’s a design flaw. When we architect software for 99.9% uptime but run our teams at 100% capacity, we create a system with zero fault tolerance. In this talk, we move beyond the superficial “resiliency” narrative and analyze team health through the lens of systems engineering.

We will explore how to apply SRE principles (like load shedding, redundancy mechanisms, and leading indicators) to the human element of the stack. You’ll learn why “idle capacity” is the secret to low latency, how to make cognitive load visible, and how to build a system where high performance doesn’t require a “hero culture” destined for a catastrophic outage.

Key takeaways

• Burnout is a systems failure, not a people problem.
• High performance requires slack, not heroics.
• Boundaries only work when the system enforces them.

Coding agents like Claude Code are reshaping how your team ships software, but how are you evaluating them? This talk is about using OpenTelemetry to measure their real impact on DORA metrics.

I tried out viral Claude Code ‘hacks’ and measured how effective they really are.

Agentic coding tools like Claude Code have inserted themselves into the critical path of software development. But we were still evaluating our vibe coding the same way – on vibes. This doesn’t scale across an organisation.

We realised there’s a hidden layer: your development workflow is now observable. You can measure how software gets built, not just what gets deployed.

How? These tools aren’t just generating code, they’re emitting OpenTelemetry data like token usage, latency, acceptance rates, and pull request counts. But most teams aren’t capturing it, so they’re flying blind while these tools shape delivery performance and DORA metrics. By observing your coding agents, you can understand their real impact: where they accelerate delivery, where they introduce risk, and how they affect lead time, change failure rate, and MTTR.

In this talk, I’ll show how we started treating coding agents as production dependencies, not assistants, and share what we learned, what didn’t work, and how we’re getting the most value from this data.

The teams that get the most value from AI won’t be the ones using it the most, they’ll be the ones who can see and optimise what it’s doing.

Takeaways:

• What data leaders should measure
• How leaders can use this data to improve delivery performance
• How to answer questions like: Is AI actually making us faster? Where are we introducing risk? Which tools are worth standardising on?

A hands-on case study of how one Engineering Manager rebuilt their entire workflow—people development, product strategy, and project planning—by integrating AI tools into daily leadership practice at a hyper-growth sports-tech company.

Two years ago, I was drowning. As the sole leader of a brand-new product at Sofascore—a sports-tech company that had grown from 30 to 250+ employees in 3 years—I was doing market analysis, writing tickets, leading a cross-functional team, reviewing every pull request, and still coding half my week. I needed 60 hours to fit into 40. Something had to break, and I decided it wouldn’t be me.

This talk is the story of what I built instead: an AI-augmented Engineering Manager workflow that fundamentally changed how I lead people, products, and projects.

I’ll share three concrete transformations from my real experience launching Sofascore Fantasy (from a Croatian alpha test with 20K users to a global product in 2 years) and building out our NHL product coverage.

First step: People. How I moved from reviewing every line of code to coaching engineers through structured career plans—including my current 18-month plan to grow an introverted but technically brilliant engineer into a senior role. I’ll share how four engineers I hired as students from our Android Academy are now strong mid-to-senior contributors after years of intentional mentorship.

Second step: Product. How I used Claude, Gemini, and ChatGPT to conduct competitive analysis, map our data provider’s API coverage, run market-fit research, and cross-reference it with real UX research—giving me the clarity to make better prioritisation decisions, faster.

Third step: Projects. How I learned to draw the line on my own responsibilities, delegate with precision, and advocate for the hires that would make my team scalable—moving from “I do everything” to “I enable everyone.”

This is not a talk about AI replacing managers. It’s about a manager who was stretched to the limit, used AI to reclaim clarity, and became a better leader because of it. Attendees will leave with a practical, honest playbook they can start applying immediately.

Takeaways:

• Identify which parts of your EM workflow (research, planning, analysis) AI can meaningfully accelerate—and which it cannot replace (coaching, judgment, trust-building).
• Apply a practical framework for drawing the line on your personal responsibilities so you can delegate with clarity instead of guilt.
• Use AI tools to conduct competitive analysis, API mapping, and market research that would otherwise take weeks—compressing your strategic decision-making cycle.
• Build structured, long-term career development plans for engineers at different stages—from academy hires to senior promotions—using project-based coaching.
• Recognise the early warning signs of an unsustainable leadership workload and take concrete steps to redesign your role before burnout hits.

AI helps engineers ship faster, but makes learning harder to see. How do leaders mentor, assess growth, and build real competence when output no longer reflects understanding?

AI is creating a dangerous illusion: developers are shipping faster while learning less visibly. We’ve long relied on signals like questions, iteration, independence, and output to understand how engineers grow. But in an AI-assisted world, many of those signals are disappearing.

As someone leading teams using AI daily, I’ve seen this shift go both brilliantly and badly.

Some engineers accelerate their learning dramatically using AI to explore unfamiliar systems, test ideas, and build confidence faster than ever. Others become highly productive while quietly accumulating gaps in understanding that only surface later: in fragile decisions, unclear reasoning, or an inability to debug when things go wrong.

The challenge for engineering leaders is that the learning process itself is becoming harder to see.

Where junior developers once asked questions throughout their work, exposing their thinking as they went, managers now increasingly see only the final output: a polished pull request. When productivity no longer reflects competence, how do we know whether someone is growing or just generating?

This talk explores how AI is reshaping developer learning and what engineering leaders need to do differently in response.

Together we’ll explore questions many leaders are already wrestling with:

• When engineers stop asking questions, what signal replaces them?
• How do you distinguish AI-assisted output from real understanding?
• What new blind spots appear when managers only see the pull request?
• How do you coach deeper engineering judgment, not just faster delivery?
• And how do you create teams where learning stays visible?

Leaders will leave with practical approaches for mentoring, feedback, and capability-building in AI-enabled teams, helping engineers develop real competence, not just AI-assisted productivity.

Key takeaways

• Recognise why traditional signals of engineering growth become less reliable in AI-assisted teams.
• Learn how to distinguish AI-assisted productivity from genuine understanding and capability.
• Identify new ways to make learning visible when managers only see the pull request.
• Adapt mentoring and feedback to build engineering judgment, not just faster delivery.
• Spot the warning signs of hidden capability gaps before they become team risks.”

Culture can’t be mandated – it emerges from repeated interactions. This talk shares an experience-based framework for deliberately reshaping team dynamics through intentional changes related to people, processes, and behaviours.

Team culture is one of the most cited – yet least clearly understood – levers in engineering leadership. Everyone wants to change it; few have a clear model for how.

This talk starts with a simple, but powerful, reframe: culture is not values on a wall or a collection of team rituals. It is a pattern of repeated interactions that emerges from the interplay of people and processes. You can’t mandate or declare it with a slogan – but you can be deliberate about changing it.

Using a graph analogy, we model a team as a network, where people and processes are nodes, interactions are edges, and trust is the weight on those edges. This turns culture change from a vague aspiration into a set of concrete interventions:

• introduce structural nodes (new processes and people that create desired interactions)
• remove or reshape high-impact nodes (blockers, misalignments, or overloaded connectors)
• reinforce edges (through conscious choices about what to praise, tolerate, challenge, or ignore).

This isn’t theory. Over three years leading an engineering team responsible for one of Bloomberg’s core products, I applied this framework systematically to reshape a team facing common scaling challenges: context with fragmented ownership, uneven collaboration patterns, and a slowed hiring pipeline. Through deliberate changes to both team composition and process design, we reshaped interaction patterns across the group.

You’ll leave with:

• a mental model for diagnosing your team’s culture
• a practical, repeatable framework for influencing it
• and a realistic understanding that culture change is non-linear – patience matters as much as intent.

The magic formula: Values → Structure → Repeated Interactions → Culture

Key takeaways

• Culture is shaped by repeated interactions, not declarations. It’s a function of both people and processes – change either, and you change the culture.
• Design for behaviour, don’t ask for it. You can’t tell people to collaborate more – but you can create an environment where collaboration is the default path.
• Leaders develop culture through everyday decisions. What you praise, tolerate, challenge, or ignore defines what’s truly expected.
• Culture change is non-linear. Progress comes in bursts and plateaus – expect doubt during flat periods, and plan for it.

How AI lets senior engineering managers lead deeper into the technical core of their teams, and into the customer’s seat

The discourse around AI and engineering management is mostly panic: managers drifting back to coding, leadership work leaking out, the productivity story breaking down at the manager layer. I want to argue the opposite.

I run a portfolio of teams whose technical core I have, historically, never quite been able to reach: hardware test infrastructure, developer tooling, documentation systems. The cost of getting deep enough to be useful in those domains used to be prohibitive for a senior manager. That cost has collapsed.

I’m diving into code and architecture I would have delegated past last year. I’m prototyping inside areas of deep team expertise I previously had to take on faith. I’m picking up customer-side work end-to-end and becoming the user of the thing my team ships, because the barrier to understanding an unfamiliar domain has dropped to near zero.

This is not a leader regressing to IC. It is a leader gaining access to two zones the role was always implicitly excluded from: depth inside the team’s technical core, and the customer’s seat. Both are high-leverage and… both are easy to do badly.

This talk is what I’ve learned about leading deeper without leaking the rest: where manager-coding accelerates team value, where it displaces it, and what changes when “I can be in the weeds with you” is the energy leaders bring to their team.

It is a defense of the manager who codes, and a sharper rule for what they should code on.

Takeaways:

• The two zones of high-leverage work that AI now makes accessible to senior engineering managers, and why delegation alone could never reach them.
• A practical rule for deciding when manager coding compounds team value versus when it quietly displaces it, particularly in platform, infrastructure, and tooling teams (while still applying to product engineering organizations).
• How being able to say, “I can be in the weeds with you,” changes leadership conversations, and what leaders should invest in to remain technically credible.
• Where the line between “delegate” and “engage with” has shifted now that AI has lowered the cost of diving deep into technical work.

Closing thoughts from the host, Pat Kua.

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.

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. 

Find out the secrets to success in your next career move.

A huge part of LeadDev is helping people advance in their career – but understanding the expectations of the role above you isn’t always easy. 

As such, Next Steps AMAs bring together groups of leaders who can help answer the fundamental questions that folks have relating to their role; how do I advocate for my promotion, what will my new responsibilities be; how will I know that I’m successful?

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. 

Explore solutions for your technical issues.

Make the most of your breaks with our demo stage sessions, where leading tech providers will showcase their innovative solutions in informative and concise presentations. Each carefully curated 10 minute demo will show the very best engineering solutions available.

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.

Hang out with other leaders in similar roles.

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

Candid conversations about the real impact of AI on engineering leadership and practice.

Engineering is being reshaped in real time.

AI isn’t just another tool in the stack – it’s changing how teams are structured, how leaders lead, how juniors learn, and how software is built at scale. While the industry is still finding its feet and before any frameworks can claim to be “battle tested”, there exists a huge diversity of thought about how to create the golden path forward. 

The Big Debate is a series of high-level discussions that gets to the heart of this- tackling the most urgent, unresolved questions in modern engineering.

This is a chance to listen in as a trio of industry experts at the cutting edge share how they’re thinking about what comes next. 

Join these sessions to hear how some of the most forward-thinking leaders in the industry are debating, designing, and defining the future of engineering.

Grab lunch, meet your peers and discuss core engineering challenges.

Finding the right solution for core engineering issues isn’t about isolated thinking – it’s about building your support network and leveraging the power of peer learning via genuine diversity of experience. 

Join us for a relaxed, drop-in lunch and learn session where women leaders in engineering will be discussing core engineering challenges, share their experiences , and learn from one another, facilitated by five experienced women engineering leaders,  who will help guide the discussion.

Sponsor-led talks highlighting tools and solutions for real-world engineering problems.

Join these 10-minute talks to explore how our partners are helping teams tackle real-world engineering challenges. Each session shares practical examples, lessons learned, and insights into the decisions behind the solutions — giving you ideas you can take back to your own teams and systems. 

Lean into intimate, interactive sessions and put your skills into practice.

Join one of our 80-minute microshops for an intensive learning experience guaranteed to ignite your thinking. Led by expert engineering leaders with years of industry experience, you’ll walk away from this session with actionable insights and battle-tested strategies to implement immediately.