Explore what’s happening at StaffPlus New York

The systems we build today fundamentally affect nearly every aspect of human life, and the largest count their user bases in the billions. This means the way we used to work, focusing entirely on how our systems might succeed, is no longer enough: like other engineers, we now need to be simultaneously focused on how our systems might fail, and making sure they fail safely.

This is a fundamental change in the way we do our jobs, and it falls on us as leaders to understand this, articulate it, and work it into every aspect of what we do. I’m going to discuss what this looks like for real systems and how engineering and product leaders can drive this change in our profession.

As engineers upgrading long standing features and products, we sometimes have to choose between the correct engineering decision and the decision that is best for our users. This talk walks through the experience of uncovering surprising use cases and navigating that tension in a product release journey. 

Guiding OSS projects can teach us about scaling ourselves, influencing technical direction, and collaborating effectively across disparate team members.

In this presentation, I'll share the lessons learned by me and other open source maintainers that impact how we perform as staff+ engineers and leaders today.

While there isn't a simple yes or no answer, in this session, Tanu will share a decision-making framework with examples that can help you figure out the right answer for your organization. 
 

What they need is not more technical discussion or research, but rather someone who can bring clarity to the path forward, distill their many pros and cons into concrete risks, and finally push them to action. By way of an example of a recent AWS -> GCP migration, I'll show that we're all on this ship together, we know where we're headed, but we just need to agree on what's happening on the Lido Deck and when, and make it happen. 

Companies can experience canon events too – most often in the form of a high-severity incident.

Incidents are unavoidable; they will happen. However, how you choose to respond to them is what matters and for better or worse, it will shape your engineering organization. In this talk, I’ll take you through a journey of a few canon events I have experienced throughout my career, including ones with names such as “The Great Reliability Crisis”. I’ll also share some things I’ve learned and how best to guide teams through them.

You know why there are daily grumbles from your developers and why it's so frustrating to make seemingly small changes to the system. You know why you are shipping buggy releases. The trouble is, you can't seem to convince management to let you do the work. Or, worse, you CAN convince them, but it always falls off the priority road map; feature development takes first place. 

Why is it so hard to convince others of what is so obvious to you? Because you are doing it wrong. 

Come and learn from my mistakes and my successes pitching a large refactor project when I was a Senior Staff at Slack. I will tell you about my experience tech leading a major internationalization and localization project that I turned into an infrastructure rearchitecture project. My small and mighty team of four ended up saving us months and month of development time, reducing overall development time by ~65% and leaving the code much easier to understand. 

I will show two example pitches: one is a typical pitch scenario that I've seen get rejected time after time, and the other is similar to the pitch that was accepted for the large infrastructure project at Slack.

While frequently well-intentioned, this advice gives developers the message that there’s something wrong with them or their code if they experience code review anxiety - a message that is not just inaccurate, but even damaging. So what can you do about code review anxiety? As a clinical scientist in the Developer Success Lab with expertise in stress and anxiety, I recently decided to go up against this harmful advice with scientific evidence on who experiences code review anxiety, how it is maintained and exacerbated, and what we can actually do to mitigate it. 

In this talk, I’ll share the story of my empirical research conducted with software engineers and developers across industries experiencing code review anxiety. You’ll learn about our new empirically tested model of code review anxiety and the important cognitive mechanisms like self-efficacy, probability bias, and cost bias that maintain and exacerbate code review anxiety. I’ll also share how a brief intervention can help junior and senior engineers manage their anxiety about giving and receiving code reviews. Along the way, I’ll pull the curtain back on how we do “developer science,” sharing the journey of developing and scientifically testing a code review anxiety intervention based on cognitive-behavioral therapies, using a rigorous randomized control experimental design – the same methods that we use to test interventions in complicated real-world settings like healthcare. I’ll end by providing science-backed, actionable recommendations for how developers can reduce their code review anxiety and create a code review culture that preemptively reduces code review anxiety in others.

If you've ever delivered a major project that was met with a shrug, you know that it is possible to work hard, hit all of your goals, and still deliver no business value. With freedom to choose projects and implementation, how do you know if you've chosen correctly? 

