Decision Log

A real-time record of context, options considered, criteria used, and reasoning - capturing how a decision was reached, not justifying it after the fact.

Decision Log

A decision log is written at the moment of deciding, not after the decision has proven itself. This timing is what gives it value. A document written after the fact is a justification dressed as a record - it knows the outcome and selects the evidence that supports it. A decision log written in the moment of deciding captures the actual options that were on the table, the actual criteria that mattered, and the actual reasons the chosen path seemed best given what was known at the time. Future readers can assess whether the reasoning was sound without being misled by hindsight selection.

The context section is the most undervalued part of a decision log. Decisions made six months ago often look inexplicable without it. “Why did we deploy on a Friday?” makes no sense unless the reader knows that the client had a board presentation Monday and the demo environment was broken. Context is not a formality - it is the load-bearing section that makes everything that follows legible to a future reader who was not in the room.

An ADR (architecture decision record) is a decision-log specialized for software architecture choices. Decision-log is the general form. The same structure applies to product decisions, process changes, hiring decisions, vendor selections, and any other choice where the reasoning will matter later. The specialization of ADR for architecture adds conventions about drivers and consequences; the general decision-log form is deliberately more open.

Structural conventions

• Context section captures the situation and constraints that existed at decision time
• Options section lists the alternatives actually considered, not a post-hoc menu
• Criteria section names the values or constraints that governed the evaluation
• Decision section states the chosen option and the reasoning - the “because,” not just the “what”
• Written at decision time, not reconstructed afterward
• Does not require the decision to have been correct - a good decision log records good reasoning, not good outcomes

When to use

Any significant decision where the reasoning will matter to future team members: vendor selections, technology choices, product pivots, process changes, and hiring decisions. Especially valuable in onboarding contexts where new team members need to understand why things are the way they are, and in governance contexts where the auditability of reasoning is required.

When not to use

Routine operational decisions that will not affect future readers. Avoid when the audience needs the decision communicated rather than the reasoning behind it, in real-time situations where structured logging overhead is not warranted, and when the outcome is immediately visible and the reasoning is self-evident.

Pairs well with

pragmatic-architect, direct-communicator, adr, matter-of-fact

Often confused with

adr: An ADR (architecture decision record) is a decision-log specialized for software architecture choices, with conventions specific to that domain - drivers, status, consequences in a technical sense. Decision-log is the general form that applies to any significant organizational choice. Every ADR follows the decision-log pattern; not every decision-log is an ADR. The distinction is scope and specialization, not structure.

Tells

• Organized around context, options, criteria, and decision rather than as continuous prose
• A context section captures the situation and constraints that existed at decision time
• The options section lists the alternatives actually considered, not a tidied post-hoc menu
• The decision section gives the reasoning - the “because,” not just the “what”
• Written as if the reader was not in the room, so a future reader can follow the choice
• Records the reasoning as it stood, without grading the decision by an outcome it could not have known

Anti-patterns

• Writing the log after the outcome is known and selecting the evidence that makes the choice look right - A record written with hindsight is justification dressed as a log; the value comes from capturing the reasoning as it actually existed at decision time.
• Listing a clean menu of options nobody seriously weighed, or omitting the ones that were genuinely on the table - A post-hoc options list misrepresents the decision; the section is honest only when it names the alternatives actually considered.
• Leading with the recommendation and supporting analysis for a busy reader to act on - Presenting a conclusion to drive action is an executive summary, a confusable neighbor that looks forward; a decision-log looks backward at how the choice was reached.

Failure modes

• Over-applies the impulse to record everything, logging routine decisions and padding every section with context until the load-bearing reasoning is buried in ceremony - Reserve the structured record for decisions whose reasoning will matter later, and keep context to what a future reader genuinely needs to make the choice legible.
• Over-honors auditability by logging every consideration with equal weight, so the decision is stated but the reader cannot tell which factor was actually decisive among the dozens recorded - Capture the reasoning that mattered and mark what tipped the choice; a faithful record still distinguishes the load-bearing reason from the considered-and-set-aside, or the future reader inherits a transcript rather than a rationale.

Instruction

Write as a decision log. Organize around four sections: context (what was true when this
decision was made), options (what was actually considered, not a post-hoc list), criteria
(what values or constraints governed the evaluation), and decision (what was chosen and why -
the because, not just the what). Write as if the reader was not in the room. Do not justify
the decision in hindsight - record the reasoning as it actually existed at decision time.
A good decision log records good reasoning; it does not require the decision to have been
correct in hindsight. Do not include pleasantries or framing prose; go directly to the
structured record.

