A welcome from the host, Tanya Reilly.

If I had only 30 minutes to distill what I’d learned over the years, this is the talk I’d give. Most of the lessons will be about teams (the real distributed systems). I can’t guarantee consistency, but I will strive to be both available and tolerant.

Inspired by the book The Phoenix Project and by DevOps principles, we worked to close the gap between Development and Operations, to come together and collaborate for the good of the organization. We even invited security into the fold and embraced DevSecOps.

Granted, if you’re like me, you’re still shaking your fist at somebody on the regular. You know who I mean. But they deserve it. Look at how much they mess everything up! They’re the ones who need to wise up and change, right? Right? The divides we encounter might be between teams, between geographical locations, between IT and “the business,” and more.

Join this session for an examination of why “us vs. them” thinking arises and how we can spot it in action. You’ll gain tips for why and how to bridge the divide – and why the effort can be worthwhile, even if “they” seem unmoved and unmovable.

Key takeaways:

• How to spot “us vs. them” thinking in action
• Tips for how to bridge the divide
• Why the effort is worthwhile

As a Principal Engineer in Stripe’s Payment Intelligence org, I’m responsible for scaling real-time AI systems that detect and prevent fraud—without adding latency to Stripe’s most critical code path, known as the “charge path”.

At the heart of Stripe’s infrastructure, the “charge path” is a shared Ruby monolith that processes almost every transaction across the platform. In 2024 alone, it handled over $1.4 trillion in volume. It’s one of the most latency-sensitive and business-critical systems at Stripe, actively maintained by several engineering orgs and touched by hundreds of developers. Making changes here requires precision, coordination, and a deep understanding of systemic constraints.

Our org had a strong roadmap of AI innovations to improve fraud prevention and authorization rates. But executing that vision meant working through legacy architectural decisions and Ruby’s lack of native concurrency—all without exceeding strict latency constraints. To move forward, I brought together tech leads and domain experts from across Stripe for a virtual onsite. We ran an event storming workshop to surface shared constraints, uncover tribal knowledge, and identify architectural leverage points for introducing safe and meaningful parallelism. I proposed a series of deep but targeted architectural improvements to unlock more ML execution within the charge path, minimizing the risk. I then collaborated across teams to build a multi-quarter roadmap that aligned efforts, minimized conflicts, avoided throwaway work, and accelerated the landing of impact.

This talk is about what it takes to deliver AI innovation inside a high-stakes, real-time system—navigating legacy architecture, aligning across teams, and scaling machine learning under strict performance constraints.

Key takeaways:

• How to scale real-time AI in a latency-sensitive system
• How to introduce parallelism in a legacy Ruby monolith
• How to uncover system constraints through structured collaboration
• How to align multiple teams around architectural change

A story of building long-term outcomes out of the chaos of daily reality.

Have you ever tried to build a house on quicksand? I can’t imagine it would work very well! The ground is so chaotic and the landscape itself isn’t reliable enough to be the foundation you need. It feels like you can’t even get started, let alone build something sturdy enough to last.

Honestly, trying to build an engineering strategy and an engineering organization in today’s environment feels just as chaotic. Things are churning faster and faster, and the days of clear strategy are long gone (if they ever existed in the first place). Quarterly planning? Long-term thinking? Some days they feel like relics of the past, so what’s a leader to do?

In this session, join Hazel as she walks through a journey of how she took a rapidly evolving environment, where only short term goals could survive, and turned that chaos into something that long term success could be built on top of.

Key takeaways

• Strategies for making local decisions pay off in the long run.
• Techniques to not get buried in the firefighting.
• What worked, what didn’t, what would Hazel have done differently?

As a Staff+ engineer, your role isn’t just about scaling systems—it’s about scaling influence across the organization.

Interestingly, distributed systems principles offer a powerful mental model for leadership. This talk explores how fault tolerance, redundancy, service contracts, and eventual consistency apply to leading large-scale engineering efforts.

