Hidden Decisions You Don't Know You're Making

2026-08-0132 min read
#engineering-culture#decision-making#incentives#platform-engineering#career-development

Dan Fike opens with an observation that is easy to agree with and easy to underrate: a workday is a sequence of decisions, and the more senior you get the more of your time goes into making them, facilitating them, or assembling the context needed to build conviction around them. Their talk is not about those decisions. It is about the decision sitting underneath each one — the one nobody wrote down, nobody debated, and nobody remembers making. These decisions are hidden not because they are complex but because we never admitted to ourselves that we were deciding at all.

Shawna Martell is a principal software engineer at Imprint; Dan Fike is a principal engineer and deputy to the CTO at Carta. Between them they cite more than 40 years in the industry. The talk runs 45 minutes and 41 seconds and was recorded at QCon San Francisco 2025; InfoQ published the recording, slides, and transcript on March 31, 2026. The published transcript contains the prepared session only and no audience Q&A, so nothing in these notes is drawn from questions.

Everything below is what the two speakers presented. Where I add background an intermediate engineer might want but the talk did not state, the text says so explicitly.

What You Will Learn

  • What the speakers mean by a "hidden decision" and how it differs from an unintended consequence.
  • Why measuring platform success by adoption count quietly incentivizes engineers to build complexity rather than remove it.
  • Why "we decided to build" is the most frequently skipped decision in engineering, and what it costs.
  • The causal chain from a slow CI pipeline to unreviewable pull requests to accumulated risk, and why the speakers call the result cultural rather than technical.
  • How team ownership boundaries can produce duplicated platforms without anyone choosing duplication.
  • What measurement drift is, and a worked example of a metric that showed healthy progress while the underlying problem stayed put.
  • How the same defaults operate on a career, in both the leaving-a-job and the being-assigned-a-job direction.
  • The three excavation techniques the speakers offer for surfacing these decisions before they harden.

What Counts as a Hidden Decision

The speakers build the definition from the audience's own situation. Everyone in the room chose which session to attend, knowing the consequence that attending one 2:45 session means missing the others. That choice was overt. But Fike points out that some people chose based on personal interest and others chose based on what is most relevant to their employer's current struggles, and that the two are not the same for everyone. Whichever you did, you did not just pick a talk. You applied a principle that resolves the choice — you made a decision about how to decide — and you probably did not notice doing it.

That is the shape of the thing. A hidden decision sits one layer beneath an overt one, usually as an unnamed principle or default, and it reaches past the immediate issue into culture, relationships, architecture, and future decisions. Martell is deliberate about the word choice in the conclusion. These could be called unintended consequences, and she acknowledges the overlap, but calling something a consequence says it merely happened, which turns it into something you react to rather than something you interrogate, explore, or take responsibility for. Calling it a decision keeps it yours.

Fike makes the layering explicit, and it is the part most easily lost. Once you have decided, this time with intention, which principles to apply in your decision-making and which culture you want those principles to promote, you run the same question on that answer: why is that the culture you want your principles to promote? Even these hidden decisions can be rooted in further hidden decisions. Martell's closing prompt is the compact form of the whole talk: when you are making a decision, ask what principles, policy, and process brought us to this decision, at this time, with these people — and did we end up here intentionally, or did we somehow wander in by accident?

Platform Adoption Counts Incentivize Complexity

Fike opens the examples with a position he is careful to frame as his own: most successful platform tech enables simplicity, not complexity — he notes the sentence needs parentheses, and that he means "most successful platform tech," not "the most successful platform tech." He is not asking the audience to agree. The point is that this is a principle his teams made deliberately, discussed, and wrote into their platform execution strategy, so that engineers weigh design trade-offs against it. The failure mode it guards against is tooling that solves ten tricky problems and introduces nine new ones, where the complexity of life without the platform is simply replaced by the complexity of life with it. Martell's version of the test is blunt: if your platform supports 94 use cases but nobody understands the first one, you may not be helping.

Fike's diagnosis of the root cause is a goal mismatch. If your primary goal is to enable users to achieve complex results, you get complexity; the antidote is to enable users to avoid complexity, which requires something simple to understand and simple to use. Before his teams named that principle, he watched small solutions to small problems get tweaked repeatedly into complex solutions to every kind of problem: indexing services generic enough to do nothing, and new foundations launched with a barrier to entry so large that nobody adopted them — or, he says, arguably worse, that some people adopted.