The fear is a sign that you're out of alignment with your company's business strategy. 

This talk will cover the three main types of business strategy, how to learn which strategy your company is pursuing, and how to discuss projects through the lens of strategy. Learn how to identify projects with clear value that do not align with strategy; and how to discuss the problem with stakeholders. 

Be a force multiplier by refocusing projects into alignment and reducing work that doesn't add value.

This talk introduces the Listen-Act-Share framework, a powerful tool for evaluating and acting on high-impact projects. Through real examples-including the transformation of Datadog's internal analytics infrastructure to a data lakehouse architecture—you'll learn how to:

• Find high-impact opportunities
• Invest your time where it counts
• Iterate and scale your efforts after validating

Discover the key criteria that separate good opportunities from great ones, and learn how to apply these insights within the Listen-Act-Share framework.

Without alignment, decisions are re-litigated, escalated, or suboptimal. At Carta, we have two new initiatives to drive alignment: defining a canonical position on our shared execution strategy, and designating a select group of senior engineers as "Navigators" to drive and interpret that strategy across the organization. In our session, we’ll discuss why this helps, how we put them together, what we’ve learned so far, and when you might benefit from a similar program in your organization. 

Your engineering organization has a strategy, whether you know it or not. Those principles or considerations you apply to make a decision, or determine if a decision is "good" or not? That’s your strategy. And it can be immensely powerful to simply write this down. In a land full of debates on what to prioritize, what to build, and how to build it, a shared strategy is a shortcut to shared context and quick decisions. 

Even the best strategy is subject to nuance and exceptions. This is where Navigators come in. Our Navigators are strategically deployed across the organization to help others interpret our strategy. Navigators are empowered to make decisions and remove the need for consensus. This requires Navigators maintain a close relationship with engineering executives, making them ideal for identifying areas where strategy is missing or wrong. 

We’ll compare and contrast Navigators with Directors, juxtaposing a team and execution focus with that of the long-term health and productivity of software and systems. We’ll also dig into some specific scenarios where Navigators have increased velocity and driven organizational alignment. Finally, we’ll provide ideas for pitching a similar program at your organization.

No casualties were reported other than perhaps the ego of a few software engineers: The 1996 inaugural flight of the Ariane 5 rocket was cut short due to a series of software design missteps. We’ll analyze these historical flaws to discuss resilience and product security; Touching on the nuance of testing, validation, legacy code, assumptions during design, and, for when things don't blow up, the unique challenge of proving that a negative event did not occur. 
 

You do amazing work, identifying an unsolved problem and building an invaluable solution. Customers or other engineers begin to rely on it. But since other people rely on it, someone needs to support it. And because you’re a responsible staff engineer, you keep owning it. Repeat this a couple of times, and this maintenance responsibility can end up dominating your time. Eventually, you don’t have enough time or energy left for higher leverage work. This is bad for everyone: you burn out and maybe end up quitting, more junior ICs miss out on opportunities, and the company loses your creativity and ability to explore new domains. 

Preventing this kind of burnout requires a new approach: what if we were more selfish? What if we began every new initiative with an exit strategy in mind? 

In this talk we will explore a few possible exit strategies, including: transferring ownership, bootstrapping a new team, pressing pause, and winding down. We will examine how to select an exit strategy for a particular project, and how we might preserve optionality in case there might be a variety of possible outcomes. Finally, we will talk about how to work with engineering leadership to get buy-in on an exit strategy from the beginning. 

By the end of this talk, you should feel better prepared to scope out new work with the intention of a limited engagement and without apprehension of knowing you might be forever responsible for keeping it afloat. And you'll see how being a *little* bit selfish is good for your organization.

Some of these opportunities draw on the emergent resilience we behold in nature; others emulate how human societies have adapted to adversity in other problem areas since antiquity; and more still extend existing engineering practices for velocity, productivity, and reliability.

By the end of this keynote, you will bask in this new philosophy of software security with newfound means for realizing it in practice.