Related

Pairs well with

Pragmatic Architect, Direct Communicator, Architecture Decision Record, Matter of Fact

Avoid with

Devotional Reflection, Playful, Warm

Often confused with

Executive Summary

Examples

Should we adopt async-first standups?

Decision: 2026-Q2 Standup Format

Status: Decided Date: 2026-04-08 Owner: Lina Acosta (Platform Eng Manager) Stakeholders: Platform team (11 engineers); Head of Engineering (informed, not approving)

Context

The Platform team is 11 engineers across four timezones: US Pacific (3), US Eastern (3), UK (2), India (3). The current synchronous daily standup runs at 9am Pacific, which is 9:30pm IST for the three India-based engineers.

Two recurring problems are now well-evidenced rather than anecdotal:

1. Attendance inequity. Q1 attendance data: India engineers averaged 3.2 of 5 weekly standups; US-based engineers averaged 4.6. The gap correlates with the meeting time, not with the engineers.
2. Information loss. Standups run 14 minutes on average. Roughly 4 minutes drive concrete action. The remainder is verbal status that does not persist. We have multiple recent instances of engineers re-diagnosing problems that teammates solved earlier the same day. The most concrete: a 401 auth fix discussed in standup on March 3, then re-diagnosed by a different engineer on March 4 because they were not on the call.

The status quo is not free. It is paid disproportionately by the India engineers and intermittently by anyone who misses a meeting.

Options Considered

Option A: Keep the current sync standup

Cost concentrated on India team. Information loss continues. No change required, no risk introduced.

Option B: Rotate the standup time weekly across timezones

Spreads the inequity rather than removing it. Calendar churn for everyone. Still does not solve the information persistence problem.

Option C: Two sync standups (Americas + Europe/India)

Splits the team into two information silos. Doubles the meeting load on anyone bridging both. Cross-region context gets worse, not better.

Option D: Async-first standup with weekly sync working session

Eliminates the timezone tax. Creates a searchable record. Preserves a real-time slot for discussion that benefits from it. Requires behavior change.

Option E: No standup at all

Lowest meeting cost. Highest information cost. Rejected without serious consideration; the team is not co-located enough to absorb the loss of any structured status mechanism.

Criteria

The decision is being made against these criteria, in priority order:

1. Equity across timezones. No single timezone should bear a disproportionate share of off-hours meeting cost.
2. Information persistence. Daily status should be searchable, not ephemeral.
3. Blocker resolution speed. Blocked items should route to the right person quickly.
4. Real-time bandwidth preserved. The team still needs occasional real-time exchange for hard problems.
5. Reversibility. Whatever we choose should be revertible within a sprint if it does not work.

Decision

Adopt Option D for a 30-day trial starting 2026-04-13.

Specifics:

• Daily async post in #team-standup, three fields: Shipped, In progress, Blocked or at risk. Posted by 10am local time. Blockers @mention the unblocker.
• 9am Pacific sync slot becomes a 60-minute Thursday working session.
• Day 15 informal check-in. Day 30 formal evaluation against success criteria.

Success criteria at day 30

The trial extends if at least two of three are positive:

1. Median blocker resolution time during overlap windows under 2 hours.
2. At least 9 of 11 engineers posting at least 4 of 5 weekdays.
3. Team survey shows equal or better context on teammates’ work versus the sync model.

If two of three fail, revert to a rotating-time sync standup (not the current fixed time, which is the worst option).

Reasoning

Option D scores best on criteria 1, 2, and 3, neutral on 4, and equivalent to most other options on 5. Option A scores poorly on 1 and 2. Options B and C reduce one cost while introducing a new one. Option E is dominated by D on every criterion except meeting count, which is not in our top five.

The deciding factor was criterion 1. The current attendance gap is not a behavior problem; it is a schedule problem. Once we accepted that, the options that preserved the schedule were no longer viable.

Open Questions

• Does the Thursday working session need a standing agenda template, or is a free-form shared doc sufficient? Defer to day 15 check-in.
• Should “Blocked or at risk” be split into two fields? Some engineers may underreport “at risk” items. Defer to day 30 review.
• If we revert, what is the rotating-time schedule? Owner: Lina. Due before day 30 in case revert is needed.

How to start a morning routine

Decision: 2026 Morning Routine Format