The hidden decision underneath is about success criteria. The organization had subconsciously settled on measuring a new platform utility by how many users it attracts. To the engineer building it, the way to guarantee adoption over whatever people were doing before is to satisfy every need and use case so nobody has a reason to hold out. Martell's framing is the one that generalizes: nobody sat down and said "let's incentivize complexity by measuring users." It was in no quarterly business goal. It was a decision anyway, sitting behind the well-intentioned design documents, migration plans, and success metrics.

The Sneakiest Default: Deciding to Build

Long before choosing what tools to build, what abstractions to introduce, or whether to inline something versus extract a library, we decide to build. Fike's point is that engineers rarely establish any principle for what to build and what not to build — the step is skipped entirely, and we live under an unintentional principle that code is the default solution to problems.

Martell's story is the talk's clearest illustration. Her team was building a set of AI agents to help internal teams with critical customer work, an ambitious and bleeding-edge project for the organization. Iterations shipped about as fast as the ideas that sparked them and the energy was, in her word, electric — but they were building in the dark, because observability needs had not been sufficiently considered up front. Feedback came from generous users sharing anecdotes and frustrations, which gave a glimpse of agent performance but not numbers. The answers that existed were scattered across user logs, decision-flow traces, and conversation histories, which she describes as JSON that had lost a fight with a wood chipper. Her assessment was that they did not need new infrastructure; they needed insight.

With the team thrashing on the problem, she arrived one day to a giant pull request awaiting review: thousands of lines introducing a new generalized agent metric tracking solution, clearly the product of a lot of thought. Her stomach sank, because the step had been skipped. They were not building to learn, they were building to build. She is explicit that the engineer had not weighed trade-offs and picked one — they went with the flow. The existing data was genuinely awful to work with, and that was a problem, but it was not the problem, and in some ways it was a distraction.

The team stopped and had the conversation: were they going to commit all this new code to production while still unable to answer a single question about agent performance, and would it even deliver the insight they wanted? Their answer was no. Instead they built what Martell calls the world's ugliest Jupyter notebook — a crime scene that parsed weird blobs repeatedly, neither pretty nor impressive — and it gave them the insight. The better outcome was what they learned in the process: the generalized metric tracker was not quite positioned to produce the data they actually needed.

She draws two conclusions. First, the hidden decision is not only to build something new but to accept its long-term cost and risk, because software is simultaneously one of a company's most valuable assets and one of its greatest liabilities; if you are taking on that liability you should do it consciously. Second, the reason building is the default intuition is institutional. Engineering productivity and performance are measured in systems built and code shipped, and, as she puts it, she has never known anybody promoted to staff engineer on the back of a good Jupyter notebook. The default is established in the culture and then allowed to persist.

Slow Pipelines Are a Decision About Behavior

Fike's thesis for this stretch of the talk is that incentives and hidden decisions are tightly coupled. Hidden decisions are often the cause of misaligned incentives — either directly, or indirectly through the tools those decisions produce. They shape how we work, how we collaborate, and the behaviors we are silently optimizing for. Build and deployment pipelines are his worked example of that mechanism, chosen because everyone can relate to them: your feelings about yours are largely determined by what you can do while it runs — a coffee-length pipeline produces a happy caffeinated engineer, a Thanksgiving-dinner-length one produces something else. The choices inside it are not hidden. Whether to run the full test suite on every pull request or a subset, how many linters to run, how to handle type checking, whether security scans are for prevention or detection — these go in design docs, meetings, and tickets, and they feel deliberate because they are.

The buried decision is the question nobody names: what behaviors does this pipeline incentivize? Take a developer with big ideas and tight deadlines whose CI takes an hour per pull request. How many times a day can they afford to wait? Not many. So they do not get slower — they start bundling, putting big changes into big pull requests to outsmart the bottleneck. The pipeline does not merely delay work; it reshapes how work is done around it. The resulting large PRs are hard to review, attract far more rubber-stamping to get through, and become nearly impossible to reason about fully.

