Agenda

You may have heard your boss say it: "You need to be more strategic!". Maybe it came up in your latest performance review. Or you just want to work more strategically in order to fill all parts of your role as a leader. Or maybe your team/organisation needs more strategic support to help them succeed. But now you're wondering: - What does it actually mean to really think and act strategically? - How can you know that you are on the right path to becoming a more strategic leader? - What actions can you take to become more strategic every day? - What skills can you develop that help your ability to think and act strategically? - How can you handle setting strategy in fast-changing organisations like startups? Or in a large corporation where your area of influence may be limited? - And how can you create space for strategy in your busy schedule? You're not alone with these questions! Many leaders want to (or even need to!) create space for more strategic work, but it can be really hard to do so. In this talk, we'll cover these questions to help you become more strategic. In addition, I'll share real examples from engineering leaders to help you understand what you can do in your daily work. You'll walk away with practical tips that you can start implementing tomorrow to help you become a more strategic leader and, consequently, more effective and successful in your role.

Every day, we spent many of our waking hours at work and selfishly, I would like it to be fun! Sprinkling in weekly magic to your team is helpful in making work more enjoyable and getting to know the smart, kind, fun people you work with. This is especially important with hybrid or distributed teams. Come experience a "best of" highlight reel of what teams do to create these connections and leave with tons of ideas that you can do with your team.

As technology evolves, so does the complexity. Where once we could throw some simple JavaScript and HTML together to build a web application, modern web development requires expertise in a multitude of areas. At Netflix we leverage our web platform team to remove this complexity for UI engineers so they can get back to building and shipping features. In this talk, we’re going learn what a platform team is, what they do, and why your business needs one.

Have you felt frustrated by your team's speed of execution? Have you asked yourself, perhaps in the middle of a sprint planning session: Are we stuck? Why do some teams seem to work faster than others? Why do some people perceive a team as too slow, while others consider the same team fast enough? And engineers on some teams appear to be more satisfied and more motivated than those on other teams; why? Engineers don't lack motivation -- it is systems that fail to create an environment for engineers to make magic. In this talk, I’ll lay out a step-by-step guide for managers and ICs to ask the right questions towards this problem.

- Alignment: Are the team’s goals and metrics aligned with the business? Is the team aware of broader priorities and constraints? Is there agreement around when to optimize for user-visible features vs technical debt? Is there alignment around what exactly the team owns?
- Doing Too Much: Is the team keeping too many projects active at the same time? We’ll talk about how to identify if this is happening, and how to use metrics and models to choose what to prioritize.
- Thrashing: Big and frequent changes in priority can make engineers take the priorities themselves less seriously— but such change is a reality in a fast-growing company. How do you reduce thrashing as well as increase adaptability to change?
- Deep, slow projects: Some projects simply take a long time. This is especially true for infrastructure work. In this context, it’s important to demonstrate value early— engage with users, go deep before going broad.

As a manager or lead developer, this talk will give you a playbook to analyze and work on your team’s engineering velocity— and ultimately, to create an environment where people work together at their highest potential.

This year the tech industry has seen a shift in hiring, with many larger companies implementing freezes or layoffs. As engineering managers, how do we grow our teams’ ability to execute and succeed when we’re unable to hire more people?

Join CJ as he uses colorful AI-generated images to illustrate three stories about how he approaches this challenge.

As you settle into your management role, work will inevitably pile up, and your team will become hungry for more opportunity. Attempting to do all of the work yourself is a recipe for burnout and will stifle the growth of your team.

Luckily for you, providing your team more opportunity and reducing your workload are both solved by effective delegation! But how should you decide what to delegate? What context is critical to provide? How much autonomy should you give and when? Can you coach on progress or direction without micromanaging?

Learning how to delegate not just tasks, but problems, ideas, and business needs, will enable you to take on larger and more critical challenges without burning out. Delegation gives your team the opportunity to take leadership roles and leads to growth, learning, and career advancement for your team. Growing your team and taking on critical business needs will enable you to take the next step in your career as a leader as well.

With the techniques I present in this talk, you’ll be prepared to delegate, sponsor, and coach your team in a way that empowers them to grow their careers and makes your load manageable. Done right, delegation will be an invaluable tool you reach for again and again.

