Tech has hit rough waters. Each week seems to bring fresh news of layoffs and hiring freezes at some of today's biggest companies. A similar trend is also happening at smaller organizations, but they may not have the name recognition to pop up in your news feed. In any case, it's a difficult time, and there are a lot of talented people suddenly out of work.
To be clear, no company wants mass layoffs. As Stanford Graduate School of Business Professor, Jeffrey Pfeffer, notes, layoffs take a heavy toll on the behavioral and physical health of those impacted, and increases mortality and morbidity. And there's a whole generation now going through this process for the very first time.
For software developers and others still working at an organization which has undergone layoffs, fear and stress can run high as teams tread carefully and avoid making mistakes under the perception that new missteps could potentially cost them their jobs.
In our recent report, "Release assurance: Why innovative software delivery starts with trust and psychological safety," we found that organizations that put too high an emphasis on avoiding errors can inadvertently impact everything from retention to the ability to create any sort of meaningful progress that could separate a product from its competition.
"It’s hard to be productive when you spend days at a time backchanneling, hodgepodging your department back together," writes author Anne Helen Petersen, "accustoming yourself to new org charts and workflows and desk locations, and just generally internalizing the demonstrated logic of your organization: that layoffs can happen without warning, in seemingly irrational and surprising and untargeted ways, and there is no way to protect yourself from the next wave."
For software companies, the trend of mass layoffs has also opened the door to some pretty public (and ugly) debates: how many developers do you really need to keep a website or app up and running? And what risks—loss of institutional knowledge, uptime, and market momentum, to name a few—could be lurking at an organization when a sizable portion of devs leave all at once?
Since we're a developer-first company, we spoke with some engineers at LaunchDarkly for their thoughts on what happens when an organization makes drastic, immediate cuts to a development team. Specifically, we asked:
- Stacy Harrison, Engineer
- Tom Totenberg, Staff Solutions Engineer
- Brian Rinaldi, Developer Experience Engineer
Below you'll find their responses to our questions. And if you've been directly impacted by recent layoffs, LaunchDarkly has open roles.
LaunchDarkly: What are the dangers of firing a sizable portion of your engineering staff all at once?
Stacy: The amount of institutional knowledge lost during a mass-layoff is incredibly damaging. Many engineering teams aim to reduce siloed information, but it has to be baked into an engineering team’s culture to be done successfully. It can range from knowing how to interpret a vague error message to understanding a complex system of services. Chances are, the folks left behind are scouring chat messages and outdated documentation for crumb trails of information to mitigate issues. In addition to more errors, I’d expect longer incident remediation times due to understaffing. With fewer engineers available, I’d expect fewer bugs to be fixed and fewer efforts to address technical debt. The remaining engineers, on top of more responsibilities, will also have the social and emotional impact of so many of their peers suddenly leaving.
Tom: In the short-term, everything will take longer. Workflows get disrupted, nobody knows where to go for support, and mistakes will happen. In the long-term, there’s a lot of institutional knowledge that walks out the door. You can hope that everything is well documented, but there’s a big difference in speed and quality of work between a person following someone else’s documentation, and the person who wrote the documentation. Now imagine if it’s not documented! How long does it take to untangle a potentially complex problem that used to belong to someone else? How many of those will appear?
Brian: The biggest risks are that you lose institutional knowledge about how the application works that can't be regained without painstaking work to dig through the codebase and architecture. This can affect ongoing projects or any future plans. The other risk is that there's a significant bug that affects your users but the expertise to resolve the issue no longer exists on the team. This can cause outages to be more significant than they might otherwise be.
LaunchDarkly: After a sizable portion of the engineering staff has left, how does that change the responsibilities of those who stay?
Stacy: Depending on what roles were let go, remaining engineers will likely need to take on tasks outside their current skillset. The size of the company will determine the scope of impact. Typically small startups hire well-rounded engineers who can do a wide variety of tasks, but as the company grows, engineers have more opportunity to specialize in narrow, deep skills. In general, I’d expect a small company to handle a staff reduction with more agility than a larger, established company. For a larger company, I’d anticipate a lot of specialized engineers needing to quickly adjust to a high volume of wide-ranging tasks, with little to no adjustment period. Larger companies also typically have more tasks related to reducing technical debt and supporting internal teams. With fewer folks to share the workload, a reduced engineering team will impact all other areas of the company, while also driving up the amount of technical debt.
Tom: Everyone needs to wear multiple hats. Roles that used to be clearly defined and segmented no longer have owners, so everyone else needs to pick up the slack. That’s a big overnight cultural and mentality shift! People working in early stage startups are used to this sort of constant context-switching, but that’s expected in a small, hyper-growth company. Forcing that shift on a previously stable workforce layered with inevitable morale issues makes for a challenging work environment.
Brian: It depends a lot on how the team was structured to begin with. The biggest impact will likely be that a lot of the remaining engineers will get tasked with critical maintenance work and it will cause new and ongoing feature development to lose a ton of velocity.
LaunchDarkly: What do you make of people who say laying off a bunch of engineers is fine if the site/app remains functional?
Stacy: If a company’s app remains running smoothly, from the outside, that’s a testament to the talent of the engineers who built those systems. Depending on whether a company is public or private greatly influences whether they are required to disclose security vulnerabilities, performance, and incidents. We may not hear about all the issues internally, but that doesn’t mean we can assume everything’s fine or will remain fine. Over time, technical debt may accrue, performance may gradually worsen, and new features will take longer to ship.
Tom: I haven’t changed the oil in my car for a year, and it still runs fine! Any complex system requires constant maintenance and attention to run smoothly in the long-term. Eventually things will start to break down. Technologies evolve; dependencies get stale; and security standards are in a constant arms race against nascent vulnerabilities. One would hope you have adequate staff to get beyond maintenance, and have the bandwidth to actually innovate and grow. The world changes fast, and all communication platforms are in an ongoing popularity contest. If you’re not innovating, you’re falling behind.
Brian: Until it doesn't. Things break. Even if you aren't deploying changes to the code or infrastructure, issues arise. This is especially true on a complex application with a lot of moving parts. However, it's rare that companies would just leave the code as is after a layoff. They are deploying complex, potentially breaking changes that could cause a serious incident that they may no longer have the internal expertise or staff to quickly resolve.
.webp)