Fike is careful about what he is not saying: security scans matter, tests are critical, and the right answer to what belongs in CI is "it depends." His claim is narrower and harder to escape. Nobody puts "encourage large pull requests" in an engineering strategy, but allowing a pipeline to drift into slow and cumbersome has exactly that effect. Quality, in his framing, is not a test-coverage number, it is behavior. And this kind of hidden decision does not stay technical: it becomes how new engineers are onboarded, how pull requests get stamped, and how risk accumulates in the system over time. His summary is that culture is shaped as much by the friction you choose to remove as by the friction you choose to leave in place. Martell adds the consequence that matters for remediation: once it has become a cultural problem, tooling alone cannot fix it, which is why the decision to make deliberately is what behaviors you want to incentivize and how tooling can support that.

The same dynamic shows up in the non-technical parts of the job. Fike asks when your team last made a decision based on who had the strongest conviction rather than who had the clearest insight, and lists the defaults that substitute for following the data: the loudest voice, the most senior person, whoever writes most persuasively in Slack, or simply the person you are used to asking first. It is not exclusion, it is defaulting. Martell extends it from which voice stood out to who was in the room at all, and describes the result as cultures accidentally calcifying — rooms getting smaller, voices getting narrower, and teams no longer noticing who they trust by default or which edge cases they are ignoring.

Ownership as Accidental Architecture

Ownership is treated as a virtue, and Fike agrees it usually is, but without intention it becomes a constraint. He invokes the phrase "shipping the org chart" for architecture that mirrors company structure, and argues the same thing happens one level up in the decision-making layer: people end up owning decisions not because it is right for the product or the business but because it fits cleanly into the org chart.

Supplementary note, not from the talk: "shipping the org chart" is the informal name for the effect described by Conway's law, the observation that systems tend to mirror the communication structures of the organizations that build them. The speakers use the phrase without attributing it.

Martell's story: years earlier she worked on a platform service integrating with a third-party HR system — think Workday or Rippling — where customers connected their data and the platform disseminated normalized HR data to different parts of the product, powering many user experiences. It ran in production for years after she moved on. Then she was pinged to review a document from another team proposing a new HR integration layer. (Fike interjects that starting Slack conversations that way is itself a bad idea.)

She went in skeptical but open. The document was thorough — plan, architecture, use cases, a clear path — and acknowledged that the existing platform did not solve all their problems. What bothered her was the absence of evidence that the existing platform had been seriously considered, and the absence of curiosity about whether it could be extended. So she asked why they were building from scratch, why not use what existed, and what made that a non-starter. The root cause surfaced quickly. The existing platform focused on user experience, scalability, and data normalization; the proposed one needed to focus on user experience, scalability, and data normalization. It was not about architecture, capabilities, scale, or features. It was about ownership.

The invisible decision was: we don't build on things we don't own, we don't ask other teams to adapt, we avoid that friction entirely. The existing platform was owned by another group, written in a different language, living in a different repo, with a different roadmap — so despite solving roughly 80% of the same problem and, in her assessment, being extensible to the new cases, it was never in the running. The consequences of the duplication are the familiar ones: fractured user experiences and the long-term cost of two parallel infrastructures solving essentially the same problem slightly differently. As she puts it, no team ever convenes and resolves to maintain two HR integration platforms forever, because that would be bananas — but that is what they set out to do. The decision did not happen in a meeting; it happened in the absence of one, in the skipped step of asking the platform team what was and was not possible.

Her verdict draws the line carefully. She believes in ownership, but building a second platform because the existing one lives in another team's repo is not ownership — it is, at best, inertia masquerading as strategy, and it is legacy waiting to happen. The default had become "each team builds and manages their own stack," which skipped the underlying question of when teams should differentiate versus when the company should invest in shared infrastructure. Both answers can be right depending on context; what matters is having a shared principle, and the moment where you name the default and consciously accept or challenge it. Without that moment, the most important decisions a team makes are not made with intention at all — they just happen.

Measurement Drift

