The Decisions You Don’t Know You’re Making: QCon Keynote Explores Hidden Choices in Engineering

Engineering teams make their most consequential decisions not in architecture reviews or sprint planning, but through invisible choices embedded in metrics, defaults, and everyday behaviors. In their QCon San Francisco 2025 keynote, Shawna Martell and Dan Fike challenged the industry’s focus on documented decision-making while the decisions that truly shape systems and culture go unrecognized.

The talk invited engineering leaders to ask uncomfortable questions: What behaviors do our CI/CD pipeline speeds actually incentivize? Which defaults have we inherited without examination? What are we measuring, and what behaviors does that measurement reward? For organizations struggling with poor outcomes or culture issues that seem disconnected from technical choices, the hidden decision analysis offers a new lens.

Rather than prescribing solutions, the speakers offered a diagnostic framework for recognizing hidden decisions. Their approach echoes broader industry conversations about Architecture Decision Records. The key insight: hidden decisions can be named and examined once teams learn to identify them.

Hidden behaviors and choices have a broad impact on the engineering work we eventually see

“Sometimes, as engineers, the right decision for us is not to build,” they said. The hidden decision to build implicitly accepts the costs and risks of building and maintaining something new. As developers, we often love to solve problems with code. But we never stop to ask ourselves, “Is this the correct solution?” when, many times, it isn’t.

The problem, they explain, is that engineering organizations measure outcomes such as features shipped or system uptime but rarely examine the decision quality that produced those results. This phenomenon creates a dangerous blind spot where teams optimize for the wrong things without realizing it.

Examples of metrics that, when measured, can drive the wrong behavior

The speakers illustrated their thesis with CI/CD pipelines. When pipelines run slowly, engineers aren’t just waiting longer for builds to complete. They start exhibiting behaviours like bundling PRs together. As a result, instead of having small, manageable PRs, we have massive changes that are harder to review, rubber-stamped approvals, and deteriorating quality.

Per the speakers, we should ask ourselves, “What behaviours do we want to incentivise, and how can our tooling support that?”.

The speakers then termed “the default trap.” Teams accept defaults and act on them whether they consciously accept them or not. They cited an example of a team that decided to build its own platform instead of using an existing one within the organization, even though the existing one already solved a similar problem, simply because the default in that organization was for every team to own its own stack. In this case, team ownership became the “default” and was not challenged until Martell explicitly called it out. “We need to name the defaults to be able to explicitly accept or reject them as required”.

The most insidious hidden decisions emerge from metric selection. The speakers described how, during an architectural change, measuring events sent to Kafka led to massive unnecessary traffic because teams optimized for the metric rather than the underlying need. “Most events were not even required,” they explained.

Similarly, measuring career progress through title changes obscures the real decision about career strategy—whether engineers are actually making progress in a direction that makes sense for them. Engineers build skills that lead to specialization, which builds their reputation and the value they provide, which in turn determines their roles, until changing direction becomes risky. “Once you’re building that view of yourself, deciding to change is risky,” and so identifying these hidden decisions in real time is even more crucial.

Career cycles are affected by hidden choices that are harder to change as we progress