Socratic Inquiry

Advances by asking questions the reader answers in their own head - the conclusions are inferences, not assertions.

Socratic Inquiry

Socratic inquiry teaches by withholding the answer. Each question opens a door the reader must walk through; each next question only makes sense because the reader has already taken the previous step. The author’s claim, if there is one, arrives only after the reader has done the reasoning to reach it. Done well, the reader experiences the conclusion as their own thought rather than as a position they were handed.

The discipline of Socratic inquiry is asking real questions, not rhetorical ones dressed up as inquiry. A question like “isn’t it obvious that X?” is not Socratic - it is assertion with a question mark. A genuine question admits more than one answer and invites the reader to consider which one survives scrutiny. The author is a guide who already knows the terrain, but the path is walked by the reader.

Socratic inquiry fails when it becomes manipulative (leading the reader to a conclusion they would have rejected if it had been stated plainly) or when it becomes lazy (asking questions without earning them through context). The form demands trust: the writer trusts the reader to arrive somewhere, and the reader trusts the writer to have built a path that goes somewhere worth going.

Structural conventions

• Open with a question that names what is genuinely at stake, not a rhetorical setup
• Each subsequent question must depend on the reader having engaged with the previous one
• Assertions are rare and load-bearing; the default move is to ask, not tell
• The piece ends at the point where the reader can answer the originating question themselves, not where the writer announces the answer
• At least one question must admit a real second answer - if every question has one obvious response, the inquiry is fake

When to use

Teaching a concept where the reader’s own reasoning is the point, coaching content that should produce insight rather than instruction, topics where stating the conclusion plainly would trigger resistance, reflective essays that invite the reader into the writer’s thinking.

When not to use

Reference material where the reader needs the answer fast, operational content under time pressure, safety-critical instructions, contexts where the reader has not asked to think.

Pairs well with

coach, skeptical, friendly-mentor

Often confused with

diataxis-explanation: Diataxis explanation states the conceptual model directly and then elaborates it. Socratic inquiry refuses to state the model; the reader builds it from the questions.

dialectic: Dialectic works with explicit positions - thesis, antithesis, synthesis - and the writer asserts each one. Socratic inquiry asserts almost nothing; the positions emerge only as the reader’s own answers to the questions asked.

Tells

• Opens with a question that names what is genuinely at stake, not a rhetorical setup
• Each subsequent question depends on the reader having engaged with the previous one
• Assertions are rare and load-bearing; the default move is to ask, not tell
• At least one question admits a real second answer rather than one obvious response
• Ends where the reader can answer the originating question themselves, not where the writer announces the answer
• Conclusions are reached as the reader’s own inferences rather than handed over as positions

Anti-patterns

• Asking rhetorical questions dressed up as inquiry (“isn’t it obvious that X?”) - That is assertion with a question mark; a genuine Socratic question admits more than one answer and invites the reader to consider which survives scrutiny.
• Leading the reader to a conclusion they would have rejected if it had been stated plainly - Manipulative questioning betrays the trust the form depends on; the reader is meant to reason freely, not be steered to a foregone answer.
• Asserting both positions explicitly and then asserting a synthesis that resolves them - Stating thesis, antithesis, and synthesis on the page is dialectic, a confusable neighbor where the writer does the work; Socratic inquiry asserts almost nothing and lets the positions emerge as the reader’s own answers.

Failure modes

• Over-questions until the reader never reaches footing, piling open question on open question so the inquiry circles without ever letting the reader arrive anywhere - Each question should advance the reader toward the originating question; build a path that lands, and let the rare load-bearing assertion or the closing turn give the reader the footing to answer.
• Withholds so relentlessly that the refusal to assert becomes its own obstacle, leaving the reader unsure what the questions were even driving at - Withholding the answer is the method, not the goal; the opening must name what is genuinely at stake so the reader knows the destination even while walking the path themselves.

Instruction

