We're very excited to welcome this year's speakers! They'll share insights and experience on cross-platform engineering, crucial career conversations, remote teams, technical leader burnout, and so much more.
The schedule will be announced soon. If you're booking travel in the meantime, we expect the conference to start around 9 AM and finish around 5:30 PM.
Looking to make the most of your conference experience? Check out our training workshops on April 29.
When Julia Grace joined Slack 3 years ago, the company had fewer than 100 engineers. It’s now at more than 500, and her own team grew from 10 to 100 people in 2 years. Julia shares tips and stories from the leadership front lines as she learned how to rapidly scale herself and her leadership team during a period when her job was substantially changing every six months.
As engineering managers, we're used to managing the Sprint Burndown chart. Even in non-agile projects, the idea still applies. Over time, the amount of work that remains to be done should go down, and good engineering managers carefully guide the team towards this goal.
However, engineering managers have to manage more than backlogs of user stories. They have to stay current with an ever-changing technology landscape, manage the professional and personal concerns of their team members, navigate office politics, and solve the challenges of their own lives. These competing responsibilities often result in burnout and a reduction in the capacity of engineering managers as well as the teams that rely on them for direction.
This talk will provide insights and tools to help engineering managers reduce burnout and keep their stress levels in a managed state.
Career conversations are a necessary part of your direct report’s growth, but without care, these meetings can lack purpose, meaning, and impact. Are you really getting to the heart of their struggles and aspirations, or do you find yourself going through the motions, setting minimally viable targets just to be able to say you did? If you’re not having meaningful career conversations with your direct reports, you’re missing out on one of the best opportunities you have to learn what motivates them and help them set specific goals so that they can shine on and within your team.
In her book Radical Candor, Kim Scott offers a framework for career conversations where you ask your direct to tell their life story, share their dreams, and make an action plan for the future. No small feat! In this talk I’ll share stories of the framework in practice, putting the test on my diverse and distributed teams. I’ll share what went well and what didn’t, strategies for course-correcting, and how I built scaffolding to support and deepen the conversation.
You’ll learn how career conversations are not only a critical tool for your direct report, but crucial to helping your whole team grow together, and will even improve your ability to collaborate with your direct. With clear guidance, you’ll feel ready to schedule meetings that matter.
Having worked extensively in the Shopify codebase, one of the largest rails apps in existence, I have experienced firsthand some of the downsides of working in monolithic codebases. These include painfully slow tests, new code causing unexpected repercussions due to dependencies across functional boundaries, and decreased developer productivity due to the need to understand the entire codebase to be effective in it.
During this talk, I will discuss how to identify these symptoms and others that are tell-tale signs that the monolithic architecture is no longer serving you. Once identified, I will walk through the architecture and pros & cons of two alternative solutions, both of which I have implemented.
As technologists and technology leaders, we live in an interesting and chaotic time. The days of ivory-tower enterprise architects doling out treatises on approved technologies are over, instead, we have agile, two-pizza teams building using emerging architecture techniques and the latest languages. How do we get a handle on this environment and make sure what's being done is documented and communicated out to the larger organization?
In this talk, I'll discuss three techniques that can be used to help:
All of these may not be right for everyone, but taken together, they can be a powerful force to help document and communicate the decisions that your teams are already making every day.
The quest for the perfect cross-platform solution has been like the quest for the Holy Grail. It’s been going on a long time, there are a myriad of perceived benefits, and every time someone claims to have found it, it’s never the right one. Many people ask, “Should I go with a cross-platform solution, or a native solution?” but the reality is the quest is bringing us closer to a solution where there isn’t a meaningful difference.
React Native wasn’t the first to show a solution could be both cross-platform and native, but it has certainly convinced a lot of people. As many of those early converts are discovering the limitations, they are beginning to fall back into either-or thinking. Maybe they just have the wrong assumptions.
Kotlin Multiplatform makes some new assumptions and, although it wasn’t the first to do so, is gaining in popularity very quickly. Is Kotlin Multiplatform the holy grail of cross-platform? Probably not. But it does bring cross-platform and native closer than ever before.
This talk will map out the quest for the perfect cross-platform solution, why we embarked, the twists and turns we’ve had along the way, and why the future of cross-platform is native.
As an engineering leader, there will likely come a time when you need to manage your team through change. Sometimes it will be a lot of change all at once and sometimes it will be a series of changes over time. Change can also manifest in many forms like technical and architecture change, cultural change, and organizational change. For example, in just the past year I've worked at a company that has re-architected our platform, been acquired, grown significantly, and hired a new CEO. Through all types of change, your team will need you to support and lead them through it.
In this talk, I will walk through a framework for leading engineering teams through change, using real examples and things I've learned as an engineering leader during times of massive change and growth. Some experiences I'll draw from include: working at five different companies who have been acquired, re-architecting dozens of different products and platforms, and spearheading several culture changes and re-orgs. The framework will pivot around two important centers: the phase of change you're in and the leadership qualities you can use to support yourself and your team. There's an expression that 'change is hard' which is true, but I hope to empower other leaders with a framework and toolkit to make change more approachable.
How confident are you in your prod servers staying up without your help? Too often in tech we mistakenly interchange three important concepts when describing our socio-technical systems: how resilient they are, the reliability they exhibit in day to day work, and how robust they are under duress. Though interrelated, they are not equivalent.
How can we successfully gain insights in post-incident reviews, execute chaos engineering experiments, and build scalable infrastructure if we're misinterpreting our approaches? By separating out these core concepts, we can isolate better approaches in adapting to unforeseen circumstances. We'll look at common misconceptions when describing our systems as resilient and focus on proven methods to help us improve our understanding of our systems.
Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team won't be as successful. But now someone's suggesting that you might be happier in a less technical role. If this describes you, congratulations: you're the glue. If it's not, have you thought about who is filling this role on your team?
Every senior person in an organisation should be aware of the less glamorous - and often less-promotable - work that needs to happen to make a team successful. Managed deliberately, glue work demonstrates and builds strong technical leadership skills. Left unconscious, it can be extremely career limiting. It pushes people into less technical roles and even out of the industry.
Let's talk about how to allocate glue work deliberately, frame it usefully and make sure that everyone is choosing a career path they actually want to be on.
Your team has communication problems. You just can't see them because you all sit in the same room. Techniques that work well for co-located teams break down once remote workers join a team. The local team dials-in the remote to make them feel part of the team, yet remotes still feel disconnected. They don't feel like they have an equal voice in meetings. They feel like they're missing key conversations from the hallway track. And having an ad-hoc, impromptu conversation usually requires booking a meeting room. What if we are approaching this problem the wrong way? What if the issues are not about remotes but rather latent issues exacerbated by being remotes?
An environment with everyone in close proximity encourages synchronous communication. You will learn how asynchronous communication and systematic documentation offers a far more inclusive environment and more accountability.
An open office makes it easy to break into impromptu brainstorming sessions. You will understand why fostering the distraction-free environment that remotes enjoy can also benefit your co-located team and let them get into the zone.
This talk will uncover how to improve your team’s productivity by learning from remote team best practices. By approaching team collaboration from a remote-first perspective, you can gain insight into your co-located teams’ inefficiencies.
One of the biggest challenges in people management is ensuring that your engineers are growing in their career. We expect larger companies to have an established career ladder, but it often gets sacrificed at many companies in the name of remaining “flatter” and “more agile”. As the demand for talent gets more competitive, painting a clear growth path for engineers becomes an asset in any serious engineering organization.
Marco Rogers will give a concrete idea of what a career guide looks like for engineers based on his experience as an engineering leader at multiple companies. There are the big things like creating levels that engineers progress through, and addressing what “Senior” means. He will also touch on the less obvious aspects, such as providing guidance on how to get promoted, and maintaining consistency between internal hiring and external recruiting.
Keeping an application stable starts off being simple since your codebase is small, there are few points of failure, and you can easily reason about the implications of code changes. Once the team scales, managing quality becomes intractable as your hire engineers, acquire users, and ship features and refactors. In this talk, I cover several systems and processes you can use for managing application reliability.
On-call duties are high in the list of things developers dislike doing the most. And there’s a reason for that. On-call work can be tedious, and can also be very time consuming for people in teams. In the worse cases, it can literally keep people from sleeping.
Many engineering teams though fail into taking an engineering methodical approach at defining what a good on-call rotation looks like, so they could focus on reducing the burden of being on-call for their software stack.
In this talk, Fernanda will share her experience working in production systems for over 10 years, and share principles and practices on what can make on-call much less painful to the people doing it. Applying some of those principles and practices, you’ll be able to get your on-call under control, and have a happier and more productive team as a result, focused on the long term projects instead of fire-fighting.
When using tens or hundreds of microservices to provide an application's critical functionality, diagnosing what interaction between components is causing an outage can be challenging. Engineers spend a lot of time building dashboards to improve monitoring but still spend a lot of time trying to figure out what’s going on and how to fix it when they get paged. Building more dashboards isn’t the solution; you need a new set of strategies to understand your systems. Learn from Liz's experience working with companies large and small introducing better observability practices to developers and operators.
True or False. Zero or One. Computers are viciously black and white in their logic.
Humans, on the other hand, are messy — Emotional, forgetful, biased and opinionated. Convincing one person can be hard. Harder still is having influence over a team, especially when you need to manage the implicit authority (or lack thereof) your title may afford you.
That’s the key: the growth of your career, whether as an individual contributor or a manager, will be dictated by your ability to drive impact at increasing scale.In this talk, learn to capitalize on your interpersonal connections within your workplace to drive consensus, to optimize your time and efforts while selling your ideas to others, to reduce surprise to help you achieve your goals, and to build a strategy that can be bought into by other leaders and executed on by your team without you having to micromanage the process.
Are you looking to grow your engineering team, engage with the community and gain brand exposure? Please get in touch with Daisy Wort, Sponsorship Manager, to request a sponsor pack.
Sign up to receive updates about The Lead Developer Conferences, including speaker previews, ticket launches, Call for Proposal details and other exclusive content. We won’t spam you and will only send you emails we genuinely think you’ll find interesting. You can unsubscribe at any time and you can find more information in our Data Promise.