Learn how to design for autonomy without chaos, how to create decision-making guardrails without bottlenecks, and how to recover from failure—both technically and organizationally. Whether you’re shaping technical strategy, aligning teams, or driving long-term change, this talk provides actionable insights to amplify your technical impact.

Key takeaways:

• Apply distributed systems principles to scale your technical influence.
• Design decision-making frameworks that prevent bottlenecks in large organizations.
• Use fault-tolerance strategies to navigate organizational misalignment.
• Build technical strategies that are resilient to leadership and system failures.

Alignment is one of the most used and least understood concepts in engineering leadership. We say it’s critical, we hold meetings to get it, and we celebrate it in performance reviews. But if we’re really aligned, why do we keep needing more “alignment” meetings?

After a year of obsessing over this concept, I’ve come to believe that most alignment work is actually just anti-misalignment: a reactive attempt to avoid conflict, surprises, or churn. It’s alignment by damage control.

In this talk, I’ll reframe alignment as a form of group flow, a state where everyone knows where we are, where we’re going, and how we’ll navigate tradeoffs along the way. I’ll share a simple model that explains why misalignment feels so painful (and so obvious), and why real alignment isn’t a meeting, it’s a shared sense of direction, context, and trust. We’ll look at the difference between alignment and agreement, explore some dangerously common anti-misalignment patterns, and walk through lightweight strategies you can use today to improve clarity and autonomy across your team.

Whether you’re a Staff+ IC, a manager, or a tech lead, this talk offers a vocabulary and lens for the invisible cultural friction that slows teams down and a more proactive way forward

Key takeaways:

• “Alignment” is a rarely useful concept as it can mean everything and nothing all at the same time
• Misalignment is one of the most painful and visceral forces in an organization
• Most “”alignment”” work is actually driven by the fear of misalignment
• What true proactive and productive alignment looks like
• Strategies to tease out true alignment against the background of “Anti-misalignment”

You may have heard that rewriting code from scratch is a Thing You Should Never Do. We’ll critically examine the origins of that proverb and its applicability to modern software development, as well as share some stories and common patterns from successful rewrites.

Software engineering is a complex and contextual domain. Given any question, there’s a good chance that the best answer is “it depends.” Despite this, we still elevate some prescriptions to the level of “common sense” or even dogma. One such idea is “never rewrite the code from scratch,” which traces back at least as far as the year 2000.

I’ve had this proverb recited to me more than a few times by my superiors and peers. Sometimes, avoiding a rewrite has been the right call. But other times, eyes open to the potential issues and strategies to avoid them, I’ve pushed for a new system. Those projects have been some of the most rewarding and impactful of my career.

I’ll discuss the origins of the “never rewrite” idea and why the original reasoning doesn’t always apply to us today. I’ll also present my framework for planning a rewrite and how to capitalize on a successful one. Finally, I’ll share some stories of my successful rewrites and how they improved our engineering teams.

Key takeaways

• Why rewrites are sometimes (but not always) a terrible idea and how to tell the difference
• How to approach redesigning a system from scratch, from pitching the idea through to successfully landing your new system
• Examples of successful redesigns, their technical impact, and the effect they had on their engineering teams

How do you build something magical, fast?

In creating a new feature, engineering leaders have a lot to balance. Designs could be constantly in flux. Sharp pivots could be made weekly. There could be pressure to cut corners to hit deadlines. Despite all of this, engineering leaders are still expected to deliver.

To ensure that the team is spending their time in the right places, it’s essential to understand different approaches to prioritizing work to minimize risk and maximize impact. Engineering leads must also allow for balance timelines and flexibility, enabling the product to change as new insights come in, without letting development drag on. Making decisions in a fast moving environment can be overwhelming – it’s easy to get analysis paralysis. That’s why knowing when a decision needs to be made, and having a framework for making that decision, is crucial.

Key takeaways:

• How to know what aspects of a new system to build out first
• How to make decisions, while dealing with a lot of unknowns and pivots
• How to deal with changes in scope, especially when dealing with strict deadlines