After providing some context on the problem space (production readiness in the context of General Election Preparation), we'll walk through the blameless post-mortem analysis of where our technical vision and strategy fell short due to organizational issues we overlooked. More specifically, we'll review organizational issues like top-down and bottom-up buy-in, organizational structure, technical processes, and culture around blamelessness and accountability.

However, developing these applications is far from trivial because of the engineering challenges—ranging from subscribing to various data sources, and defining complex streaming transformations, to integrating with multiple data sinks. 

Key takeaways:

• How declarative interfaces simplify the development of streaming applications at Airbnb
• Benefits of GraphQL in designing the declarative interface for streaming applications
• How to reuse data sources and common logic across different streaming applications
• Best practices and lessons learned in developing streaming applications based on the declarative interface at Airbnb

Leaning into the analogy to "debt", how can we tell the difference between good and regrettable technical debt? What is the true cost of a choice to e.g. share a database, and what does it take to change it? When is the right time to tackle something like this, and how can we tell? Sharing our experience with these questions will set you up for success with your own enormous debt payment.

Sounds exciting, right? But if you’re the person given this massive – and often extremely important – ask, you’ve got some hard work ahead of you. 

You may be the first to scope out the project, but you’ll need to build a team to help you deliver on it. Once you have a team you’ll need a vision that can excite and inspire them, as it’s unlikely you’ll deliver the quality of outcome within the timelines needed without one. Complicating things, it’s probably a poor choice for you to take an ‘official’ leadership position within a team: you’ll need to steer, support and drive the team all from within. 

I’ve been this person many times over, and I know how big a challenge it can be. But if you’re the type of staff engineer who has deep technical expertise, is unafraid of big problems and knows the business well, the impact you can have doing this type of work can be company-altering. 

