LeadDev New York Agenda - March 14-15, 2023

After years of high growth, many tech companies realized over the last six months that their projections were too optimistic. As a result, they changed strategy, cut budgets, restructured, and laid off many thousands of employees. Having spent years interviewing, hiring, growing teams, and taking bigger strategic risks, our roles as leaders are now shifting.

In this talk, we‘ll explore:

• What principles can you apply to lead in this time of uncertainty?
• What does it mean to optimize for efficiency as a technical or people leader?
• How can you manage up to keep your boss in the loop and stay aligned?

Leading in a tech downturn is challenging for you and for your teams. Applying the steps outlined in this talk will help you change the way you think and operate, and will help you be the leader that your business and your team needs during this time of uncertainty.

Much of the research on hackathons has focused on success only defined in terms of their impact on products: for example, how many hackathon projects lead to new features. But hackathons can also be a critical turning point for people: a place where developers can safely experiment with new identities and new ways of working together.

In this lightning talk, I’d like to share an example of a successful internal hackathon at Pluralsight and how it impacts developer experience. I’ll present evidence from our original research study, where we used rigorous research measures of anxiety and imposter syndrome to find quantitative evidence for the benefits of hackathons with 64 participants, using pre- and post-measures from behavioral science. Crucially, we found that teammate behavior during hackathons was an important lever for mitigating people’s stress, anxiety, and imposter syndrome, and that positive hackathon experiences can predict not only good outcomes from a single hackathon, but also people’s likelihood of engaging with hackathons and new technical work afterward.

Hackathons aren’t just good for team-building in the moment: in our study, we found that hackathons can serve as a microcosm for engineering teams in general, which work in similarly high stress and time-limited environments. One key take-away from our story is that leadership investment in small but powerful novel learning opportunities outside of people’s normal day-to-day work, like hackathons, can have a long-term impact in developers’ growth and sense of belonging within an organization. In this talk, I’ll provide science-backed, actionable recommendations for how managers can run successful hackathons, foster a culture of team belonging and learning, and mitigate the impacts of workplace anxiety and imposter syndrome, which disproportionately impact employees with minoritized identities.

What if tech debt wasn’t always an accident, caused by incorrect assumptions and unexpected circumstances? How would you spend a tech debt mortgage? This talk presents an investment-based approach to thinking about software development. Time is our currency; we can spend it now, and we can also take on technical debt that commits us to spend time later. Project tasks are investments that cost time and return something of value, like user-facing features or learnings for the development team. But watch out—most investments aren't a sure thing, so you need to spend wisely. By taking risk into account and prioritizing creating value sooner, you can reduce wasted effort and improve your project's odds for success. We'll discuss how this framework was used to rapidly build and ship Squarespace's Email Campaigns product in less than 15 months. Along the way you'll get several practical guidelines for how tech debt can supercharge your technical investments, with real examples from inside Squarespace.
 

At Spotify, we have historically built services based on our own proprietary messaging protocol and framework. Three years ago we kicked off the daunting multi-year task of migrating everything to gRPC. Migrating over 3000 services to gRPC poses interesting challenges, many of them are not technical in nature - it all boils down to questions of engineering culture and leadership at scale: How do you get 400 autonomous engineering teams to align on something as fundamental and cross-cutting as a new RPC framework? How do you roll-out gRPC at scale with minimal disruption to both the organization and to the end-user? This presentation will address these questions alongside more technical discussions of advanced gRPC concepts such as interceptors, load balancing, and traffic management and how they are essential in large distributed systems.

Whether or not folks call those incidents is one thing, but these events take us away from our day-to-day which impacts our productivity, planning, and goals. What can we learn from these reactive, coordinative events? The data on how our companies can improve is more often than not, hiding in these seemingly innocuous, reactive events, how people coordinated around them, and who participated. Over time, they become our culture.

In this talk, Nora will dive into how we can get the most out of these events before they become our culture in a way we didn't intend.

This talk describes how an engineering lead can identify prospective team members, enable them to gain experience in the proposed role, and ultimately make the switch. Done well, this represents a win-win: the engineer enjoys a role they are excited to take on while the lead gets a motivated employee whom their experienced engineers can mentor. This talk is based on my experience at Square, first switching from a machine learning engineer role to a backend software engineering role and then into engineering management. In both instances, I was able to try out the new role, gaining confidence that it was the right choice for me all while proving my ability to succeed at it. More specifically, this talk will discuss how to:

• Ensure sufficient motivation
• Align on goals
• Avoid impossible guarantees
• Create a support system to maximize chance of success
• Gain confidence the candidate will be effective in role

 Most leaders identify strongly with the work they chose to commit to. When a workplace unexpectedly can’t return the commitment, it can really throw us for a loop!