Who knows what engineering VPs are thinking? I sure did not, until I became one. (Some say I still do not.) The real problem is a two-way information gap: your VP is starved for ground-truth, and you are missing the “why” behind their opaque decisions. This talk is a frank little conversation on how to build a partnership that closes that gap, so you can understand the strategy you need to do your job, and they can get the unfiltered perspective they have lost.

Ever seen an off-the-wall decision by the senior leadership cabal and wondered what they were thinking? It turns out it is rarely a secret plan, it is a structural information gap. Your VP is often starved for the ground-truth that you have, and you are missing the strategic “why” behind their decisions. They end up guessing about what is really happening on their teams, and you end up guessing about what work actually matters.

As a former VP who started at Slack as a Senior Staff IC, I have had the dubious pleasure of living on both sides of this gap. I have felt the IC’s frustration with confusing directives, and I know the executive’s pressure to make big calls with incomplete information. This talk is my attempt to translate the view from the VP chair. (For the record, I did not actually get a new physical chair.)

I will share a practical playbook for bridging this gap by trading your ground-truth for their context. We will cover how to make your VP an ally and advocate for your work, while acknowledging that the best path forward is often one that neither of you saw at the start. You will, ideally, walk away with a clearer plan to help decide where the ship is going instead of just being told to row.

Key takeaways

• Your ground-truth is your most valuable currency. The core of the partnership is a trade: your unfiltered view of reality for their strategic “why.” This is how you both stop guessing about what work actually matters.
• Your senior leadership isn’t a cabal; they’re disconnected.* Whether they’re a new leader learning the ropes or a veteran who’s lost touch, they are making big calls with incomplete information. Your role is to be their bridge to the team’s reality. Also, their meetings with bigwigs aren’t fun and their travel isn’t cool. JFYI.
• Context is the foundation of influence. Use the strategic “why” you gain from the partnership to move beyond brilliant execution. This is what allows you to propose better solutions, stop projects that don’t make sense, and help steer the ship instead of just being told to row.

*If you are an engineer with, say, Skull & Bones, they might be a cabal though.

Practical cues and rituals that help senior ICs oscillate between architectural vision and hands-on execution.

An essential challenge for senior individual contributors (ICs) such as architects and staff+ engineers is guiding engineering teams towards well-informed technology decisions at scale. This can be a daunting task, often frustrating and at times feels impossible.

Software engineering is inherently creative, much like painting, where no two artists would create the same artwork. This creativity leads to strongly held opinions, often resulting in spirited debates that can feel like arguing and conflict rather than collaborative brainstorming. These debates, though difficult and uncomfortable, are extremely important and critical to our overall success.

This talk delves into the unique challenges faced by senior ICs who wield influence but lack direct authority, emphasizing the importance of presenting choices over solutions and engaging early in the decision-making process. We will explore techniques to make these debates more constructive, collaborative, less driven by ego and conflict, and more likely to result in decisive, well-informed decisions.

Key takeaways:

• Harnessing Conflict for Progress: Embrace the chaos and recognize that conflict, when managed well, can drive innovation and better outcomes.
• Effective Decision-Making: Learn how to present choices over solutions to foster collaboration and reduce conflict.
• Early Engagement: Understand the importance of influencing decisions early to avoid entrenched solutions and defensiveness.

It covers the 5-7 year development journey of a NextGen SPECT/CT scanner at Siemens Healthineers, from concept to clinical trial, sharing insights gained while leading an engineering team through challenges in architecture, culture, and compliance.

In this talk, you’ll get hard-earned leadership lessons from a 7-year NPD journey of a new line of Nuclear Medicine/CT scanners—systems where failure isn’t an option and reliability is non-negotiable. From handling deep tech complexity to empowering engineers to own quality, speed, and motivation in one of the most regulated domains in tech. Drawing on a multi-year product journey in healthcare tech, this talk reveals simple but powerful techniques to lead with intent, foster autonomy, and get world-class results—without hero culture.