As companies move more workloads into public cloud platforms, managing those costs becomes more important and more complex. Even when armed with cloud cost management frameworks and best practices, a lot of companies still struggle to manage their public cloud spend. To succeed long-term, companies also need to focus on the people involved, ensuring they're engaged and on board.

In this talk, we'll cover why frameworks and best practices aren't enough and three key steps to create a cost-conscious culture.

R&D organizations understand the importance of an onboarding process for new engineers. But what about engineering managers? How do you set up a leader, either a promoted employee or a new hire, to succeed? What are the long-term implications of how this happens? I

n this talk, I’ll share my four-week onboarding process for engineering leads that emphasizes peopleware, tech leadership, and delivery management. I’ll provide a behind-the-scenes look at this super adaptable process, which uses a framework of ‘sessions’ and ‘experiences’ - and share everything from my mistakes to my insights.

So much of engineering hiring these days is based on meeting a technical bar when in fact that should be secondary to almost every other attribute. While we need engineers who’s technical skills match the scope and responsibility of the role, more than that we need engineers that can complement, fill gaps, and help push the team forwards; rarely does filling the gap mean finding another engineer that can identify when to use a hash map in a 10 min code challenge. This talk will cover additive hiring practices and tips at all size companies from hiring the first engineer at a startup to finding a great staff+ engineer at a big tech company.

Every team has its heroes - the superpowered engineers who run headfirst into any technical fire. Unfortunately, what works in the comic books doesn’t scale in reality, and the same folks won’t always be able to answer the Bat Signal. In this talk, Plum discusses the "user experience design" of incident response processes that allow them to grow alongside a rapidly expanding team and technical landscape. Using a real-world example, we'll look at the workflows that enable a "neighborhood watch" of cross-functional team members to join forces to battle bugs - sometimes under cover of night - so that the heroes can retire (or at least get some more sleep).

Six months into my role as an Engineering Director, I embarked on my parental leave for my second child. I did not have many role models of senior women leaders who had taken extended period of time off to focus on family and come back. So I charted my plan with the help of my leaders, peers, friends and mentors. In this talk I will cover what I did to prepare before my parental leave, from the perspective of business and how to keep an org functioning healthy while you are out, and from a personal perspective so I can focus on the new phase in my life. And will cover how I eased back into my role upon return. The talk will also cover what you can do as managers and peers to support your coworkers on parental leave.

“Cloud native” technologies have existed for less than 10 years but in that short time have radically changed everything about how we define, schedule, and run workloads in the Cloud. The past few years have been marked by significant innovation in Cloud technologies— from the processors at the bottom of the stack all the way up through the software at the top of the stack. And yet, we are still catching up to the implications of all of this change for the performance and efficiency of running workloads at scale. In this talk, we will cover: - Hardware trends in the Cloud, from multi-arch and processor price/performance analysis, to capacity, scheduling and the advent of preemptible VMs - Workload scheduling topics, such as cluster autoscaling and binpacking - OS & Kernel trends, such as the rise of the cloud OS and distroless - Changes in the container space, such as dockerless builds and multi-arch builds - Recent improvements in the JVM for performance and benchmarking - K8s interactions such as workload autoscaling, auto-tuning, and Java settings - Cloud-native developments in observability, profiling, and tooling - with real cross-cutting performance examples!

Uh-oh, you wrote another meandering doc where your reviewers lost the plot. Maybe you just sent out a long-winded email announcement that was met with more confusion. Or your tech spec is met with that famous question: "what are we solving here again?"

What if there was a way to focus your ideas and communicate them clearly and concisely? Barbara Minto did just that in 1985 in her seminal book, _The Pyramid Principle_ and its now-famous SCQA framework. How might we learn from her so that we can be effective written communicators in a remote work world?

Join us as we help a beleaguered tech lead edit their team's product spec by learning about the key components of the SCQA framework. We'll learn how to deliver the core ideas first, build logical, deductive arguments, and win approval and achieve alignment along the way. You'll leave with a clear understanding of how to uplevel your technical communication with leadership and your colleagues!