Fike's bridge is that defaults harden first in what we count. If ownership shapes behavior, measurement cements it. To understand what a team truly values, ignore the mission statement and look at what it measures, because what gets measured gets optimized, and what gets optimized reveals what is believed to matter even if nobody decided it. Martell supplies the pattern: we say we want impact and measure feature delivery; we say we want customer delight and measure ticket throughput; we say we want resilience and measure uptime while ignoring operational drag. Fike names this measurement drift — a culture built by accident, one dashboard at a time. It is subtle precisely because the metrics are not evil. Shipping velocity, cycle time, and MTTR are all useful signals; they become dangerous when treated as a proxy for value without revisiting how they relate to it, because once a number becomes a goal it stops being neutral and starts shaping behavior.

Supplementary note, not from the talk: the general form of that last sentence is usually credited to Goodhart's law, that a measure which becomes a target ceases to be a good measure. The speakers do not name it.

His worked example is a Kafka rollout. An infrastructure team was standing up new messaging infrastructure — brokers, topics, a schema registry, codegen tooling — with the good goal of moving teams away from tight synchronous dependencies toward something more decoupled. Being new, it needed a progress metric, and the team picked the obvious one: how many events flow through Kafka. More events implies more adoption implies more dependency problems solved.

Supplementary note, not from the talk: Kafka is a distributed log-based messaging system. Producers append events to topics and consumers read them independently, so a service can publish a fact without waiting on, or even knowing about, whoever reacts to it. A schema registry stores the agreed structure of those events so producers and consumers can evolve independently. The decoupling benefit only materializes when something actually consumes the events instead of a synchronous call being made anyway.

Fike is careful to frame the team generously. They were not being political and they were not chasing a vanity metric; what they measured and encouraged was useful, in a sense. It simply produced a lot of activity and not a lot of progress.

What happened instead: teams were encouraged to instrument all kinds of events — helpful ones, but also speculative "maybe useful one day" and "we should probably have an event here just in case" events. Counts went up a lot. Almost nobody was consuming them, and most of the growth traced back to a small number of very high-frequency events. Progress looked healthy while, functionally, the core problem was not improving: teams were still making brittle synchronous API calls against overly coupled services.

Fike's correction is the most transferable detail in this section, and he rules out the near-miss answer explicitly. The right proxy is not events sent, and it is not events consumed either — it is the number of distinct event consumers in the codebase, because each one replaces what would previously have been a blocking call. He offers the visual: it is the count of edges in your dependency graph that should go from a solid line to a dotted one. His diagnosis of the hidden decision is that before the team deliberately decided what to measure, it had unintentionally decided to focus on the solution it was building rather than the problem it was solving; when it asked "is it working?", it had never agreed on what "it" was.

He adds a second-order effect that makes this hard to escape: the team started celebrating the metric. The more a metric is rewarded, the less anyone questions it, and the more tooling gets built to track and showcase it, the less anyone asks whether it is the right thing to measure. False success makes real success harder to find and the hidden decision harder to identify. Martell's generalization is that metrics do not merely observe performance, they teach teams what success looks like: measure shipping velocity heavily and teams optimize for output; focus on what users say they want and you may miss what they actually need. Fike closes the section with the uncomfortable part — the things that genuinely help build better judgment are harder to measure, and the easy things to measure are often the ones that merely look interesting.

The Same Defaults Run Your Career

Martell carries the argument into careers by noting that the easiest things to measure there are titles, promotions, and job changes, which quietly teach us what personal success means. She frames her own story with the context that she has been in the industry a long time but has not worked in many places, and does not live in San Francisco, New York, or another major tech hub, which shaped early decisions — or, as she reframes it, the decisions she did not realize she was making.

Her first seven years out of school were at Wolfram Research, the last few as a people manager. Deciding to return to being an individual contributor was not a hidden decision — it was deliberate, and the company accommodated it. She hoped it would be the reset she wanted, and for various reasons it was not. That is where it got fuzzy: she told herself she wanted something different, so she left. It felt decisive, like action and momentum. What she recognized only much later was that she had made half a decision. She had decided she was leaving without spending much time on where she was going, never asking what kind of work she actually wanted, or the uncomfortable questions — what work brings me energy, what key traits am I looking for in the next opportunity. That was the hidden decision. After a single interview and an accepted offer, she told herself this was clarity; what she had really done was let circumstance choose, having unintentionally adopted a strategy of "anywhere but here."