Key takeaways

• Fostering a culture of collaboration, open communication, and equal partnership across distributed teams is essential for leveraging global strengths, maintaining engagement, and ensuring product quality through real-time testing.
• Technical leadership in the medical device industry demands a strategic focus on long-term planning, maintainability, regulatory compliance, and resource management, balancing innovation with the significant upfront investment and extended product lifecycles.
• A multi-level testing approach—combining simulators, automated testing, and real-world system validation—along with fostering a culture of collaboration between development and system test, ensures comprehensive defect detection and guarantees software reliability and quality.
• Understanding regulatory guidelines early in the development process and testing critical requirements separately are essential for managing compliance efficiently, preventing delays, and overcoming the unique challenges of new product development in a highly regulated industry.
• While the challenges of long development cycles and unexpected obstacles, like the COVID-19 pandemic during clinical trials, can create uncertainty, the ultimate satisfaction of seeing your work positively impact users’ lives offers invaluable lessons that shape future leadership and decision-making.

Closing thoughts from the host.

Explore solutions for your technical issues.

Learn how real engineering teams turn ideas into practice.

The integration of AI into engineering teams isn’t just changing how work gets done—it’s fundamentally shifting team dynamics, individual roles, and the emotional landscape of leadership.

In this interactive workshop, you’ll tackle the real challenges: creating clear agreements about AI use on your team, evolving your leadership approach in the age of AI, and identifying the skills your team needs to succeed in this new reality. You’ll leave with practical tools including a framework for building your team’s AI charter, strategies for navigating your evolving leadership role, and a clear approach for developing the human skills that become more valuable as AI handles routine work.

In this workshop you’ll learn how to:

• Create your team AI charter
  • Establish clear, shared agreements about how your team will use AI tools, what standards you’ll maintain, and where human judgment remains essential.
• Navigate your evolving role
  • Shift from managing tasks to developing capabilities, balancing team members at different AI adoption levels, and leading effectively in the new landscape.
• Develop the skills your team needs most
  • Identify and intentionally build the critical capabilities like complex problem framing, systems thinking, and cross-functional communication that become more valuable when AI handles routine work.

As described in Accelerate: The Science of Lean Software and DevOps, organisations adopting principles and practices from the Lean Software and DevOps movements are seeing payoffs in terms of higher quality, better reliability, faster delivery, and reduced costs.

Leaders wanting to achieve these results will need to understand how to build a transparent, aligned metrics-driven team in order to successfully navigate their improvement journey.

Using material from Accelerate, Jez Humble will discuss:

• Important concepts in measurement
• Known predictors of success that any team can use
• A tool to apply them

As engineering leaders, we make big decisions every day—about people, projects, and our own careers. But when the stakes are high, it’s easy to get stuck, overthink, or second-guess ourselves.

This workshop offers a fresh approach: treat decisions like A/B tests. Instead of waiting for perfect clarity, you’ll learn how to break big choices into smaller experiments so you can move forward with confidence.

Whether you’re deciding how to lead your team, handle a tough situation, or plan your next move—you’ll walk away with a repeatable, low-pressure way to make decisions that feel aligned and proactive (not stressful or rushed).

This session is interactive, practical, and built for real-world leadership. Let’s take the pressure off decision-making—and make it something you can actually feel good at.

In this workshop you’ll learn how to:

• How to turn big, overwhelming decisions into small, testable steps
• Simple tools to move forward—even when the “right” answer isn’t obvious
• Ways to apply product-thinking and feedback loops to your leadership style
• Ways to reduce overthinking and perfectionism when the stakes feel high

A welcome from the host, Tanya Reilly.

After spending her career building and operating petabyte scale databases, Sammy left the infrastructure org to join a product team on an ambitious cross-functional project. She’ll share her experience bringing together infrastructure and product mindsets.

