![Tanya Reilly](https://res.cloudinary.com/leaddev/image/upload/q_100,c_fill,g_auto:classic,e_sharpen,h_100,w_100/prod/sites/default/files//contributors/2024-02/Tanya Reilly.png)
Tanya
Reilly
Principal Software Engineer
Squarespace
![](/sites/default/files/2021-08/Squarespace_0.png)
Get your colleagues together and make it a team day. Standard and group tickets are available now.
Welcome to StaffPlus New York 2024
A welcome to StaffPlus New York 2024 from the host Tanya Reilly.
Tanya Reilly is a Principal Software Engineer at Squarespace working on infrastructure and site reliability. Before Squarespace she spent 12 years in Site Reliability Engineering at Google. She is originally from Ireland, but is now an enthusiastic New Yorker. Tanya likes raspberry pi, coding on trains and figuring out how systems will break. She blogs at noidea.dog.
View Tanya's LeadDev articles and talksThis talk walks through the experience of uncovering surprising use cases and navigating that tension in a product release journey.
One of the challenges and privileges of being a successful company is customers will find ways to use our products in ways we didn’t intend.
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.
View Eva's LeadDev articles and talks
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? Tali will share their experiences with these questions to set you up for success with your own enormous debt payment.
Through a case study of breaking up a monolithic and intertwined database (ain't nobody got those, right?), some things about technical debt became clearer.
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.
Tali's love of computers is broad and all-inclusive: She created websites in the olden days, assembled machines (also in data centers!), designed and built systems, and let this or that game suck in a bunch of hours. Aside from that, she takes pride in being a good friend, a mother of 2 adorable children, a climber and a skier. She tried getting ChatGPT to write this bio. She still doesn't like ChatGPT.
View Tali's LeadDev articles and talksOffice hours is your opportunity to connect face-to-face, ask questions and find out more.
Inspired by Lara Hogan’s Manager Voltron, build your personal network at StaffPlus New York.
Work together to find ways of solving a common problem posed by our moderator.
Join facilitated conversations on measuring engineering success.
Dedicated sessions on how to take the next step in your career for:
"Should we multi-cloud?" is a provocative question that is getting asked by many organizations in the face of newsworthy outages and increasing pressure to mitigate vendor lock-in. 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.
"Should we multi-cloud?" is a provocative question that is getting asked by many organizations in the face of newsworthy outages and increasing pressure to mitigate vendor lock-in.
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.
Tanusree (Tanu) McCabe is currently a Distinguished Engineer at CVS, leading public cloud strategy. She previously lead enterprise architecture strategy at Capital One and authored an O'Reilly book, "Fundamentals of Enterprise Architecture". She has over 20 years of IT experience, focusing on automation, cloud and architecture.
View Tanusree (Tanu)'s LeadDev articles and talksOliver will show, using a recent AWS -> GCP migration as an example, that they're all on this ship together. They know where we're headed, but they just need to agree on what's happening on the Lido Deck and when and make it happen.
There is a class of problems that we face as Staff+ engineers where the team has all the technical expertise they need already in the room, but for some reason they can't make progress.
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.
Oliver is a Principal Engineer with Recursion Pharmaceuticals, where he likes to focus on backend and data problems. He lives in Toronto with his family and far too many bicycles.
View Oliver's LeadDev articles and talksIn this talk, Sally Wahba will share some best practices for reducing infrastructure cost, both technical and organizational
Your product may be running on your customer's premises or provided as a service.
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.
Sally is a Principal Software Engineer at Splunk where she works on data ingestion for observability. Before Splunk, she spent almost a decade working on operating systems for data storage systems at NetApp. Sally obtained her PhD in Computer Science from Clemson University. She presented her work and research both nationally and internationally. When not working you will find her doing computer science outreach activities, reviewing for technical conferences, mentoring, and learning Spanish.
View Sally's LeadDev articles and talksCome and learn from Choi's mistakes and successes, pitching a large refactor project when she was a Senior Staff at Slack.
You know exactly why your engineering team has slowed down.
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.
View Choi's LeadDev articles and talks
Office hours is your opportunity to connect face-to-face, ask questions and find out more.
Watch or participate in free 1:1 coaching
Join facilitated conversations on management skills for AI.
Dedicated sessions on how to take the next step in your career for:
In this talk, Carol will share the story of my empirical research conducted with software engineers and developers across industries experiencing code review anxiety.
Tell someone you feel anxious about giving or receiving code reviews, and you’ll likely be told that it’s a “junior developer thing that you’ll eventually get over,” then given tips for writing “cleaner/ better code.”
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.
As a Principal Research Scientist in the Developer Success Lab, Carol leverages her expertise in mental health and thoughtful measurement to study how developers cope and thrive through stressful circumstances. Carol has over a decade of experience leading academic and industry research in clinical health, measurement, and human behavior. Carol serves as a research fellow at the Integrated Behavioral Health Research Institute and as a clinical science advisor for Bravely Mental Health. She holds a Ph.D. in clinical psychology from UMass Boston.
View Carol's LeadDev articles and talksThis 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.
"Am I working on the right thing?" is a common fear for Staff+ Engineers.
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.
Jeffrey Sherman drives scaling and performance at ActiveCampaign through his role as a Staff Engineer. In addition to hands-on coding, he teaches problem decomposition, iterative delivery, and his philosophy of never doing greenfield rewrites. He co-hosts the NeverRewrite Podcast and writes on scaling SaaS software at ShermanOnSoftware.com
View Jeffrey's LeadDev articles and talksBy 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.
What started as a small ask from a single team led to a multi-department, multi-quarter initiative that completely transformed how data and analytics are served internally.
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.
Chris is a Staff Engineer at Datadog, living in New York. With a career spanning finance, cryptocurrency, and SaaS sectors, he has gathered a wealth of experience and insight. His professional journey has led him to renowned companies like Zapier and now Datadog, where he leads multiple engineering teams. His current work revolves around developing self-service data analytics tools for internal stakeholders. When he's not working, you'll likely find him embracing the joys and challenges of chasing his two young children around.
View Chris's LeadDev articles and talksShawna and Dan will 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. They'll also dig into some specific scenarios where Navigators have increased velocity and driven organizational alignment.
As organizations grow, it becomes increasingly difficult to maintain alignment among individual contributors (ICs), managers, and executives.
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.
Shawna Martell is a Senior Staff Engineer at Carta, Inc. Her previous experience includes Big Data tech at Yahoo, and she was one of the original engineers on Wolfram|Alpha. She holds an MS in Computer Science from Syracuse University and an MBA from UIUC. Beyond her professional pursuits, she channels her passion into volunteering in local politics and finds solace in the world of podcasts.
View Shawna's LeadDev articles and talksDan Fike is a Principal Engineer and Deputy to the CTO at Carta, Inc. His experience ranges from game development to web app infrastructure, from Google to a 5-person tech startup, from programmer to architect, and from writing patents to conducting M&A diligence. He holds a BS in Computer Science from UIUC.
View Dan's LeadDev articles and talksOffice hours is your opportunity to connect face-to-face, ask questions and find out more.
Dedicated sessions on how to take the next step in your career for:
Hear from the LeadDev content team on the secrets of crafting winning speaker submissions and effective article proposals.
Join facilitated conversations on improving developer experience
The 1996 inaugural flight of the Ariane 5 rocket was cut short due to a series of software design missteps. Mark will analyze these historical flaws to discuss resilience and product security.
Thirty nine seconds after its launch towards space, rocket no. 501 erupted into a scintillating fireball.
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.
Mark started as an offensive security consultant, doing penetration testing and code and design reviews. Mark then expanded his skillset into the defensive side, leading cybersecurity at various organizations. Mark is a conference speaker, holds security certifications, and has been an instructor at a Columbia University cybersecurity bootcamp for over four years. Mark now works at Activision Blizzard, combining his passions for gaming and cybersecurity.
View Mark's LeadDev articles and talksBy 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.
All too often, staff engineers are responsible for an overwhelming number of mission critical services or features.
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.
Adam Berman is the Head of Engineering at Semgrep, building static analysis tools to improve software security. He enjoys the pendulum between IC and Manager, and has built multiple teams and products at Semgrep and Meraki. Adam is a bay area local, a proud holder of a US National Parks pass, and an ultimate frisbee player.
View Adam's LeadDev articles and talksClosing session
Tanya Reilly is a Principal Software Engineer at Squarespace working on infrastructure and site reliability. Before Squarespace she spent 12 years in Site Reliability Engineering at Google. She is originally from Ireland, but is now an enthusiastic New Yorker. Tanya likes raspberry pi, coding on trains and figuring out how systems will break. She blogs at noidea.dog.
View Tanya's LeadDev articles and talksOffice hours is your opportunity to connect face-to-face, ask questions and find out more.
Welcome to StaffPlus New York 2024
A welcome to StaffPlus New York 2024 from the host Tanya Reilly.
Tanya Reilly is a Principal Software Engineer at Squarespace working on infrastructure and site reliability. Before Squarespace she spent 12 years in Site Reliability Engineering at Google. She is originally from Ireland, but is now an enthusiastic New Yorker. Tanya likes raspberry pi, coding on trains and figuring out how systems will break. She blogs at noidea.dog.
View Tanya's LeadDev articles and talksAfter providing some context on the problem space (production readiness in the context of General Election Preparation), Lesley will walk through the blameless post-mortem analysis of where their technical vision and strategy fell short due to organizational issues they overlooked.
Anchoring on a case study about driving observability platform adoption in a multi-product organization, we'll review the organizational implications that impeded adoption.
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.
Lesley Cordero is currently a Staff Engineer at The New York Times. She has spent the majority of her career on edtech teams as an engineer, including Google for Education and edtech startups.She is primarily focused on platform engineering and reliability management, particularly in the observability space. Her leadership style focuses on cultivating a culture that builds with the most vulnerable employees in mind first, and she shows care for others by holding them accountable to the best versions of themselves – and by buying them the occasional bubble tea.
View Lesley's LeadDev articles and talksWe 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.
The growing importance of streaming applications in today's tech landscape is driven by the need for real-time data processing, scalability, enhanced user experiences, and competitive advantage.
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.
Xiangmin is a Senior Software Engineer on the Data Frameworks team at Airbnb, where he specializes in real-time data processing and streaming applications. Passionate about optimizing data flows and streamlining development processes, Xiangmin has been instrumental in implementing innovative solutions that drive Airbnb's data strategy. Residing in Seattle, he enjoys the natural beauty of the Pacific Northwest, often spending his free time hiking and pursuing his love for photography.
View Xiangmin's LeadDev articles and talksIn 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 reflecting on my journey to becoming a staff engineer, I realized many of the practices I apply to my day-to-day work come from my time working with open source software maintainers, as a contributor and fellow maintainer.
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.
Nick is an empathetic community member, staff engineer, avid climber,and cyclist. He is currently a developer advocate at Viam where he helps anyone bring their robotics ideas to life. He is an invited expert with TC53 to help shape the future of JavaScript on embedded devices. Previously, he helped organize ManhattanJS and contributed to Hoodie, node-serialport, Johhny-Five, and Tessel. In his free time, he tinkers with home automation and robots built with JavaScript. His mustache is a figment of your imagination.
View Nick 's LeadDev articles and talksOffice hours is your opportunity to connect face-to-face, ask questions and find out more.
Dedicated sessions on how to take the next step in your career for:
Hear from the LeadDev content team on the secrets of crafting winning speaker submissions and effective article proposals.
Join facilitated conversations on innovating with fewer resources.
In this talk, Lawrence will share what he's learned from his experiences bootstrapping teams. He'll draw from his 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.
Staff engineers can make for an excellent advance party, someone you give a problem like “build a new product” and know they’ll turn that ask into an actionable plan, eventually releasing something great.
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.
Lawrence spent his early career at GoCardless as both SRE and product engineer, helping the company grow from start-up to unicorn. Having spent years working as a Principal SRE building an internal PaaS and helping GoCardless scale their services, Lawrence joined incident.io as employee #1 to build the incident response product he’d wished for over the hundreds of incidents he’d been involved in. Now his focus is on establishing the foundations for a world-class engineering team, and recently building the incident.io Status Pages and Catalog products.
View Lawrence's LeadDev articles and talksYour responsibility to work toward this change also increases dramatically with your privilege. Nicole will talk through some concrete ways to magnify the change you effect in your work while doing things you already do anyway.
Wherever you are in the organization, you can help foster inclusivity, but your opportunities for doing so increase exponentially with your level.
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:
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.
Nicole started writing code in 2012, and has been in love with python ever since. Passionate about social justice and climate change, they can currently be found at Arcadia, helping build the 100% renewable future. In their free time, Nicole is an avid dancer and teacher, sci-fi book fanatic, soul and jazz aficionado, gardener, and cheese lover. They have an MA in English Literature and Women’s Studies from the University of Liverpool.
View Nicole 's LeadDev articles and talksIn this talk, Dylan will share their experiences with leading a team through uncharted waters and the lessons they learned along the way.
Tech stacks vary widely from company to company.
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.
Dylan is a Staff Engineer at Rent the Runway and is the current Tech Lead for their flagship iOS app. He has over 8 years of iOS experience and his technical interests range from Architecture and Performance to Test Strategies and CI/CD. He loves learning and sharing knowledge from any topic and loves to meet new people. If Dylan isn't coding on the couch he may be distracted by his latest board game addiction or baking something in the kitchen.
View Dylan's LeadDev articles and talksWe 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?
The phrase of the day is “prompt engineering”—developing the skills to make LLMs productive for generating code, tests, and documentation.
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?
Chris is a senior engineering leader, lately focused on frameworks and programming languages as ratchets: tools which help other developers to build better software. He was the tech lead for LinkedIn’s desktop web application and the go-to expert for LinkedIn’s TypeScript adoption, founded and led the Ember.js TypeScript team, and was a member of the Ember.js Framework team. He is also an active composer of contemporary classical music, a half-marathoner, a typography nerd, an espresso and whiskey aficionado, and—most importantly—a dad, a husband, and an Anglican Christian.
View Chris's LeadDev articles and talksOffice hours is your opportunity to connect face-to-face, ask questions and find out more.
Watch or participate in free 1:1 coaching
Join facilitated conversations on running effective code reviews
Dedicated sessions on how to take the next step in your career for:
This talk delves into the pitfalls of advocating for Generic Goodstuff without consideration for the context we're working in.
In the dynamic landscape of software engineering, there's a pervasive allure to what I call "Generic Goodstuff™" - universally lauded practices that seem like silver bullets to team improvement.
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.
Randall's career can be politely summed up as "interesting". He's worked everywhere, from tiny startups to Netflix to teaching introductory programming. He wrote a book on RxJS, which didn't impress his cats much. You can find his words in written form at https://rkoutnik.com/ and shorter words at https://twitter.com/rkoutnik
View Randall's LeadDev articles and talksIt seems like every engineering team reaches a tipping point where bottoms-up technical steering where everyone "just knows who to talk to" no longer scales. 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. Joy and Nathan will cover how they overcame these challenges at Plaid through the creation of a technical leadership structure parallel to management.
It seems like every engineering team reaches a tipping point where bottoms-up technical steering where everyone "just knows who to talk to" no longer scales.
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.
Joy is a principal engineer at Plaid and works as an Architecture Lead focusing on Plaid’s reliability and engineering platforms. She previously managed Plaid’s Core Services and International engineering teams, and was a co-founder of the Women+ ERG. Joy lives in San Francisco and spends most of her free time baking and reading.
View Joy's LeadDev articles and talksNathan is a Principal Engineer at Plaid focused on building and scaling new products. He spends his time diving into complex problems and working across the organization to produce clarity from chaos. Originally from Florida, Nathan spent 10 years in the Bay Area and recently relocated to Brooklyn, NY, where he enjoys staying active, vegan cooking, and creating electronic music. Nathan holds a BS in Symbolic Systems and a MS in Computer Science from Stanford University.
View Nathan's LeadDev articles and talksOffice hours is your opportunity to connect face-to-face, ask questions and find out more.
Inspired by Lara Hogan’s Manager Voltron, build your personal network at StaffPlus New York.
Work together to find ways of solving a common problem posed by our moderator.
Join facilitated conversations on tackling difficult conversations.
This talk by Ainsley will cover when to know you've outgrown your monolith and what to do about it.
View Ainsley's LeadDev articles and talks
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, Audrei will take you through a journey of a few canon events experienced throughout his career, including ones with names such as “The Great Reliability Crisis”. He will also share lessons learned and how best to guide teams through them.
We are all shaped by the sum of our life experiences. Canon events are the most formative: those responsible for building character and shaping us into who we are.
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.
Audrei Drummond (they/them) is a Staff Engineer and Engineering Leader at Opal. Over the last 15 years of their career, they’ve held various roles at Slack, Redfin, Microsoft and Webflow. Audrei realized they have a surprisingly love for enterprise software, especially identity, access management and security when they realized they missed all of the acronyms. Outside of evaluating architectures and diving into standards, Audrei enjoys mentoring, helping other engineers on their paths and building strong engineering cultures.
View Audrei's LeadDev articles and talksClosing session
Tanya Reilly is a Principal Software Engineer at Squarespace working on infrastructure and site reliability. Before Squarespace she spent 12 years in Site Reliability Engineering at Google. She is originally from Ireland, but is now an enthusiastic New Yorker. Tanya likes raspberry pi, coding on trains and figuring out how systems will break. She blogs at noidea.dog.
View Tanya's LeadDev articles and talksStay up-to-date with everything that's happening at StaffPlus New York.