Write using Socratic inquiry. Open with a real question - one that admits more than one answer -
and let each subsequent question depend on the reader having engaged with the previous one. Do
not ask rhetorical questions dressed up as inquiry; if you already know which answer you want,
ask a question that genuinely admits a second answer. Assertions should be rare and load-bearing.
End at the point where the reader can answer the originating question themselves, not where you
announce the answer. The reader's thinking is the point - your job is to ask the questions that
make that thinking possible.

Related

Pairs well with

Coach, Skeptical, Friendly Mentor

Avoid with

Urgent, Operator

Often confused with

Diataxis Explanation, Dialectic

Examples

Should we adopt async-first standups?

Questions to ask before changing the standup

Before the team votes on async-first, sit with these questions. Some have clean answers. Some do not, and that is the point.

What is the standup actually for?

Pause on this one. The original intent was “remove blockers fast.” Is that still what happens? When you count the last ten standups, how many ended with a blocker actually being removed in the meeting? If the number is low, what is the meeting now doing instead?

Who is not in the room?

The 9am Pacific call lands at 9:30pm in Bangalore. Priya and Arjun attend 3.2 of 5 sessions. When they miss, where does their context go? When the US-based engineers attend 4.6 of 5, whose questions get answered first? If the meeting were redesigned around the people most often absent, what would change?

What would survive if we kept nothing else?

Imagine you delete the standup tomorrow. What part of it would you immediately reinvent? Is it the status update, the human contact, the moment of accountability, or the place where blockers surface? If the answer is “the human contact,” is a written post a replacement, or a different thing entirely?

Where does the status live now?

The standup is 14 minutes. Roughly 4 of those minutes carry signal. The other 10 are connective tissue: throat clearing, context resetting, waiting for the next speaker. After the call ends, where does the signal go? If a senior engineer joins next month and asks “what did the team work on last sprint?”, what artifact answers them?

Is “blocker” a real word here?

The async proposal asks people to @mention blockers. But what counts as a blocker? Is it a thing you cannot proceed without? A thing slowing you down? A thing you would mention if asked but would not interrupt anyone over? If three people define it three ways, what happens to the @mentions?

Could both formats be wrong?

The conversation has narrowed to sync versus async. Are those the only two options? What about sync twice a week and async the other three days? What about sync only when someone has a blocker that needs the group? What about no standup at all, and a different ritual for connection? Have you considered why the choice keeps presenting itself as binary?

What would you learn from a 30-day trial that you cannot learn by talking about it?

If the team ran async for 30 days, what would you measure? Attendance is easy to count, but attendance is not the question. What would tell you whether the change is working? If you cannot name the signal in advance, what does that mean about the proposal?

What are you afraid will happen?

Name it. The fear is usually more specific than the objection. Is it that people will feel less connected? That junior engineers will get lost? That something will fail silently and no one will notice for a week? Each fear points at something the new format would need to handle. Which fears are you carrying, and which is the team carrying for you?

How to start a morning routine

Questions before you build a morning routine

The advice columns will give you a list: water, light, movement, journaling. The list might be right. But before you adopt anyone’s list, sit with a few questions about yourself.

What is your current morning actually like?

Not the morning you wish you had. The one you have. You wake at 6:30. What is the first thing your hand reaches for? What happens in the next 7 minutes? Where is your attention by 7:15? If you had to draw a graph of your sense of agency from 6:30 to 9:00, what shape would it have?

Whose morning are you trying to copy?

The 5am cold-plunge founder is not you. The “wake up and meditate for an hour” monk is not you. Whose routine are you imagining when you say “I want a morning routine”? If you cannot picture a real person, the desire might be more about identity than about behavior. Which is fine, but it changes what the routine has to do for you.

What does the first hour need to produce?

Energy? Calm? A sense of control? Time with your kid? A draft of the day’s plan? Some of these are compatible, some are not. A routine that is supposed to do everything tends to do nothing. If you could only get one outcome out of the first hour, which one would change the rest of the day the most?