In this talk, I share my layoff experience. Recounting this, I hope to share some practical considerations and grounding thoughts that might be of use regardless of your employment situation.

The answer is communication. Social science researchers have shown that how managers communicate plays a pivotal role in company success. In this talk, you will hear about the three main categories of communication — pathological, bureaucratic and generative — and the important role they each play in a company's success and failure.

You'll learn how using a generative approach lets employees see how their work is having an impact and imparts a sense of ownership and value. I will also lay out the quantitative and qualitative benefits of a mission-focused management approach, from measurable increases in productivity to satisfied engineering teams engaged in work that excites them.

How we behave as leaders can have a massive impact on how our organization behaves. Do we encourage experimentation by celebrating failure, or do we shut down anyone who brings up potential issues? It's time to pull back the curtain and face the facts: how we communicate determines whether a company thrives or fails.

Many teams know it's time to start getting serious about security, but don't know where to start. In this talk, I'll try to tell you as much as possible in 30 minutes about what you do need to worry about, when you need to worry about it, how you can fix it, and what you don't need to worry about — yet.

We'll go over application security, infrastructure security, detection and response, and all the random IT cruft that you've started using and forgotten about already. You'll get a balance of "how to think about security" and "do these specific things first", along with some of the pitfalls teams run into. We'll also cover the choices you can make about both your technology and how you manage your teams that can make the systems you build more security and more resilient.

As more and more companies offer longer than before parental leaves or sabbaticals, we as engineering managers are faced with the grappling question of - how will my team fare when I am gone? Will all hell break loose? Will things remain about the same?

In this talk I will share the things you can do to ensure success for your team while you are away. I had the privilege of taking 6 months of parental leave and when I came back, I was pleasantly surprised to see things functioning great, with the team having made great strides towards our annual goals & KPIs. Not only that, ICs had grown themselves in different skill sets, each of them assuming different roles and responsibilities while I was away, helping them move up in various competencies.

This talk will broadly cover:

• What all should your handover document cover
• How to assign ICs on your team various roles and responsibilities while you are away
• How to build an efficient roadmap with your product partner ensure long term success for the team
• How to find someone on your team who can step into your role when it comes to making important engineering decisions
• How to continue to promote aspects of culture which you have created to ensure everyone feels motivated and excited about working in the team

What do you do when faced with a seemingly impossible situation that may also affect your own role?

I had the chance to build and lead an engineering group over several years that was delivering results on-time and had an objectively great culture, but still suddenly had our product canceled just weeks before launch. Within minutes I went from planning multi-year roadmaps to figuring out how we could wind everything down, all while helping the team process their own reactions to the news (and trying to process my own).

I’ll share how the mistakes I made early in my career as a manager helped prepare me to handle a terrible situation in a way that stayed consistent with our values and got the members of my team to the best, most empathetic outcome we could hope for.

Do you want to be that go-to engineer who solves those weird problems? That requires an understanding of the low level components of your systems. Not just the (virtual) hardware, but the OS, algorithms, and how it all works together at a fundamental level. Leaders: come learn why this matters to your product, engineers, come learn why the investment is worthwhile.

Software development teams traditionally use the retrospective ceremony to reflect on their results, performance and processes. But the software team retrospective can – and should – periodically focus on team-level concerns beyond these traditional themes.

In this talk, Kristen Foster-Marks will share her experience of leading a learning-themed retrospective, which encouraged her team to reflect on their personal beliefs about learning and up-skilling, their team’s learning culture, and the ways in which these beliefs and culture can both encourage and discourage engagement in on-the-job learning and up-skilling activities. Through this exercise, her team began to identify the strengths and weaknesses in their learning culture, as well as if, how and why they’re accumulating personal and team-wide learning debt.

Engineering leaders will walk away with vignettes around up-skilling challenges that she and her teammates have faced in their careers, as well as an overview of and access to a learning-themed retrospective template.

Making the leap from managing your own work to managing others is a big career move. Managing managers might seem like more of the same but it's a whole new role which requires different skills. Just as important, we need to adopt new mindsets. This talk will cover the difference between the two roles and the key mindset shifts leaders need to make to manage managers.

Despite the excitement in the industry for Engineering Platforms, the truth is that they are often created without a strong product vision, and they end up being either not fully adopted or, worse, negatively affect the organisation's throughput.

While the concept of "Platform as a Product" is more well-known nowadays, most leaders are left with little clarity on how to apply product thinking to their platforms and what metrics to use to drive their evolution. I'll share the HEAT metrics we created while working at Babylon, how they helped us create a successful Platform Product, what essential product decisions you need to make to help other teams strive and how they fit with other engineering metrics like DORA.

It's easy to feel overwhelmed as an engineering manager. But how is it that some engineering managers work flat-out managing a handful of reports, whereas others can juggle multiple teams without (seemingly) breaking a sweat?

