# Architecture Is a Conversation Across Time  Daniel Antos --- > "Captain, the weather radar has helped us a lot." *— Flight engineer, Korean Air 801, 1997* *Source: Malcolm Gladwell, Outliers* Note: In 1997, Korean Air Flight 801 is approaching Guam. And the flight engineer says this. And it's a strange line to hear in a cockpit. Not because it sounds dramatic — but because it doesn't. It sounds calm, technical, almost routine. And yet it clearly points to something the crew is seeing. For a little while longer, there was still a chance to break off the approach and try again. But the captain never hears the warning. --- Software is lower-stakes. But architecture fails in a very similar way. Note: - Staff engineer at a startup — focused on collaboration, decisions together, buy-in - Joined Dropbox, inherited systems I didn't build, people who built them gone - Realized the conversation doesn't end when the team moves on - That's what this talk is about --- <!-- .slide: data-background-color="#FDE8E8" --> When good intentions go south Note: - "I believe we all have good intentions. Even a flawed approach is better than inactivity." - "These are my confessions" --- The discussion started too late. Note: - Hand raise: someone was supposed to do a small fix, put up a giant refactor - Keep hand up if you've been that person ---  Note: - My confession: was supposed to add a database model, one day of work - Felt we had issues, fixed one thing then another - 100+ comments, paragraphs going back and forth - In the beginning I thought this is great, people are talking - But everyone dug into their trenches, sense of urgency, either block or push through - And you should have seen the product manager face when the one day task turned into 3 weeks battle and then a follow-up refactor. --- Someone walked into the room already in love with the answer. Note: - Hand raise: meeting supposed to be about a decision, felt like a sales pitch - Keep hand up if you were doing the pitch ---  Note: - My confession: Kafka. Attended too many conferences about it - 10-person startup, three engineers. You don't want to support Kafka at that scale - My sales pitch was apparently quite good, we went with it - Problem: I was very unclear about the problem space, constraints, context - Whole conversation got pulled down to the solution I wanted --- All decisions made by one person. Note: - Ivory tower: great way to lose driven, motivated, and creative people - Story: senior engineers discussing two solutions for 30 minutes - Junior engineer faintly raises hand, asks about integration with another system - Nobody had thought about it. 30 minutes wasted. Happy it wasn't 2 months --- <!-- .slide: data-background-color="#E8F5F2" --> Making disagreement useful Note: - "So what actually helped?" - In each of those situations, people wanted to do good work - The question is how to make it easier --- Turns disagreement into evidence.  Note: - Proof of concept - "Didn't you just show us a PR you said not to do?" — big difference - PoC is going to be discarded, no rush, no emotion, no urgency - Feels like an invitation, not something that will go to production - Makes abstract disagreement concrete --- Diagrams fire different parts of the brain. Note: - I'm not a designer, diagrams are as close to pencil as I get - Somewhere between free-flow text (abstract) and code (concrete) - Often the first verification of ideas - Much easier to discuss over a diagram than same text read differently - Callback to Kafka: friend drew 4 options as diagrams, deciding took 10 minutes after that ---  --- An invitation, not a decree. Note: - Decision records: archive of important decisions - Problem, broader context, options, decision - Writing is thinking — write it, go for a walk, come back, realize it's bad before sharing - Starts as public draft, everyone sees it early - Feels like invitation: "I want to collaborate with my team" - Callback to giant PR: this is the opposite of that ---  --- <!-- .slide: data-background-color="#E0EDFF" --> What's missing? Note: - "These were my thoughts before joining Dropbox. Now I've realized something is missing." - Pause. Let them sit with the question. --- Why? Note: - Decision records have a "context" section - Most people, including me, don't fill it up properly - We write the problem, options, decision - The real why — assumptions, constraints in our heads — gets skipped --- Why? Assumptions? Note: - Story: wanted to expose existing tasks through API - Found that someone tried this years ago, had a design spec, trade-offs, decision - Could verify the trade-offs, see the code - But had a different idea and didn't know why they chose what they did - Can reconstruct problem, decision, trade-offs — can't recreate context - Made me realize my own decision records are missing obvious assumptions ---  Note: - Tasks story: new product needed task functionality, team moved fast - Pulled in existing system from another product, wired it together - Open questions left for later - Original assumption hardened into the foundation - Built on top of what was supposed to be a shortcut - Context was something the team was living in — obvious to them, invisible to me --- And it's getting harder. Note: - We know assumptions matter, we know the why gets lost - But something has changed recently --- A polished doc is evidence of **polish**. It is not yet evidence of **intention**. Note: - We use AI, I use AI, it's good at writing neatly polished documents - When I see a well-structured design doc now, I don't know - Were the assumptions between the lines made on purpose? - Were they the author's intention or inferred by AI? - Polish used to signal deep thinking — that signal is gone --- Assumptions can't be inferred from between the lines. Note: - Context was already hard to capture when people wrote things themselves - Now writing looks thoughtful by default - Assumptions, constraints, things obvious to the team — never in the polished text - They were between the lines - Now the lines are written by something that doesn't know what the assumptions were --- I don't have a solution for this. Note: - Not pretending I've figured this out - But I pay a lot more attention now - When writing or reading: what assumptions are being made? - Try to write down not just what I chose, but what I assumed, what I didn't know - Because I've been on the other end, wishing someone left me a note --- How do *you* make the why, the assumptions, the intention more explicit? Thank you. Note: - Hope we can carry this on after the talk