# Christian Battaglia — Product Engineering (full text) > Concatenated published articles from https://cdbattaglia.com/prodeng. See /llms.txt for the index. Unpublished previews are omitted. Generated from 6 published articles. --- # Why Great Products Are Built in the Tradeoffs, Not the Backlog - Canonical: https://cdbattaglia.com/prodeng/articles/why-great-products-are-built-in-the-tradeoffs - LinkedIn: https://www.linkedin.com/pulse/why-great-products-built-tradeoffs-backlog-christian-battaglia-lwy3e - Date: 2025-12-23 Most product failures aren't technical. Most engineering failures aren't about talent. They're failures of decision-making. Too many teams confuse having ideas with making choices. ## The Engineering Butcher Shop I think of product engineering as a butcher shop, not a kitchen. The kitchen exists to execute demand. The butcher shop exists to shape it. When an ambitious product idea shows up, the job isn't to say "yes" or "no." The job is to present a menu of intentional tradeoffs. IMO, every serious initiative should be framed this way: ### 1. Fast **What can we ship in days?** - **Purpose:** validate, unblock, or learn - **Cost:** corners cut, assumptions baked in - **Risk:** low; because it's meant to be temporary Fast is for momentum. Fast is not for pride. ### 2. Good **What's the responsible baseline?** - **Purpose:** deliver real value to real users - **Cost:** known and intentional debt - **Risk:** moderate; but controlled Good is where most businesses should live most of the time. ### 3. Well **What would we build if this truly matters?** - **Purpose:** durability, leverage, scale - **Cost:** time, coordination, discipline - **Risk:** high; but only worth it when the payoff compounds Well is expensive. Well is powerful. Well should be rare; and deliberate. ## The Real Skill: Knowing Which One to Choose High-performing teams don't always build Well. They build the right thing for the moment, then execute with conviction. The failure mode I see over and over: - Engineering defaulting to Well when the business needs Fast - Product pushing Fast when the system is already brittle - Leadership asking for everything and getting none of it done well Product engineering lives in the tension between speed, quality, and leverage; and embracing that tension instead of pretending it doesn't exist. ## What This Newsletter Will Cover Every two weeks, I'll write about: - How to frame product decisions engineers actually buy into - Where teams over-invest (and under-invest) in quality - Technical debt as a strategic tool, not a moral failure - Incentive alignment between product, engineering, and leadership - Real patterns from scaling B2B systems under real constraints No hype. No "10x engineer" nonsense. Just clear thinking about how products actually get built. If you build software where tradeoffs matter; welcome. --- # The Real Constraint in Product Development: Known and Unknown Unknowns - Canonical: https://cdbattaglia.com/prodeng/articles/the-real-constraint-in-product-development - LinkedIn: https://www.linkedin.com/pulse/real-constraint-product-development-known-unknown-christian-battaglia-i16ee - Date: 2025-12-26 In the last article, I argued that great products aren't built by optimizing a backlog; they're built by making explicit tradeoffs. This raises a natural question: **What are we actually trading off against?** The answer isn't effort, or points, or even quality. It's uncertainty. More specifically: known unknowns and unknown unknowns. Most friction between business, product, and engineering isn't disagreement. It's people reacting to different kinds of uncertainty, without naming which ones they're dealing with. ## Two Types of Unknowns That Matter ### Known Unknowns These are the risks you can name upfront. You know there's uncertainty; you just don't have the answer yet. Examples: - Will customers adopt this? - Will this performance profile hold at scale? - Can this dependency deliver on time? - Is this scope sufficient? Known unknowns are uncomfortable, but manageable. They can be tested, priced, and planned around. This is where most teams think they're operating. ### Unknown Unknowns These are the risks you don't know exist yet. They only reveal themselves through: - real usage - real scale - real failures - real change Examples: - an assumption embedded deep in the system - a workflow no one anticipated - a scaling cliff that wasn't obvious - an organizational bottleneck that only appears under pressure Unknown unknowns are why plans break. They're also why rewrites happen. ## Why Backlogs Are a Trap Backlogs are good at organizing work. They are terrible at surfacing unknown unknowns. A backlog assumes: - problem is understood - solution is known - work is enumerable Unknown unknowns violate all three. When teams treat the backlog as truth, they optimize execution around assumptions that haven't been stress-tested yet. **That's how you end up "on schedule" and still wrong.** ## Tradeoffs as a Tool for Managing Uncertainty This is where the Fast / Good / Well framework from the first article matters. These aren't quality levels. They're uncertainty strategies. ### Fast: Expose Unknowns Quickly Fast is about surfacing unknown unknowns cheaply. - prototypes - spikes - narrow releases - temporary solutions Fast isn't reckless; it's investigative. ### Good: Stabilize What You Now Understand Good is for known unknowns. - core value is proven - edges are still fuzzy - system needs to work reliably, not perfectly Good keeps options open while the product matures. ### Well: Reinforce Where Brittleness Appears Well is a reaction, not a default. You build Well after: - something breaks - scale exposes stress - change becomes expensive - the business depends on it Well exists to remove specific risk, not to feel responsible. ## Why Rewrites Actually Happen Rewrites don't happen because teams built Good. They happen because: - unknown unknowns were ignored - Fast was never revisited - brittleness wasn't reinforced in time - debt was left invisible **Rewrites are the cost of pretending uncertainty doesn't exist.** ## The Real Work of Product Engineering Product engineering isn't about eliminating risk. It's about: - distinguishing known unknowns from unknown unknowns - choosing the right tradeoff for each - revisiting decisions as evidence arrives When teams fight over scope, quality, or speed, they're usually arguing about which uncertainties matter most right now. Name the uncertainty, and the tradeoff becomes obvious. That's how you move from backlog-driven delivery to outcome-driven building. --- # The Cost of Certainty (and Why the Best Teams Avoid It) - Canonical: https://cdbattaglia.com/prodeng/articles/the-cost-of-certainty - LinkedIn: https://www.linkedin.com/pulse/cost-certainty-why-best-teams-avoid-christian-battaglia-oze1e - Date: 2026-01-06 In the first two articles, I argued that great products are built through tradeoffs; and that most of the real friction in product, engineering, and business comes from unknowns, not incompetence. This article attempts to complete that thought. Because once teams accept that uncertainty is unavoidable, a new failure mode appears: the temptation to eliminate it. That instinct is understandable. It's also incredibly expensive. ## Certainty Is a False Optimization Certainty feels like rigor: - Perfect requirements - Locked roadmaps - Fully scoped architectures - "No surprises" delivery plans But certainty is not an input. It's an output; and only after reality has been allowed to push back. When teams demand certainty upfront, what they're really saying is: **"We'd rather delay learning than risk being wrong."** That tradeoff doesn't reduce risk. It just postpones visibility. ## Where the Pursuit of Certainty Quietly Hurts Teams Certainty usually enters the system wearing a disguise. ### In Product - "Let's not ship until we fully understand the customer" - "We need more validation before committing" - "We can't change scope mid-cycle" The result isn't better product. It's product that lags reality by months; and nobody notices until churn, adoption, or sales friction spikes. ### In Engineering - "We should design this for all future use cases" - "Let's refactor first so we don't accrue debt" - "This needs to be more elegant before it ships" The system becomes internally coherent; and externally misaligned. ### In Leadership - "Let's wait for alignment" - "We need more data" - "We should socialize this more" Decisions decay into consensus theater. Velocity slows without anyone explicitly choosing it. ## This Doesn't Change With Company Size A common mistake is assuming this philosophy only applies to startups. It doesn't. Startups don't have a monopoly on uncertainty. Enterprises don't have a monopoly on rigor. What changes as companies scale is the blast radius, not the underlying dynamic. ### Startup - **What's different?** Low external cost of mistakes - **What's the same?** The future is still unknowable ### Mid-size - **What's different?** Customers depend on you - **What's the same?** You're still guessing; just with more data ### Enterprise - **What's different?** Trust and uptime are existential - **What's the same?** Behavior and usage are still unpredictable No organization ever graduates from uncertainty. They only graduate into more expensive ignorance. ## This Is Not "Fail Fast" or "F*** It, Ship It" Those slogans confuse speed with learning. This isn't about recklessness. And it's definitely not about carelessness. Mature teams don't fail fast. They fail contained. They don't ship impulsively. They ship reversibly. The goal isn't speed for its own sake. The goal is early, honest signal; without burning trust. ## Strong Teams Don't Reduce Uncertainty — They Absorb It This is the real dividing line. Weak systems try to eliminate uncertainty. Strong systems are built to absorb it. You see this in: - Modular architectures - Loosely coupled teams - Feature flags and dark launches - Reversible decisions - Explicit kill-criteria for projects - Time-boxed bets instead of permanent commitments Different tactics at different scales. Same philosophy everywhere: learn without destabilizing the system. ### What This Looks Like in Practice - **Startups** use narrow rollouts, throwaway tooling, and aggressive iteration. - **Mid-market teams** rely on backward-compatible changes, parallel systems, and clear cutover points. - **Enterprises** use shadow traffic, staged migrations, and long deprecation windows. The mechanics change. The constraint does not. ## Rewrites Aren't Failures; They're Evidence of Learning This ties directly back to the earlier articles. Rewrites don't happen because teams "built badly." They happen because: - the problem space evolved - the business learned - constraints changed Enterprises rewrite too; they just call it "modernization," "platform investment," or "digital transformation." The rewrite isn't the failure. Pretending a rewrite won't be necessary is. The real mistake is building systems (technical or organizational) that make learning traumatic. ## The Question High-Performing Teams Actually Ask Instead of asking: **"How do we get this right?"** Strong teams ask: **"How wrong can we afford to be — and how fast can we recover?"** That single reframing drives: - smaller bets - clearer escape hatches - calmer teams under pressure - less ego, more iteration It also creates organizations that don't panic when reality disagrees with the plan; because they expected it to. ## Certainty Is Comfort. Progress Is Not. Certainty feels responsible. Progress feels messy. If your roadmap, architecture, or product strategy feels too clean, that's not a win; it's a warning sign. The teams that scale aren't the ones that move fastest. They're the ones that never lie to themselves about how much they still don't know; even when the stakes get high. And they build systems (human and technical) that can survive being wrong. This series started with tradeoffs, moved through unknowns, and now lands on how teams respond when uncertainty refuses to go away. There's more to explore here; especially around incentives, organizational design, and how teams accidentally optimize for the wrong signals as they grow. More to come. --- # The Trust Tax: What Low-Trust Environments Actually Cost - Canonical: https://cdbattaglia.com/prodeng/articles/the-trust-tax - LinkedIn: https://www.linkedin.com/pulse/trust-tax-what-low-trust-environments-actually-cost-battaglia-ruaje - Date: 2026-01-20 ## What Low Trust Actually Costs Most teams know trust matters. Few understand how expensive the absence of it is. The numbers are stark: **Performance and Productivity:** - Workplaces with low trust experience a **40% reduction in performance**[^1] - High-trust organizations report **50% higher productivity**[^2] - Disengaged employees—often a direct result of low trust—cost the global economy **$8.8 trillion annually**, roughly 9% of global GDP[^3] **Retention and Turnover:** - High-trust organizations experience **50% lower turnover** than their low-trust competitors[^2] - Replacing an employee costs **1.5 to 2 times their annual salary**[^4] - In 2023, toxic corporate culture was **10 times more predictive of turnover than compensation**[^5] **The Hidden Overhead:** But those are just the visible costs. The real damage happens in the behaviors low trust creates: ### 1. Cover-Your-Ass Culture When trust is low, people optimize for looking right over being right. Research on defensive decision-making in organizations found that **80% of managers had made at least one defensive decision in the past year**—and on average, **25% of their most important decisions** were made to avoid personal repercussions rather than serve the organization's best interest[^6]. What this looks like in practice: - **Excessive documentation** that no one reads, created solely to prove you did your job - **Shadow files**—secret personal logs of interactions used as evidence in future disputes - **Email chains** copying five people on routine decisions "just to be safe" - **Consultant theater**—hiring external firms to validate decisions already made, providing a ready scapegoat if things go wrong The time cost alone is staggering. Significant energy gets diverted from productive work to justifying decisions and covering bases. ### 2. Defensive Architecture Low trust doesn't just affect processes. It affects technical decisions. When engineers don't trust that mistakes will be handled fairly, they build systems that optimize for blame avoidance: - Over-engineered solutions "just in case" - Layers of approval processes baked into the system - Refusal to touch legacy code for fear of being blamed if something breaks - Architecture that makes changes expensive by design, so no one can be blamed for moving slowly The system becomes internally coherent and externally misaligned. Sound familiar? ### 3. The Silence Problem Perhaps the most expensive cost is invisible: **the problems that never get surfaced**. When people don't feel safe speaking up: - Critical bugs go unreported until they hit production - Bad decisions aren't questioned until they become sunk costs - Technical debt compounds silently until it forces a rewrite - Customer pain points remain invisible until churn spikes Google's Project Aristotle—a multi-year study of 180 teams—found that **psychological safety accounted for 43% of the variance in team performance**[^7]. It wasn't just the most important factor; it was **foundational to all other dynamics**. Teams with high psychological safety experienced: - **19% higher productivity** - **31% more innovation** - **27% lower turnover** - **3.6x more engagement**[^7] The mechanism is counterintuitive: in high-safety environments, members **report more errors**, not fewer. They feel safe admitting mistakes, allowing for earlier intervention. In low-trust environments, problems hide until they become crises. ## The Speed-Trust Relationship Here's the uncomfortable truth: trust isn't orthogonal to velocity. It's the unlock. Think of it as a 2x2 matrix: | | **High Speed** | **Low Speed** | |---|---|---| | **High Trust** | Learning culture
Fast iteration, contained failures, rapid recovery | Deliberate culture
Slow but steady, high quality, low drama | | **Low Trust** | Chaos
Recklessness, burnout, firefighting | Death spiral
Paralysis, CYA overhead, best people leave first | Most "move fast" advice assumes high trust. When you copy those tactics into a low-trust environment, you don't get innovation—you get chaos. Similarly, slowing down in a low-trust environment doesn't create rigor—it creates paralysis. **Trust is what allows speed to be productive rather than destructive.** This is why the Fast/Good/Well framework from earlier articles only works in environments where people feel safe making explicit tradeoffs. Without trust: - "Fast" becomes reckless - "Good" becomes defensive - "Well" becomes gold-plating ## How Trust Breaks Trust doesn't usually shatter in one dramatic moment. It erodes through patterns. ### 1. Blame Culture The fastest way to destroy trust is to respond to failure by looking for who to blame rather than what to fix. Research on blameless postmortem culture shows this clearly. Elite engineering teams **prevent approximately 95% of repeat incidents**, while average teams experience the same failures quarterly[^8]. The difference isn't talent—it's whether the organization treats incidents as learning opportunities or witch hunts. When Google documented their "fearless shared postmortem" approach, they noted that **psychological safety was the #1 predictor of team performance**. In high-safety environments, people report incidents earlier and more honestly, allowing the system to learn before small problems become catastrophic[^8]. The contrast is stark: - **Blame culture asks:** "Who clicked the wrong button?" - **Learning culture asks:** "How did the system allow this to happen?" One finds a scapegoat. The other fixes the system. ### 2. Arbitrary Reversals Nothing kills trust faster than decisions that get reversed without explanation or consultation. When leadership: - Commits to a technical direction, then pivots without context - Approves scope, then cuts it mid-cycle with no discussion - Promises resources, then reallocates them silently People learn that decisions aren't real. They start optimizing for flexibility over commitment. Planning becomes theater. Velocity craters. ### 3. Hidden Agendas Trust requires transparency about priorities and tradeoffs. When teams suspect there are unstated goals—performance review rankings that contradict "we're a team," roadmap commitments that contradict "we're customer-driven," cost-cutting that contradicts "people are our most important asset"—they stop believing anything leadership says. The gap between **stated priorities and revealed priorities** becomes corrosive. ### 4. Inconsistent Consequences Perhaps most toxic: when the rules change based on who broke them. When mistakes get treated differently based on seniority, political capital, or relationship with leadership, people learn that the system isn't fair. They stop taking risks. They stop being honest. They optimize for not getting caught. ### 5. The "Paradise Lost" Effect Amy Edmondson's recent research uncovered something particularly troubling: **new hires typically enter roles with high optimism but experience a significant decline in psychological safety after their first year**[^9]. This "Paradise Lost" effect happens as employees realize that questions or suggestions may not be welcomed. They learn to "mute" their views to avoid interpersonal risk. The organization doesn't get worse—people just stop believing it's safe. The cost? You hired someone for their perspective and insight, then trained them to keep it to themselves. ## Building Systems Safe to Change So how do you build trust? Or rebuild it once it's broken? The bad news: there's no quick fix. Trust is built slowly through consistent patterns. The good news: those patterns are concrete and learnable. ### 1. Psychological Safety Isn't "Niceness" Let's be clear: psychological safety is not about being nice, avoiding hard conversations, or protecting feelings. Edmondson defines it as **"the belief that the team is safe for interpersonal risk-taking"**—that you can admit mistakes, ask questions, or challenge assumptions without fear of embarrassment or punishment. High-trust teams have hard conversations. They disagree openly. They challenge each other's ideas aggressively. The difference is that those challenges are **about the work, not the person**. And there's no penalty for being wrong. ### 2. Blameless Postmortems Done Right The blameless postmortem isn't a meeting format. It's a philosophy. When something breaks: **Don't ask:** "Who did this?" **Ask:** "What conditions allowed this?" **Don't document:** "Engineer X deployed without testing" **Document:** "Deployment process didn't require pre-production validation; adding automated checks" **Don't create:** Action items for individuals to "be more careful" **Create:** System changes that make the failure impossible or obvious earlier The research is clear: organizations that treat incidents as learning opportunities **reduce repeat incidents by 50%**[^8]. Those that blame individuals don't learn—they just get better at hiding problems. **Key practices:** - Schedule the postmortem within **3-5 days** while details are fresh[^10] - Assume **everyone acted with good intentions** based on the information they had - Focus on **systemic issues**, not individual actions - Create **action items with owners and deadlines**—learning without action is just catharsis - Consider **sharing postmortems externally** to build customer trust and industry learning ### 3. Clear Decision Rights Trust breaks down when people don't know who can decide what. You need clarity on: - **What decisions require consensus** (interfaces, customer promises, shared infrastructure) - **What decisions can be made independently** (implementation details, internal architecture) - **How decisions get escalated** (clear path, clear criteria) - **How decisions get reversed** (transparent process, explained rationale) Consensus theater—pretending everyone needs to agree when they don't—is trust-destroying. It wastes time and obscures accountability. True clarity often means accepting that **not every decision needs your input**. And that's okay. ### 4. Learning From Near-Misses Most organizations only learn from disasters. High-trust organizations learn from near-misses. When someone catches a problem before it hits production, don't just fix it and move on. Celebrate it. Publicize it. Use it as a learning opportunity. This creates a culture where people **feel rewarded for surfacing problems early** rather than punished for creating them. The message becomes: "We value catching issues over pretending they don't exist." ### 5. Make Incentives Match Reality This is the hard one. If you say "we value learning" but promote people who never make visible mistakes, you're teaching people to hide problems. If you say "we value innovation" but punish failed experiments, you're teaching people to play it safe. If you say "we value speed" but reward perfect execution over fast iteration, you're teaching people to over-engineer. **Your revealed priorities matter more than your stated ones.** High-trust organizations align: - What they say they value - What they measure - What they reward - What they promote When those four things point in the same direction, people believe you. When they diverge, trust erodes. ## The Leadership Question If you're a leader reading this, here's the uncomfortable question: **Do your people feel safe telling you the truth about what's actually happening?** Not "do they report status." Do they tell you when they're stuck? When they think a decision is wrong? When they've made a mistake? When the plan isn't working? Because if they don't, you're leading blind. You're making decisions based on filtered information. You're optimizing a model that doesn't match reality. You're hemorrhaging trust and productivity, and you might not even notice until your best people start leaving. The constraint isn't your strategy, your process, or your tools. **It's whether people feel safe telling you that your strategy isn't working, your process is broken, and your tools aren't helping.** ## This Doesn't Change With Scale A common pushback: "This sounds great for startups, but we're an enterprise. We need more process, more controls, more oversight." Wrong frame. **Trust and accountability aren't opposites. They're complements.** High-trust organizations often have *more* rigorous processes than low-trust ones. The difference is the *purpose* of those processes: | **Low-Trust Process** | **High-Trust Process** | |---|---| | Proves you did your job | Helps you do your job better | | Prevents people from making mistakes | Helps people learn from mistakes | | Assigns blame when things fail | Fixes systems when things fail | | Optimizes for CYA | Optimizes for learning | At startup scale, low trust kills velocity through firefighting and churn. At enterprise scale, low trust kills velocity through bureaucracy and paralysis. The tactics change. The constraint doesn't. ## Certainty Is Comfort. Trust Is Courage. Bringing this back to the earlier articles: remember the "cost of certainty"? Low-trust organizations pursue certainty because they can't afford to be wrong. They over-plan, over-document, over-engineer—not because those things create value, but because they create cover. **The pursuit of certainty is often a symptom of low trust.** High-trust organizations can embrace uncertainty because they trust they can recover from being wrong. They can: - Ship Fast without it becoming reckless - Build Good without it becoming defensive - Invest in Well without it becoming gold-plating They can make explicit tradeoffs because they trust that mistakes will be treated as learning opportunities, not career-limiting events. **Trust is what makes the entire framework work.** ## The Unlock Here's what changes when trust is present: **At the individual level:** - People surface problems early instead of hiding them - They take smart risks instead of optimizing for safety - They collaborate instead of building silos - They learn instead of defending **At the team level:** - Velocity increases because coordination costs decrease - Quality increases because problems get caught earlier - Innovation increases because people try new things - Retention increases because people feel valued **At the organizational level:** - Decisions are faster because you trust the information - Adaptability increases because pivots don't feel like betrayals - Execution improves because energy goes to work, not CYA - The system can learn without destabilizing This isn't soft skills. This is the foundation that determines whether your product engineering succeeds or fails. ## The Work Building trust isn't about team-building exercises or inspirational speeches. It's about **consistent patterns of behavior over time**: - Treating incidents as learning opportunities, not blame opportunities - Being transparent about priorities and tradeoffs - Making consequences consistent and fair - Rewarding honesty over perfection - Admitting when you're wrong - Following through on commitments - Explaining decisions, especially reversals Every interaction either builds or erodes trust. There are no neutral moves. The question isn't whether you have time to build trust. **The question is whether you can afford not to.** Because right now, if trust is low, you're paying for it in: - Lost productivity (40% performance reduction) - Turnover (2x salary to replace people) - Defensive behavior (25% of decisions made to avoid blame) - Hidden problems (issues that fester until they become crises) - Overhead (documentation theater and approval chains) You're already paying the trust tax. You're just not calling it that. ## A Final Thought The teams that ship great products aren't the ones with the best processes, the smartest engineers, or the most ambitious roadmaps. They're the teams where someone can say "I think we're building the wrong thing" and be taken seriously. Where someone can say "I made a mistake" and the response is "what did we learn?" Where someone can say "this isn't working" and the team pivots without drama. **The constraint isn't velocity. It's not even quality.** **It's whether people feel safe telling the truth about what's actually happening.** Everything else builds from there. --- ## References [^1]: ["The Hidden Cost of Distrust: Analyzing the Financial Implications of Low Trust in the Workplace"](https://blogs.psicosmart.net/blog-the-hidden-cost-of-distrust-analyzing-the-financial-implications-of-low-trust-in-the-workplace-210700) - PsicoSmart, 2024 [^2]: ["The Reasons Why High-Trust Organizations Outperform"](https://realizesolutions.ca/strategy/why-high-trust-organizations-outperform/) - Realize Solutions, 2024 [^3]: ["Employee Engagement Strategies: Fixing the World's $8.8 Trillion Problem"](https://www.gallup.com/workplace/393497/world-trillion-workplace-problem.aspx) - Gallup, 2024 [^4]: ["Turnover's Biggest Price Tag Isn't Recruiting – It's Lost Productivity"](https://c-suiteanalytics.com/price-is-lost-productivity/) - C-Suite Analytics, 2024 [^5]: ["Surprising Employee Turnover and Retention Statistics"](https://www.webmdhealthservices.com/blog/surprising-statistics-about-employee-retention/) - WebMD Health Services, 2023 [^6]: ["Cover Your Back! Frequency and Causes of Defensive Decisions in Public Administration"](https://link.springer.com/article/10.1007/s40685-018-0074-2) - Journal of Management and Governance, 2018 [^7]: ["Google Project Aristotle - Psych Safety"](https://psychsafety.com/googles-project-aristotle/) and ["Understand team effectiveness"](https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness) - Google re:Work, 2016 [^8]: ["Effective Post-Mortems: Executive Brief"](https://www.benjamincharity.com/articles/post-mortem-executive-brief/) - Benjamin Charity, 2024; ["Blameless Postmortem for System Resilience"](https://sre.google/sre-book/postmortem-culture/) - Google SRE Book [^9]: ["New Hires Lose Psychological Safety After Year One. How to Fix It."](https://www.library.hbs.edu/working-knowledge/new-hires-lose-psychological-safety-after-year-one-how-to-fix-it) - Harvard Business School Working Knowledge, 2024; ["In Tough Times, Psychological Safety Is a Requirement, Not a Luxury"](https://hbr.org/2025/11/in-tough-times-psychological-safety-is-a-requirement-not-a-luxury) - Harvard Business Review, 2025 [^10]: ["Step by Step - PagerDuty Postmortem Documentation"](https://postmortems.pagerduty.com/how_to_write/writing) - PagerDuty, 2024 --- # Managing Product Engineers: Autonomy + Visibility - Canonical: https://cdbattaglia.com/prodeng/articles/managing-for-product-engineering-output - LinkedIn: https://www.linkedin.com/pulse/managing-product-engineering-output-high-autonomy-christian-battaglia-aripe - Date: 2026-02-06 ## The Two Management Traps Most engineering managers fall into one of two traps. **The Micromanagement Trap:** Spending leadership time on Jira boards, sprint tracking, daily standups. This turns high-leverage roles into project coordinators. Engineers become order takers, not problem solvers. Leadership can't focus on architecture, platform vision, or cross-product coherence because they're stuck in tactical coordination. Harvard Business School research found that executives now spend an average of 23 hours per week in meetings, up from less than 10 hours in the 1960s. During the pandemic, employees attended 13% more meetings, and workdays extended by 48.5 minutes on average[^1]. Worse, HBS research showed that stand-up meetings actually inhibit innovation; in a field experiment at a Google hackathon, teams using stand-ups developed less-novel products[^2]. **The Hands-Off Trap:** Engineers have autonomy but no strategic context. Leadership loses visibility into blockers until it's too late. Team capacity is a mystery; overcommitment happens silently. Personal struggles go unnoticed. Most managers think they have to choose between control and autonomy. The best managers realize you need systems that provide visibility without requiring coordination overhead. ## The Two Systems That Enable Visibility Without Micromanagement ### System 1: Async Check-Ins (DailyBot) Instead of 30-minute daily standups where people aren't listening, use async check-ins. I use [DailyBot](https://www.dailybot.com/) connected to Slack and Jira, asking four questions daily: 1. **What did you do yesterday?** (Auto-tracked from Jira) 2. **What's your plan today?** (Forces prioritization thinking) 3. **Are you blocked?** (Surfaces obstacles in real-time) 4. **What's your score today (1-10)?** (Wellbeing check) The DORA Report 2024, surveying over 39,000 technology professionals, found that teams with effective communication systems remained resilient and productive[^3]. Async updates create that system; they replace meetings with written records, respect timezones, and enable pattern detection. ### System 2: Calendar Transparency (Free/Busy Visibility) Instead of defining explicit "working hours," use a simple principle: block your calendar when you're unavailable. Leadership sees free/busy status, not details. When someone doesn't respond to Slack, I glance at their calendar. If they're blocked, I know not to expect immediate response. If they're unblocked and quiet, I check their DailyBot for work blockers. Calendly's 2024 survey found that 67% of Gen Z workers proactively set calendar boundaries, compared to 53% of Millennials and 48% of Boomers[^4]. The trend is clear: younger workers understand that transparency enables async work. Calendar blocks explain non-responsiveness, reveal natural work rhythms, and protect focus time. The implicit contract: "I'll block my calendar when unavailable. You won't question why or expect responses during blocks. When unblocked, I'll be responsive." ## The 1-10 Scale Philosophy The simplicity of using 1-10 across different contexts makes the system intuitive and consistent. ### Daily Wellbeing: "Thriving or Surviving" I call this the "thriving or surviving" check-in. When someone reports 7-10, they're thriving. When they report 5-6, they're surviving. Anything below 5 means they're struggling and need help. I don't need to know if it's personal or technical. The score is a trigger, not a diagnosis. If someone consistently reports 5s or below, I reach out: "I saw your score; need anything?" No interrogation, just an offer to help. Gallup's wellbeing research found that highly engaged employees with strong wellbeing achieve 23% higher profitability, while poor wellbeing costs organizations $322 billion globally in turnover and lost productivity[^5]. Regular wellbeing check-ins enable real-time pattern detection and intervention. GitLab, one of the world's largest all-remote companies with over 1,500 engineers across 65+ countries, found that asynchronous communication is more efficient and effective in delivering business value while helping engineers achieve work-life balance[^6]. Their research showed that 52% of remote workers would consider leaving a colocated company for a remote role. The daily score creates psychological safety that enables this autonomy; engineers can be honest about struggling without career consequences. ### Monthly Performance: "Are You Meeting Expectations?" Separately from daily check-ins, I give every direct report a performance rating in monthly 1v1s using the same 1-10 scale: - **5 is the baseline**: You're doing your job; meeting expectations - **6-7**: Exceeding expectations; you're on the promotion track (if you want it) - **8-9**: Significantly exceeding expectations; high impact - **10**: Irreplaceable; operating at next level (I've given this twice in my career) - **<5**: Not meeting expectations; performance improvement plan (PIP) is imminent I want everyone to go above and beyond; a 5 is just the starting point, not the goal. And yes, I'm aware that in 2025, "6-7" became a viral meme that Gen Alpha kids were yelling everywhere until schools banned it. So when I tell someone they're performing at a 6 or 7, I can't help but think: at least they're not becoming a TikTok trend. The 1-10 scale makes performance visible, but what you do with that trajectory should be up to the engineer, not imposed by leadership. Some of the best engineers are happiest at a senior IC level, building great systems without the coordination overhead that comes with promotion. ## The Five Questions (Monthly 1v1s) Monthly 1v1s aren't about status; DailyBot handles that. They're about support, development, and removing friction. After reviewing daily patterns, I ask five questions: 1. **How are you doing personally?** 2. **How do you feel about your role on the team?** 3. **How do you feel about our team?** 4. **What more can I do for you?** 5. **What more can we do for the team?** Then I give the performance rating. Giving feedback after listening shows I'm considering their perspective, not just observing from above. The "what more can we do for the team?" question surfaces systemic issues early. Engineers see patterns leadership might miss. It creates ownership; they're helping improve the system, not just complaining. ## How This Enables Product Engineering This approach creates what McKinsey calls appropriate "span of control" without the supervisory burden Deloitte warns against[^8]. McKinsey found no magic number for reports per manager; it depends on work type, process standardization, and team independence[^8]. Deloitte found that too-narrow spans force managers into "working manager" mode, spending 100% of time on execution rather than strategic leadership[^9]. Async systems enable leadership leverage. I can read updates in 5-10 minutes versus attending 30-minute standups across multiple teams. This is how you scale from 5 engineers to 50 to 200 without losing visibility or adding layers of middle management. That freed time goes to: - Building train track ahead of the train (proactive architecture) - Serving as technical air traffic controller (cross-product decisions) - Deep technical work (reviewing migrations, writing infrastructure code) - Strategic thinking (platform coherence, grand vision) Engineers get high autonomy plus high visibility. They work independently, but leadership sees capacity, blockers, team health, and availability. No surprises; no micromanagement. Google's Project Aristotle found that psychological safety accounts for 43% of variance in team performance[^7]. The score system only works when engineers feel safe admitting struggle. Low-trust teams can't adopt this; they'll game the numbers or avoid honesty. ## What This Looks Like in Practice **Morning routine (5-10 minutes):** Check DailyBot; scan for blockers and low scores; glance at team calendars. Respond to specific asks. **When someone struggles:** Low wellbeing score (5 or below) triggers gentle check-in: "I saw your score; need anything?" Pattern of low scores means deeper 1v1 conversation. **When leadership needs deep work:** Block your own calendar. Model the behavior. Async system means uninterrupted focus time. ## The Tradeoffs This isn't "set and forget." It requires discipline to read updates, follow through when blockers surface, and build trust that scores won't be used punitively. This works best when teams are async-first, leadership values leverage over control, and tools integrate seamlessly. This struggles when leadership doesn't actually want to give up control or culture rewards "looking busy" over results. If you don't have time to read daily updates, you don't have visibility now either. This is the highest-leverage 10 minutes of your day. ## The Unlock The constraint isn't velocity. It's not quality. It's whether your management system enables engineers to think strategically while maintaining high autonomy. Product engineering doesn't happen when managers work harder; it happens when managers build systems that surface the right information at the right time, create psychological safety for honest communication, and free leadership time for high-leverage work. The teams that ship great products aren't the ones with the most meetings. They're the ones where everyone knows what matters, what's blocked, and who needs help without turning leadership into project coordinators. In the [Fast/Good/Well framework](https://www.linkedin.com/pulse/why-great-products-built-tradeoffs-backlog-christian-battaglia-lwy3e) from Article 1, these systems reveal which quality level is appropriate based on progress and blockers. In the [known/unknown unknowns framework](https://www.linkedin.com/pulse/real-constraint-product-development-known-unknown-christian-battaglia-i16ee) from Article 2, blockers surface unknown unknowns early. In [Article 4's Trust Tax](https://www.linkedin.com/pulse/trust-tax-what-low-trust-environments-actually-cost-battaglia-ruaje), the score system demonstrates why psychological safety is foundational; without trust, none of this works. The question isn't whether to give engineers autonomy or maintain visibility. It's whether you'll build systems that enable both simultaneously. [^1]: Harvard Business School Working Knowledge, "You're Right! You Are Working Longer and Attending More Meetings" (2020). Research analyzing 3.1 million people found employees attended 13% more meetings during pandemic and workdays extended by 48.5 minutes. [https://hbswk.hbs.edu/item/you-re-right-you-are-working-longer-and-attending-more-meetings](https://hbswk.hbs.edu/item/you-re-right-you-are-working-longer-and-attending-more-meetings) [^2]: Harvard Business Review, "Stand-up Meetings Inhibit Innovation" (2021). Field experiment at Google hackathon found teams using stand-ups developed less-novel products. [https://hbr.org/2021/01/stand-up-meetings-inhibit-innovation](https://hbr.org/2021/01/stand-up-meetings-inhibit-innovation) [^3]: DORA (DevOps Research and Assessment), "2024 Accelerate State of DevOps Report." Survey of 39,000+ technology professionals emphasizing effective communication systems for remote team resilience. [https://dora.dev/research/2024/dora-report](https://dora.dev/research/2024/dora-report) [^4]: Calendly, "The State of Meetings 2024." Survey of 1,200 business leaders found 67% of Gen Z workers proactively set calendar boundaries vs 53% Millennials and 48% Boomers. [https://calendly.com/resources/guides/2024-state-of-meetings-report](https://calendly.com/resources/guides/2024-state-of-meetings-report) [^5]: Gallup, "Employee Wellbeing Is Key for Workplace Productivity." Research showing highly engaged employees with strong wellbeing achieve 23% higher profitability; poor wellbeing costs $322B globally. [https://gallup.com/workplace/215924/well-being.aspx](https://gallup.com/workplace/215924/well-being.aspx) [^6]: GitLab, "How to embrace asynchronous communication for remote work" and "2021 Remote Work Report." Research from company with 1,500+ engineers across 65+ countries showing async work delivers business value while improving work-life balance; 52% of remote workers would leave for remote roles. [https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous) [^7]: Google re:Work, "Guide: Understand team effectiveness." Project Aristotle multi-year study of 180 teams found psychological safety accounts for 43% of variance in team performance. [https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness](https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness) [^8]: McKinsey & Company, "How to identify the right 'spans of control' for your organization." Research identifying five managerial archetypes and context-dependent optimal span of control. [https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/how-to-identify-the-right-spans-of-control-for-your-organization](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/how-to-identify-the-right-spans-of-control-for-your-organization) [^9]: Deloitte, "Sustainable Organizational Improvement: Understanding supervisory burden." Framework showing too-narrow spans force managers into "working manager" mode spending 100% time on execution. [https://www.deloitte.com/us/en/what-we-do/capabilities/mergers-acquisitions-restructuring/articles/supervisory-burden-root-causes.html](https://www.deloitte.com/us/en/what-we-do/capabilities/mergers-acquisitions-restructuring/articles/supervisory-burden-root-causes.html) --- # The Air Traffic Controller Problem: Every Team Needs One - Canonical: https://cdbattaglia.com/prodeng/articles/the-air-traffic-controller-problem - LinkedIn: https://www.linkedin.com/pulse/air-traffic-controller-problem-every-team-needs-one-battaglia-usigc - Date: 2026-02-20 Air traffic controllers don't fly planes. They prevent collisions. When six planes approach the same runway, the ATC doesn't separate them all into different airspaces. Some planes are grouped in formation. Some share the same approach path. Some need to land simultaneously on parallel runways. The ATC's skill isn't applying one rule. It's knowing which rule fits which situation. That role doesn't just exist in aviation. It exists in every team, every function, every organization. Most just don't name it. And when it's missing, you don't get crashes. You get something worse: coordination overhead that compounds until everyone is working harder and delivering less. I used the phrase in the [previous article](https://www.linkedin.com/pulse/managing-product-engineering-output-high-autonomy-christian-battaglia-aripe) as a management job: seeing across product lines so teams can move without collisions. This piece is about the role itself. Not just in engineering. Every function needs someone doing this, in the work, not above it. ## How to Read This Article - **CEO / COO / CFO:** The Symptom → The ATC in Every Function → For Executives - **CTO / VP Eng:** What the ATC Actually Does → Why the ATC Can't Be a Contractor → For Engineering Leaders - **CPO / CMO:** The ATC in Every Function → For Product and Marketing - **CSO / VP Sales / AE / BDR:** The ATC in Every Function → For Sales - **Engineer:** The 10-Hour Problem → What the ATC Actually Does - **Everyone:** The whole thing, about fifteen minutes ## The Symptom Everyone Recognizes This isn't just an engineering problem. But engineering makes it visible first. **Year 1:** 10 engineers. Features ship independently. Velocity is high. **Year 2:** 20 engineers. Features require coordination. Velocity plateaus. "We need better process," someone says. **Year 3:** 40 engineers. Every change cascades across teams. Your best people are coordinating, not building. Output went up 30%. Headcount went up 300%. Where did the rest go? **Coordination overhead.** And it happens in every function. I've watched this play out. A team I worked with had one engineer everyone relied on. Not because she wrote the most code, but because she was the only person who understood how the pieces fit together. By the time the org hit 40 people, she wasn't shipping anymore. She was in every planning meeting, every design review, every "quick question" Slack thread, because she was the only one who could see where a change in one system would break another. We had accidentally turned our best builder into a full-time router. The work didn't get harder. The coordination around it did. DORA's research on loosely coupled teams found that the teams that can test, deploy, and change systems without depending on other teams require **little communication to get work done**[^1]. The teams that can't spend their weeks coordinating instead of building. Randy Shoup, formerly Engineering Director at Google, put it concretely: Google's Datastore service is **"one of the largest NoSQL services in the world, and yet it is supported by a team of only about eight people, largely because it is based on layers upon layers of dependable services built upon each other."**[^1] Eight people running one of the largest services on the planet. Not because they're 10x engineers. Because someone designed the boundaries so they could operate independently. **That someone is the ATC.** ## The 10-Hour Problem Atlassian's 2025 State of Developer Experience report surveyed 3,500 developers and managers across six countries and found a striking paradox: **68% of developers save 10+ hours per week using AI tools**, then **50% lose 10+ hours per week to organizational inefficiencies**[^2]. Atlassian's own framing is the wash: you save ten hours, you lose ten hours. Not to coding problems. To finding information, new technology, switching context between tools, and **collaborating with other teams**[^2]. Notice what's absent from the top friction points: the actual work. The work itself isn't the bottleneck. The coordination around the work is. Cortex's 2024 State of Developer Productivity report, a survey of 50 engineering leaders at companies with 500+ employees, found the same pattern from the management side: **"gathering project context" and "waiting on approvals" tied at 26% each** as the largest productivity leaks[^3]. When 58% of those leaders report losing 5+ hours per developer per week to unproductive work, and the top causes are context-gathering and approval-waiting, you're looking at a missing ATC[^3]. Someone should have designed the system so that context is findable and approvals aren't bottlenecks. Someone should be looking at the whole picture and asking: why does this team need to wait on that team? ## The ATC in Every Function Here's the thesis: **the ATC role isn't an engineering role. It's a universal role that every function needs.** The ATC is the person who sees the whole system and makes judgment calls about where independence helps and where coordination is necessary. In engineering, we've started naming it: platform engineering, technical leadership, architecture. In other functions, the role usually exists informally or doesn't exist at all. ### In Engineering **The tradeoff:** Shared infrastructure (consistency, less duplication) vs team independence (speed, autonomy). **What the ATC does:** Decides which services share a database and which own their data. Chooses where to centralize authentication and where to let teams deploy independently. Designs interfaces so teams don't wait on each other. **When the ATC is missing:** "Simple" changes cascade across 6 systems. Engineers live in alignment meetings. New hires take months to become productive because nobody can explain how the pieces fit together. ### In Sales **The tradeoff:** Standardized playbook (consistency, training efficiency) vs territory-specific approaches (relevance, speed). **What the ATC does:** Decides which parts of the sales motion are standardized (pricing, contracts, demo flow) and which are customized per territory or segment. Ensures AEs aren't competing on the same accounts. Designs handoffs between BDR → AE → SE → implementation so deals don't stall. **When the ATC is missing:** Territory conflicts. Competing discounts on the same prospect. Deals stalling in handoffs because nobody designed the interface between roles. Implementation surprises because sales promised something engineering can't deliver. ### In Marketing **The tradeoff:** Unified brand (consistency, recognition) vs regional/campaign autonomy (speed, relevance). **What the ATC does:** Decides which brand elements are centralized (identity, messaging framework, compliance) and which campaigns run independently (regional promotions, channel-specific content). Designs systems so marketing teams can launch without waiting on engineering. **When the ATC is missing:** Campaigns wait 12 weeks for a landing page because marketing can't configure without engineering. Brand inconsistency across regions. Competing campaigns cannibalizing each other's audience. ### In Product **The tradeoff:** Shared roadmap (alignment, cross-product coherence) vs independent shipping (speed, team ownership). **What the ATC does:** Decides which product features share infrastructure and which ship independently. Makes dependencies explicit during planning instead of discovering them mid-cycle. Ensures Product A's roadmap doesn't silently depend on Product B's timeline. **When the ATC is missing:** Planning cycles become negotiation theater. Product teams block each other without knowing it. The roadmap looks clean but execution reveals invisible dependencies everywhere. ### In Operations / M&A **The tradeoff:** Unified operating model (efficiency, standards) vs business unit autonomy (speed, context-specific decisions). **What the ATC does:** Decides which processes are standardized across the organization (compliance, reporting, HR) and which business units run independently. During acquisitions, determines what integrates immediately (auth, SSO) and what stays independent (product features, team structure). **When the ATC is missing:** Acquisitions drag because nobody decides what should merge and what should stay separate. Bain's surveys of M&A practitioners who've lived through a failed deal found **83% pointed to integration as a primary cause**[^4]. Twenty years ago, Bain put the overall failure rate near 70%. The companies that improved those odds got better at the integration work: deciding what to merge, what to leave independent, and how fast. The ATC is often still the missing role. ## The ATC at Every Scale The role doesn't change with size. Who holds it, and how many of them you need, does. **Startup.** The founder is the ATC, implicitly. They hold the whole system in their head because they built most of it. Boundaries are informal because everyone can see everyone. This works until it doesn't, usually around the point where no single person can still explain how all the pieces fit. **Mid-market.** The implicit role has to become explicit. This is where you name it: a first platform team, a principal engineer, a head of revenue operations. The mistake here is waiting too long, letting coordination overhead compound while insisting the founder can still hold it all. **Enterprise.** One ATC can't see everything anymore, so the role federates. You get ATCs who each own a domain and, above them, an ATC whose whole job is designing the boundaries between the boundaries. The risk flips: too many ATCs, each optimizing their own patch, and no one owning the seams between them. The blast radius grows. The mechanics change. The judgment call stays exactly the same: where does independence help, and where is coordination worth its cost. ## Why "Decouple Everything" Is Wrong **Every pattern for increasing independence creates new problems.** Event-driven architecture? Duplicate data. Dropped events. Microservices? 47 services, nobody knows what talks to what. Regional marketing autonomy? Brand inconsistency. Territory-specific sales? Pricing conflicts and account overlap. Independent P&Ls? Duplicated infrastructure, missed cross-sell. **The ATC doesn't pick "independent" or "coordinated." They pick the right tradeoff for each boundary.** Ruth Malan put it sharply: **"If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins."**[^5] That applies to every system, not just software. Your org chart, reporting structure, and approval chains determine how fast things move. The ATC designs those boundaries intentionally. Spotify learned the same thing the hard way. A 2023 peer-reviewed study found **"surprisingly many" technical dependencies** constraining squad autonomy, even after the company tried to decouple by design, across roughly **500 squads**[^6]. Spotify Engineering has described that same fleet as **10,000+ components**[^7]. Autonomy was the goal. Coordination overhead was the reality. The answer wasn't more independence. It was better boundary design. ## What the ATC Actually Does Across every function, the ATC does five things: **1. Sees the whole system.** They carry context from every team. They know the CMO's market window, the CSO's integration timeline, the engineer's deployment constraint, and the CEO's acquisition strategy, all at the same time. No single team has this view. **2. Designs boundaries.** They decide where teams operate independently and where they coordinate. These aren't technical decisions. They're organizational decisions with technical, commercial, and strategic implications. The best ones do it proactively: they build the train track ahead of the train, laying down the boundary before the collision, so teams never hit the blocker in the first place. **3. Makes tradeoffs explicit.** Instead of letting dependencies form accidentally, the ATC names them. "This requires coordination; here's the cost. This can be independent; here's the risk." Every team benefits from that clarity. **4. Prevents collisions.** When two teams are about to build conflicting things, the ATC spots it early. When a sales commitment conflicts with an engineering constraint, the ATC surfaces it before it becomes a crisis. **5. Does the actual work.** This is the one most organizations get wrong. The ATC isn't a coordinator. They're a practitioner who coordinates because they're in the work, not above it. ## Why the ATC Can't Be a Contractor (Or a Pure Coordinator) Here's where organizations make the most expensive mistake: they hire a consultant to "design the architecture," bring in a contractor to "set up the platform," or create a dedicated "coordination role" whose sole job is connecting teams. All three fail for the same reason: **the ATC's judgment comes from doing the work, not observing it.** A contractor designs boundaries and leaves. They don't live with the consequences when the event bus starts dropping messages at 2 AM. They don't feel the pain when the "clean" API design creates three extra handoffs for every feature. They optimize for elegance because they won't be around for maintenance. A pure coordinator (program manager, scrum master, architecture review board) sits in meetings and draws diagrams. Their understanding of the system is secondhand. They know what teams told them in status updates, not what actually happens when code ships. Their boundary design becomes theoretical because it's disconnected from ground truth. **The ATC has to be someone doing the work.** The VP Engineering who still reviews database migrations and writes infrastructure code. The VP Sales who still closes deals, not just reviews pipeline. The CMO who still runs campaigns, not just approves them. The CPO who still talks to customers, not just reads NPS dashboards. Why? Because the work is where you learn which boundaries are real and which are imaginary. The engineer who ships code knows the "simple API call" actually requires three teams to coordinate. The salesperson who closes deals knows the "standard integration" actually takes six months. The marketer knows "self-serve" actually requires an engineering ticket. **That ground truth is what makes boundary design relevant.** Without it you get architecture astronauts, designing beautiful systems they've never operated, and coordination theater, meetings about alignment that never produce clarity. The ATC feels the pain personally when a boundary that made sense six months ago starts slowing teams down, so they fix it before it calcifies. Contractors optimize for the engagement; employees living inside the system optimize for the outcome. That's why the role can't be outsourced. Werner Vogels described Amazon's version: the transition **"from a two-tier monolith to a fully distributed, decentralized, services platform"**[^8] wasn't just an architecture decision. It was an organizational design decision made by people who were building the system, not advising on it. The Bezos API Mandate of 2002 (six rules, the last being **"Anyone who doesn't do this will be fired"**[^9]) forced every team to communicate through designed interfaces. The people who designed those interfaces were the same people who operated the services. That's what made it work. ## The ATC's Failure Mode There's a way to get this exactly wrong, and it's the mirror image of having no ATC at all. The ATC who sees everything can start deciding everything. Every boundary runs through them. Every cross-team question waits for their answer. They become the single point of failure they were supposed to design away. Now you don't have accidental coordination overhead; you have deliberate coordination overhead, routed through one person's calendar. The org can't move faster than they can context-switch. You feel this most clearly when they're gone. Friday. The ATC is on vacation, or in back-to-backs, or out sick. Slack fills with the same three messages: "who knows how X works?", "who can approve this?", "who remembers why we did it that way?" Work doesn't stop. Context does. You didn't lose a coder for a week. You lost the map. That's not a staffing gap. That's a weak system. A weak system depends on a hero who holds it all in their head. A strong system uses that hero to build boundaries other people can operate without them. The best ATCs measure themselves by how many decisions they no longer need to be in. They develop other ATCs. They write the interface down so it outlives the conversation. They design themselves out of the critical path on purpose. If your ATC is indispensable, they haven't finished the job. The goal isn't to be the person who sees the whole system. It's to build a system that doesn't need any one person to see all of it. ## Integration as Competitive Moat (For Sales) Sales feels boundary design as a quote that changes. Without an ATC: "We'll assess your environment, build custom connectors, and scope it with professional services. Typically four to six months." With one: "Most customers are live in two to four weeks. You can start during the trial." The difference isn't engineering talent. It's whether someone designed the interfaces so integration is composable by default. ## Role-Specific Cheat Sheets ### For Executives (CEO, COO, CFO) | Question | Why It Matters | |----------|----------------| | "Do we have someone who sees across all functions and designs boundaries?" | Tests whether the ATC role exists | | "Can we add products without existing products changing?" | Tests boundary design quality | | "What percentage of time is coordination vs actual work?" | Quantifies the cost of missing an ATC | | "If we acquire a company, how long until integration unlocks value?" | Tests M&A readiness | | "Where are teams waiting on each other, and has anyone designed that away?" | Surfaces accidental dependencies | ### For Engineering Leaders (CTO, VP Eng, Directors) | Decision | Centralize When | Distribute When | Watch Out For | |----------|----------------|-----------------|---------------| | **Data** | Single source of truth matters (auth, billing) | Teams need independent schemas (features) | Distributed data + event bus = consistency risk | | **Communication** | Low latency required; simple request/response | Teams need independence; fire-and-forget | Event-driven creates invisible side effects | | **Deployment** | Tightly integrated components (shared release) | Independent features (separate pipelines) | Version drift between independently deployed services | | **APIs** | Internal APIs with few consumers | External APIs or many consumers (version them) | Versioning adds complexity; don't version prematurely | | **Testing** | Shared infrastructure (integration tests) | Independent services (contract tests) | Contract tests only work if contracts are enforced | ### For Sales (CSO, VP Sales, AE, BDR) | Discovery Question | What You Learn | |-------------------|----------------| | "How long do integrations take with your current vendor?" | Current pain; sets up contrast | | "When your vendor ships updates, do your integrations break?" | Reveals poor boundary design | | "How many teams coordinate for a typical new feature?" | Quantifies their coordination overhead | | "Have you acquired companies? How long was tech integration?" | M&A pain is expensive and memorable | ### For Product and Marketing (CPO, CMO, Product Managers) | Scenario | Without ATC | With ATC | |----------|------------|----------| | New campaign feature | 8-12 weeks (requires engineering) | 1-3 days (self-serve, pre-designed) | | A/B test variant | 4-6 weeks per variant | Hours (config-driven) | | Add product to platform | 12-18 months (integration trauma) | 4-8 weeks (designed for composability) | | Respond to competitor | Months (roadmap locked by dependencies) | Weeks (independent shipping) | ## Connecting to the Series The ATC role touches every framework in this series. Without it, teams can't choose [Fast/Good/Well](https://www.linkedin.com/pulse/why-great-products-built-tradeoffs-backlog-christian-battaglia-lwy3e) independently, because a change in one place cascades into five others. The [unknown unknowns](https://www.linkedin.com/pulse/real-constraint-product-development-known-unknown-christian-battaglia-i16ee) stay hidden because nobody sees the whole system well enough to spot them. Accidental boundaries are a form of [false certainty](https://www.linkedin.com/pulse/cost-certainty-why-best-teams-avoid-christian-battaglia-oze1e): instead of deciding where coordination is worth its cost, the org lets the boundary form on its own and calls the result inevitable. Low-trust environments manufacture coordination through defensive behavior; every approval chain that exists for [CYA](https://www.linkedin.com/pulse/trust-tax-what-low-trust-environments-actually-cost-battaglia-ruaje) is a boundary someone should have designed differently. And [async management](https://www.linkedin.com/pulse/managing-product-engineering-output-high-autonomy-christian-battaglia-aripe) only works if teams can operate independently; otherwise you're just moving the meetings to Slack. ## How to Become the ATC You don't need the title. You need the view and the willingness to use it. Start where you already work. Notice the boundary that keeps generating friction: the handoff that always stalls, the "simple" change that always touches three teams, the approval everyone waits on. That friction is a boundary nobody designed. Name it out loud, name the tradeoff, and propose where it should sit. That's the whole job in miniature. Then widen the view. Sit in the planning meeting for the team next to yours. Learn what constraint they're actually solving for. The ATC's power comes from carrying more context than anyone else in the room, and context is just accumulated attention. Stay in the work. The moment you stop shipping, closing, or building, your boundary judgment starts drifting toward theory. Keep one foot in the thing you're designing boundaries around. And design yourself out. If you become the person every decision routes through, you've recreated the problem. The test is simple: can the team still operate next Friday if you're out? If the answer is a Slack scramble, the view still lives in one head. The goal is boundaries other people can operate without you. ## The Air Traffic Controller's Paradox The best ATCs are invisible. Planes land on time. No collisions. No drama. Nobody thanks them because the system just works. The best organizational ATC looks the same. Teams ship independently. Integrations are smooth. Acquisitions plug in. Sales quotes timelines with confidence. Marketing launches without waiting on engineering. Nobody notices the boundary design because it feels natural. **That's the paradox: the better the ATC does their job, the less visible it is.** Every function has the same "centralize vs distribute" tradeoff. Most organizations let it resolve accidentally: whoever pushes hardest wins, dependencies form without design, coordination overhead compounds until everyone's drowning in meetings. The organizations that scale? They staff the role. Not always with a title. Sometimes it's a VP Engineering who sees across product lines. Sometimes it's a COO who designs operating models. Sometimes it's a sales leader who designs territory boundaries and handoff protocols. But someone is doing it. Deliberately. With the whole system in their head. There's the remaining problem, and it's the one the role can't solve by itself. If the whole-system view lives only in that person's head, the org is one vacation away from flying blind. Designing yourself out only works if the view can live somewhere other than a person. **The constraint isn't talent, capital, or technology.** **It's whether someone sees the whole system clearly enough to design the boundaries that let everyone else move independently.** Every team needs an air traffic controller. Most just don't know it yet. --- ## References [^1]: DORA (DevOps Research and Assessment), "Capabilities: Loosely Coupled Teams." Teams that can test, deploy, and change independently require little communication to get work done. Randy Shoup's Google Datastore quote is on the same page. Forsgren, Humble, and Kim, *Accelerate* (2018), established loosely coupled architecture as a primary predictor of delivery performance. [https://dora.dev/capabilities/loosely-coupled-teams/](https://dora.dev/capabilities/loosely-coupled-teams/) [^2]: Atlassian, "State of Developer Experience Report 2025." Survey of 3,500 developers and managers across six countries (Wakefield Research). 68% save 10+ hours per week with AI tools; 50% lose 10+ hours per week to organizational inefficiencies; 90% lose 6+ hours. [https://www.atlassian.com/blog/developer/developer-experience-report-2025](https://www.atlassian.com/blog/developer/developer-experience-report-2025) [^3]: Cortex, "The 2024 State of Developer Productivity." Survey of 50 engineering leaders at companies with 500+ employees; 58% report 5+ hours per developer per week lost to unproductive work; "gathering project context" and "waiting on approvals" tied at 26% each. [https://cortex.io/report/the-2024-state-of-developer-productivity](https://cortex.io/report/the-2024-state-of-developer-productivity) [^4]: Bain & Company, "The 10 Steps to Successful M&A Integration." Among M&A practitioners who experienced a failed deal, 83% pointed to integration as a primary cause. [https://www.bain.com/insights/10-steps-to-successful-ma-integration/](https://www.bain.com/insights/10-steps-to-successful-ma-integration/) Harvard Business Review, "A Better Approach to Mergers and Acquisitions" (May-June 2024), recounting Bain's older finding that roughly 70% of mergers failed, and noting that those odds later inverted as frequent acquirers got better at integration. [https://hbr.org/2024/05/a-better-approach-to-mergers-and-acquisitions](https://hbr.org/2024/05/a-better-approach-to-mergers-and-acquisitions) [^5]: Ruth Malan, "Conway's Law" (2008). "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins." [https://ruthmalan.com/traceinthesand/conwayslaw.htm](https://ruthmalan.com/traceinthesand/conwayslaw.htm) [^6]: Darja Šmite, Nils Brede Moe, Marcin Floryan, Javier Gonzalez-Huerta, Michael Dorner, and Aivars Sablis, "Decentralized decision-making and scaled autonomy at Spotify," *Journal of Systems and Software* 200 (2023). Peer-reviewed. ~500 squads as of spring 2020; "surprisingly many" technical dependencies constraining autonomy despite microservice decoupling. [https://doi.org/10.1016/j.jss.2023.111649](https://doi.org/10.1016/j.jss.2023.111649) [^7]: Spotify Engineering, "Managing Software at Scale" (October 2023). Niklas Gustavsson describing 500+ squads managing 10,000+ software components in production. [https://engineering.atspotify.com/2023/10/managing-software-at-scale-googles-kelsey-hightower-talks-with-spotifys-niklas-gustavsson-about-fleet-management](https://engineering.atspotify.com/2023/10/managing-software-at-scale-googles-kelsey-hightower-talks-with-spotifys-niklas-gustavsson-about-fleet-management) [^8]: Werner Vogels (CTO, Amazon), "A Second Conversation with Werner Vogels," *Communications of the ACM* (2019). Describes Amazon's transition from a two-tier monolith to a fully distributed, decentralized services platform. [https://cacm.acm.org/practice/a-second-conversation-with-werner-vogels/](https://cacm.acm.org/practice/a-second-conversation-with-werner-vogels/) [^9]: Steve Yegge, internal Google memo (2011), recounting Jeff Bezos's 2002 API Mandate, including "Anyone who doesn't do this will be fired." Preserved at [https://gist.github.com/chitchcock/1281611](https://gist.github.com/chitchcock/1281611). Secondary write-up: [https://konghq.com/blog/enterprise/api-mandate](https://konghq.com/blog/enterprise/api-mandate)