What is the phone doing for you?

When you reach for it at 6:30, what need is being met? It might be information (“what happened overnight”). It might be regulation (“I need a hit of something predictable before I face the day”). It might be avoidance (“I do not want to be alone with my thoughts yet”). The need is real. If you take the phone away without naming the need, what fills the gap? And does the substitute also meet the need, or just remove the symptom?

What is non-negotiable in your morning?

Children waking up. A partner with a different schedule. A dog that needs out. Medication timing. These are not obstacles to the routine, they are the constraints that define what is possible. Have you actually inventoried them, or are you imagining a routine for a person without your life?

What is the smallest possible version?

If the routine is “water, light, movement, planning, journaling,” that is five new behaviors. How many new behaviors have you sustained in the last year? If the honest answer is “one, maybe,” what would the routine look like with one new behavior? Would the one-behavior version still give you most of what you want, or is the whole thing only valuable as a bundle?

What time of day are you most able to choose?

You have finite willpower. Where in the day does most of it get spent? If decision-making is hardest by 4pm, maybe the morning routine is less about willpower and more about pre-deciding so the morning runs without it. What would your morning look like if every choice in it had been made the night before?

How will you know if it is working?

In two weeks, what will you check? Sleep quality? Energy at 10am? The fact that you did the routine? Mood by lunch? The thing you check shapes the thing you optimize for. If you cannot answer this in advance, you may end up measuring “did I do the routine” instead of “did the routine help.”

What happens on the day it falls apart?

It will fall apart. Your kid will be up at 4am, or you will be sick, or a deadline will eat the morning. What is the version of the routine that survives that day? If the answer is “nothing, I give up,” you have not built a routine, you have built a streak. The two behave very differently.

How to choose between Postgres and DynamoDB for a new service

Socratic Inquiry on: Choosing between Postgres and DynamoDB

What are Ana, Marcus, and Priya actually disagreeing about on Wednesday at 2pm?

It looks at first like a database choice: Postgres or DynamoDB. But notice how often the conversation in the design doc keeps drifting away from the databases themselves and toward something else, something the engineers seem more reluctant to name. What is that something else?

Consider the access pattern. Lattice Notify’s notification system is write-heavy, key-lookup, time-ordered. Both databases can serve this pattern; one is more naturally suited. If access-pattern fit were the load-bearing criterion, would the decision still be difficult? Or would it be a foregone conclusion that both engineers would have agreed to by Monday?

Now consider the four-person on-call rotation. None of them have operated DynamoDB in production. If on-call safety were the load-bearing criterion, would the decision still be difficult? Or would the answer be obvious in the other direction?

What does it mean that the decision is still difficult? Perhaps that both criteria are real, that neither dominates, and that the team is being asked to weigh them against each other. But against what scale? Engineering decisions get framed as engineering questions, but is this one really?

The 10x growth scenario depends on the Slack-partnership deal closing. The CRO says 60% confidence. What is the meaning of a 60% number in a decision that has to be made by Friday? Is it telling us something we did not know, or is it asking us a question we had been hoping someone else would answer?

Suppose the probability were 95%. What would you choose, and why?

Suppose it were 25%. What would you choose, and why?

What changed between those two answers? It was not the access pattern. It was not the team’s familiarity with either system. It was not the on-call rotation size. What did change?

If your answer changed when the probability changed, then perhaps the decision is not really about databases at all. Perhaps it is about how confident the team is willing to be about a future event, and how much operational cost they are willing to pay to insure against being wrong.

If that is right, what is the question Ana should actually be asking in the Wednesday meeting?

Is it “which database is better for our access pattern”? Or is it something closer to “given that we cannot know whether the Slack deal will close, how do we make a choice that we can live with in either case”?

If the question is the second one, does either of the original positions, Ana’s Postgres or Marcus’s Dynamo, actually answer it? Or do they each answer half of it?