Always use feature flags for gradual rollouts. Never change too many things at once. No one-way data migrations. As an infrastructure engineer, these are rules that Sammy lived by her whole career. Then she was asked to move into the product org to help lead a massive cross-functional project involving 50+ engineers and cross-functional partners across business, sales and marketing. The project had ambitious scope and extremely inflexible, tight timelines. Additionally, the launch came with strict requirements — the team had to launch everything all at once at 10am on a single day, with no path to rollback if something went wrong. What could have been a disaster ended up being one of the smoothest large-scale launches Figma has ever done. Come learn how Figma raised the company’s bar for product launches with new approaches to consistency, stateful workflow pipelines and safer data migrations. Alone the way you’ll learn lessons from Sammy’s experience transitioning from infrastructure to product and back again.

Key takeaways

• How to transition from infrastructure to product successfully and the ways in which you can provide value by bringing a scalable and reliable mindset while also learning a lot about how product works.
• How to bring learnings from product back to infrastructure to push for improvements like faster deploys, better stateful workflows and consistency checking frameworks.
• Deep technical challenges of launching a project that was impossible to rollback and had no tolerance for correctness issues — data migration strategies for mitigating risks.
• How to work to align engineering and cross-functional business partners to deliver the right outcomes without over-committing.
• How to beat the “mythical man month” problem and actually accelerate a late project by adding additional people (in the right way).

“It’s me– Hi. I’m the problem, it’s me,” croons Taylor Swift on her iconic track, “Anti-hero.” When it comes to the growth of those around us, this also applies to Staff+ Engineers.

Simply put, experienced ICs are often the largest barrier to growth of those around them. Leadership will turn to you when something mission critical has to get done fast. Leadership will turn to you to save someone else’s project that has run off the rails. Playing the hero feels really good in the short run. But it’s not sustainable in the long-run for you, or for the organization. Even if you don’t burn out, you slow or stunt the growth of others.

Think about when you grew most as an engineer. Some people will say, “it was when this really experienced person took me under their wing.” But most will say something like, “it was when that really experienced member of the team left, and I had no other choice but to step up.” By default, others grow more in our absence than in our presence. And, we struggle with this problem quite a bit. Our median tenure is quite high, which means the most common growth opportunity in the industry (“a senior IC leaves”) happens less often than elsewhere. This pushes us to experiment with different ways to grow others.

In this talk, I reflect on the ways I’ve tried (and often failed) to cultivate other engineers. Conventional wisdom says we should “scale” ourselves by focusing on “org wide impact”. But I’ve discovered the power of doing what doesn’t scale. When I’ve carved out time each week to invest in the three most capable engineers around me, something remarkable happens: the whole team sings.

Key takeaways:

• By default, others grow more in your absence than in your presence.
• Identifying and investing in 2-3 key people is super impactful
• Push your best people regularly out of their comfort zone

Learn how to effectively mentor aspiring technical leaders, focusing on cultivating the unique blend of technical mastery, broad impact, and organizational influence required for a Distinguished Engineer role.

Becoming a Distinguished Engineer is generally not an inline promotion. It is a position in which most companies ask you to apply. As the requirements are numerous and cover technical and non-technical areas, you need to develop a plan and support structure to prepare for this journey.

Most engineers can clearly articulate their technical capabilities. That’s the easy part. The more difficult areas include understanding the challenges and opportunities for the Business your Enterprise is engaged in. How do you develop and use your soft skills to influence senior management on roadmaps and directions for exploration.

In this talk, you’ll hear about the career development paths that will help you achieve your goals for becoming a Distinguished Engineer.

Key takeaways

• The general requirements for Distinguished Engineer
• The type of support will you need on this journey
• The career development areas that you’ll need to develop

This talk explores the engineering challenges and key decisions involved in scaling LinkedIn’s search infrastructure, focusing on architecture, scalability, and resilience at massive scale.

In this talk, I’ll walk through the journey of scaling LinkedIn’s search infrastructure, highlighting the key engineering decisions and challenges faced along the way. As one of the largest and most complex search systems in the world, LinkedIn’s infrastructure supports millions of users and billions of queries each day – while maintaining low latency, high availability, and scalability.