We live and work in a world of continual improvement, whether we’re improving our software, our development practices, or our company policies. As leaders, we often have the freedom to suggest improvements in our team processes, but what do you do when the friction is at a broader level? Perhaps you need to work with other organizational leaders, or partner with Human Resources. Perhaps you’re proposing something for every engineer or every employee. Perhaps you can think of something you’d like to change at your company right now!

In order to succeed, you’ll need to influence others at every step of the way: sharing your vision, aligning on a plan, and following through. Influencing without authority means not relying on personal traits like:
• Your level or role position in your company hierarchy, or
• Your tenure and expertise about your organization.

Those traits can help contribute to the beginning of a process change, but they will not get you to the finish line, and you don’t need any of them to be successful.

What you need is a playbook! You will learn how to successfully navigate each part of the process:
• Validating your hypothesis about the problem, • Gaining sponsorship to safely add this to your workload,
• Interviewing stakeholders to help you develop the right solution,
• Enrolling allies so that you’re not alone, • Following through with a great communication strategy,
• Monitoring your other priorities along the way, triaging as you go, and
• Being recognized for your efforts after meeting milestones.

By the end of this talk, you’ll be able to form a plan to influence change beyond the scope of your team, leading to better outcomes for yourself and your peers. You’ll also avoid the pitfalls of over-indexing on broad impact while ignoring your other responsibilities.

As engineering leaders, we have a large opportunity to scale our effectiveness as our decisions impact the output of our whole organisation. This means our investments in helping our teams become more effective is of particularly high value. A good starting point is sharing the insights that help grow people into effective individual engineers. There is of course so much more to it than this. From reducing sources of friction to optimising career growth goals to align with what produces maximum value, this talk will touch on tips, tricks and frameworks for building effective teams based on over a decade of experience Addy has had working on the Chrome team at Google. The insights here will apply across management and technical leadership.

For years there has been somewhat of a “hero” culture within the ops and incident world, there is always a person who has been at an org for years, knows how to do everything, and saves the day when we need them. Until the next incident.

While we always appreciate our heroes; in order to get out of the cycle of incidents and start learning from them, we have to start treating our post-incidents processes as a team sport. Learning from incidents can make a difference in our teams and companies by helping us turn our outages into opportunities to improve the way we do our work, understand pitfalls, and collaborate better as a team. This cannot be done by one single person though, the magic happens when you have a group of folks who are bought into it, do the work together, and want to learn because they know it makes a difference.

In this talk I will walk you through the different stages of a Post-Incident Process (based on the Howie guide released last year) and explain how to get folks from different parts of your org involved. You will understand how to gather insights from different points of view (not just from the person who fixed it), let folks share their narratives, and most importantly share the learnings to instill progress.

When we involve others we can then move our post-incident processes away from a template-filling post-mortem meeting that everyone dreads attending to collaborative reviews, living documents, and conversations that lead to change!

It’s an oft-repeated mantra around here that security is everyone’s responsibility. Unfortunately, it’s easier said than done and this talk will describe how we introduced a new security approach to empower product teams, enable accountability among team leads and ensure teams and leadership are jointly informed about and responsible for risks.

This cross functional requirement, which can impact the reputation and financial status of any company, being reactively implemented across most teams highlights a process gap.

That is what we sought out to solve and a year later, we have engineers who have learned the value of “why” in security and SDLC controls, as opposed to checking a box like it has been done countless times before, a maturity model that helped leadership take informed decisions. An important aspect of the organizational culture shift needed for improving AppSec is the critical role of security champions. Security champions are your AppSec specialists who help lead, mentor and train the team. These champions help share the load with the dedicated AppSec leaders helping magnify the impact of AppSec in the organization. They lead by example for the development team and are pivotal to the cultural change needed for security.

In this session you will learn: * How to communicate and educate your teams on security approach and best practices * Leverage security champions embedded within the development teams to scale the impact of your AppSec program * Measure and coach teams through the process and to improve both their and the organization's overall application security posture