In this talk, I’ll share what I’ve learned from my experiences bootstrapping teams. I’ll draw from my experience at GoCardless as a Principal Engineer when leading efforts to build a new Open-Banking payment scheme, and more recently as the engineer who helped go from zero-to-release of the [incident.io](http://incident.io) Status Pages and Catalog products. 

I’ll cover what worked and what – sometimes painfully – didn’t, and ask whether the most important outcome of this work is the product or the team you end up building around it.

Your responsibility to work toward this change also increases dramatically with your privilege. I'll talk through some concrete ways to magnify the change you effect in your work while doing things you already do anyway: 

• Individual change: onboarding new interviewers, being a good example of inclusive meeting facilitation 
• Team change: formalizing equitable access to mentorship and opportunities
• Org change: not just joining or creating Diversity/Equity/Inclusivity groups, but also bringing software solutions to recruiting & people teams, start cross-team initiatives i.e. accessibility, bringing equity considerations to data analysis conversations, advocating for pay equity analysis 

This talk will give real-world examples of action to take, and the outcomes they’ve had at organizations. 

Change doesn't have to be a top-down initiative; and in fact, inclusive and equitable change seldom starts that way, considering those at the top are seldom from disempowered groups. As managers and individual contributors in positions of relatively large scope and authority, we're in a great position to bring change to our organizations. As a bonus, the work we do toward these goals often benefits our own careers, and often doesn't require a ton of time or financial investment.

The technologies available to us are constantly evolving. Likely your tech stack isn't the most modern it could be. By extension maybe you, as an IC, aren't as exposed to those technologies as you'd like. If you're facing a tech stack that needs a long-overdue refactor should you commit to technologies you haven't been as exposed to? In this talk I'll share my experiences with leading your team through those uncharted waters and the lessons I learned along the way. 

But we have a bigger challenge on our hands: the need for better *substrate* engineering. A substrate is the layer an organism grows and lives on and is supported by. For LLM-based tools, that means the frameworks and programming languages we use every day. 

Put it this way: Would you trust LLM-generated C code to be free of memory vulnerabilities? As a rule, human-authored C has many vulnerabilities. By definition, so will Copilot-style tools. The programming language itself is no help here, and LLM-based tools can only be as good as the data they were trained on. What’s more, they can only be as good as the frameworks and programming languages they target. So in a world where these tools let programmers author far more code, far more quickly, our foundations matter more than ever. 

We need to start investing much more in migrating to better programming languages, building better tooling, and authoring new frameworks where correctness is built in. What does that look like for your engineering organization today?

Yet, reality often falls short of expectations. This talk delves into the pitfalls of advocating for Generic Goodstuff without consideration for the context we're working in. First, let’s talk about what Generic Goodstuff is and isn’t. There are plenty of great tools in software: Testing, documentation, process improvements, type systems (and more) all are good stuff - when applied to the right problems! The trouble arises when we stop thinking about the context we’re working in and apply these tools as generic, one-size-fits-all solutions to our software woes. Eager software engineers at every level want to improve things, but, lacking context, end up falling into the Generic Goodstuff trap. They end up driving initiatives that fizzle out without impact because great tools are applied in the wrong situation. It’s up to us Staff+ engineers to fuel that enthusiasm with context around the mission of the organization and the specific challenges our organizations are facing. We’ll address strategies for navigating Generic Goodstuff conversations, keeping the focus on the desired outcome, bringing valuable context to the table, and gaining a deeper understanding of what decisions brought us to our current situation.

It becomes increasingly difficult to maintain shared mental models for how systems operate and should evolve over time. As a result, technical debt accumulates that no one feels empowered to take on, and cross-cutting initiatives stall without centralized strategy, accountability, and clear decision-makers, especially due to the historically flat nature of the org. Resolving technical disagreements often relies on either organizationally empowered EMs (violating our principle that technical leadership should come from ICs) or the accumulated social capital of the proposers (a non-inclusive system), rather than folks who are clearly empowered and accountable for making decisions.

This talk will cover how we overcame these challenges at Plaid through the creation of a technical leadership structure parallel to management. Since 2020, we have had a few iterations of our program. The first attempted to empower ICs by carving out time and accountability for engineers to focus on technical excellence, separate from a lot of day-to-day work on their teams. Based on learnings from this first iteration, we set up later iterations to better align with team structures and responsibilities.

We will discuss our learnings from these iterations and why we settled on our current approach. This includes our strategies for advocating for this type of program, what type of buy-in we needed from engineering management in order to make it happen, and how we knew that we had finally reached the tipping point that warranted a larger change. In our experience, creating a successful program is highly dependent on specific properties of your organization, so we will also share the specific attributes of Plaid that informed our choices, and how this might vary at other companies.

In this session Amy will talk about her experiences as a change agent and what she learned about how to do it sustainably, even when the change ahead is drastic.

Your service may be hosted on your premises or in the cloud. One cost remains common: infrastructure cost. In this talk, Sally Wahba will share some best practices for reducing infrastructure cost, both technical and organizational. She will share lessons learned from her experience at different companies to reduce costs from product development stage to running a service in production. 

In this session, Leslie Chapman will celebrate what it means to be a senior individual contributor. What better way to close out the conference than with a love letter to what brings us together?

We have to know how to prioritize, manage work to deadlines and perhaps the hardest - lead others. Our role means a shift from doing to guiding and supporting. We must know when to manage, mentor or coach. When we use these modalities well we build capacity in the team, increasing our ability to meet organisational goals. Along with it, people feel valued, we strengthen our culture and create a workplace where people want to come to work.

In this mini-workshop, we'll talk about the difference between each of these skills and how to know when to use them. You'll learn three key coaching skills and have the opportunity to practice deciding which modality to use. You'll walk away more confident in your ability to lead others.

And then it’s even harder to tell if it’s been received or understood correctly. But as leaders, pretty much all of our job is communication: steadying the ship during rocky waters, navigating friction or disagreements, or clearly signposting change. So how do you effectively communicate when there’s so much that can be misinterpreted? 

In this micro workshop, we’ll dive into the common ways that communication can break down (lack of buy-in, lack of clarity, communication overload, confusion about outcomes, etc.) and share techniques for improving. You’ll diagnose your own communication challenges at the team or individual level, and learn how to make sure that your message has landed.