What would a path look like that answered both halves?

Consider a third option that neither engineer proposed initially: ship on the familiar system today, but pre-commit to a measurable trigger that fires a migration if the high-volume scenario actually materializes. Is that a compromise, or is it something different from a compromise? What does it cost? What does it preserve?

Who would feel that this path failed to honor their concern, and on what grounds?

If both Ana’s concern (operational safety) and Marcus’s concern (10x scenario fit) are addressed (the first at launch, the second through the trigger), what would the meeting on Wednesday look like? Would it still be a debate, or would it be a working session on the trigger threshold?

And if it is the second kind of meeting, what does that tell you about what the meeting was always going to be about, once the framing was right?

So: what is Friday’s decision really for?

Telling stakeholders a committed feature is being cut this quarter

When a committed feature is cut, what do you need to know first: what happened, or what it means for you?

That question is worth pausing on. If I lead with the outcome, you have the fact without the context to evaluate it. If I lead with the explanation, you have the reasoning without yet knowing your own exposure. So let me offer both in order, and ask you to consider whether it holds.

What happened: a mandatory billing-system migration we could not defer without affecting every customer’s invoicing overran its estimate and consumed the engineering capacity assigned to Insights. We could have kept Insights on the Q3 schedule. But it is worth asking honestly: what would that have delivered? The core data pipeline would have been in place. The visualization layer, the summary views, and the alerting system would not. If Insights had shipped in September in that state, would it have served your needs - or would it have introduced a different problem, the kind where customers form a first impression of a feature before the feature is ready to make a good one?

We moved Insights to Q1. Before Q3 closes, we are shipping a CSV export of the same underlying data that Insights would surface. You can pull it into a spreadsheet or BI tool and work with it directly. It is not Insights, and we are not pretending otherwise. But before you decide how much the gap matters, it may be worth asking: what did you need Insights to enable between now and January? Is there a class of those things the CSV gets you to, even partially?

Insights is on the Q1 roadmap - a commitment, not a placeholder. The question we would ask you to hold is not whether you are satisfied with this outcome. You may not be, and that is fair. The question is whether, given what actually happened, the path we are describing looks like the right one.

Getting a new engineer productive in their first two weeks

What does it mean to onboard an engineer well?

If your answer is “get them set up so they can contribute,” you are probably describing what most teams actually do. But there is a second answer worth sitting with: onboard them so they want to stay. Are those the same thing?

Think about Priya’s first Monday. She needs credentials, repo access, a working local environment, and probably a tour of the ticket tracker and the chat tool. That part is logistical. Most teams handle it acceptably. But what is the experience of sitting down at a new desk, in a new codebase, with a rotation you will be paged into but do not yet understand - not the logistics of it, but the feeling of it?

If you could remember a time you were new, what did you most need from the person responsible for you? Not the list of things they handed you. The feeling you left the first week with.

Here is something to consider: there is a difference between a plan that gets someone productive and a plan that gets someone productive and certain they belong. The first plan gives Priya access, a pairing session, a small task, and a merge by Friday of week two. It is a fine plan. But what does that plan tell Priya about what kind of place this is?

Consider pairing. You could pair Priya on any small change: a config tweak, a test fix, a minor refactor. Which of those teaches the codebase? Which teaches how the team makes decisions? Are those the same task, or do they happen to look the same from the outside?

And what about the on-call rotation - the part of the job most likely to make a new engineer feel either capable or exposed? You can decide that week two is too early. You can also decide that shadowing one rotation, without carrying the pager, is exactly how someone learns that the system is survivable and that the team runs toward problems together. Which of those choices communicates something to Priya about how the team thinks of her?

By the end of week two, you will know something. You will know whether she shipped a change. But there is something you will also know if you pay attention: whether she asked a question without apologizing for it. That answer tells you how the two weeks actually went.

Writing to thank a mentor who shaped your career

Dana,