It worked out — brilliant people, great problems, and her first chance to work with Fike — but she attributes that to pure luck, and her line is that luck is not a strategy. You do not get to opt out of having a career strategy: "I'll just see what happens" is one, merely a strategy in which momentum decides for you. That is what makes these decisions sneaky; they do not feel like decisions at all, they feel like action. The decision to leave is only half the move, and the other half is asking where you are going and why, because if you do not name what matters to you, your circumstances will name it for you. She adds a caveat that deserves to be carried forward with the advice: she was fortunate, not everyone gets to choose their moment, jobs disappear, markets turn, and sometimes survival is the only decision available — but even when you do not get to decide the start of a change, you deserve to be intentional about what comes next.

Fike's story runs the other direction, showing the same mechanism when the job is assigned rather than chosen. His first role out of school in 2007 was at Volition, a games studio that no longer exists. He was thrilled to have any job, having already been laid off once before starting: an earlier role produced only a signing bonus and a severance check, which he notes is not bad for zero days worked but is uncomfortable for a new graduate in June. Breaking into games was notoriously hard, and as a lifelong gamer he was excited. Volition was small, in a minor Midwest metro, with low attrition and correspondingly unsophisticated onboarding — he did not know his team or project until his first day. He imagined the new Saints Row team (SR2) or the new Red Faction team (RFG), and was told he was joining CTG, which he initially took for a secret IP. It stood for Core Technology Group: the team building memory profilers, debug utilities, build pipelines, asset browsers, and content serializers — the tools engineers, artists, and designers use to build the game. He was disappointed, thinking this was not really making games; he says it is, and that he was naive at the time. Most staff had consoles at their desks for their work, and he did not need one. He told himself it was fine, small companies mean many hats, and he had a lot to learn. Each day he made a decision to do the next right thing.

Nearly 20 years later the pattern is obvious: across almost every job, his software's primary users have been his coworkers — internal platforms, infrastructure, tooling, systems for other engineers. He never sat down and set a career strategy of improving internal velocity through backend tooling. It became a default: what he learned to reach for, what felt natural, what he was rewarded for, what he got good at. He articulates the compounding chain directly: the work you lean into shapes the skills you develop, the skills you demonstrate shape the reputation you build, that reputation shapes the value others project onto you, and that value determines what roles, scope, and problems you get access to. Nobody told him he was on a tools and platforms track; he started walking and someone pointed him in a direction, and over time the trail behind him began to look like identity. He is honest that he cannot untangle cause from effect — did he get good at it because he liked it, or start liking it because he was good at it?

The consequence he wants engineers to see is that a professional identity is not declared, it is accumulated, and once people see you as a specific type of engineer, changing is not just technically difficult but emotionally and politically risky, because you are pushing against what others believe about you and often against what you believe about yourself. He lists where this shows up — glue work, testing, developer productivity, zero-to-one product builds, migration efforts, observability, operations — as quiet niches where strong engineers go looking for problems, have no trouble finding them, get good at solving them, and then get quietly boxed in by the value they have proven. Every day we do the next right thing: the task at the intersection of what the company needs, what we are good at, and what nobody else wants to do. He does not say that is wrong. He says we need to decide why we are doing it, and what principles sit behind it. Is it work you enjoy, or are you indifferent? Do you believe deep specialization is coveted and valued, or do you find the heroics satisfying, or do you want the line to go up and to the right? His closing distinction is between choosing your career and accepting the one that shows up when you do not. Martell ties it back to the opening: it is the same question as how you chose which talks to attend — are your principles shaped by your choices, or did you end up here automatically with less intentionality than you hoped?

The speakers stress in their recap that none of this is a prescription to do more or less of anything. The ask is that when you do something, or don't, it is a conscious active choice rather than something that happened, and that you understand which principles you are applying to make it right for today.

Excavating a Hidden Decision

The speakers close by drawing three themes out of the six stories — the AI metrics platform built instead of using data already on hand, the slow CI pipeline producing big pull requests, the duplicate HRIS solution, the counted Kafka messages, Martell leaving a job, and Fike being assigned one.

