Problem-Solution

Frames the piece as a diagnosis followed by a remedy - establishes the pain before the cure.

Problem-Solution

Problem-solution is the workhorse of professional writing. It earns the reader’s attention by naming what they already feel (the problem) before proposing anything (the solution). The pattern works because it meets the reader where they are: already experiencing the friction, already asking “why is this hard?” The solution then arrives as a response to a question the reader is already asking.

The key discipline of problem-solution is specificity. A vague problem statement (“organizations face many challenges with process”) earns nothing. A specific problem statement (“the deploy pipeline takes 45 minutes and blocks three engineers every afternoon”) creates attention and stakes. The solution must then address the specific problem named, not a generalized version of it.

Problem-solution is not Problem-Complaint. It must arrive at the remedy. A piece that diagnoses brilliantly and then ends without a path forward has only done half the work.

Structural conventions

• Problem stated before solution, never after
• Problem section must be specific enough that the reader can confirm “yes, this is my situation”
• Solution section addresses the specific problem named, not a generalized one
• Optional: “before/after” contrast to show the delta

When to use

Technical proposals, product requirement documents, pitch decks, executive summaries, blog posts addressing a real pain point.

When not to use

Devotional writing, narrative content, contexts where the reader has not experienced the problem.

Pairs well with

pragmatic-architect, operator, candid, matter-of-fact, adr, prd

Often confused with

comparison-contrast: Comparison-contrast traces relative differences between options. Problem-solution names a pain and proposes a fix.

classical-argument: Classical argument builds a defensible claim with warrant and rebuttal. Problem-solution is prescriptive (here is the fix) rather than argumentative (here is why this position is correct).

Tells

• States the problem before the solution, never after
• The problem is specific enough that the reader can confirm “yes, this is my situation”
• The solution addresses the specific problem named, not a generalized version of it
• Often draws a before/after contrast to show the delta the remedy creates
• Arrives at a concrete path forward rather than ending at the diagnosis
• Meets the reader inside a friction they already feel, so the solution answers a question already being asked

Anti-patterns

• Opening with a vague problem (“organizations face many challenges with process”) instead of a concrete pain - A generic problem statement earns no attention or stakes; specificity is what makes the reader recognize their own situation and care about the fix.
• Diagnosing brilliantly and then ending without a remedy - This is Problem-Complaint, not problem-solution; the form must arrive at a path forward or it has done only half the work.
• Weighing several options against each other on parallel dimensions for the reader to choose among - Evaluating options relative to each other is comparison-contrast, a confusable neighbor; problem-solution names one pain and proposes one fix for it.

Failure modes

• Inflates the problem to glorify the solution, over-dramatizing the pain and its cost so the remedy looks more impressive and necessary than it actually is - Size the problem honestly; the solution should fit the pain as named, and a remedy propped up by an exaggerated problem collapses the moment the reader recognizes the inflation.
• Over-specifies the diagnosis until the problem section sprawls into an exhaustive account of the pain and the solution arrives starved of equivalent concreteness - Name the problem precisely enough to create stakes, then give the solution the same specificity; the point is the remedy, not a catalogue of the suffering.

Instruction

Write using problem-solution structure. Name the specific problem first - not a vague category
but the concrete pain the reader experiences. Make the problem statement specific enough that
the reader says "yes, that is my situation." Then introduce the solution as a direct response to
the named problem. The solution must address what was actually named, not a generalized version.
If you include a before/after contrast, make both sides concrete. Do not end the piece at the
diagnosis - you must arrive at the remedy.

Related

Pairs well with

Pragmatic Architect, Operator, Candid, Matter of Fact, Architecture Decision Record, Product Requirements Document

Avoid with

Devotional Reflection, Reverent, Pastoral

Often confused with

Comparison-Contrast, Classical Argument

Examples

Should we adopt async-first standups?

The Problem

The team’s daily standup runs at 9am Pacific. Three of the team’s eleven engineers are based in India (UTC+5:30), which puts the meeting at 9:30pm their local time. On any given week, at least one of those engineers misses the call because of a conflict with evening life. When they miss it, they do not get the context shared in the meeting - including blockers that affect their work.

The problem is not just timezone fairness. The meeting’s information does not persist. When @priya mentions in the standup that the auth service is throwing a 401 on a specific endpoint, that information lives in a 14-minute Zoom recording that nobody will watch. The engineer who hits that same 401 at 2pm does not know Priya already diagnosed it. They spend 45 minutes retracing the same path.