The need for interpretable artificial intelligence systems grows along with the prevalence of artificial intelligence applications use in everyday life. The current situation is such that these systems are able to predict and decide upon various cases more accurately and speedily than a human. Despite the successes, these systems have their own limitations and drawbacks. The most significant ones are the lack of transparency and interpretability behind their behaviors, which leaves users with little understanding of how particular decisions are made by these models. Explainable AI systems are intended to self-explain the reasoning behind system decisions and predictions. Researchers from different disciplines work together to define, design and evaluate explainable systems. In addition to explaining predictions, providing a global perspective is important to ascertain trust in the model. However, most of the current research has been devoted to explaining individual predictions. In this talk, I present the existing literature and contributions already done in the field of XAI, including a prospect toward what is yet to be reached. Also, I provide newcomers to the field of XAI with an overview that can serve as reference material in order to stimulate future research advances, but also to encourage professionals from other disciplines to embrace the benefits of AI in their activity sectors, without any prior bias for its lack of interpretability.

In January of 2021, I was asked to step into a Director of Engineering role, and despite thinking I was solidly on the technical track, I decided to take on the challenge of leading an engineering team. There was so much that I loved about leading that team, but by the end of the year, I knew that leadership wasn’t for me. And so, I asked to move back into an individual contributor role, and I specifically requested to stay on the team that I had spent a year leading. What I’ve found since making the transition is that because of that year in leadership, I’m a stronger, more confident, and more efficient software engineer than I was before. In this talk, I’ll discuss the specific ways in which leadership has accelerated by growth, impact and efficiency as an individual contributor. Some of these include my strengthened bonds with my teammates; my newfound initiative to take ownership of and suggest change around team processes; my willingness to advocate for time to upskill; and the ditching of my long-time imposter syndrome. I’ll provide specific examples of mindsets and behaviors connected to these growth areas both before and after leadership in order to best illustrate my professional development, with the dual goals of helping existing senior engineers understand their current or potential superpowers, as well as equipping engineering leaders with ideas around how to coach and develop their engineers.

We hold these truths to be self-evident: “Climbing the career ladder” is about expanding leadership, influence, and scope. We aim to answer the question “How should engineers think about the skills to sustain the expansion?”
First, the distinction between “leadership” and “management” can be blurry. Even worse, it’s rarely explained explicitly, and engineers enter management on “You never know until you try 😉”.
We aim to clarify things by making things less clear and breaking “leadership” into three kinds of management, which has helped senior ICs at Two Sigma:
* Team management - Organizations function better when they are happy and socially coherent? Managers are accountable, but Staff+ contribute.
* Project management - Completing multi-quarter or multi-year projects requires a certain skillset. So does feedback.
* People management - How do you manage and direct individuals, especially those who are junior and need more hands-on attention. The “tech track” expects mentorship, and effective Staff+ engineers do not rely on managers “making people do things” to scale projects beyond their own capabilities.

Second, Staff+ involves more than leadership. For that, we present five abstract skills helpfully organized with an R theme: risk, reliability, reputation, relationships, and reducing complexity. In contrast to concrete skills, which explain the how tos (how to write a better document, how to balance meetings with coding, etc.), abstract skills explain the hows and should permeate planning, execution, and communication.
* Risk - Many Staff+ role descriptions include phrases like “sets own priorities.” You’re an expensive asset! How do you get the organization to trust you to invest your time?
* Reliability - What does delivery look like when objectives become more abstract?
* Reputation - How are you representing yourself and your team?
* Relationships - How are you building and maintaining trust?
* Reducing complexity - Are you able to effectively communicate complex information? Are you comfortable with summaries from others?

Agile vs Waterfall. Scrum vs Kanban.In the end, engineering teams are all trying to produce the best work in the most effective and efficient manner. So, I'll throw polychronic vs monochronic time systems into the mix as another layer for understanding any engineering team better.

Time is relative. Or, time is absolute. Both of these statements can be true depending on your personality, or the culture you were raised in. Working with people who do not see time in the same manner can be frustrating and lead to conflict.
 

Understanding these time systems and how they affect both individuals and teams can help technical leaders define the most effective approach for their company, while building a better collaborative culture.
 

This talk will explain the polychronic and monochronic time systems, how different cultures and the processes and tools we use at work relate to time, and finally how to take advantage of the strengths in each to build a better team.

