At 3:47pm on a Friday afternoon in November 2019, a senior engineer at a payments company glanced at a pull request that modified how the system handled currency conversions. The change looked straightforward: moving a rounding operation from after the conversion to before it. The tests passed. The code was clean. "This seems fine," he typed into Slack, and approved the merge.
By Monday morning, the company had lost $1.2m in accumulated rounding errors across hundreds of thousands of transactions. The engineer had been right that the code worked. He had been catastrophically wrong about whether it did the correct thing. The difference between "working" and "correct" had cost roughly $400,000 per word of his approval message.
Three months earlier, at a different company, a different senior engineer had reviewed a complex refactoring of authentication logic. She spent four minutes reading the code, asked two clarifying questions, then said: "Yeah, this is good. Ship it." The change deployed without incident and eliminated a class of security vulnerabilities that had plagued the system for eighteen months. Her intuition, formed over twelve years of building authentication systems, had compressed what should have been a week-long security review into a Tuesday afternoon.
These two moments capture the central paradox of senior technical judgment: it is simultaneously the most valuable and most dangerous thing in software organizations. When it works, it cuts through bureaucracy and enables the kind of rapid decision-making that separates successful companies from also-rans. When it fails, it creates spectacular disasters that formal processes exist to prevent. Understanding when to trust intuition and when to demand rigor is perhaps the most important and least understood skill in technology management.
The Machinery of Intuition
What people call "senior engineer intuition" is not mystical. It is pattern recognition operating on a database of experience too large and too nuanced to be consciously articulated. When a senior engineer says something "seems fine," they are not guessing. They are running a massively parallel pattern-matching algorithm against every system they have built, every bug they have debugged, every incident they have responded to, and every code review they have conducted over a decade or more of practice.
Consider what happens when an experienced engineer reviews code. Junior engineers read linearly, following execution paths and mentally simulating program behavior. Senior engineers operate differently. They notice what is absent as quickly as what is present. They see that error handling is missing before they consciously look for it. They register that a database query lacks an index before they trace the query path. They recognize architectural patterns and anti-patterns at a glance, the way a chess master recognizes board positions.
This skill has measurable economic value. Research by companies including Google and Microsoft suggests that senior engineers can review code 10-20 times faster than junior engineers while catching the same or more defects. A rigorous security review that might take a team of specialists three days can be compressed into an afternoon by someone who has internalized the patterns. This speed advantage compounds across thousands of decisions, enabling organizations to ship faster, iterate more quickly, and respond to opportunities that would otherwise pass by.
The pattern database that enables this speed is built slowly and expensively. It requires not just years of experience but particular kinds of experience: seeing systems fail, debugging production incidents at 3am, making architectural decisions and living with the consequences, reviewing thousands of pull requests and watching some become elegant solutions while others become technical debt. The engineer who lost $1.2m on currency rounding had plenty of experience, but not with financial systems. His pattern database did not include "rounding order matters in currency conversions" because he had never encountered a system where it did.
This points to the first limitation of intuition: it works only within its training distribution. The chess master's pattern recognition fails when you change the board size. The authentication expert's judgment fails when evaluating quantum cryptography. Senior engineers often fail to recognize when they have left their domain of competence because expertise itself creates confidence that extends beyond its legitimate boundaries.
The Cost of Not Trusting
Organizations that fail to leverage senior intuition pay a different kind of price. One large financial technology company, stung by several high-profile bugs, instituted a review process so comprehensive that every change required sign-off from multiple teams: security, operations, architecture, and data. The goal was admirable: prevent catastrophic failures by ensuring exhaustive review. The effect was that deployment frequency dropped by 60%, cycle time increased from days to weeks, and their most senior engineers spent 40% of their time in review meetings.
The cost was not just slower shipping, though that alone was significant. The larger cost was talent. Their best engineers left within eighteen months. When asked why, they gave variations on the same answer: they had been hired to exercise judgment, but the organization had systematically prevented them from doing so. One former staff engineer put it bluntly: "They paid me $400,000 a year to rubber-stamp decisions that had already been made by process. I could either stay and atrophy, or leave and build things. I left."
This is the hidden cost of excessive process: it drives out the people whose judgment you most need. Senior engineers tolerate process when it enables better outcomes, but they leave when it becomes theater. And because the best engineers have the most options, the organization that over-indexes on process loses precisely the people whose intuition would make that process unnecessary.
The same company eventually reversed course, but the damage was done. Rebuilding senior technical capacity took three years and cost substantially more than the bugs they had been trying to prevent. The irony is that their original bugs stemmed not from lack of process but from failing to listen to senior engineers who had flagged the risks early. They had responded to a judgment problem by eliminating judgment entirely.
Other organizations err in the opposite direction, trusting senior intuition without bound. A well-known social media company famously operated on the principle that senior engineers could ship anything to production without review. This worked brilliantly for years, they moved faster than competitors and built a reputation as an engineering-driven culture. Then a staff engineer, moving quickly and trusting his judgment, deployed a change that inadvertently exposed 50 million user records. His intuition had been correct about the code. It had failed to account for newly introduced compliance requirements he did not know existed.
When Intuition Fails
The failures of senior judgment follow predictable patterns. The first and most common is domain mismatch: applying intuition developed in one context to a genuinely different problem. The engineer who lost $1.2m on rounding errors had spent his career building systems where rounding was inconsequential. His intuition correctly identified that the code would run without errors. It failed because his pattern database did not include the domain-specific knowledge that rounding order matters in financial calculations.
This is insidious because the engineer feels confident. The code looks fine. The tests pass. The change seems straightforward. All of the heuristics that usually indicate safety are present. What is missing is a pattern the engineer has never encountered: domain-specific constraints that are not visible in the code itself. These failures cluster in regulated industries, financial systems, healthcare, and anywhere that correctness depends on rules that exist outside the codebase.
The second pattern is novelty. Intuition is pattern matching, and pattern matching fails on genuinely novel problems. When a company encounters a scale it has never operated at, a technology it has never used, or a failure mode it has never seen, senior judgment becomes unreliable. The patterns that worked at 100 requests per second fail at 10,000. The architectural decisions that were correct for a SQL database are wrong for a distributed system. The security practices that sufficed five years ago are inadequate against modern threats.
Organizations often fail to recognize this because they conflate general seniority with specific expertise. An engineer with fifteen years of experience building monolithic web applications is a junior engineer when evaluating microservices architectures. Their intuition about system design is not just less valuable, it is actively misleading because it suggests solutions that worked in a different context but fail in the new one.
A third failure mode is cognitive bias. Senior engineers are no more immune to confirmation bias, anchoring, or availability heuristics than anyone else. When a respected engineer says "this seems fine," teams often stop looking for problems. The engineer's confidence becomes a stopping condition for critical thinking. This is especially dangerous when the engineer has a track record of being right: past success creates current overconfidence, and overconfidence prevents the kind of second-guessing that catches subtle bugs.
Consider the authentication refactoring that succeeded. The senior engineer who approved it was right, but she was also lucky. The change happened to align with her expertise, occurred in a system she knew intimately, and involved no novel requirements. Had any of those factors been different, her quick approval could have been the opening chapter of an incident report rather than an example of efficient decision-making. The difference between brilliant intuition and costly overconfidence is often just the particular set of circumstances that happened to obtain.
The Economics of Review
Formal review processes exist because intuition fails, but they impose their own costs. A comprehensive code review might catch 95% of bugs, compared to 85% for a senior engineer's quick scan. That extra 10% sounds valuable until you calculate what it costs. If a rigorous review takes eight hours instead of fifteen minutes, and you conduct a thousand reviews per quarter, you have consumed 8,000 hours of engineering time, roughly four full-time engineers, to catch 10% more bugs.
Whether this trade-off makes sense depends entirely on the cost of bugs. For a social media feed, where bugs are annoying but not catastrophic, optimizing for speed makes sense. For medical device software, where bugs kill people, the calculation obviously inverts. Most systems fall somewhere between these extremes, and most organizations fail to think clearly about where they sit on this spectrum.
The optimal review intensity is not static. It varies by component, by risk, by the specific people involved, and by context. The same change might warrant a fifteen-minute review in a development environment and an eight-hour review before a regulatory submission. Organizations that apply uniform review standards across all code pay either the cost of excessive process (when they over-review low-risk changes) or the cost of insufficient scrutiny (when they under-review high-risk ones).
Leading organizations have learned to calibrate review intensity to context. They use lightweight reviews for low-risk changes, comprehensive reviews for high-risk ones, and, crucially, they trust senior judgment to distinguish between the two. This creates a kind of meta-judgment problem: you need good judgment to decide when judgment alone is sufficient. Organizations that get this right move fast and fail rarely. Organizations that get it wrong either move slowly or fail catastrophically, and sometimes both.
The challenge is that the people best equipped to make these calibration decisions are senior engineers, and they are making judgments about when to trust their own judgment. This requires a rare combination of confidence and humility: confidence to trust intuition when appropriate, humility to recognize its limits. Many senior engineers have one or the other, but few have both in proper balance.
Building Systems That Think
The question is not whether to trust senior intuition but how to get its benefits while mitigating its risks. The answer lies in what might be called "structured intuition", systems that leverage expert judgment while protecting against its failure modes.
One approach is to make implicit knowledge explicit through checklists and forcing functions. The aviation industry learned this decades ago: even the most experienced pilots use checklists because intuition fails under pressure and in novel situations. The checklist does not replace judgment; it ensures that judgment operates on complete information. A senior engineer reviewing authentication code might rely on intuition to assess the overall approach while using a checklist to verify specific requirements: credential validation, session management, token expiry, rate limiting.
This works because it splits the problem. Intuition handles the high-dimensional, hard-to-articulate judgment about whether the approach is sound. The checklist handles the low-dimensional, easy-to-articulate verification of specific requirements. Senior engineers resist checklists when they feel like bureaucracy, but embrace them when they genuinely catch mistakes that intuition misses.
A second approach is to bound the consequences of wrong decisions. One large e-commerce company allows senior engineers to deploy changes immediately to a small percentage of users without review. This gets the speed benefits of trusted intuition while limiting the blast radius of mistakes. If the change works, it rolls out automatically. If it fails, it affects only a fraction of users and triggers automatic rollback. The senior engineer's judgment about whether something "seems fine" is tested against reality before the decision becomes irrevocable.
This transforms the question from "is this change correct?" to "is this change safe to test?" The first question demands certainty; the second requires only reasonable confidence. Senior intuition is well-calibrated to assess whether something is safe to try, even when it cannot guarantee correctness. Organizations that create safe-to-fail environments enable more aggressive use of intuition because failures remain cheap.
A third approach is to build organizational memory that captures when intuition fails. One financial technology company maintains a "close calls" database documenting times when senior judgment nearly caused problems. This is not a blame system, reports are anonymized and focused on patterns rather than individuals, but it serves as a collective pattern database that helps calibrate when intuition is trustworthy. Engineers reviewing payment code see that rounding errors have caused problems three times in company history, which triggers additional scrutiny even when the code "looks fine."
This works because it makes the organization smarter than any individual. Each engineer has their own pattern database built from personal experience. The close calls system creates a shared pattern database built from collective experience. An engineer who has never encountered a rounding bug can benefit from the experience of those who have, without needing to cause a $1.2m incident themselves.
The Organizational Bargain
At its core, the decision to trust senior intuition is a bargain. The organization accepts some risk of catastrophic failure in exchange for greater speed and the ability to attract and retain senior talent. The engineer accepts responsibility for decisions made quickly, based on incomplete information, knowing that some percentage will be wrong.
This bargain only works when both sides understand its terms. The organization must create genuine space for judgment, not theater that pretends to trust while actually constraining every decision. The engineer must exercise judgment responsibly, recognizing its limits and escalating when operating outside their competence.
Many organizations fail because they want the benefits without the costs. They want senior engineers to move fast but blame them when speed causes errors. They want the confidence to ship quickly but the safety of exhaustive review. They want judgment without risk. This is incoherent, and senior engineers recognize it as such.
The companies that succeed make the bargain explicit. They define what risks are acceptable and what risks are not. They specify what kinds of changes can be deployed on intuition alone and what requires additional validation. They create clarity about the consequences of being wrong. This does not eliminate risk, nothing can, but it aligns the organization's risk tolerance with its operational practices.
Consider Stripe, which allows senior engineers to deploy payment code to production with minimal review, despite operating in one of the most regulated and risk-sensitive domains in technology. This works because they have built extensive automated testing, comprehensive monitoring, and rapid rollback capabilities. They have also been extraordinarily careful about who becomes a "senior engineer" with deployment authority. The title is not handed out based on tenure but earned through demonstrated judgment under pressure.
This reveals something crucial: trusted intuition requires trustworthy people. Organizations cannot skip the work of developing judgment by throwing process at the problem, but they also cannot eliminate process without first building capacity for good judgment. The sequence matters. Build expertise, demonstrate judgment, earn trust, remove constraints, in that order.
The Paradox of Expertise
The deepest problem with senior intuition is that it is both self-reinforcing and self-limiting. When an engineer's judgment proves correct repeatedly, the organization trusts it more. This increased trust means the engineer's judgment faces less scrutiny, which means errors are less likely to be caught. Over time, the engineer's decisions are validated primarily by the absence of visible problems rather than by active verification.
This works until it catastrophically does not. The engineer who had been right ninety-nine times makes a judgment call on the hundredth decision that happens to fall outside their expertise. Because previous decisions went unchallenged, they do not recognize that this one is different. Because the organization has learned to trust them, nobody else catches it either. The failure, when it comes, seems sudden, but it was actually built gradually through a process that rewarded intuition without testing its boundaries.
The authentication expert who quickly approved the security refactoring had been right so many times that people stopped questioning her judgment. This was efficient when her decisions fell within her domain. It would have been catastrophic if she had applied the same confident intuition to, say, a cryptographic protocol or a distributed consensus algorithm, areas where her expertise did not extend. The organization had no systematic way to distinguish between "senior engineer operating in domain of expertise" and "senior engineer overconfident about unfamiliar problem."
Some organizations try to solve this by requiring senior engineers to justify their decisions. This rarely works because articulating the basis of intuition is difficult and time-consuming. The chess master cannot easily explain why a position "feels" wrong, the judgment emerges from pattern matching that operates below conscious awareness. Forcing explicit justification either slows decisions to the point where the benefits of intuition vanish, or creates post-hoc rationalization that sounds convincing but does not actually represent the engineer's reasoning.
A better approach is to calibrate confidence through prediction. One technology company asks engineers to estimate, when approving changes, how confident they are that the change will deploy without issues: 50%, 80%, 95%. They track these predictions against outcomes. Over time, they learn which engineers are well-calibrated (their 80% predictions succeed about 80% of the time) and which are overconfident (their 95% predictions succeed only 70% of the time).
This creates a feedback loop that helps engineers recognize the limits of their intuition. An engineer who discovers they are overconfident about database changes but well-calibrated about API design learns to escalate database decisions while trusting their API judgment. The organization learns which engineers to trust for which decisions. The calibration happens automatically, through measurement rather than through the awkward dynamics of questioning someone's expertise.
The Future of Judgment
The rise of AI code assistants adds a new dimension to this question. When GitHub Copilot can generate plausible code instantly, and when large language models can review pull requests and suggest improvements, what becomes of senior intuition? Does automation make judgment more valuable or less?
The answer appears to be "more." AI systems excel at pattern matching against known problems but struggle with novelty, context, and edge cases. They can generate code that works in standard situations but fail to account for system-specific constraints, business requirements, or operational realities. This makes senior judgment more important, not less: the question shifts from "is this code correct?" to "is this the right code to write?"
Consider a scenario where an AI assistant generates a database migration that adds an index to improve query performance. The code is syntactically correct, the approach is sound, and automated tests pass. But a senior engineer reviews it and says: "This will work, but it will lock the table for three hours on our production dataset. We cannot deploy it during business hours, and we cannot take a three-hour downtime window. We need to build the index concurrently, which requires a different approach."
The AI knew how to write a database migration. It did not know about the production dataset size, the organization's uptime requirements, or the existence of concurrent index building as an alternative approach. The senior engineer's "this seems fine, but..." judgment integrated technical knowledge, operational context, and business constraints in a way that current AI systems cannot match.
This suggests that the future of senior judgment lies not in being faster than AI at writing code but in being better at evaluating whether the right code is being written at all. The value shifts from implementation expertise to architectural judgment, from "how do we build this?" to "should we build this, and if so, how should it fit into the larger system?"
Organizations that understand this are investing less in teaching senior engineers new programming languages and more in developing their judgment about system design, risk assessment, and organizational dynamics. They recognize that the scarce resource is not code generation, AI will get very good at that, but wisdom about which code to generate and how to integrate it into complex sociotechnical systems.
The Irreducible Residue
Despite everything written above, some component of senior judgment will always remain irreducible to process, checklist, or automation. The moments that define engineering careers are often those where formal analysis suggested one path but intuition insisted on another. Sometimes the engineer ignored intuition and regretted it. Sometimes they followed it and were vindicated. Sometimes they were wrong, and the organization paid the price.
One principal engineer at a major technology company describes a moment where everything suggested that a system redesign was safe: architecture review approved it, load testing passed, and incremental rollout showed no problems. But something felt wrong. He could not articulate what, the concerns were vague, more emotional than analytical, but he insisted on delaying the full rollout. Two days later, a subtle interaction between the new system and a rarely-used administrative tool would have caused catastrophic data corruption. The tool was not covered by testing because it was used so infrequently that nobody thought to check it.
His intuition had detected a pattern that formal analysis missed: the redesign changed fundamental assumptions about system state, and there were probably edge cases nobody had considered. He was right, but he might easily have been wrong. No checklist would have caught the problem because nobody knew to look for it. No AI system would have flagged it because the scenario was too specific and too rare to appear in training data. It required the kind of paranoid attention to systemic risk that comes only from years of debugging production systems.
This is the irreducible residue of senior judgment: the ability to be usefully paranoid about problems nobody has explicitly considered. It cannot be fully systematized because the space of possible failures is too large. It cannot be automated because it requires understanding the specific system, organization, and context in ways that resist generalization. It can only be developed through experience, refined through reflection, and exercised with appropriate humility.
Toward Calibrated Trust
The goal is not to always trust senior intuition or never trust it, but to build organizations that can calibrate trust appropriately. This requires several things working together.
First, clarity about domains of expertise. An organization must know what each senior engineer is actually senior at. Fifteen years of experience is not fungible, experience in distributed systems is different from experience in front-end development, which is different from experience in security. Organizations that treat "senior engineer" as a monolithic category will inevitably over-trust judgment outside its domain of validity.
Second, mechanisms to detect when decisions fall outside established domains. This might be explicit (a checklist of risk factors that trigger escalation) or implicit (a culture where saying "I am not sure this is in my wheelhouse" is respected rather than penalized). Either way, the organization needs immune-system-like responses that activate when decisions venture into novel territory.
Third, safe spaces to test intuition. Organizations that allow rapid experimentation with bounded consequences enable more aggressive use of judgment because errors remain cheap. This requires investment in testing infrastructure, monitoring, rollback mechanisms, and blast-radius limitation. It also requires cultural acceptance that failed experiments are information rather than failures.
Fourth, feedback loops that calibrate confidence. Engineers should learn when their intuition is reliable and when it is not, through measurement rather than through painful post-mortems after major failures. This means tracking predictions, analyzing near-misses, and creating non-blaming environments where miscalibration can be corrected before it causes harm.
Fifth, explicit discussion of the trust bargain. Organizations should be clear about what risks they are willing to accept in exchange for speed, and engineers should be clear about the limits of their expertise. This conversation is often uncomfortable because it requires acknowledging uncertainty, but it is less uncomfortable than discovering misaligned expectations during an incident review.
Organizations that get all five pieces working together can move faster than their competitors while failing less often. They leverage senior intuition where it is reliable, substitute formal analysis where intuition is unreliable, and create systems that degrade gracefully when judgment proves wrong. They accept that some percentage of decisions will be mistakes and build accordingly, rather than trying to achieve zero defects through ever-more-elaborate process.
The Ultimate Constraint
The practical constraint on leveraging senior judgment is that senior engineers are scarce. Building the pattern database that enables reliable intuition takes years of focused experience. This experience cannot be rushed, and it cannot be outsourced. An organization can hire consultants to write code, but it cannot hire consultants to develop organizational intuition about its specific systems, teams, and constraints.
This makes retention of senior engineers perhaps the most important capability an organization can develop. The engineer who has been with the company for eight years, who has debugged production incidents across three system redesigns, who knows where the bodies are buried and why the architecture is the way it is, that person's judgment is worth vastly more than their code contribution. They are the organization's institutional memory, pattern database, and error-correction system all rolled into one.
Yet many organizations manage senior engineers in ways that systematically destroy this value. They burden them with process that prevents judgment. They reorganize frequently enough that hard-won context becomes obsolete. They promote them into management, removing them from the technical work where their intuition is most valuable. They fail to recognize that the senior engineer who says "this seems fine" is not being lazy or casual, they are performing a highly sophisticated pattern-matching operation that represents years of accumulated expertise.
The companies that win in technology are increasingly those that understand this. They create environments where senior judgment can flourish: minimal process, high trust, rapid feedback, and serious consequences for getting it wrong. They accept that this will occasionally produce spectacular failures, and they build systems resilient enough to survive those failures. They recognize that the alternative, elaborate process that prevents judgment, produces a different kind of failure: the slow death of organizational capability as the best people leave for environments where their expertise is trusted.
The Unending Tension
There is no final resolution to the tension between intuition and rigor. Every organization must navigate this trade-off continuously, adjusting as systems change, teams grow, and risks evolve. What worked at fifty engineers fails at five hundred. What was appropriate for a startup racing to product-market fit becomes inadequate for a public company with regulatory obligations. The conversation about when to trust judgment and when to demand process is not something to resolve once but something to revisit constantly.
The payment company that lost $1.2m on rounding errors did not respond by eliminating senior judgment. They responded by improving their processes for identifying domain-specific risks, by building better testing for financial calculations, and by ensuring that engineers knew when to escalate decisions outside their expertise. The senior engineer who approved the change remained senior, but the organization became smarter about which decisions required which level of scrutiny.
The authentication expert who quickly approved the security refactoring continues to make fast decisions on security issues. But she has also become more explicit about flagging when a decision falls outside her domain, and the organization has become better at distinguishing between "quick review by domain expert" and "quick review by generalist who happens to be senior."
Both organizations improved not by choosing between intuition and process but by becoming more sophisticated about when each applies. They learned that "this seems fine" can be the right answer or the wrong answer, and which it is depends on who is saying it, what they are reviewing, and what systems exist to catch mistakes when judgment fails.
This is the real lesson: senior judgment is not a substitute for rigor, and rigor is not a substitute for judgment. They are complementary tools for managing uncertainty in complex systems. Organizations that master both, and know when to use each, will build better systems faster than those that commit fully to either extreme. The engineer who says "this seems fine" might be exercising valuable intuition or dangerous overconfidence. The art of engineering management lies in being able to tell the difference.