The synchronous standup was designed for co-located teams. It assumes everyone can occupy the same time slot without cost, and that verbal delivery is sufficient for information sharing. Neither assumption holds for this team.

The Solution

Replace the synchronous standup with a structured async update in #team-standup. Each engineer posts by 10am their local time, answering three questions: what shipped in the last 24 hours, what is in progress today, and what is blocked or at risk. Any blocked item must @mention the specific person who can unblock it.

The channel becomes the single searchable record of daily status. When an engineer hits a 401 at 2pm, they search the channel and find that Priya posted the fix at 8am India time.

Blocked items are resolved faster because the @mention reaches the right person directly, rather than relying on that person happening to attend the meeting and remember.

The synchronous meeting is replaced by a 60-minute working session on Thursdays, reserved for discussion that genuinely requires real-time exchange.

After 30 days: review blocker resolution time, channel engagement rate, and a team survey. Extend or revert based on data.

How to start a morning routine

The Reactive Morning Problem

The problem

Most working adults begin the day in a posture they would not choose if they noticed it. The alarm sounds, the hand reaches for the phone, and within ninety seconds the first messages, headlines, and notifications have entered the brain. Before the eyes have fully focused, the day has already received its first wave of input from elsewhere.

This is the reactive morning. It looks like this:

• Wake, check phone, see three things that demand a response.
• Spend the next twenty minutes mentally drafting replies that have not yet been sent.
• Arrive at the kitchen already tired, already behind, already irritated.
• Move through breakfast, dressing, and commute on autopilot, since attention is already allocated.
• Sit down to the first deliberate task of the day around mid-morning, with depleted resources.

The cost is not the twenty minutes spent on the phone. The cost is that the day’s emotional baseline has been set by inputs from elsewhere, and that baseline now follows you for the next eight hours. By the time you notice it, you are too far in to reset.

The reactive morning is not a discipline problem. It is a structural problem. There is currently nothing between waking and the first incoming demand. Whatever fills that gap will set the tone of the day, and right now the phone is filling it.

The solution

Insert a structured first hour between waking and the first reactive demand. The structure does not need to be elaborate. It needs to be reliable.

A workable shape:

Minutes 1 to 5. Phone stays where it slept (ideally in another room). Get out of bed. Drink a full glass of water. Open a curtain or step outside briefly. The single goal of this window is to establish that the day has started on its own terms.

Minutes 5 to 25. A short physical movement (a walk, a stretch sequence, a few minutes of any exercise). The goal is not fitness. The goal is to give the body a signal that the day is underway.

Minutes 25 to 45. A single quiet activity. Reading, journaling, prayer, planning the day on paper, slow coffee with no input. One thing only, chosen in advance.

Minute 45 onward. Phone enters. By now the day has its own shape. Incoming messages are received from a stable baseline, not from a reactive one.

The total is forty-five minutes. The minimum viable version is fifteen: water, light, one quiet activity.

Before and after

Before. Wake at 6:30. Phone in hand by 6:31. First reply mentally drafted by 6:45. At the desk by 8:30 already two emotional gears down from where the day started.

After. Wake at 6:30. Water and outside light by 6:35. Movement by 6:45. One quiet activity until 7:15. Phone enters at 7:15. At the desk by 8:30 with the first hour intact and the baseline set by the morning rather than by the inbox.

The structure is the solution. The specific content is negotiable. What is not negotiable is that something occupies the first window other than incoming demand.

How to choose between Postgres and DynamoDB for a new service

Problem-Solution on: Choosing between Postgres and DynamoDB

The problem

Lattice Notify needs to commit to a storage choice for the new notification system by Friday so the team can plan next sprint, and the team is stuck. Ana (tech lead) wants Postgres because the eight-engineer backend team has shipped at the 500K-events-per-day launch volume on Postgres before and the four-person on-call rotation can debug it cold at 3am. Marcus (senior engineer) wants DynamoDB because the access pattern is write-heavy, key-lookup, and time-ordered, and because the 10x growth scenario tied to the Slack-partnership deal would force a Postgres sharding project the team has never done.

The standoff is not a personality conflict; it is a real structural disagreement about what the decision is optimizing for. The current state is that the architecture meeting Wednesday 2pm Pacific has been on the calendar for ten days, two thoughtful engineers have produced credible analyses in opposite directions, Priya has reset the deadline twice already, and the team is now four days from sprint planning with no committable answer. Getting this wrong costs 3-6 weeks of rework if a migration is forced. Getting it right gives the notifications team a year of stability on a foundation that will not need to be replaced. The cost of further indecision is concrete: every day past Friday delays the notification launch by a day.