I’ll cover the technical decisions made in designing and evolving the system, including tool selection, framework choices, and architectural patterns that enabled LinkedIn to scale its search capabilities in response to growing data and user demands. From designing distributed systems to optimizing indexing, query handling, and storage, I’ll share the trade-offs involved in ensuring reliability and performance at scale.

Beyond the technical aspects, I’ll also discuss the organizational and team dynamics that come with scaling such a large system. This includes aligning cross-functional teams, coordinating across engineering groups, and making decisions that balance immediate execution with long-term vision for the platform.

Key takeaways

• Key engineering decisions and challenges when scaling large-scale search infrastructure.
• Best practices for designing and optimizing distributed search systems.
• How to balance performance, scalability, and reliability in high-demand platforms.
• Strategies for aligning cross-functional teams in large-scale infrastructure projects.
• Lessons learned from building and evolving search systems to support millions of users.

Migrations need to be fast and seamless. But at scale, they’re often anything but – especially when many teams are involved and coordination overhead balloons. What if you could make migrations self-serve, so they just happen, without endless follow-ups or hand-holding?

At Airbnb, we’ve been working AI into our migration toolkit to rethink migrations from the ground up, guided by two tenets: “Complete to 100%” and “Be a host” – taking responsibility for migrations on behalf of teams.

In this talk, I’ll share how we built tooling, infrastructure, and guidance to enable rapid, large-scale AI-driven migrations. Through some case studies, you’ll learn how these principles are letting us scale migrations across the company, the new challenges we faced (like review bottlenecks), and practical lessons for anyone looking to accelerate migrations in their own organization.

Key takeaways:

• How migration tenets like “be a host” and “complete to 100%” are foundational for accelerating migrations with AI by changing the planning, ownership, and tooling approach
• The specific tools and infrastructure we’ve built to scale AI-accelerated migrations and make them self-serve and repeable
• The key points we use to train our migration owners to help deliver successful AI-accelerated migrations
• And some of the bottlenecks and hurdles we’ve hit doing this (some we’ve addressed, some we haven’t yet)

A crisis is a transformative moment for an organization. If you’re prepared, and with a little luck, it can be an ideal moment to make big technical changes.

All organizations experience crises. An existential threat from a competitor, a highly visible outage, or a disruptive reorg can all land you in the same place. The organization has to adapt to continue to exist. New habits and coordination structures are required. Team members have to perform at their best, and do it while stressed and short of time.

In such conditions, change is coming to your organization. As a Staff+ engineer, you have a key role to play. I’ll show how listeners can direct and shape the changes, leaving systems and structures that are stronger than before.

Key takeaways

• How to identify a useful crisis conditions
• What can staff+ leaders contribute in a crisis?
• Technical capabilities you might want before a crisis

This talk will describe the process of building one of the flagship new feature areas that Figma launched at its annual conference this year (May 2025). I’ll talk through how I turned a small team, a lot of passions, and a large mandate into a successful product launch.

For the past year I’ve been the lead engineer and de facto product manager for a large new product area at Figma. In just a few months, armed with only a handful of engineers and a huge product mandate, our team had to be efficient, resourceful, and most importantly, needed to have a lot of fun in order to deliver such an expansive feature set. Follow along our journey to unlock entirely new ways of being creative with Figma: our successes, our mistakes, and unexpected experiences all the while navigating a highly performance-sensitive front-end C++ stack.

Key takeaways

• How having a strong technical perspective from the start is key to building an efficient roadmap
• How building partnerships with other engineering teams can stretch your headcount a long way
• How to continually prioritize, adapt, and communicate about product decisions
• How to continually develop buy-in with leadership and give your team space in doing so
• How to build a happy team, and how to delegate, trust, and build leaders within your team

Technical debt often carries negative connotations—as an inevitable burden rather than a pathway to innovation.

