The Hidden Decisions Shaping Your Career and Code

Dan Fike and Shawna Martell reveal how "hidden decisions" silently shape software architecture and engineering culture. By examining the invisible defaults behind CI/CD bottlenecks, platform complexity, and misaligned metrics, they share frameworks for leading with intentionality. Learn to identify the "decision behind the decision" to better incentivize high-performing teams and careers.

---

The Architecture of Unintentional Choices

Every commit, every pull request, every hire begins with a decision. But beneath these overt choices lie hidden decisions—the ones we make without realizing it. These invisible defaults shape our culture, relationships, architecture, and careers.

Platform Success: Simplicity Over Complexity

After years building backend platform tooling, Dan Fike has a controversial take: the most successful platform technology enables simplicity, not complexity.

"I've seen tooling that solved 10 tricky problems and introduced 9 new ones. Where the complexity of our life without that platform ends up being replaced by the new complexity of life with that platform."

This isn't about avoiding powerful features. It's about making tools simple to understand and simple to use. The root cause? When platforms aim to enable users to achieve complex results rather than avoid complexity entirely.

Shawna Martell adds a crucial dimension: "If your platform supports 94 use cases but nobody understands the first one, maybe you're not really helping."

The Decision to Build

Before deciding what to build, we must decide whether to build at all. This fundamental choice often goes unexamined.

Shawna shares a cautionary tale from an AI agent project. The team was thrashing, lacking observability into agent performance. When an engineer proposed a massive generalized metrics tracking solution, they'd skipped the critical step: building to learn, not building to build.

"We weren't building to learn. We were building to build. The decision to build it never felt like a decision."

Instead of shipping thousands of lines of infrastructure code, they built a "crime scene" Jupyter Notebook that parsed messy JSON blobs. It was ugly but effective. They learned their generalized tracker wouldn't have provided the insights they actually needed.

This reveals a deeper truth: code is both our most valuable asset and our greatest liability. When we default to shipping new code, we default to accepting long-term costs and risks.

Hidden Decisions in Team Culture

The CI/CD Bottleneck Effect

Slow pipelines don't just delay work—they reshape behavior. When CI takes an hour, developers bundle changes into massive pull requests that are hard to review and rubber-stamped through.

"A slow pipeline doesn't just delay us, it reshapes the way we work around it."

This hidden decision—allowing pipelines to drift into being slow and cumbersome—creates a culture of big, risky changes instead of small, manageable ones.

Who Gets Heard

Hidden decisions also determine whose voices matter. We often follow the loudest voice, the most senior person, or whoever's most persuasive in Slack. Sometimes we just follow whoever we're used to asking first.

This isn't about excluding others—it's about defaulting. And defaults are powerful.

Ownership as Constraint

Ownership is usually a virtue, but without intentionality, it becomes a constraint. The classic "shipping the org chart" problem occurs when architecture mirrors company structure.

Shawna tells the story of a team building a duplicate HR integration platform. The existing platform solved 80% of their needs but was owned by another team, written in a different language, and lived in a different repo.

"The decision that had happened basically invisibly is that we don't build on things we don't own. We don't ask other teams to adapt. We just avoid that friction entirely."

The hidden decision wasn't about architecture or capabilities—it was about ownership boundaries creating duplication and long-term maintenance costs.

Measurement: The Hardest Hidden Decision

If ownership shapes behavior, measurement cements it. What we measure becomes what we optimize for, even when nobody decided it that way.

Dan shares the Kafka adoption story. The infrastructure team wanted teams to move from tight synchronous dependencies to decoupled event-driven architecture. They measured success by counting events flowing through Kafka.

"More events means more adoption. More adoption means we're solving more dependency issues."

But this created the wrong behavior. Teams instrumented speculative events "just in case." Event counts soared, but coupling didn't improve. The real metric should have been the number of distinct event consumers—each representing a line in the dependency graph converted from solid to dotted.

This wasn't malicious. The team was measuring what was easy to measure, not what actually indicated progress toward their goal.

Career Strategy: The Ultimate Hidden Decision

Hidden decisions shape careers as much as code. Shawna's story illustrates this perfectly. After seven years at Wolfram Research, she decided to return to individual contributor work. When that didn't provide the reset she wanted, she left—but only made half a decision.

"I decided that I was leaving, but I really hadn't spent much time thinking about where I was going."

She allowed circumstance to choose for her. "Anywhere but here" became her strategy. She was lucky—the next role was great—but luck isn't a strategy.

Dan's career followed a similar pattern. His first job out of school was in games, but he ended up in Core Technology Group building tools for other engineers. It wasn't a deliberate choice.

"I enjoy my work a lot. Did I get good at it because I liked it, or did I start to like it because I was good at it?"

Professional identity accumulates. Once people see you as a specific type of engineer, changing isn't just technically difficult—it's emotionally and politically risky.

The Physics of Decision-Making

Will Larson's concept of "the physics of the situation" helps reveal hidden decisions. Consider a developer experience survey: making feedback more structured might require more effort from reviewers. The physics says if you make something harder, people will do less of it.

"Balls don't roll uphill. If you are, for example, iterating a developer experience survey for your engineers, and you want the feedback you collect to be more structured and measurable, you might, in order to achieve that, place a larger burden on the reviewer for how they organize their thoughts. If you do that, you're not going to get better feedback, you are going to get less feedback. That's the physics of it."

When making decisions, consider: Does this make one behavior easier than another? Is that what you want to incentivize?

Finding the Decision Behind the Decision

The solution isn't more meetings or more documentation. It's asking better questions:

• What principles brought us to this decision?
• Did we end up here intentionally or by accident?
• What behaviors does this decision incentivize?
• What's the "decision behind the decision"?

Use the "five whys" technique not just for incident analysis but for decision analysis. Behind every choice, there's usually a core principle or philosophy—your strategy.

Practical Framework

Before building that next thing or scheduling that meeting, pause and ask:

1. Is there a default we're falling into unintentionally?
2. What behaviors does this decision incentivize?
3. Are those the behaviors we want?
4. What's the decision behind this decision?
5. What principles are we applying, and are they the right ones?

The Power of Intentionality

Hidden decisions aren't hidden because they're complex—they're hidden because we never admitted we were deciding at all. The most important decisions we make often happen in the absence of meetings, in the space between choices.

"You don't get to opt out of having a career strategy. Even 'I'll just see what happens'—that is a strategy. It's just one where momentum decides for you."

Whether in code, culture, or careers, the key is noticing when we're shaping outcomes. When you're making a decision, ask yourself: What principles, policy, and process brought us to making this decision at this time with these people? Why? Were they the right principles?

Because if we don't name those things for ourselves, our circumstances will name them for us.

---

This content is based on the QCon San Francisco 2025 presentation "Hidden Decisions You Don't Know You're Making" by Dan Fike and Shawna Martell.