Date. 2026-05-14 Decider. Self Status. Decided. Effective 2026-05-15.

Context

Current morning pattern: wake at 6:15, phone in hand within 60 seconds, first deliberate action of the day around 7:30. Pattern has held for approximately eighteen months. Self-reported mornings range from “fine” to “already behind by 7:00.” Two prior attempts at a structured morning routine (in 2024 and early 2025) failed within two weeks. Both prior attempts were ambitious in scope (5:00 wake, full workout, journaling block). Both collapsed on the first travel week.

Trigger for revisiting: three consecutive weeks of arriving at the 8:30 standup already irritated, traceable in retrospect to specific phone content seen between 6:15 and 6:30.

Options considered

Option A. Keep the current pattern. No change. Phone-first morning continues. Accept the cost as priced in.

Option B. Aggressive overhaul. 5:00 wake, one hour of structured activities (workout, journal, plan), phone after 7:00. Similar to the 2024 attempt.

Option C. Minimal pre-phone routine. Phone sleeps in kitchen. Wake at 6:15. Water, light, one quiet activity (15 minutes total) before phone enters. No change to wake time.

Option D. Phone software lock until 7:30. Keep phone bedside. Use a screen-time lock to make it unavailable until 7:30. Wake time and other behavior unchanged.

Criteria

1. Survives a bad day (sick child, travel, deadline) without collapsing.
2. Total time cost under thirty minutes on a normal day.
3. Does not require new equipment, new apps, or a new wake time.
4. Failure mode is recoverable (skipping one day does not end the routine).
5. Demonstrably different from the 2024 and 2025 attempts in shape, not just intensity.

Evaluation against criteria

Criterion	A	B	C	D
Survives bad days	N/A (no routine)	No (prior evidence)	Yes	Partial (lock can be overridden)
Under 30 min total	Yes	No	Yes	Yes
No new equipment / wake time	Yes	No	Yes	Partial (requires app)
Recoverable failure	N/A	No	Yes	Yes
Different from prior attempts	N/A	No	Yes	Yes

Decision

Option C. Phone sleeps in the kitchen starting tonight. Morning sequence: water (1 min), window or step outside (2 min), one chosen quiet activity (10 to 12 min, alternating weekly between reading and planning on paper), then phone. Total target time: 15 minutes. Wake time unchanged at 6:15.

Reasoning

Option A is rejected because the cost is now visible and traceable to a specific behavior. Continuing it is no longer a default; it is a choice with a price tag.

Option B is rejected on prior evidence. Two previous attempts at this shape failed within two weeks. The failure was not motivation; it was design. Routines that require ideal conditions do not survive non-ideal ones, and non-ideal conditions are most days.

Option D is rejected because it depends on a software constraint that can be disabled in three seconds. The phone-in-another-room rule is harder to circumvent because circumventing it requires walking to another room, which is enough friction to break the reflex.

Option C is chosen because it changes the structural variable (phone location) rather than the willpower variable (resisting the phone). It is recoverable because the only hard rule is the phone location, and the rest of the routine can compress to two minutes on a hard day without breaking.

What we are explicitly not deciding

• Wake time. Stays at 6:15. May revisit in ninety days.
• Workout placement. Stays in current evening slot. Not a morning concern.
• Weekend variation. Will be evaluated at the thirty-day checkpoint, not now.

Review

Reassess at thirty days (2026-06-14) and ninety days (2026-08-13). At each checkpoint, evaluate: completion rate, subjective day-quality on routine vs non-routine days, and whether any element should be removed (not added).

How to choose between Postgres and DynamoDB for a new service

Decision Log on: Choosing between Postgres and DynamoDB

Decision: Notification System Primary Storage

Status: Decided Date: 2026-05-15 Owner: Ana Velasquez (Tech Lead, Notifications) Stakeholders: Marcus Chen (Senior Eng, prototype owner); Priya Singh (PM); 4-person on-call rotation Forum: Architecture meeting, Wednesday 2026-05-13 2pm Pacific

Context

Lattice Notify is a 50-person Series B with 8 backend engineers. The product currently runs as a monolith on Postgres. We are building a real-time notification system that needs new persistent storage. Launch volume is projected at 500K events/day. The CRO assigned 60% confidence on Friday 2026-05-08 to a Slack-partnership deal closing in Q3 2026; if it lands, volume reaches roughly 5M events/day in twelve months.