At WSO2, by 2020, incremental fixes for the Ballerina compiler and its VSCode plugin fell short of addressing deeper developer experience issues. Instead of viewing these challenges solely as debt, we reframed them as opportunities for innovation, professional growth, and enhanced developer satisfaction.

This talk shares experiences from my journey transforming technical debt into strategic improvements through a comprehensive redesign toward a responsive, real-time compiler architecture. Key strategies included empowering engineers, clear and transparent communication, and maintaining community trust. By repositioning technical debt positively, we significantly improved developer productivity and innovation capabilities.

You will gain practical insights into leveraging technical challenges to propel innovation, engineer growth, and community development. This talk will be a retrospective of that journey, exploring what worked and what didn’t.

Key takeaways:

• Technical debt can be reframed as a powerful driver for innovation and growth.
• Effective communication is critical when introducing significant technical changes.
• Prioritizing developer satisfaction can dramatically enhance productivity and community engagement.
• Successful transformations require empowering your engineers and fostering trust.

As a Staff Engineer, uncertainty is a given. But sometimes, it lands right where it stings the most—on the expectation that you’re the technical expert. This talk is about my own experience leading initiatives where I didn’t have expertise in the tech at hand and how, despite that, a team can still be inspired, empowered, and deliver great results. I’ll share what worked, what didn’t, and the lessons I’ve carried forward about leading without always being “the expert.” Whether you’ve been in this position before or just want to be ready when it happens, this session will give you a candid look at turning uncertainty into strength.

Key takeaways:

• Confidence that effective leadership doesn’t require mastering every technical detail.
• Strategies to empower teams and foster collaboration in unfamiliar technical domains.
• Techniques to turn uncertainty into an opportunity for growth and innovation.
• Insights into building trust and credibility while navigating new challenges.

This talk introduces hypothesis-driven development as a method for validating architectural choices. We’ll explore how to design experiments that provide actionable data, allowing teams to make informed decisions and adapt to changing requirements.

As a Staff+ engineer, you’re expected to lead complex, cross-functional initiatives, align teams around technical direction, and deliver meaningful outcomes – all in the face of ambiguity and rapid change. Yet the most important architectural decisions often happen early in a project – precisely when knowledge is limited and uncertainty is highest.

To lead effectively in this environment, you need a mindset shift: embrace the role of a lean architect and treat architecture as a series of testable hypotheses. Validate decisions early – while changes are still inexpensive and easy to make. Start small. Build steel threads: thin, end-to-end slices that deliver value and surface insight. Use them to ask sharper questions:

• Will this pattern scale in production?
• Are our boundaries enabling speed or creating new bottlenecks?
• What is real-world usage telling us about our assumptions?

By experimenting your way to better decisions, you create space for smarter choices and generate the feedback needed to shape architecture. As successful patterns emerge, your team can invest with confidence – steadily building scalable, resilient systems one iteration at a time.

Many organizations run POCs to validate new technologies, enhance data infrastructure, or improve decision-making, but these efforts often fail due to unclear goals, lack of stakeholder alignment, or execution challenges.

This talk presents a structured approach to leading successful POCs that scale beyond the experimental phase and drive meaningful impact. I will share a practical, repeatable framework covering:

• Defining success criteria to align technical efforts with business needs
• Scoping and structuring POCs for rapid iteration without sacrificing long-term scalability
• Engaging stakeholders early to secure buy-in and resources
• Implementing in phases to gather feedback, reduce risks, and optimize for production readiness
• Transitioning validated POCs into production environments with minimal disruption
• Attendees will leave with actionable strategies to execute and scale POCs effectively, ensuring they deliver measurable value and do not remain proof-of-concepts forever.

Key takeaways:

• A structured approach to defining, scoping, and executing POCs effectively.
• Strategies for securing stakeholder buy-in and ensuring alignment.
• Techniques for phased implementation and iterative improvements.
• Common pitfalls to avoid when transitioning POCs to production.
• Practical insights from real-world case studies.