The solution

Ship the notification system on Postgres with a queue, and pre-commit to a binding trigger condition that fires a planned migration to DynamoDB if real volume crosses 2M events/day on a 30-day rolling average. This addresses the specific problem named because it resolves the actual disagreement: Ana’s concern about operational safety for the four-person rotation is honored at launch, and Marcus’s concern about the 10x scenario is converted from a projection-driven argument into a measurable trigger that fires on real data.

The execution: Ana owns the Postgres schema and the queue integration for a 2026-06-15 production target. Marcus’s prototype Dynamo schema is preserved in the design-docs repo with the status “deferred design, ready to revive,” not deleted, not productionized. Priya owns the quarterly volume review against the 2M events/day threshold starting 2026-Q3. The on-call rotation stays at four engineers on one storage system at launch; if the trigger fires, the rotation is revisited before the second storage system goes live.

The decision survives the load-bearing critique from each side. From Ana’s side: the team is not committing now to operating DynamoDB; the commitment is only to revisit when volume demands it. From Marcus’s side: the team is not pretending the 10x scenario will not happen; the trigger is binding and tied to real data rather than to hope. The 60% Slack-deal probability from the CRO is what makes this trade rational rather than evasive: at 60%, the expected cost of running two storage systems for a year is higher than the expected cost of a scheduled migration if the high-volume scenario materializes.

Before and after

Before: two engineers in disagreement, a PM resetting deadlines, a four-day countdown to sprint planning with no decision, and a meeting on Wednesday with no path to convergence. After: a recommendation circulated 24 hours before the meeting, the meeting ratifying the path, the decision committed to the engineering channel Friday morning, sprint planning running Friday afternoon against concrete tasks, and a trigger condition that converts the unresolved future into a managed contingency.

This is the path. Run it.

Telling stakeholders a committed feature is being cut this quarter

What Happened to Insights, and What Ships Instead

We committed Insights for Q3. You made plans around that commitment - sales conversations, customer expectations, roadmap conversations with your own stakeholders. We owe you a clear account of why that date is not holding and what we are doing about it.

The Problem

Partway through August, we were six weeks behind on Insights. The cause was a billing-system migration that ran longer and deeper than the estimate we built the quarter’s capacity plan around. The migration is not optional - it closes a compliance gap that would otherwise affect every customer’s billing accuracy. But it consumed the engineering time allocated to Insights.

At that point, we had a choice: ship what was done on the original date, or move the full feature and ship something useful in its place.

Shipping the partial build was the wrong call. The version of Insights that was shippable in Q3 was missing date-range filtering, multi-metric overlays, and CSV export - the three capabilities named in nearly every sales conversation and customer discovery call. A dashboard that can display only a single metric for the current period is not the product you committed to. Shipping it would have required a second onboarding when the rest of the features arrived, and it would have anchored your customers’ first experience to something we know is incomplete.

The Path Forward

By the end of September, we are shipping a CSV export of the underlying Insights data. The export includes the same event streams Insights will visualize: session activity, feature-interaction rates, and funnel completion broken down by cohort. You can load it into a spreadsheet or BI tool you already use and run the analysis you have been waiting for.

The full Insights dashboard - with date-range filtering, overlays, and saved views - ships in Q1. We are locking scope now so engineering can start immediately after the billing work wraps, with no planning gap between.

We will send the export field guide and file format on September 15. When the Q1 launch date is confirmed, you hear it before anyone else does.

If there is a specific workflow - a customer-facing report, a board deck, a quarterly review - that the delay creates a concrete problem for, tell us now. We will work out a bridge.

Getting a new engineer productive in their first two weeks

The default is drift.

When Priya arrives on a team that ships every day and runs on-call, the calendar is already full and everyone is already behind. The default is that she gets a wiki link, a ticket queue to browse, and calendar invites to every recurring meeting. By the end of week one she has attended twelve stand-ups and touched nothing real. By the end of week two she can describe the architecture from a diagram but cannot find where the authentication service actually lives in the repository. She has not shipped anything. She does not yet know if she belongs here.

That is the specific failure mode that needs a plan to prevent: not malice, not neglect - just the absence of deliberate structure on a team that has none to spare.