Spotting decisions that don't feel like decisions. Martell's inventory is deliberately exhaustive: everything you are working on came after a decision, and so did everything you are not working on; every tool you use, every frustration you overlook, every meeting you attend, and everyone included in or excluded from that meeting. Did you notice? She ties the inventory back to the first theme: the sneakiest decision of all is just deciding to build in the first place, and decisions about what to build unintentionally take the shape of the organization, even when nobody intends that — sometimes under the guise of ownership. She is upfront that there is no one trick here and they do not know how to guarantee you will see them next time. The best advice they have, and what they say they try to do themselves, is to pause briefly before building the next thing or scheduling the next meeting and ask whether there is a default being fallen into unintentionally.

Finding the decision behind the decision. Fike's technique borrows the familiar practice of asking why five times to reach the root cause of an incident, and applies it to decisions instead. Dig far enough and you usually find a core principle or philosophy that shaped the outcome — and that is your strategy. It might be working backward from the decision-making culture you want, weighing the trade-off between autonomy and redundancy, or defining a proactive career strategy. Each is a chance to decide how you decide before you start deciding. His concrete homework is a retrospective on past decisions: can you derive principles from them, can you name the strategy you were applying, did you deliberately choose it or did it just happen, is it the right one, what can you do if not — and if it is right, how do you communicate to your team that you are adopting it, so it is available the next time.

Incentives. Martell describes a tailgater decision that follows each real decision into action as a new incentive for the team. If you find yourself unable to understand why your team or peers behave the way they do, it very often reduces to misaligned incentives — either misaligned with yours, or with what the company actually needs. Once you see how metrics shape behavior it is hard to unsee; in the CI/CD story, the team was being taught to run CI as little as possible. The payoff she states for the lens is practical: once you understand why people are doing what they do, changing the behavior becomes far easier to plan. Her practical inversion is important: do not look at what people are not doing, look at what they are doing instead and ask why. Her examples of visible behavior are teams neglecting to include tests in PRs, constantly declaring themselves unavailable for engineering interviews, or repeatedly piling new responsibilities onto one existing layer of code. Decisions are hard to spot; behaviors usually are not. Then ask what incentives explain the behavior, whether those are the incentives you wanted, and what decisions created the incentive structure you have.

Fike adds a fourth tool he attributes to Will Larson, whom both speakers worked for: the physics of the situation. It means stepping out of the usual headspace of architecture or policy and considering the natural mechanics, the plain cause and effect. Balls do not roll uphill. His example: if you are revising a developer experience survey and want feedback that is more structured and measurable, you might place a larger organizational burden on the respondent for how they organize their thoughts. You will not get better feedback; you will get less feedback. Make something harder to do and people do less of it. So when deciding, ask whether the decision makes one behavior easier than another or rewards a particular behavior, and whether that is what you meant to incentivize.

A Synthesized Excavation Loop

The talk describes a repeatable excavation process rather than a system. The diagram below is my own synthesis of the three themes plus the physics check, assembled into one loop; the speakers did not present it as a single flow or diagram.