Making the leap from team-focused engineer to org-level technical leader can feel like freefall. Suddenly, your old ways of working and measuring success no longer apply. You’re overwhelmed, directionless, and wondering if you even belong in this role. Sound familiar? You’re not alone.

This talk introduces the concept of the Performance Cliff, a psychological shift that explains why highly capable engineers often feel lost when stepping into broader influence. Drawing on years of mentoring and hard-won lessons, the speaker will explore practical strategies to reframe your mindset, build new systems of success, and thrive in the ambiguity of Staff+ org leadership.

Over the last several years of mentoring other Staff+ engineers, the speaker has had many conversations that follow a similar pattern:

“I recently moved from being a team leader to being an org leader, and I have no idea what I’m supposed to be doing / I feel like I’m failing / I’m overwhelmed by all of the work on my plate / I’m lost and confused / maybe this isn’t the right role for me / I feel so alone.”

If this resonates, you’re not alone. The speaker experienced the same thing when moving from a Staff Engineer role on a team to an Architect role with broad responsibility across many teams. Despite working toward this transition for years, the shift felt disorienting. It created a sense of failure, uncertainty, and fear of being found out. But that reaction is not a sign of inadequacy – it’s a normal response to a major change.

This talk is for anyone who has stepped into a larger role and quietly wondered if they’re the only one struggling.

Closing thoughts from the host.

Explore solutions for your technical issues.

Learn how real engineering teams turn ideas into practice.

The integration of AI into engineering teams isn’t just changing how work gets done—it’s fundamentally shifting team dynamics, individual roles, and the emotional landscape of leadership.

In this interactive workshop, you’ll tackle the real challenges: creating clear agreements about AI use on your team, evolving your leadership approach in the age of AI, and identifying the skills your team needs to succeed in this new reality. You’ll leave with practical tools including a framework for building your team’s AI charter, strategies for navigating your evolving leadership role, and a clear approach for developing the human skills that become more valuable as AI handles routine work.

In this workshop you’ll learn how to:

• Create your team AI charter
  • Establish clear, shared agreements about how your team will use AI tools, what standards you’ll maintain, and where human judgment remains essential.
• Navigate your evolving role
  • Shift from managing tasks to developing capabilities, balancing team members at different AI adoption levels, and leading effectively in the new landscape.
• Develop the skills your team needs most
  • Identify and intentionally build the critical capabilities like complex problem framing, systems thinking, and cross-functional communication that become more valuable when AI handles routine work.

As described in Accelerate: The Science of Lean Software and DevOps, organisations adopting principles and practices from the Lean Software and DevOps movements are seeing payoffs in terms of higher quality, better reliability, faster delivery, and reduced costs.

Leaders wanting to achieve these results will need to understand how to build a transparent, aligned metrics-driven team in order to successfully navigate their improvement journey.

Using material from Accelerate, Jez Humble will discuss:

• Important concepts in measurement
• Known predictors of success that any team can use
• A tool to apply them

As engineering leaders, we make big decisions every day—about people, projects, and our own careers. But when the stakes are high, it’s easy to get stuck, overthink, or second-guess ourselves.

This workshop offers a fresh approach: treat decisions like A/B tests. Instead of waiting for perfect clarity, you’ll learn how to break big choices into smaller experiments so you can move forward with confidence.

Whether you’re deciding how to lead your team, handle a tough situation, or plan your next move—you’ll walk away with a repeatable, low-pressure way to make decisions that feel aligned and proactive (not stressful or rushed).

This session is interactive, practical, and built for real-world leadership. Let’s take the pressure off decision-making—and make it something you can actually feel good at.

In this workshop you’ll learn how to:

• How to turn big, overwhelming decisions into small, testable steps
• Simple tools to move forward—even when the “right” answer isn’t obvious
• Ways to apply product-thinking and feedback loops to your leadership style
• Ways to reduce overthinking and perfectionism when the stakes feel high