Priya set a Friday 2026-05-15 deadline so the team can plan the next sprint. The on-call rotation is four engineers, none of whom have operated DynamoDB in production. Ana has scaled Postgres to this range before in a prior role; Marcus has prototyped on DynamoDB but not operated it.

The cost of being wrong: roughly 3-6 weeks of rework if a migration is forced later. The cost of being right: roughly a year of stability on the chosen storage path.

Options Considered

Option A: Postgres with a queue

Reuse the existing Postgres cluster, add a notifications schema, put a queue (likely SQS) in front to absorb write spikes. Known operational profile. Sharding required in the 10x scenario, but reversible.

Option B: DynamoDB

Stand up a new DynamoDB table for notifications. Natural fit for the write-heavy, key-lookup, time-ordered access pattern. Scales transparently in the 10x scenario. Adds a second storage system the team has never operated. Cross-database queries to existing Postgres tables move into application code.

Option C: Postgres now, plan a Dynamo migration if and when the Slack deal closes

Hybrid. Defers the new-system learning curve until the volume actually arrives. Accepts a 3-6 week migration project in the future as an explicit, scheduled cost.

Criteria

In priority order:

1. Operational safety for the on-call rotation. A four-person rotation cannot be on-call for two storage systems they cannot debug.
2. Cost of being wrong. Recoverable errors are preferred over diffuse, hard-to-roll-back errors.
3. Fit to the launch-day access pattern at 500K events/day.
4. Fit to the 10x scenario, weighted by the probability of that scenario.
5. Cross-system query cost with billing, analytics, and product reads that live in Postgres.

Decision

Adopt Option C: ship on Postgres with a queue. Pre-commit to a Dynamo migration project if and when the Slack deal closes.

Specifics:

• Notifications schema lands in the existing Postgres cluster behind an SQS queue. Marcus owns the schema design and queue integration. Target: in production by 2026-06-15.
• A trigger condition is defined now, not later: if Slack-partnership volume puts us above 2M events/day on a 30-day rolling average, the Dynamo migration project begins the following sprint. Owner: Ana.
• The Dynamo design Marcus prototyped this week is preserved in the design-docs repo with a status of “deferred design, ready to revive.”
• The 4-person on-call rotation does not take on a second storage system at launch.

Reasoning

Option C scores best on criteria 1, 2, and 3. It scores worst on criterion 4 if the Slack deal lands, but the pre-committed trigger condition converts that worst case into a scheduled project rather than an emergency. Option B scores best on criterion 4 but worst on criterion 1, and the team agreed that operational safety for the on-call rotation was the right load-bearing constraint. Option A and Option C are structurally similar; the addition of the explicit trigger condition is what makes Option C honest rather than wishful.

The deciding factor was the recognition (Ana, in the Wednesday meeting) that the decision was really about how much we believe the Slack deal will close. At 60% confidence, the expected operational cost of running on Dynamo from day one is higher than the expected migration cost of moving to Dynamo later.

Open Questions

• Exact trigger threshold for the Dynamo migration: 2M events/day on a 30-day rolling average is the starting number; revisit at the 2026-Q3 architecture review with real volume data.
• Should the SQS queue be replaced with the existing internal event bus? Defer to Marcus’s schema design review.
• Who owns the Dynamo runbook drafting if the trigger fires? Owner unassigned; revisit when the Slack deal closes.

Telling stakeholders a committed feature is being cut this quarter

Context

At the start of Q3, Insights was committed as a Q3 deliverable - a real-time analytics dashboard surfacing product usage data. The commitment was made to the sales team as a close tool for several in-flight deals, and to key customers who had requested the capability explicitly. Two engineering teams were allocated.

In week seven of Q3, a mandatory billing-system migration - a compliance requirement triggered by a vendor contract change - overran its projected timeline by four weeks. Both teams were reassigned to prevent the billing system from entering an unsupported state before the contract deadline. Neither team could continue Insights work during that period. When the migration completed, six weeks remained in Q3. Completing Insights to a stable, testable state required nine to ten weeks of remaining engineering work.

Options Considered

Three options were on the table as of August 19, once the migration overrun was clear:

1. Ship on the original Q3 date, with the export, filtering, and drill-down features incomplete.
2. Move Insights to Q1 with no interim deliverable.
3. Move Insights to Q1 and ship a CSV export of the underlying data in September, usable in a spreadsheet or BI tool.

Criteria

Three constraints governed the evaluation, in order of weight:

• Do not ship a partial product against a full promise. A half-built dashboard resets customer expectations downward.
• Provide something of value before year-end to the customers who waited. A pure deferral is harder to absorb than a deferral with interim capability.
• The interim capability must be low-risk. The team is stretched after the migration; a complex stopgap adds compounding risk.

Decision

Insights moves to Q1. A CSV export of the underlying data ships in September before Q3 closes.

Option 1 was eliminated: shipping a partial dashboard against a full-scope promise sets an expectation we cannot sustain. Option 2 was viable but left customers with nothing for two quarters. Option 3 is chosen because a CSV export is low-scope, low-risk, and genuinely useful. Customers who need the data can load it into a spreadsheet or BI tool and begin analysis now. It does not substitute for Insights, but it delivers the underlying data access that motivated the original request.

The migration overrun is the proximate cause of this change, not a shift in product priority. The reasoning behind the Q3 commitment was sound when it was made. The capacity that would have delivered Insights was consumed by a compliance dependency that could not itself be deferred.

Getting a new engineer productive in their first two weeks

Decision: Priya’s First Two Weeks

Status: Decided Date: 2026-06-26 Owner: Roshan Mehta (Engineering Lead)

Context

Priya started Monday on a team that ships a service-oriented backend daily and runs a rotating on-call schedule she will join in week four. She has solid fundamentals but has not touched our service mesh, deployment pipeline, or the ownership model that coordinates work across six engineers. Two weeks is a fixed window. Marco, her primary pair, has capacity for roughly three focused hours per day in week one, less in week two as a customer migration runs.

Options Considered

Option A: Self-directed ramp. Reading list, documentation, a service map, check-in at end of week one. Low team cost, high cost to Priya. Engineers ramping alone in a complex service topology accumulate gaps they don’t know they have.

Option B: Full-pair for two weeks. Marco shadows every PR in real time. Comprehensive, but his bandwidth drops in week two, and the result is often learned dependency rather than independence.

Option C: Structured sequence with a paired first change. Explicit milestones (access, walkthroughs, paired ticket) with named owners, anchored to a real shipped change by end of week two.

Criteria

1. She ships something real. A diff merged to main - the full deploy path navigated - is the threshold for genuine ramp completion.
2. Buddy cost must be sustainable. Exhausting Marco in week one risks cutting corners in week two when she needs him more.
3. She learns ownership, not just operation. An engineer who can deploy but cannot identify who to escalate to is unblocked only until the first incident.
4. She belongs, not just functions. Engineers who function but feel isolated start leaving by month three.

Decision

Option C. Week one: Marco runs morning walkthroughs, one service per day. Access and tooling are handled by the admin checklist in parallel. By Thursday, Priya and Marco pick a ticket together; Priya drives the scoping discussion. Week two: Priya drives the ticket; Marco is available but not reviewing every line before commit.

The load-bearing call is the specific paired change over open exploration. An open ramp leaves Priya knowing the codebase without knowing whether she can ship under real conditions. One merged diff closes that gap before on-call begins. It also gives her a social entry point: “I shipped X” reads differently than “I’ve been reading the docs.”

Marco’s involvement is front-loaded into week one mornings rather than distributed evenly - that matches where uncertainty is highest and keeps his bandwidth available in week two.

Open question logged now: who handles introductions to the other six engineers? Marco will not cover this during walkthroughs. Owner: Roshan. Due Monday of week two.

Writing to thank a mentor who shaped your career

Decision: Project Lead Assignment, Meridian Integration

Status: Decided - record written ten years after the fact Owner: Dana Chen (Senior Manager, Client Delivery) Stakeholder affected: One direct report, eight months into role

Context

In early 2026, a mid-scale client integration needed a lead: direct client relationship, cross-functional coordination, a deadline tied to an external commitment. I was eight months into the role. Several more experienced colleagues were available. I told you I did not feel ready. You acknowledged that and put my name forward anyway.

Options Considered

You could have taken the lead yourself, assigned Marcus (who had run two comparable projects without incident), or given me a bounded piece under someone else’s direction. Any of those would have been defensible. You chose the option with the highest short-term delivery risk and the highest development upside.

Criteria

I did not know the criteria at the time. I have reconstructed them by watching how you operated afterward, and more recently by making the same call about someone I manage.

As best I can recover them: (1) Could this person do the job with support, even if not yet without it? (2) Would the project survive the learning curve? (3) Would the investment compound across many future engagements, not only this one?

You were not optimizing for smoothest delivery.