What a deliberate two weeks looks like.

Week one is about reducing the blast radius of confusion. On day one, walk her through the full service map live - not a diagram, but the actual repository layout, the deploy pipeline running in a terminal, the on-call rotation schedule on a screen. At the end of day one she should have deployed a hello-world change to a staging environment using her own credentials. Not because that change matters, but because the deploy cycle should stop being abstract before anything else starts.

Days two through four: pair on a known-small, bounded change. A config value. A log statement. A single-line bug fix with a test. Something where the worst case is a fast revert, not an incident. She writes the PR. You review it the way you would review anyone’s PR. She merges it. The specificity here matters - “pair on something small” is not the same as “pair on something where the full cycle is visible from change to deploy, and she drives all of it.”

Week two: she owns the next change top to bottom, and you are available but not driving. The shift from paired to independent is the explicit goal of the two weeks.

On the human side: pairing sessions are protected time. They do not move for sprint ceremonies or syncs. Priya learns she belongs partly through what the team treats as interruptible, and a dropped pairing session is a signal she will read correctly.

By the end of week two, she has shipped something real. She knows who owns each service because she has touched those boundaries. And she has been treated as a peer - not a project.

Writing to thank a mentor who shaped your career

Dear Dana,

The problem I kept running into, in the early years, was not that I lacked ability. It was that I was only ever handed work sized for the ability I had already demonstrated. That is comfortable. It is also a guaranteed ceiling.

When you put me in front of the Pembury account reorganization - a full client-facing engagement I had never run at that scale - I told you I wasn’t sure I was ready. You told me you thought I was, and that you’d stay close. That turned out to be a precise claim describing a precise behavior.

I understand now what you were actually navigating. The failure mode on one side: leave me unsupported, and the project suffers, and I leave it knowing I can’t handle that kind of work. The failure mode on the other side: step in when things get difficult, and I leave it knowing that someone else’s competence will always be the safety net when mine runs out. Either outcome would have confirmed the thing I already quietly believed - that I wasn’t ready, and probably wouldn’t be.

What you did instead was hold the line between support and rescue at a place I couldn’t have held it myself. You would answer a specific question and not expand it into a tutorial. You would name one thing I’d gotten wrong and stop there. For eight weeks, you were available without being present.

The delta between those two versions of that year is this: in the version where you let me fail, or stepped in to fix it, I would have left that engagement the same person who entered it. In the version that happened, I came out knowing that the feeling of not being ready is not the same as not being capable.

Last quarter, I put someone I manage - Marcus - on a client integration he told me he wasn’t sure he was ready for. I stayed close. I answered specific questions without expanding them. I stopped after naming one thing wrong. When I caught myself doing it, I recognized whose hands I was trying to move like.

That is what I wanted you to know. I learned how to do that from you, and it turns out I am still learning it.

Reflecting on keeping a discipline of rest

The Problem With Trying to Rest When You Measure Days by Output

The problem

The day you set aside for rest arrives, and by mid-morning you are composing emails in your head. You have not opened anything yet. You are technically resting. But the mental tab is still open, cycling through the same three threads from Friday, calculating how much of the list you could clear before the day ends.

This is the specific problem with rest for people who track their days by output: rest does not feel like rest when the metric is still running. It feels like falling behind. Every hour away from the list is an hour the list grows, and the anxiety of that growth is louder than the quiet you are trying to hold.

I spent two years trying to rest by deciding it each week. The decision happened on Friday: tomorrow is a full day off. The negotiation started Saturday by 9 a.m. One message to answer. A task that would take fifteen minutes. One thing led to the next, and by noon I had worked most of the morning and felt guilty about the rest of the afternoon. I had not solved anything. I had only pushed the work a few hours and paid for it with the unease of doing neither thing fully.

The problem is not willpower. It is that I kept making the rest decision at the moment the pull was strongest, with no structure to absorb the pull.

The solution

Stop deciding on the day. The decision has to be made before the week starts, and it has to be a rule rather than an intention.

I chose one fixed day and treated it as non-negotiable, the same way a flight departure is non-negotiable. No work applications, no checking the chat tool, no opening the task tracker to “just look.” Not because the pull disappeared - it did not - but because a rule does not require a good mood or the right circumstances. An intention does, and the circumstances on a Saturday morning are never right for choosing not to check.

The rule costs one full day per week. That cost is real. What is not accurate is the assumption that the cost is permanent - that the hours put down stay down. They come back, but they come back differently.