This talk is all about how to spend your most precious resource as an engineering manager: your time. We'll look at the "buckets" you should be investing your time in - people, process, interfacing, technical, hiring and strategy - and how that investment typically evolves as you increase your scope. We'll look at how you can setup effective filter systems, to avoid information overload while ensuring nothing gets missed. We'll also explore how to catch the trickiest problems you'll face as an engineering manager early, to avoid cascading failures that will quickly eat up your bandwidth.

Finally, we'll look at how to strategically spend a little of the time that you earn back, to work on high-impact, org-wide initiatives. Taking a couple of examples from myself and colleagues, we'll see how spending just a few hours a week addressing your organization's hardest challenges can be genuinely transformative - both for your company, and for your own career.

The talk aims to be as practical as possible - giving specific, actionable advice and examples throughout. Attendees should leave being able to more strategically spend their time, and create better work-life balance without sacrificing their impact.

Wouldn’t it be nice to have all the insights so you’re making the best decisions as to how to evolve in your career? Perhaps you want to roll the tapes forward to see what the future looks like. What exactly is expected at each level in the Staff + path vs the senior management path? How does one side work with the other? What changes as you progress as an engineering manager? Is there a symbiotic relationship between the two roles? Or maybe you’re at a pivotal moment in which you’re actually deciding right now which path you should take!

In this talk we’ll give you two perspectives! We’ll share our experiences and challenges from both sides of the senior leadership coin: staff+ and senior management. From navigating promotions in both tracks to the overlap in the problem spaces – we’ll share some uncut gems that will help you anticipate the changes in your role as you progress in your career.

The process of creating a technical strategy can be bewildering: it seems like strategy documents come in all shapes and sizes, and it’s unclear where to even get started. Fortunately, creating a good technical strategy doesn’t need to be this complicated, and setting successful technical strategies can become a reputable process.

This talk will dig into the nuts and bolts of setting a successful technical strategy. We’ll start by talking about the difference between technical vision and technical strategy: two concepts which are often discussed together, but serve very different purposes. We’ll then discuss the three core elements of a technical strategy, and how you can use a technical vision to inform those core elements. Finally, we’ll close with some common pitfalls of bad strategies and how to avoid them. You’ll leave with all the tools you need to create a crisp and successful technical strategy for your team.

Tech policy is a confusing term. It’s used both to describe the laws that regulate the technology industry as well as the technology that governments employ to provide services to their constituents. Should tech companies be liable for the content on their platforms? Tech policy. Should the US Army build applications on AWS or Azure? Also tech policy.

The world of tech policy is both vast and niche. Most congressional offices include it as a subset of a single staffer’s portfolio, often lumped in alongside transportation and telecom policy. But over the last decade, many people in DC have recognized the need for more technical expertise in government. There are now a collection of programs that allow for industry leaders to engage with the public sector without having to permanently alter their career paths.

In this talk, I’ll discuss some of the big ongoing tech policy debates and walk through ways you can get involved in the policy world. While I have spent my career in the private sector, I have done several fellowships in the tech policy space and am excited to share what I have learned with the LeadDev community.

One of the reasons proposed for these disparities is the Confidence Gap: the idea that men typically apply for roles when they meet 60% of the job requirements while women need to meet 100% of the requirements to apply. This statistic is culturally resonant - people from around the world in all sorts of roles refer to it and a wealth of anecdotes in the world recruiting backs this observation up. However, the root cause of the Confidence Gap is understudied. There's a lot of research to suggest that women feel as confident in their skills, abilities and leadership as men. Perhaps we have mistaken the symptom (that is, women's inability to promote themselves) for the cause?

In this talk, I will discuss how our studies of the confidence gap impact candidate pools based on millions of recruiting outcomes. I describe three specific contexts where we've seen the confidence gap manifest (overqualified roles, job titles and language of job descriptions) and describe a model for the confidence gap and what that means for companies trying to recruit fairly. I also discuss what that means for individual job seekers and mechanisms they can use to overcome it.

Every lead and every dev manager has been here in the past two years: The star developer on your team sets a fifteen-minute meeting on Friday morning for 2:30 pm that afternoon, with subject "Meeting." Uh-oh. And the meeting starts with a big sigh: "Well, this is hard to say, but..."

You're about to have ten business days to do lots_of knowledge transfer. You're about to revisit every roadmap and try to understand what's about to happen to your velocity. There's got to be a better way than just imploring that "everyone document everything." And there is!

There's a number of specific, useful things you can do to be prepared for turnover. You can implement specific strategies of team makeup, rotation of responsibilities, and flexible estimation that will not only take the dread out of "star performer" syndrome, but will also make everybody's job simpler, more productive, and more fun.