Decision

You put my name forward. You attended the first client call and let me run it. When I made a structuring mistake in week three, you flagged it, explained the consequence, and left the correction to me. You were visible enough that I knew I was not alone. You were far enough back that I had to decide.

The project delivered. Whether it would have gone better under a different lead is not something I can measure. The version of me who came out the other side was not the version who went in.

---

I am writing this record because I recently sat in the corner of a conference room while someone I manage ran a difficult kickoff she told me she was not ready for. When it was over, she looked at me with the expression that means both “how did I do” and “why did you do this to me.”

I already knew what to say, Dana, because you had already written the answer.

Thank you for the decision. Thank you for the patience it cost you to stay close without taking over. The person who can now make that call for someone else was built in the project you gave me.

Reflecting on keeping a discipline of rest

Context

I have tried to hold a full rest day three times in the past two years. Each attempt collapsed within six weeks. The pattern was the same each time: the morning held, then something arrived - a message I would only glance at, a task I could finish in twenty minutes - and the day became a lighter version of a work day.

What is prompting a fourth attempt is not renewed conviction but observation. The weeks without a rest day are not producing more output. On the two occasions this year when I held the full day, the following week felt reoriented - clearer to begin, steadier to sustain. Whether that pattern holds at scale is not yet known.

The pull to produce is real and not going away. Unscheduled time reads as waste to the part of me trained to measure days by output. Rest can feel anxious before it feels restful, and I expect that to be true for a while. I am deciding within those conditions, not waiting for them to resolve.

Options Considered

Continue without a rest day. Familiar and low-friction. The cost is what I have already observed: hours accumulate, return diminishes, and the week does not recover its edge before the next one begins.

A partial measure with one permitted check. I have tried this variant. One permitted check reliably becomes several. A partial rest day tends to expand or compress depending on what is pending. The partial version has not functioned as rest; it has functioned as a delayed start.

A full day held as a complete boundary. No task management, no notifications, no single permitted exception. The version I have not yet sustained past six weeks.

Criteria

What mattered in evaluating the options:

• Whether the practice would function as actual rest, or as anxiety management under a different label
• Whether withheld time returns anything in the following week’s quality, or is simply absent
• Whether the chosen version could hold given that willpower-only approaches have failed repeatedly

Decision

Committing to a full rest day, held weekly, beginning this week.

The reasoning: the partial version has failed consistently by the same mechanism. One permitted check is not a bug I can patch; it is structural to the partial design. The full boundary is harder to begin and has shown signs of functioning as intended on the occasions I held it.

I do not know whether the return I have noticed - the reorientation, the steadiness that carried into the days that followed - will hold reliably at scale. What I know is that the partial approach has a documented failure mode and this version has not been given a genuine trial.

The cost is real. Some things will wait. The wager is that what waits will be handled better than what was done in exhaustion.

Marking a long-serving colleague's departure

Tribute for Howard Liang - What This Document Will and Will Not Do

Context

Howard has been with us for twenty-six years. For most of that time he held the same role, not because advancement was unavailable but because leaving the work would have meant leaving the people who needed it. He was not formally designated as institutional memory; he became it. Several careers on this team exist in their current form because Howard made a quiet choice at a critical moment - the project that almost stalled in year two, the new hire who almost quit in month three. He retires at the end of this month. We are deciding how to mark it.

Options considered

• A formal presentation summarizing his tenure: titles held, projects shipped, years of service
• A team gathering with standard retirement messaging and a collected gift
• A written tribute organized around specific concrete moments rather than an accomplishment inventory
• Individual notes solicited from colleagues and published without editorial curation

Criteria

Howard has never sought recognition. In twenty-six years he has not once forwarded praise to his manager or copied the right people on a note he deserved credit for. A ceremony organized around what he accomplished would likely embarrass him and would certainly miss the point. What we are honoring is not the output but the character that produced it - the willingness to stay late when it was someone else’s deadline, to remember what everyone else had forgotten, to be the person you called when the ticket tracker was down and the client was watching. The right tribute is legible to colleagues who were in the room and to people who benefited from Howard’s influence without knowing his name.

Decision

We write the tribute around specific moments, not a summary. Not “Howard mentored many people” but the afternoon he spent in a conference room with a junior analyst walking through a model she had built wrong, line by line, until she understood why, not just what to fix. Not “Howard had deep institutional memory” but the Thursday morning when the data pipeline failed and Howard was the only person who remembered where the backup access credentials were documented, and who had the system restored before the nine o’clock standup.