Before and after

Before: a “rest day” decided fresh each week, negotiated down to a half-day by noon, ending with neither rest nor work but the residue of both. Back at the desk Monday already running a tab of guilt.

After: one fixed day, set as a rule before the week begins. The pull still shows up. The rule does not argue with it. What returns across the following six days is something I can only describe as additional weight behind the work - not more hours, but more presence inside the hours that remained.

The rest does not add time to the week. It reorders the time already there, and the reordering is the point.

Marking a long-serving colleague's departure

The hardest part about losing Howard is not the absence itself. It is the specific gap: twenty-six years of knowing where the bodies are buried, and knowing which ones to leave there.

When systems failed, most people called the incident channel. Howard would already be looking at the logs. Not because he was on call - he rotated off on-call duty years ago - but because he had learned, through repetition, exactly what a production failure looked like before anyone else had framed it as one. He knew the names of the vendors who had sold promises that did not hold. He remembered the decisions made in the early years that still shaped behavior in the codebase today, not because he had documented them, but because he was there.

That kind of knowledge does not appear on a handover document. You cannot export it into a wiki. It lives in judgment: the ability to say “this is the third time this pattern has appeared, and here is what happened the other two times.” Howard had that. He spent twenty-six years in the same role, building it, and he gave it away freely, mostly without announcing that he was doing so.

The problem is not simply that he is leaving. The problem is that organizations which produce someone like Howard often do not understand what they have built until after it walks out the door. They call it “institutional memory” and move on. They promote someone else. The gap takes years to show up - not in one visible failure but in a hundred small misreadings, small repetitions, small costs no one can trace back to the moment a specific person stopped being available.

The remedy is not a knowledge-transfer session or a documentation sprint, though both are worth doing. The remedy is this: name what he actually gave, specifically, in front of the people who received it.

He kept Devin from making a costly mistake in her first year, quietly, without Devin knowing it was a rescue until much later. He walked Carlos through a system decision that would have taken months to unwind if made wrong. He answered questions on days he had no obligation to answer anything.

That is what we are marking today. Not a career. A gift, given steadily, over twenty-six years. Name it. Carry it forward.

Marking the team shipping a hard, long project

The problem was not a mystery. For three years, users were reaching the final step of checkout and leaving. The drop-off rate was consistent enough that the data team had named it: “the cliff.” Everyone knew it was there. The original flow had accumulated patches and workarounds until the codebase no longer reflected any single design intent. A payment confirmation could take four seconds on a slow connection. Error messages were technically accurate and completely unhelpful. The experience was functional in the way a frayed rope bridge is functional: it mostly held, but you knew it was failing, and so did your customers.

The correct fix was a rewrite. Which meant keeping the old bridge in service while building a new one next to it, for fourteen months, without letting either collapse.

That constraint - running parallel systems, routing real transactions through the legacy flow while the new one took shape - is what made this project genuinely hard. It is the kind of hard that does not appear in a status update. The team held two codebases in their heads simultaneously. They built feature parity while resisting the temptation to add anything new. They absorbed two near-misses: one where a data migration looked like it would corrupt active cart sessions, another where a dependency upgrade forced a two-week detour. The launch slipped in March and again in May. Both slips were the right call.

The rollout happened on a Thursday, during a promotion that had not been moved for anyone. Peak load arrived on schedule. The new flow held.

What changed: the cliff is gone. Users who reach the final step now complete it at a rate that reflects an experience that works, not one that happens to not fail. Error messages say what to do next. Confirmation loads in under a second on the same connections that used to time out.

Priya Kim made the call to pause the March launch when the session data looked wrong. Marcus Osei rewrote the migration plan in six days. The whole team carried dual-system cognitive load for a year without dropping either side.

The work was invisible from outside. That is what we are marking today: the thing that was hard, done correctly, all the way to the end.

Arguing a public position on return-to-office

The problem isn’t remote work or in-person work. The problem is that most organizations are trying to answer the wrong question.

When leaders demand a full return to office, they are treating presence as a proxy for performance. They feel the cultural drift - the hallway conversations that never happened, the new hires who feel like contractors, the mentoring that dried up the moment the building emptied - and conclude that proximity is the fix. When remote advocates push back, they are protecting something real too: the commute hours returned to their lives, the ability to hire from any city, the focused stretches their best work requires.

Both sides are describing genuine costs. Neither side has the remedy.