Ironically, being ready for team turnover can actually reduce team turnover. And it'll take some of the dread out of Friday afternoons!

This talk will be about specific, actionable strategies to prepare for turnover - roles and responsibilities, documentation practices, anti-patterns to avoid, and even "chaos monkey" style games - that you can use immediately to make life better both for you and for your team.

The ability to tell a beautiful story about yourself, a product, the work you do, or your team is truly a gift. Over the years and after sitting through many interviews, and presentations I've realized one thing--most of us aren't good story tellers--and that's OKAY because I am going to teach you!

For me, as a leader storytelling is not just important for product launches and marketing strategy--learning how to tell our stories is about getting people to believe in YOU. Telling great stories about a product creates evangelists: people who believe in your idea or product and promote its value to others.

This talk will be about how to structure compelling stories that lead to alignment, buy in and most importantly belief from our stakeholders, partners, and more importantly our teams.

In her landmark book Accelerate, Nicole Forgsen describes the DORA4 metrics, which represent four different metrics that calculate the performance of a software development team. The ultimate goal of these four metrics is to make changes small, manageable, and frequent so that when things go well, you build more momentum, and when things go wrong, you can correct the mistakes quicker.

I believe this fundamental philosophy can also be applied to feedback, where giving it early and often is the best way to achieve a sustainable, healthy, and evolutionary feedback culture. 

You might have 1:1s, quarterly, and yearly reviews where you regularly give feedback to your reports, but I would argue this is not often enough. In a healthy feedback culture, people should be giving and receiving feedback almost every day. Applying these simple metrics will avoid the need for the big-bang feedbacks everyone dreads giving. Instead, you will foster a culture of constant corrections and adaptations that good feedback provides.

In this talk, I will propose a model much like the DORA4 model, except instead of focusing on metrics like time to merge and rate of recovery, I will focus on my personally developed metrics for feedback that ensure I am giving it early and often.

This talk will share key learnings from building and shipping Spaces within Twitter, and how those learnings can be applied to any new team looking to move quickly within a larger organization. It will focus on how we were able to gain developer velocity by applying simple principles to our team culture, focusing around simplicity, autonomy, and collaboration. As we go through the principles, we will explain how they each contributed to the team's success, and how it can be applied to other teams in similar situations.

Since you're working with TF, you probably went through its documentation, and see what resources can be used - BUT do you always have a clear path towards using them? How should you structure Modules or your TF code in general?

I’ll cover the good, the bad, and the ugly when it comes to Terraform, so you’ll ultimately have a go-to approach for working with it, and make you think about the big picture and utilize TF in a broader context rather than just an “infrastructure as code" tool.

The Evolutionary Architecture literature teaches us that everything in software engineering exists in an ever changing, “dynamic equilibrium.” As engineering leaders, what do we do with this? How can we be successful in an environment that is unlikely to remain in a steady state for long?

Through personal stories about managing large and small-scale migrations, I’ll talk about observations I’ve made and techniques I’ve used to evolve systems over time. I’ll also explore the idea that we can model and de-risk change by thinking of everything as a migration from a current state to a desired state and what that means for our architecture and teams.

An EM’s primary responsibility is to make their team and people successful, creating an environment where the team is productive and its members fulfilled. But how much should an EM actively act on their team to achieve those goals?

Leading as an EM is a challenging path, balancing being proactive enough to drive positive change while avoiding micromanaging engineers while doing it. In addition, a lack of leadership and excessive delegation can negatively affect the team in different areas like productivity, tenure, and diversity.

This presentation will discuss how to achieve this balance using systemic thinking, talking about how an EM can be a positive leader for their team. It will:

• Discuss the challenges of lack of leadership in software and why an EM should act as a leader for their team.
• Talk about how EMs can think systemically about their team, focusing on creating productive environments that empower diverse people within them.
• Introduce practical management techniques that EMs can use to lead positive change.

It will focus on how EMs act efficiently as leaders, creating successful and diverse teams where engineers are fulfilled to work in.

How do you recruit great software engineers?

For two years, I curated and delivered the Made Tech academy programme. Two or three times a year, we recruited between twelve and twenty-two individuals with minimal coding experience. They earnt a salary while training full time in modern software development techniques, followed by a new job as a software consultant.

We deliberately targeted under-represented groups and did not expect candidates to have any qualifications at all, or even any work experience. All we asked for was a commitment to tech and a small amount of coding experience.

From modest beginnings and over a period of five years, Made Tech have built a highly successful and effective training programme which is still going strong. In this talk I share some of the principles and techniques which make it work.

Key takeaways:

·         How to recruit fledgling engineers

·         How to use an academy programme to nurture new talent and maximise diversity

·         How to curate and deliver effective learning content

·         How to build an ongoing learning culture