The archetype of the engineer who says 'no' to most things thrived during the ZIRP era, but now faces existential challenges as tech companies prioritize speed over quality.
In software engineering circles, there's a familiar archetype: the senior or staff engineer whose default response to most proposals is 'no'. These engineers slow down development, block features that add complexity, and ensure minimal code gets written—after all, code is a liability. We can call them 'just-say-no engineers,' distinct from their counterparts, the 'just-say-yes engineers' who prioritize speed and approve most changes.
The just-say-no engineer is having a particularly difficult time in the current tech landscape. Their traditional role of gatekeeping and maintaining high standards is being challenged from all sides. But to understand why this archetype is struggling now, we need to look at the economic environment that created and sustained it for over a decade.
The ZIRP Era and the Rise of the Gatekeeper
ZIRP (Zero Interest Rate Policy), referring to the period between 2008 and 2022 when banks allowed companies to borrow at near-zero interest rates, fundamentally reshaped the tech industry. During this time, investors threw borrowed money at anything tech-related, creating an environment where companies were incentivized to constantly hire engineers for low-risk, high-reward projects.
Successful companies routinely expanded from tens of engineers to thousands, who worked on all sorts of initiatives: tangential open-source projects, endless technology migrations, complete rewrites into other languages, and more. It was a golden age for software engineers, who had significant bargaining power and could command top dollar for nearly any work.
But this growth created a problem: how would companies prevent their systems from becoming completely unmanageable with so many engineers working independently? The answer was the just-say-no engineer.
In this environment, having senior engineers whose primary role was to say no was incredibly valuable. Several factors made this approach effective:
- Keeping engineers busy with proposal-and-rejection cycles was preferable to having them impact business-critical systems
- It prevented the 5% of engineers who might get drunk on technical freedom from making reckless proposals like migrating to a hand-rolled database
- Maintaining a reputation for high technical standards helped with hiring (and during ZIRP, every tech company was always hiring)
The just-say-no engineer enjoyed implicit support from management. When complaints arose, responses like "that engineer knows what they're doing, if they said no, then I trust them" were common.
The End of ZIRP and the Cultural Shift
When interest rates rose, tech companies immediately laid off 5-20% of their engineers. It was no longer profitable to maintain bloated engineering staffs simply to boost stock prices. Companies had to actually make money.
Interestingly, this economic shift coincided roughly with the rise of ChatGPT, allowing tech companies to blame layoffs on AI rather than admitting they had been funding unproductive work. The narrative became "with this transformative new technology, we're able to deliver 10x the value with half the engineers," even though this logic doesn't quite hold up—if AI made engineers 10x more productive, why not keep them all and deliver 20x the value?
This economic shift has created a hostile environment for the just-say-no engineer. Companies are now more focused than at any time in the past two decades, desperately chasing new capabilities and features that can generate revenue. This new reality is antithetical to the just-say-no approach.
The support these engineers once enjoyed has vanished. They're now being criticized and overruled by management, told to be more of a team player, or simply excluded from key decisions. They're receiving poor performance reviews for the same behavior that was previously rewarded.
AI: Adding Insult to Injury
Ironically, if ZIRP had continued, this would be a glorious moment for just-say-no engineers. LLMs would have exacerbated the "engineers running wild" problem, making gatekeepers even more valuable. Companies would have relied heavily on these engineers to prevent an avalanche of AI-generated code.
Instead, LLMs have compounded the challenges for just-say-no engineers. They're forced to watch while other engineers merge AI-generated PRs that would previously have been blocked. They're being told to use the tools themselves—essentially becoming the kind of engineer they've spent their careers battling against.
What makes this particularly difficult is that the AI tooling mostly works. The code isn't quite as clean and may be less well-understood, but it's "good enough," especially in a world where companies are experimenting with many new features and abandoning those that fail.
The Identity Crisis
The just-say-no engineer now faces a threat not just to their livelihood but to their entire self-identity. They must either insist that an AI apocalypse is imminent or accept that their technical role was contingent on a specific economic environment that no longer exists.
This creates a profound dilemma: the core identity of these engineers is built on maintaining high standards and preventing technical debt, but the current business environment demands speed and experimentation.
Finding a New Niche: Pure vs. Impure Engineering
The just-say-no engineer won't go extinct, but their role is changing. They're less suited to the "impure engineering" that dominates most tech companies today—poorly scoped, customer-driven work where companies try features they're not sure will succeed.
However, these engineers still excel in "pure engineering" contexts—well-scoped, largely technical goals like building compilers, language runtimes, or core infrastructure. During the ZIRP era, many companies treated even impure work like pure work, but that's no longer sustainable.
For just-say-no engineers who want to maintain their approach, the path forward is to specialize in these pure engineering domains. They'll have a more limited scope than they did in the 2010s, but their skills will remain valuable in the right contexts.
The Community Response
This shift has sparked significant discussion in developer communities. On Hacker News and similar forums, engineers are debating the changing nature of technical leadership and the evolving role of senior staff members.
Some argue that the just-say-no approach was always problematic, stifling innovation and maintaining the status quo. Others contend that technical standards and thoughtful gatekeeping are more important than ever as AI-generated code becomes more prevalent.
What's clear is that the economic environment continues to shape engineering culture in profound ways. The just-say-no engineer archetype emerged during a unique period of abundant capital and will need to adapt as that environment changes.
For individual engineers, this moment presents an opportunity to reflect on what truly matters in their work. Is it maintaining perfect technical purity? Delivering business value quickly? Finding the right balance between the two? The answers may differ based on company context and personal values, but the conversation itself is valuable.
As we move further into this post-ZIRP era, engineering culture will continue to evolve. The just-say-no engineer may need to modify their approach, but the underlying principles they represent—thoughtfulness, quality, and long-term thinking—will remain essential to building sustainable software systems.
For those interested in exploring these ideas further, the author's original article can be found at their blog. The discussion continues on platforms like Hacker News, where developers share their experiences and perspectives on these shifting dynamics.

Comments
Please log in or register to join the discussion