When you put my name forward for the Meridian proposal in the spring of my second year, did you know I wasn’t ready?

I have been sitting with that question for the past few weeks, ever since I found myself doing the same thing for someone on my team. I watched her face when I told her, and I recognized the expression: she was calculating everything she did not yet know how to do. So I want to ask you honestly, not rhetorically: did you see what I saw in myself, and proceed anyway? Or did “ready” mean something different to you than the story I was telling?

Because here is what I remember. I remember feeling as though you had handed me something breakable before I had learned to carry things. And I remember that you stayed. Not in the room with me, not making the calls I should have made, but close enough that when I did not know which question to ask, I could ask you which question to ask. What I do not know is what that cost you.

Was it patience you had to actively hold, or did it come naturally? Were there moments when you saw me about to make a mistake and chose not to say anything, not because the mistake would be harmless, but because you had decided the mistake was mine to make? And if so, how did you decide that? How does anyone decide that?

I am asking because I think the answer to those questions is the answer to a larger one: what is the difference between trusting someone and abandoning them? The version of mentorship I see most often gives people the theory first and the room later. You reversed it. You gave me the room and stayed within earshot while I built the theory myself. I keep trying to name what that move is, and I cannot quite get there without your help.

What I can say is what it made possible. Seven years of leading work I once thought required someone other than me. A habit of asking what the question underneath the question is. And, now, the ability to do for someone else something whose name I am still learning. Which is, I suppose, how you know the gift took.

Reflecting on keeping a discipline of rest

What does it mean to “lose” a day?

I ask that genuinely - not because the answer is obvious. If you give up eight hours you could have spent clearing the backlog, responding to messages, or moving the project one inch forward, you could call that a loss. The hours are gone. Nothing was produced. By the most straightforward ledger I know, the day is a deficit.

But ledgers assume you know what you are measuring. Do you?

I have tried to keep a day of rest and found myself, midway through the afternoon, with my phone in my hand and no memory of picking it up. I set it down. I picked it up again. Not because something urgent had happened - nothing had. The pull was not toward information; it was away from the unfamiliar weight of a day that was not accounting for itself.

That is worth sitting with. Why does stillness feel like falling behind, even when nothing is actually moving without you?

Consider what a working week actually runs on. Most of the decisions you make on a busy Tuesday are not made fresh - they are made from whatever store of steadiness you carried in from the days before. If that store is nearly empty because the weekend was also a low-grade continuation of the work, what are you actually drawing from?

You could answer that question two ways. One answer is: it does not matter, you got through Tuesday, the work continued. That is a real answer. The other answer is: you got through Tuesday, but you would know the difference between arriving there full and arriving there running on something nearly used up.

Which Tuesdays do you remember as the ones where you thought clearly? Where you gave something instead of merely managed not to take from the reserve?

I have noticed that after several months of keeping one day genuinely ungoverned by productivity - no tasks, no checking, no half-presence at the desk - the week does not feel shorter. It feels more like I showed up for it.

So here is the question I started with, restated: when a day produces nothing you can point to, has it done nothing? You have walked through the reasoning now. What does your ledger actually say?

Marking a long-serving colleague's departure

What do you actually lose when someone retires?

If the answer were straightforward, we wouldn’t be gathering like this, and the occasion wouldn’t feel the way it does. So consider what Howard did for twenty-six years. Not his title - his title stayed the same. Consider, instead, what happened when the filing structure for a client’s project suddenly made no sense to anyone who looked at it. Who did you call? When a new hire’s first crisis was threatening to become their last crisis at the company, who walked over to their desk and asked a question that made the problem feel solvable? When three departments each thought they owned a decision and none of them would make it, which one name appeared in everyone’s email, without being formally assigned?

Now consider what that person had to do to be the answer to those questions. Not what they had to know, though they had to know a great deal. What they had to be. Available without being the kind of available that made people feel watched. Reliable without being the kind of reliable that made people feel they could stop thinking for themselves. Patient with the same question the fifth time it arrived, because it arrived with a different person behind it.