Here is the specific problem underneath the noise: unplanned collaboration and trust-building require physical co-presence, but sustained, focused work is destroyed by it. These are not competing preferences. They are different cognitive modes. Open-plan offices optimized for one mode throttle the other. Fully remote setups do the reverse.

The current debate treats this as a zero-sum choice. It is not.

A deliberate hybrid - two or three shared anchor days per week, the rest fully flexible - addresses both failure modes directly. On anchor days, the team is physically together, not to “work” in the conventional sense but to do the things that only in-person time does well: whiteboard a gnarly decision, onboard a new teammate with real face time, share a lunch where no one is looking at a screen. The rest of the week, people work where they work best.

Before this structure, the team I observed closest had a different experience every week - three people in the office, two at home, nobody sure which was “right,” meetings that served neither mode well. After moving to two fixed anchor days, the informal trust conversations happened because everyone knew those two days were the days to be there. Focused work happened because everyone knew the other days were protected.

The anchor-day model is not a watered-down compromise that makes no one happy. It is a structure that matches the mode to the need. Office-first leaders get the co-presence time where it earns the most. Remote advocates keep the flexibility where it matters most. The question is not how many days people are in the building. The question is which days, and why.

Announcing a new product to an outside audience

If your team collects customer feedback, you probably collect it everywhere. A thread in the chat tool. A batch of support tickets. A spreadsheet someone started after the last round of user interviews. Notes from a sales call buried in a shared folder. The pile grows. The problem is what happens when someone asks: “What should we build next?”

The answer depends entirely on who you ask and which pile they last looked at. The person handling tickets sees one pattern. The person running customer calls sees another. Neither view is wrong, but neither is the whole picture, and closing the gap between them takes a meeting - usually followed by another meeting. The ranked roadmap never quite materializes, or when it does, it lives in a document only the person who wrote it can interpret. Share it with a partner, a board member, or a new hire, and you spend the next half hour explaining the reasoning behind the ordering.

Tidemark is built for exactly this situation.

It collects your scattered feedback into one surface - support tickets, interview notes, survey responses, whatever form the input takes - and gives your team a single place to tag, weight, and rank it. The output is a roadmap that shows not just what you plan to build, but which customer signals drove each decision. That context travels with the document when you share it. A stakeholder reading it cold understands the reasoning without a guided tour.

Before Tidemark: three people, three partial views, one recurring meeting to negotiate the gap.

After Tidemark: one ranked list, evidence attached, shareable in a link.

Tidemark launches next week. If your team is currently managing feedback across more channels than you want to count, early access is open now at tidemark.io. You can import your first batch of feedback in under ten minutes, and a ranked view is ready as soon as you start tagging.

A personal year-end reckoning with a difficult year

The problem with how I handled this year was not the losses. It was the strategy I used to survive them.

Two things broke between March and June. The Foundry project - three years of work and a team I had genuinely believed in - ended when the client, Marcus, told us they were going a different direction. The language was careful and corporate. The outcome was a product that shipped nowhere. Around the same time, a relationship I had been in for four years changed in ways I did not choose. Lena did not leave with an argument I could study. Things eroded, and then they were different.

My response to both was to look for the lesson. I read every post-mortem. I replayed the hard conversations. I was searching, implicitly, for an argument that would let me reframe the losses as preparation - painful now, but secretly investments in something better.

That search was the problem I actually had. Not the failures. The strategy.

The lesson-hunting kept me from looking directly at what I got wrong. On the project, I got wrong the moment in month eighteen when Marcus raised the scope question and I redirected instead of listening. I treated his concern as a negotiation tactic and moved past it. On the relationship, I got wrong the conversation in March when Lena said she needed more time with me and I booked a work trip instead of staying home. These are not complete accounts of what happened. But they are the parts I had control over, and I spent most of this year not examining them because examining them without a larger meaning felt like punishment without purpose.

The remedy is specificity. Not acceptance, not reframing.

I am carrying forward two corrections I chose, not discovered. First: when someone names a problem in the middle of something I have built, that is the moment it needs attention, not redirection. Second: scheduling around a conversation I am avoiding is not a plan.

The year did not hand me these. I looked at what happened, named what I got wrong, and drew a line. That is different from finding a gift in the difficulty. I am not going to pretend the hard parts were secretly preparing me for something better. They were just hard, and I made some of them harder than they needed to be.

Appears in diff-pairs

• problem-solution vs classical-argument (varies style)
• problem-solution vs comparison-contrast (varies style)