Berlin

November 4 & 5, 2024

New York

September 4 & 5, 2024

All our video highlights from webinars to live events

Highlights from our conferences

Measure for Change

Picking metrics is one thing. But the harder decisions lie in what to do with them afterward.

Drive product gaps as an engineering leader talk by Emily Thomas in LeadDev New York 2024 Conference

Drive product gaps as an engineering leader

Discover practical strategies for engineering leaders to influence product development effectively, even in the absence of strong product management and a clear company vision.

Smruti Patel

Growth in a downturn

In this talk, Smruti Patel asks, if hyper-growth is marked by spending more to make more, what does building for enduring growth look like?

Idea to Innovation

Join me as we embark on a journey to dissect the anatomy of innovation, uncover strategies to unlock the full potential of ideas, and transform them into impactful realities. Let’s build a strong culture of innovation, and make sure that it is not just a buzzword but a tangible outcome.

Slack enterprise key management: Senior to staff lessons

Explore the key lessons and skills Audrei gained during their first Staff+ project, Slack Enterprise Key Management. This talk offers insights for anyone growing in their Staff+ career.

  • Lessons for frontend development at scale

    Powered by technologies such as React and GraphQL, we see frontend applications reach a level of scale and complexity that was traditionally associated with backend engineering and service architectures.

  • Learning from incidents: from ‘what went wrong?’ to ‘what went right?’

    When things go wrong, we tend to focus on mistakes, miscalculations, and deficiencies in design. By limiting our investigations to the details of what went wrong, we ignore a far richer and more interesting source of learning: how things went right.

  • Scaling performance at the scale of Slack

    One of the major challenges faced by teams working on high growth product is of performance. Systems that are built for a given scale of users often fail to deliver the necessary throughput when run with orders of magnitude of load more than what they are built for. Software teams have historically resorted to a myriad set of ways in scaling performance.

  • Distributed teams: how to hone connection, communication, and collaboration

    Psychological safety is one of the leading indicators of a high performing team. Yet, forging deep human relationships and building trust can be difficult when your team is distributed or largely interacts on screens.

  • Building blocks for architecture governance with autonomous teams

    Many organizations today strive to establish autonomous development teams who can move as independently of each other as possible.

  • Strategies for making impossible decisions

    Being faced with an important choice that feels impossible to know the answer to is stressful! This comes up a lot when making business decisions, but also applies to technical choices (e.g. “should my company run 100% on AWS” or “is serverless a fad or a great idea?”).

  • Breaking down silos for better collaboration

    Technology at Spotify is filled to the brim with talented, driven and passionate engineers, who together work to solve the challenges we face to reach our north star goals.

  • Creating an inclusive engineering culture

    Having a tech career as a minority is challenging. It could mean being the only one to speak against the popular opinion, or becoming more visible to get the same level of recognition.

  • Writing effective technical documentation

    Documentation can make a big difference. Internal documentation can speed your team up and makes it easier for new engineers to get up and running. External documentation reduces time spent on support questions, and makes your product more usable.

  • Making the right salary decisions for your engineering team

    You make a hire for your team. The person wants 20% more than anyone else. Should you give it to them?

  • Handling security issues as an engineering team

    We live in a world of technology and engineering. Almost everything around us requires software. Unfortunately, the software we use or build has bugs. While most bugs can be fixed, there are these other types of bugs, called vulnerabilities, that cause headaches and haunt us at night.

  • How to affect change without losing your job

    Sometimes, we want to make changes to processes and habits our team has, but it’s not around the code itself. How can we do that? How do we make changes to the habits of hundreds? Moreover, how can we do this work as individual contributors?

  • How to scale yourself as a first-time engineering leader

    When you’re a first-time leader it’s hard to transition from being a problem solver to leading a team to solve problems. It’s often tempting to step in and solve problems for your team.

  • Bridging the gap between engineering and customer success teams

    Investing in your customer success team is high leverage. The more knowledgeable your team is, the more effective it can be at investigating, diagnosing and triaging customer issues.

  • Using an ‘architectural North Star’ to align your engineering team with your organization

    In a fast-growing, agile organization, teams are usually encouraged to self-organize. Equipped with the guiding principles such as fast iteration and frequent feedback loop with the customers, we entrust the most valuable asset, people, to make informed decisions.

  • Transitioning from technical leadership to parenthood, and back again

    Navigating any new personal scenario while leading a team can be extremely challenging, but last summer I found myself nine months pregnant and leading our engineering organization through an acquisition while preparing for the birth of my son. On the day he was born, I got the news that the acquisition had been finalized.

  • Extended leave: how to manage the anxieties of returning to work

    As more companies offer longer parental leaves and other leaves of absence, managers and their teams are learning how to handle them successfully.

  • Driving architecture alignment across a fully-distributed engineering workforce

    InVision started as a small startup several years ago with tens of engineers, small teams working independently as velocity was paramount. But as InVision grew to hundreds of engineers, all fully remote, we realized that this independence was actually slowing us down – teams resolving the same problems, inconsistent metrics, etc.

  • How to hire remote junior developers

    You wouldn’t hire a senior developer without giving them any support or possibilities for growth, would you? Of course not!

  • Crafting effective 1:1s for distributed engineering teams

    Creating relationships with the individual humans on your distributed team is difficult since you rarely get to see them in person! But a team is much less likely to be effective and successful without a foundation of interpersonal relationships and trust.

  • Splitting the monolith

    After years—even decades—on the existing legacy mainframe, we pitched a plan to migrate a company to a new, microservices-based architecture. Convincing management seemed easy, but now we have to deliver: Take the years-old legacy system and break it apart into smaller services and systems we can actually maintain.

  • Solutions for creating and managing inclusive projects

    Corporate Culture is an ecosystem and diversity is the air we breathe. As such, how a project/delivery team cultivates its culture impacts the entire project, client relations and end-user experience.

  • Clear, concise and consistent: how to communicate and prioritize risks from the engineering team to the wider organization

    Communicating risks, particularly to our non-technical colleagues, is a challenge and by not doing it well we suffer pushback from the business. The risks are varied and at all different levels, but can include technical debt, skill gaps, team burnout, and more.

  • Lessons from flying for engineering leadership

    In October of 2008, I’d been unemployed for about four months. I was doing some consulting work, but still feeling entirely uncertain about my ability to make a living, so I did the obvious thing: I decided it was a good time to learn how to fly a plane.