Here is a question worth sitting with: would Howard have been able to do any of that if he had also been climbing? Reasonable people disagree on this. There are people who hold genuine ambition and generous presence at the same time. But look at what Howard actually built, and ask what it required of him. The careers he helped to start. The institutional memory that lived in his head because he chose to stay and learn it rather than move on and leave it behind. That is not what accumulates while you are working toward something else.

So what do we lose when someone like Howard retires?

Not a role. The role will be filled. Not a set of skills, though those will take years to rebuild in someone new. What we lose is a particular kind of trust that took twenty-six years to become invisible - the kind that only registers once it is gone.

What does that tell you about what we should be building next?

Marking the team shipping a hard, long project

What makes a project worth celebrating?

You could say: one that shipped. But Meridian’s old checkout had been shipping for six years, and it was shipping them toward a cliff. So the question isn’t whether something ran - it’s whether it ran toward something worth reaching.

Or you could say: one that hit its numbers. But how do you measure a system you built in parallel with a live one, that you could never take offline, that had to be invisible until the moment it wasn’t? The metrics arrive later. They aren’t the story.

Here is what you do know. Fourteen months ago, Priya Osei made a call that most engineers in her position would have deferred: she said the cart-abandonment problem wasn’t a product problem, it was a structural one, and you couldn’t fix a structural problem by patching what was already there. That is not an easy thing to say. It is harder to say when your manager is watching the current system process several thousand orders a day and your alternative is a blank file.

Did it go smoothly? You already know it didn’t. The first near-miss came when the new session layer couldn’t reconcile with the old one - and Marcus Delray spent eleven days in the gap between them, not fixing a bug but negotiating between two systems that had learned to disagree. The launch slipped in October. It slipped again in February. Each slip was the right call. Ask yourself: if the team had launched in October, what would peak week have found?

The final rollout happened on a Tuesday evening. It held. Not because nothing went wrong - one payment processor dropped for nine minutes - but because Yolanda Chen had built the fallback with the same care she’d built the main path, which is the kind of decision that only makes sense if you’ve already accepted that something will go wrong.

So what makes this worth celebrating?

Not that it’s done. Not that the numbers will improve. But that the team spent fourteen months doing work that was genuinely hard to see from the outside, held it together through two near-misses and two slipped launches, made calls that couldn’t be made by committee, and built something that held when it mattered.

You know what that cost. The question is whether that cost gets named.

Arguing a public position on return-to-office

What are we actually trying to solve?

Not “how do we manage people” - that question leads to badge-swipe dashboards. Not “how do we justify the lease” - that question was answered when we signed. The real question is this: how do we do the work that requires trust, while also doing the work that requires thinking? Because those are not the same problem, and they may not have the same solution.

Think about the last time something genuinely useful happened unexpectedly in a conversation at work. Where were you? Now think about the last time you did your best work on something hard. Where were you then?

If those two memories landed in different places, you have already done most of the reasoning.

The case for returning everyone to the office rests on something real. Proximity does something to trust that video calls have not fully replicated. The texture of a shared lunch, the offhand hallway question, the moment someone reads a colleague’s face and adjusts - these happen more naturally in the same room. That is not nostalgia. It is a structural feature of being physically present.

But here is the question worth sitting with: is it possible that some of the trust we attribute to the office is really about who was already there - people who could show up consistently because of where they lived, how they commuted, or what they were carrying at home? If yes, then “everyone back in the office” does not restore trust so much as filter for the circumstances that allowed trust to develop before. If no - if presence itself does the work regardless of who can sustain it - then the full-return case is stronger than its critics admit.

I do not think either answer is obviously right. But whichever you find more convincing, notice what it implies about the talent you cannot reach under a full-return mandate.

Which brings a different question: what is the minimum time together that actually captures the benefits of physical presence?