As a manager of managers, you’re not just a tourist on a new manager’s journey. Early on, you must be a copilot. Later, you can step back into a traffic controller. There are several traps managers-to-be can fall into, and you as their manager are responsible for anticipating them. Their success depends on two things: spotting skillset fit and cultivating habitat fit.

Skillset fit refers to their own managerial abilities, and these are the three major traps:
1. Grow other people. Spot the difference between being a great technical mentor and doing career planning, performance management, and hard conversations. 2. Resilience. There will be pain: meeting fatigue, Slack fatigue, people problems, ambiguity, and the constant feeling that they suck at their new job. Dopamine is gone. Spotting a resilient mindset is critical.
3. Technical work. New managers get drunk on what they do best, coding, to feel better during downtime. Too much of it and you’ll suffer their hangover in the form of strategic oversights, misalignment, people dissatisfaction, and at worst, attrition.

Habitat fit refers to their direct reports, the business domain, the tech stack, the stakeholders, and more importantly: you as their manager. The major traps are:
1. Canary deployments. Create an IC-in-testing program in which the IC can progressively take on pieces of management, such as a subset of direct reports or projects first, one pillar of the strategy, and running some ceremonies.
2. Dumpster fires. Throwing a new manager into an unhealthy or complex team is analogous to hiring a junior engineer to resolve 911s. The person will burn out while leaving a worse outage.
3. Support system. A new manager is a senior engineer that just became junior in a new role. Stop thinking they’ll continue excelling out of the gate: they won’t. Assume the contrary until time and training prove otherwise.

It's every developer's dream to simply write code, click a button, and then automatically deploy and run their code at scale. However, developers today are tasked with more than just coding - they are also responsible for deploying, running, and scaling their applications. Kubernetes has been described as "a platform for building platforms". This talk will take a look at how one can use Kubernetes and abstract its primitives to build a developer friendly cloud platform. The key take-aways are to treat the platform as a product. Finding the right balance between ease of use while offering sufficient customization is crucial to having a great developer experience.

Code Review is a great collaboration tool, a socio-technical engineering practice that every developer already uses. I will talk about why we need to focus on the social aspects of it, the best practices around it and discuss concrete ways to promote inclusive code reviews. I will also discuss how we can use the power of diversity through the Code Review process and mold a team’s culture by using the process appropriately. Even if each one of us learns one way to do it better, it would have a huge positive impact in everyday lives of each of the respective Engineering teams.

First-time tech leads face the challenge of learning a new role while guiding a team. Tech leads need to have space both to succeed and to learn from their own mistakes. Teammates, particularly more senior teammates, have to be prepared to provide support without micromanaging.

Don’t remember the challenges of tech leading for the first time? Take a walk in the shoes of a more junior colleague. Follow the story of a first-time tech lead as they navigate ill-defined requirements, uncertainty about measuring progress, and ever-looming deadlines. Learn what they found helpful: mentorship, meeting cadence, team feedback, and self-reflection.

Whether you’re stepping into the tech lead role for the first time or looking to support a colleague in that position, this talk will offer practical solutions for guiding the team to success under the direction of a first-time tech lead.

We work in an exciting, progressive yet equally distracting field. With an ever-growing array of skills to master across technology, engineering and leadership, are you finding it difficult to focus your personal development? Never getting the time to invest in yourself? Forever sampling, but never mastering?

Through storytelling, we explore techniques you can adopt to uncover the leader you want to become — and help you make smart personal development investments to get you there. By standing on the shoulders of giants, we explore techniques to discover your identity vision and create a purposeful and coordinated personal development strategy.

Product and engineering are supposed to have "healthy tension", right? Often the discourse on product and engineering pits us against each other, as if we were competing for resources instead of working towards the same goal. But we're all here to build and run a business; we are allies not enemies. We'll talk about how to assess your current relationship with product leadership, how to develop mutual trust and respect, and common anti-patterns and how to fix them so you can all do your best work.

Whether you are a senior IC working more closely with your PM, a TL trying to figure out your role, or higher up in leadership looking to recalibrate, this talk is for anyone who works closely with a product leader. You will leave with tools for assessing your relationship and improving it and for forging relationships as you step into a new role.