flowchart TD
    A[An overt decision, or a
behavior you cannot explain] --> B[Name the default:
what am I falling into
without choosing it?]
    B --> C[Ask why repeatedly until a
principle or philosophy appears]
    C --> D{Was that principle
deliberately chosen?}
    D -- No --> E[Decide now: accept it
or challenge it]
    D -- Yes --> F[Check it is still right
for today's context]
    E --> G[Check the physics:
which behavior does this
make easier or reward?]
    F --> G
    G --> H{Are those the incentives
we actually want?}
    H -- No --> I[Change the tooling, metric,
or ownership boundary]
    H -- Yes --> J[Write the principle down and
communicate it to the team]
    I --> J
    J --> A

Fike's parting exercise is in the same spirit and worth doing literally. He shows a photo taken the previous April, when he and Martell were speaking at QCon London, of what he assumes is an access panel for electrical or telecom equipment set into the ground near an intersection. Someone did that. His prompt: work out what incentives might have existed, and what hidden decisions created those incentives, for that to be the outcome — and then ask whether the metaphorical equivalent is happening in your workplace, and why.

Trade-offs And Limitations

  • This is two people's experience, not evidence. Every claim rests on stories from the speakers' combined careers. There are no measurements, studies, or comparisons, and the speakers do not present any. Treat the material as well-argued heuristics.
  • The speakers explicitly refuse to prescribe. Their recap is emphatic that they are not telling you to do more or less of anything, only to make the choice consciously.
  • "It depends" is doing real work. Fike says outright that the right contents of a CI pipeline depend on context, and Martell says both differentiated team stacks and shared infrastructure can be correct depending on context. Neither offers a rule for choosing, which means the technique surfaces the question without answering it.
  • Not building has its own cost. Martell's team got their insight from a throwaway notebook, but that path leaves the underlying data problem unsolved and the analysis unrepeatable. She names the institutional counter-pressure without offering any way to change the promotion criteria that create it.
  • The better Kafka metric is harder to collect. Counting distinct event consumers in a codebase is a more meaningful proxy than counting events, but it requires static analysis of the code rather than reading a broker dashboard. Fike makes the point himself in general terms: the measurements that build good judgment are the harder ones to take.
  • Career agency is unevenly distributed. Martell is careful that her outcome was luck, that not everyone gets to choose their moment, and that sometimes survival is the only available decision. Advice to define a career strategy applies most cleanly to people with options.
  • Retrospection has limits the talk does not address. This is my observation, not the speakers': asking why five times about every decision is not free, and a team that applies it uniformly will spend meaningful time excavating decisions that did not need excavating. The speakers give no guidance on which decisions warrant the treatment.

Practical Takeaways

  • Before building anything or scheduling a meeting, pause and ask whether you are falling into a default you did not choose.
  • Write your platform principle down where engineers weigh trade-offs against it, as Fike's team did in its platform execution strategy, rather than leaving it as an assumption.
  • Judge new platform tooling by whether a user can understand and use the first use case, not by how many use cases it supports or how many users it has.
  • Treat the choice to write code as a real decision with a stated rationale, and make the throwaway analysis a legitimate option when the goal is to learn rather than to ship.
  • Measure your CI pipeline by the behavior it produces — pull request size, review depth, merge frequency — not only by pass rates and coverage.
  • Before building something adjacent to another team's system, go talk to that team and establish what is and is not possible; the duplicate-platform decision is made by skipping that conversation.
  • When picking a metric for a migration or platform, state the problem you are solving first, then find the proxy that moves only when the problem improves, as with consumer count versus event count.
  • Notice when a metric starts being celebrated; that is the point at which it stops being questioned.
  • Look at what people are doing rather than what they are not doing, and work backward to the incentive that explains it.
  • Run the physics check on process changes: if a change makes a behavior harder, expect less of it regardless of the quality you hoped to gain.
  • Run a retrospective on your own past decisions, extract the principle behind each, and decide whether you would choose it again.
  • When leaving a role, finish the other half of the decision — what work you want, what gives you energy, what traits you need in the next opportunity — before accepting the first offer.
  • Audit the work you habitually reach for; if it has quietly become your professional identity, decide deliberately whether you want the reputation it is accumulating.

Key Terms

  • Hidden decision — A decision made without recognizing it, usually an unnamed principle sitting beneath an overt choice, which the speakers distinguish from an unintended consequence because a consequence is something you react to while a decision is something you own.
  • The decision behind the decision — Fike's term for the layered choice found by asking why repeatedly about a visible decision; once articulated, it is your strategy.
  • Measurement drift — Fike's term for a culture assembled accidentally out of metrics, one dashboard at a time, when useful signals are treated as proxies for value without checking that they still relate to it.
  • Shipping the org chart — Architecture that mirrors company structure; the speakers extend it to the decision-making layer, where decisions are owned because they fit the org chart rather than because that is right for the product.
  • The physics of the situation — A decision-making lens Fike attributes to Will Larson: ignore architecture and policy framing and reason about plain cause and effect, particularly whether a change makes a behavior easier or harder.
  • Core Technology Group (CTG) — The internal-tools team Fike was assigned to at Volition, building the memory profilers, debug utilities, build pipelines, asset browsers, and content serializers that game developers use rather than the game itself.

Reference: Dan Fike and Shawna Martell, Hidden Decisions You Don't Know You're Making, QCon San Francisco 2025, published by InfoQ on March 31, 2026.