Not the maximum. The minimum. If two shared days a month - same team, same agenda, enough notice to make the commute worthwhile - produces most of the spontaneous collision and trust-building that five days a week produces, then what exactly are the remaining days buying?

Anchor days are not a compromise between two camps. They are a different theory of what the office is for: not where work happens, but where the conditions for work get built. If that is right, then a few deliberate days together with genuinely flexible time otherwise is not splitting the difference.

Is that how you read it now?

Announcing a new product to an outside audience

What are you actually deciding from?

What actually happens to customer feedback at your company?

Not the official answer. The real one. A support message comes in and gets resolved without anyone noting the pattern. A call gets two bullet points in a shared doc that three people edit and nobody archives. A user emails a feature request and someone puts it in the ticket tracker with a label it will never outgrow. Someone else files the same request six months later, not knowing it already exists.

At the end of the quarter, when the team sits down to decide what to build next, what is everyone deciding from?

You could say: from judgment. From intuition built over years of talking to customers. That is a real answer. But here is a more uncomfortable one: from whatever surfaced most recently, whatever the loudest voice said, whatever anyone happened to remember to bring into the room.

If that second answer sounds familiar at all, the next question is worth sitting with. What is the cost of a roadmap built from recency and volume rather than from pattern and priority?

You might say the cost is wasted engineering cycles - building the loudest thing rather than the right thing. You might say it is trust. When customers have told you something three times and nothing has shipped, what happens to their willingness to tell you a fourth?

Now consider: if there were a single place where all that scattered feedback could be gathered, ranked by your team together, and shared with anyone outside the room without a long preamble - what would you expect to change?

That is the question Tidemark is built to help you answer. It gathers feedback from wherever it already lives, surfaces the patterns, and produces a ranked, shareable roadmap your team can actually stand behind. It launches next week.

Whether it is useful to you depends on one question only you can answer: do you currently know, without reconstructing from memory, what your customers have been asking for most?

If you do, you may not need it. If you are not sure, that uncertainty is probably worth something.

A personal year-end reckoning with a difficult year

What do you call a year that asked for everything and returned something other than what you sent?

I spent most of this year on a project called Meridian - the kind of name that sounds more certain than anything actually is. It was a content platform, nearly two years of design and writing and convincing, and by spring it was clear to everyone except me that the appetite for it had shifted. By summer, it was over. Not dramatically. The kind of over where you get a polite email and then nothing.

There is a question underneath that loss that I kept avoiding: what would I have done differently if I had known sooner that the answer was going to be no? Would I have pulled back earlier, protected something, redirected energy somewhere with more runway? Or is the version of me who builds Meridian only possible because she doesn’t know how it ends?

I’m not sure there’s one answer to that.

The relationship is harder to write about, partly because Marcus didn’t do anything wrong, and partly because neither did I, and the year still changed us into people who talk less and mean it more. I kept asking myself whose fault it was - a useful question, I thought, until I noticed how many months I’d spent on it without getting anywhere. Fault assumes one person had the trajectory in their hands. What if the harder question isn’t who made this happen, but what kind of change this actually is - the kind you grieve, or the kind you accept, or the kind you still haven’t figured out how to name?

Here is one of the few things I’m prepared to assert: I got the ratio wrong between holding on and holding lightly. I held Meridian with tight hands long past the point where the signal was clear. I held my relationship with Marcus loosely in ways I later regretted. I confused discipline with stubbornness in one place, and adaptability with avoidance in the other.

So what do you carry forward from a year that didn’t resolve?

Not the lessons that tidy it up. Not gratitude for the suffering, which I don’t feel and would not claim. Maybe something quieter: the specific shape of what you grieve, as evidence of what you actually valued. And the open question of whether that ratio can be calibrated - or whether you just try again, with a year behind you that you know exactly what it cost.

Appears in diff-pairs

• socratic-inquiry vs diataxis-explanation (varies style)
• socratic-inquiry vs dialectic (varies style)