A career summary would be accurate. It would also be wrong. Howard spent twenty-six years making other people’s work legible to the people who needed to understand it. The tribute should do the same for him.

Marking the team shipping a hard, long project

Milestone Record: Checkout Rebuild - Project Meridian Closed

Date of record: November 14, 2024 Project: Checkout system rebuild (codename: Meridian) Authors: Maya Reyes (team lead), with contributions from Sam Chen and Dev Nakamura

---

Context

The checkout system that Meridian replaced was seven years old, written before the current payment processor existed, and maintained by accretion rather than design. Cart abandonment had grown to a rate that required explanation in every planning cycle. Internal analysis traced the largest contributor to friction in the address and payment confirmation steps, both places where the old system had accumulated conflicting state.

In September 2022, leadership chose to rebuild rather than patch. That choice is recorded in the original project charter. This record marks the decisions made during the rebuild - the turns that determined whether it shipped and in what condition.

Options at the critical turns

Near-miss one (month four): schema migration. The new system required a breaking change to the order-state schema. The options on the table: migrate all historical records and block launch; run dual schemas indefinitely; accept a translation layer for records before a cutoff date. Dev Nakamura surfaced a fourth option - a read-time shim with asynchronous backfill. This was not in the original design and required the team to carry it through six months of parallel operation before it could be retired.

Near-miss two (month nine): payment gateway behavior mismatch. The payment processor’s sandbox diverged from its production behavior on timeout handling. Options: delay integration testing until production access was confirmed; mock the divergent behavior and document the known gap; pursue early production access through a vendor escalation. Sam Chen made the call to escalate. It took six weeks and consumed team capacity at a difficult moment. It also eliminated a class of unknown failure before launch.

Launch slips (months eleven and thirteen). The team slipped twice. Both times the stated reason was the same: the rollback path under partial rollout did not meet the standard the team had committed to. The standard: rollback completable within fifteen minutes at any traffic split, by a single on-call engineer, without a secondary approval. That bar was not met until week two of month fourteen.

Criteria

Two constraints held throughout: the existing system could not degrade for customers already mid-flow during any transition, and the new system had to hold under the highest observed traffic in the prior year before full cutover was permitted.

Decision

The team held both constraints. The final rollout ran under peak load and held.

This record names what that cost: fourteen months of parallel maintenance, two near-misses absorbed by individuals rather than by process, and two launch slips made against real pressure to ship. Maya Reyes, Sam Chen, and Dev Nakamura named the options when naming them was uncomfortable. That is what this milestone marks.

Arguing a public position on return-to-office

Context

Two years of full remote operations are behind us. Leadership is split: roughly half want a return-to-office mandate to restore unplanned collaboration that diminished after the transition; the other half want to preserve remote flexibility for recruiting reach. A cohort hired in the last 18 months has never met colleagues in person. Office leases in three cities run through 2027; space is underused. We are deciding under genuine uncertainty.

Options considered

1. Full return to office - all team members in their regional office five days a week.
2. Fully flexible remote - no attendance requirements; presence self-directed.
3. Structured hybrid with anchor days - two or three shared in-office days required per week, the remainder flexible.
4. Minimum presence floor - a monthly in-office minimum with no fixed schedule.

Criteria

In rough order of weight:

• Trust and relationship formation, especially for the 18-month cohort with no in-person baseline
• Talent acquisition reach beyond the three office cities
• Coordination quality in high-ambiguity work, harder to sustain across sequential async exchanges
• Policy simplicity - something managers can apply without per-team negotiation

Decision

Structured hybrid with anchor days.

The deciding factor is the pairing of trust formation and coordination quality. A monthly presence floor does not guarantee that any two people are in the office on the same day; it optimizes for personal flexibility rather than collective overlap - and collective overlap is what is missing.

Full return to office was set aside because it forecloses talent outside the three cities and reverses a working model many people built their lives around. The causal link between full presence and better team outcomes is frequently asserted but undemonstrated in our context.

Fully flexible remote was set aside not because remote is ineffective for focused individual work - it is - but because it leaves relationship formation entirely to individual initiative. Newer hires have no guaranteed structure for building the working relationships they will depend on under pressure.

The minimum presence floor was set aside because, unless high enough to guarantee same-day overlap, it adds compliance overhead without solving the coordination problem.

