Explore what’s happening at StaffPlus New York

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.

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.

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.

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.

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

To address the complexities of building these applications, a declarative interface offers a robust solution. A declarative approach, where developers specify what to achieve rather than how, simplifies the development process by making code more modular, reusable, and understandable across different teams. It also enhances system maintainability and debuggability. 

We pioneered a declarative interface rooted in GraphQL at Airbnb to significantly ease and standardize the development of streaming applications. This methodology has been embraced by over 20 teams within Airbnb for them to more easily develop, maintain, and scale streaming applications, staying ahead in the fast-paced world of real-time data.

By describing how Datadog's internal analytics team moved from a data warehouse to a lakehouse architecture, you can learn how Staff+ ICs can spot impactful opportunities, create buy-in among early adopters, and ruthlessly prioritize to deliver at scale. 

However, this approach tends to replace old problems with new ones as novel organizational constraints on communication emerge.

This talk gives an individual perspective on how staff+ engineers are uniquely positioned to help mitigate many of the negative tradeoffs associated with their company’s organizational structure. For example, by creating casual opportunities to talk shop with peers from teams or departments they don’t usually collaborate with.

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. 

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.

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.

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.

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. 

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.

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.

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.

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. 

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?

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. 
 

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. 

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.

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.

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.