The anchor-day model accepts real costs: commuting on set days regardless of task load, and a narrower talent pool than fully remote. We accept those costs because two years of waiting for spontaneous in-person connection to emerge has not produced it.

This record does not predict that hybrid will outperform any alternative. It is the arrangement that, given current context and what we know now, best balances the criteria named above. If conditions shift materially, this log is here to help re-evaluate whether the reasoning still holds.

Announcing a new product to an outside audience

Context

Small product teams - early-stage companies without a dedicated product manager - typically manage customer feedback across three or more tools simultaneously: a chat tool for inbound messages, a ticket tracker for engineering requests, and a spreadsheet where someone collects and loosely ranks what keeps coming up. The person responsible for the roadmap rebuilds that spreadsheet by hand each planning cycle, pulling from scattered sources and making priority calls without a shared record of the reasoning. When pressed on why an item ranked where it did, the answer is typically “we kept hearing it” - a memory, not a record. The output that gets shared with stakeholders is a list, not a ranked roadmap with the feedback behind it.

There is no shortage of feedback. The problem is that it lives in fragments, and no existing tool was built specifically to collect those fragments, rank them, and produce a shareable output with the reasoning visible.

Options

Three approaches were on the table during product definition.

Integration layer on existing trackers. Add ranking fields to whatever ticket tracker the team already uses. This meets teams where they are, but leaves the output fragmented inside the tracker - nothing produces a roadmap that can be shared and explained outside the tool.

Full analytics platform. Ingest raw feedback data, apply quantitative scoring, and output weighted priority lists. More rigorous, but requires structured input most small teams do not have. The setup cost was disproportionate for the team size this was built for.

Lightweight intake-and-ranking product. Accept feedback from any source as freeform input, surface recurring themes, let the team rank and weight them, and export a shareable roadmap. Low setup friction, works regardless of existing tooling. The risk: teams may resist adding a new tool, so the output value has to justify the switch.

Criteria

Two constraints governed the evaluation: the tool must work without clean structured data as a prerequisite, and it must produce output a team can share with a non-technical stakeholder without a walk-through. A secondary goal was to keep setup friction low enough for a team that does not have a dedicated PM.

Decision

We built the third option. The integration approach did not solve the output problem - stakeholders still received a ticket list, not a roadmap. The analytics platform addressed rigor but not accessibility; it was built for teams with data pipelines, not teams with a folder of customer notes.

Tidemark is the lightweight option. Paste or import feedback from wherever it lives, surface what keeps appearing, rank the clusters against each other, and export a roadmap that shows priority alongside the feedback behind it. It launches next week. Teams can sign up at tidemark.io.

A personal year-end reckoning with a difficult year

Context

December 2024. A project I had been building with Marisol and two others ended in October without the outcome any of us wanted. The timeline broke and the runway ran out before traction arrived. The working partnership with Marisol ended six weeks after that. I am not recording the full account here - the relationship changed in ways I did not choose, and the details do not belong in this record. What matters: two significant things ended in the same quarter, and I am writing this to document what I am choosing to carry forward, not to narrate the year.

Options considered

Three postures were actually on the table:

Continue as if continuity is the default. Pick up the strands that can be - contacts, ideas, work habits - and proceed. Momentum matters, and not everything broke.

Rest and reset before deciding. Treat the next several months as deliberate space and do not commit to new directions until the signal is clearer. Decisions made from depletion tend to compound problems.

Acknowledge the break explicitly and choose what to carry. Name what ended, name what I got wrong, and decide deliberately. The most expensive option in terms of what it requires sitting with.

Criteria

I needed a posture that would let me be honest about what happened without catastrophizing it, acknowledge my own errors specifically, and be in a position to do good work next year without pretending the ground had not shifted. I did not weight sentimentality. I did not weight any form of moving on that required misrepresenting what happened.

Decision

Option three. Not because it is the cleanest, but because each of the others required misrepresenting something to myself.

What I got wrong: I underestimated how much the project was carrying for me emotionally, which pushed late-stage decisions into a defensive register. With the relationship, I waited too long on a conversation I could see coming, and the waiting did not help either of us.

What I am carrying forward: the work was real. The relationship was real. Neither fact is undone by the endings. I am not choosing to assign meaning to the difficulty - I am choosing to carry what holds up under honest examination and leave the rest as it is.

This record exists so that if I return to this year later, I know what I was reasoning from at the time, not what I remember reasoning from.

Appears in diff-pairs

• decision-log vs executive-summary (varies style)