RFC (Request for Comments)

A design proposal circulated to invite critique before a decision is made.

RFC (Request for Comments)

An RFC (Request for Comments) is a structured proposal that circulates a design or change to a group of reviewers before any decision is finalized. Its defining characteristic is the open invitation: the author lays out a problem, proposes an approach, names the alternatives they considered, and explicitly asks readers to push back. Where an ADR records a settled choice, an RFC is the conversation that happens before one.

The format originated in the internet standards community, where IETF RFCs defined protocols through iterative public comment. Engineering teams borrowed the pattern to coordinate changes that are too consequential to decide unilaterally - a new API contract, a major refactor, a shift in technical direction. The RFC disciplines the proposal author to write down their reasoning before reviewers can probe it, and gives reviewers a structured place to respond asynchronously.

Canonical template

# RFC-NNNN: [Proposal Title]

## Status
[Draft | Under Review | Accepted | Rejected | Withdrawn | Superseded by RFC-NNNN]

## Author(s)
[Name(s), date]

## Problem
[What is broken, missing, or needed. Why this matters now.]

## Proposed Approach
[What you are proposing. Be specific enough that a reviewer can push back on the details.]

## Alternatives Considered
[Other approaches evaluated and why they were not chosen.]

## Open Questions
[What the author is uncertain about and wants reviewer input on.]

## Consequences
[What this change costs, enables, or forecloses if accepted.]

When to use

Proposing a significant technical or design change that requires team alignment before work begins, coordinating cross-team decisions where multiple stakeholders need to be heard before a direction is set, changes consequential enough to deserve structured written critique while still open to revision, surfacing objections early when the design is still cheap to change.

When not to use

When a decision has already been made and needs to be recorded (write an ADR instead), urgent changes that cannot wait for a comment period, small easily reversible decisions that do not warrant structured review.

Pairs well with

pragmatic-architect, senior-consultant, candid, diplomatic, problem-solution, dialectic

Often confused with

adr: An ADR records a decision already made and explains the reasoning behind it. An RFC is the proposal that precedes the decision - it is still open to revision and asks reviewers whether the proposed approach is the right one.

prd: A PRD specifies what to build and defines requirements for an execution team. An RFC proposes how to approach a design challenge and asks peers to evaluate that approach. The PRD is an input to engineering work; the RFC is a checkpoint before committing to a direction.

design-doc: A design doc is the implementation specification for something already being built - it answers “how exactly will this work?” An RFC is a comment-seeking proposal for a design direction that explicitly invites pushback before a decision is finalized. Their templates look alike: both have a problem statement, a proposed approach, and alternatives. The line is purpose and timing - an RFC asks “should we go this direction?”; a design doc answers “here is how we are going.”

Tells

• An explicit Status line that tracks the proposal lifecycle (Draft, Under Review, Accepted, Rejected, Withdrawn)
• An Open Questions section that names what the author is genuinely uncertain about and wants reviewer input on
• An Alternatives Considered section that records what was evaluated and why it was not chosen
• A Problem section that frames the gap or failure before the solution appears
• An author byline with date, marking it as a time-bound proposal and not a standing document
• Language that actively invites disagreement rather than presenting a finished position

Anti-patterns

• Writing the RFC as a fait accompli - no open questions, no real alternatives, and a Proposed Approach that reads like an announcement - An RFC without genuine openness is theater; if the decision is already made, write an ADR. Using an RFC form to manufacture the appearance of consultation corrodes reviewer trust.
• Skipping the Alternatives Considered section or listing only one throwaway alternative - Alternatives Considered is the core evidence that the author did comparative thinking; without it, reviewers cannot tell whether the proposed approach was chosen deliberately or defaulted to.
• Treating the RFC as a PRD by writing requirements and acceptance criteria instead of a design proposal open to critique - A PRD specifies what to build for an execution team; an RFC proposes an approach and asks peers whether it is the right one. Mixing the two makes the document unusable for either purpose.
• Leaving the RFC open indefinitely with no review deadline and no decision recorded - An RFC without a status update to close the loop becomes organizational clutter; the comment period needs a deadline and the author must update the status after review ends.

Failure modes

• Collapses into a question-dump - so many open questions and so little conviction that reviewers have nothing concrete to push back on - An RFC needs a real proposed approach, not just a problem description. Draft a concrete recommendation before opening for comment; open questions should be targeted uncertainties, not a substitute for having a position.
• Stretches into a permanent consultation - the comment period never closes, the status stays Draft, and the proposal never reaches a decision - Set a review deadline when the RFC is opened. After the deadline, synthesize feedback and update the status to Accepted, Rejected, or Withdrawn; an undecided RFC is an abandoned RFC.

Instruction

Write as an RFC (Request for Comments). Structure the document with these sections:
Problem, Proposed Approach, Alternatives Considered, Open Questions, and Consequences.
In Problem: frame what is broken, missing, or needed - do not lead with the solution.
In Proposed Approach: be specific enough that a reviewer can push back on the details.
In Alternatives Considered: honestly name what you evaluated and why you did not choose it;
one throwaway alternative is not enough. In Open Questions: name the things you are
genuinely uncertain about and want reviewer input on - these are invitations, not
weaknesses. The tone should be candid and diplomatic: the author has a position but is
genuinely open to being wrong. Do not write as if the decision is already made.

Template

See the RFC (Request for Comments) template.

Related

Pairs well with

Pragmatic Architect, Senior Consultant, Candid, Diplomatic, Problem-Solution, Dialectic

Avoid with

Urgent, Playful, Pastoral, Reverent

Often confused with

Architecture Decision Record, Product Requirements Document, Design Document

Examples

Whether the team should move to async-first standups

RFC-0012: Switch to Async-First Standup

Status

Under Review

Author(s)

Engineering Manager - opened for review after Q1 retrospective

Problem

Our current synchronous daily standup is a 9am Pacific meeting that all 11 engineers are expected to attend. The team has grown from 6 to 11 engineers over the past 18 months and now spans four timezones: US Pacific, US Eastern, UK, and India. That scheduling arithmetic does not work.

For our three India-based engineers, 9am Pacific is 9:30pm IST. Q1 attendance data confirms the effect: India engineers averaged 3.2 standup appearances per week out of 5; US-based engineers averaged 4.6. The shortfall is not disengagement. It is a timezone that makes a nightly meeting unsustainable.

Beyond the equity problem, the meeting produces little durable output. The standup averages 14 minutes. Analysis of the past month puts the content that changed someone’s behavior at roughly 4.2 minutes - a blocker raised, a dependency flagged, a context shared. The other 10 minutes is status that required no response from anyone. And even the useful 4.2 minutes disappears afterward: nothing is written down, nothing is searchable. In Q1 we documented three incidents where an engineer spent more than an hour on a problem that had already been discussed in a previous standup.

The problem is not that people are attending badly. The problem is that we designed a synchronous meeting for a team that is no longer synchronous.

Proposed Approach

Replace the daily synchronous standup with an async update posted to #team-standup by 10am each engineer’s local time.

The template would be three fields:

• Shipped: what completed in the last 24 hours
• In progress: current focus
• Blocked or at risk: anything that needs attention, with @mention of the person who can resolve it

The on-call engineer reads #team-standup once between 10am and 11am Pacific and responds to any blocked items within 30 minutes during business hours. On-call rotation stays the same - the responsibility shifts from running the meeting to monitoring the channel.

The 9am Pacific standup slot gets repurposed rather than eliminated. I am proposing a 60-minute Thursday working session in its place - explicitly not a status meeting, reserved for topics that need real-time exchange. If there is nothing on the agenda by Wednesday evening, we cancel.

Before committing permanently, I propose a 30-day trial starting from a date the team agrees on, with a retro at the end to decide whether to make the change permanent.

Alternatives Considered

Rotate the standup time. We could change the meeting time each week or each sprint to distribute the timezone burden more fairly. This addresses the equity problem but does not solve information persistence, and adds scheduling overhead on a team already managing cross-timezone calendar complexity. The India engineers still get a late-evening meeting every few weeks.

Eliminate standup entirely. The meeting is low-signal, so one response is to stop having it. I am not proposing this because some coordination value does persist - the “blocked” information in particular needs a home. The proposal preserves that signal while removing the synchronous overhead.

Adopt a purpose-built async standup tool (Geekbot or similar). Several tools automate async standup collection with reminders and digest formatting. I looked at Geekbot. The cost and the additional tooling layer did not seem worth it when Slack templates can serve the same function at zero marginal cost. If the Slack-native approach proves too manual to sustain, a dedicated tool is worth revisiting.

Keep the meeting and add a writeup requirement. Require engineers to post a written summary after the standup to address the persistence problem. This stacks more process on the existing burden rather than replacing it, and still does not solve the 9:30pm IST problem.

Open Questions

What is the right posting deadline? I proposed 10am local time, but I am not confident this works for every timezone. For UK engineers, 10am GMT means their posts arrive before the Pacific team is at their desks. Does that matter for coordination? Is there a structure - a window rather than a hard cutoff - that serves both IST and UK engineers better?

How do we prevent the Thursday session from becoming a second standup? My intent is a working session for topics that require real-time exchange, not a status meeting with a different name. What guardrails would actually hold for this team? Should we require a written agenda at least 24 hours in advance?

What does “trial succeeded” look like? 30 days is a guess, and I do not have clear criteria for what we would need to see before committing. Should we set participation-rate targets? Blocker resolution time? I want us to agree on the decision criteria before we start the trial, not after.

How much does the on-call monitoring role actually cost? I am estimating 10 to 15 minutes per morning to scan the channel and handle mentions. That estimate might be too low, especially in the first weeks when blockers are more likely to surface through an unfamiliar format. I would rather know that before locking in the on-call spec.

Consequences

If accepted:

Benefits: India-based engineers participate on a schedule that fits their timezone. Status information persists and is searchable, which addresses the duplicate-work incidents from Q1. Blocked items route directly via @mention rather than surfacing verbally in a meeting no one can search later. Engineers recover the time previously spent in synchronous status reporting.

Costs: Some social cohesion from daily shared presence is reduced. The Thursday session is a partial substitute but not an equivalent. The format depends on consistent participation - if engineers stop posting, the channel’s value drops for everyone. Blockers requiring nuanced discussion may be harder to surface through a three-field template than through a live conversation.

If rejected: The current format continues to impose a 9:30pm IST obligation on three engineers. That is the strongest argument for changing something, even if this specific proposal is wrong. If reviewers reject this approach, I am asking for a counter-proposal rather than a return to the status quo.

Designing a sustainable morning routine

RFC-001: Redesign the First Hour After Waking

Status

Accepted - decision recorded in ADR-001 (2026-05-14)

Author(s)

Me, 2026-05-07. Review requested from: spouse, accountability partner. Review deadline: 2026-05-13.

Problem

I wake at 6:30am and reach for my phone before my feet hit the floor. The first 45 minutes belong to Slack, email, and news. By the time family obligations begin at 7:30am - breakfast, school dropoff, lunches - I have already handed whatever focus I had to other people’s priorities. The 9am work day begins reactive, every day.

Three previous attempts at “just stop using my phone in the morning” each lasted four to six days. The pattern of failure is consistent: I removed a behavior without replacing it, and the vacuum filled back in. A prohibition is not a design. I need a designed replacement.

Why now: the afternoon energy slump that used to arrive around 3pm is appearing closer to noon. I have not changed my diet or sleep schedule. The most credible variable is how the first hour is spent. If I am wrong, a 30-day experiment will tell me.

Proposed Approach

A four-module sequence, executed in fixed order between 6:30am and 7:30am on weekdays:

1. Water - 8oz immediately on rising. Glass prepared on the nightstand the night before. No decision point.
2. Light - 10 minutes outside or by the largest available window. No screen counts as light.
3. Movement - 15 minutes. Walk, stretch, or a bodyweight set. Threshold is elevated heart rate, not performance.
4. Planning - 10 minutes with a paper notebook. Write the day’s top three by hand before touching any work tool.

The phone stays in the kitchen, face down, until the planning step ends or 7:30am arrives, whichever is later.

Total protocol time: about 40 minutes. The remaining 20 minutes before family obligations serve as buffer for getting dressed, coffee, and whatever the morning actually contains.

Initial commitment: 30 days. I am proposing 30 rather than 90 because a previous 90-day attempt at a similar protocol collapsed on day 11. Shorter cycles with explicit checkpoints are more trustworthy than longer horizons I have already demonstrated I cannot hold.

Alternatives Considered

Do nothing. Rejected. The current state is the problem, not a baseline worth preserving.

Wake earlier at 5:30am. Considered as a way to create more slack in the morning. Rejected as premature optimization. If the existing 6:30-7:30 window is being managed poorly, adding an earlier hour will likely be managed poorly in the same ways. Fix the hour you have before adding a new one.

Use a habit-tracking app. Considered for logging and reinforcement. Rejected because it requires a screen at a moment when the design is trying to stay screen-free. Paper logging fits the protocol’s logic better.

Unstructured “intentional hour” with no fixed sequence. Considered as a lighter-weight version - just the rule that the hour belongs to me before Slack claims it, with no prescribed modules. Rejected because the three previous failures were all in this mode. Structure, not intention alone, seems to be the missing ingredient.

Open Questions

I want explicit input from my spouse and accountability partner on these before I commit:

1. Spouse coffee window. The current morning dynamic has us in the kitchen together from around 6:45 to 7:15. The proposed protocol puts me outside for the light step during that window. Is this actually a conflict, or am I projecting? I need a direct answer from you before locking the schedule, not an assumption on my part.

2. Planning before or after movement? I have sequenced it as light - movement - planning, but I am genuinely uncertain whether planning works better as a pre-movement intention-setter or a post-movement clear-head activity. Accountability partner, you have run a similar protocol. What did you find?

3. Weekend scope. Should this protocol apply on weekends, or does adding weekends make it harder to hold on weekdays? My instinct is “same as weekdays,” but I recognize that is a high burden and might be the variable that causes a collapse in week three. Happy to be talked out of it.

4. Review threshold. What should the 30-day review actually evaluate? I want a concrete completion threshold named now, before I have any stake in the outcome. My draft: if fewer than 70 percent of weekday mornings are fully completed, escalate to a session with the accountability partner before changing any design detail. Does 70 percent sound like the right bar?

Consequences

If accepted:

• The first hour becomes proactive by design rather than reactive by default.
• I will miss early Slack messages from colleagues in earlier time zones. Risk accepted - genuine urgency can reach me by phone call.
• Bedtime will need to move. I am currently drifting to around 11:30pm. A 6:30am start with enough sleep behind it probably requires a 10:30pm target. That is its own behavior change, and this RFC is not solving it - only naming it.
• Family mornings may need a brief renegotiation, depending on the answer to Open Question 1.

If rejected or substantially revised:

• I go back to the design with feedback from this review, rather than defaulting to the status quo. A rejection from either reviewer is a useful answer, not a failure.

What this forecloses:

• Spontaneous early-morning availability before 7:30am. The protocol makes me unreachable by design during the first hour.
• The 90-day horizon I originally considered. I am choosing a shorter cycle. If either reviewer thinks 30 days is too short to produce a useful signal, raise it now.

Choosing Postgres vs DynamoDB for a new service

RFC-0041: Datastore Selection for the Lattice Notify Notification Service

Status

Under Review

Author(s)

Ana Rivera, 2026-05-12

Problem

Lattice Notify is building a notification service from scratch and needs a persistent datastore before we can begin the build sprint. The service will handle an estimated 500K notification events per day at launch - a write-heavy workload with point-lookups by user_id for delivery and fanout reads for inbox hydration. Two candidates are on the table: extend the existing Postgres cluster into a new notifications schema, or adopt DynamoDB for a closer access-pattern fit.

Both options have real advocates on the team. Marcus ran a DynamoDB spike this week (experiments/notify-ddb/) that confirmed it handles the access pattern well. The operational question is less settled. We need to align before Wednesday’s architecture meeting so sprint planning on Friday starts from a locked decision, not an open one.

The question is not which database is better in the abstract. It is which database fits the team’s operational reality, given that the growth scenario that most favors DynamoDB has not materialized yet.

Proposed Approach

Build the notification service on Postgres, using a new notifications schema in the existing primary cluster with a pg_notify + notification_jobs table job queue. Provision read replicas to absorb fanout reads. Document a revisit threshold at 5M events/day sustained, at which the team evaluates a DynamoDB migration before scaling the Postgres path further.

Rationale:

Operational familiarity is load-bearing. The 4-person on-call rotation has existing runbooks, monitoring, and debugging experience on Postgres. Adding a second datastore adds a second runbook, a second monitoring surface, and a second set of debugging skills needed on-call. We have measured this cost in a prior workstream and it is not small.

The growth scenario driving the DynamoDB argument is uncertain. The 10x projection at 12 months depends on the Slack-partnership deal closing. Designing for a scenario that has not arrived, at the cost of operational complexity that lands immediately, seems like the wrong trade.

The asymmetry of reversibility is smaller than it looks. If we choose Postgres and outgrow it, the rework is 3-6 weeks. If we choose DynamoDB and find we need cross-database joins for product features, the rework is similar in size, plus we have built operational muscle on a platform we may not keep. Neither choice is a trap; both are recoverable.

Cross-database queries stay simple. Joining notifications to users, accounts, and workspaces is a real product requirement. On Postgres, that is SQL. On DynamoDB, it moves to the application layer.

Alternatives Considered

DynamoDB. The access-pattern argument is real. Marcus’s spike confirmed DynamoDB handles write-heavy, point-lookup-by-user workloads well, which is exactly our pattern. My counterargument is not that DynamoDB is wrong in principle - it is that the team has no production DynamoDB experience, no existing runbook, and the on-call rotation absorbs a new surface at launch. I would weight the access-pattern argument more heavily if the growth projection were certain. It is not.

Postgres on a dedicated cluster. Rather than sharing the monolith cluster, we could provision a separate Postgres instance to avoid coupling. I do not recommend this now. It adds the same operational complexity as a new datastore (a cluster to provision, monitor, and operate) without the access-pattern benefit. Worth revisiting at the 5M events/day threshold if we decide to isolate the service.

In-process queue with no persistent store. Rejected early in the spike. The notification service needs durability and a replay path for delivery failures. An in-process queue has no recovery story if the service restarts.

Open Questions

1. Revisit threshold definition. I have proposed 5M events/day as the migration trigger. Is that the right signal, or should the threshold be tied to a latency metric like p99 write latency or queue drain time? Marcus, your spike gave you the closest read on where DynamoDB starts outperforming Postgres for this workload - would a throughput threshold miss early warning signs?

2. Cross-database join requirements in H2. My assumption is that joining notifications to users and workspaces will be a product requirement within 6 months. If that assumption is wrong, the access-pattern argument for DynamoDB gets stronger and I want to revisit this proposal. Priya, can you confirm whether the notification-to-workspace join is in the H2 product roadmap?

3. Read replica lag tolerance. The fanout read path will hit read replicas. Is replica lag acceptable for the notification inbox - that is, can a user see their notifications a few seconds after generation - or does the product behavior require immediate consistency? This affects whether read replicas are sufficient or whether we need a different read architecture on the Postgres path.

4. On-call cost quantification. I have described the second-datastore operational cost as non-trivial but have not expressed it in concrete terms. Jordan, is there a way to frame this in the decision record - hours per incident, runbook pages, something that gives the argument more weight than my prior experience?

Consequences

If this proposal is accepted:

• The notification service ships on familiar operational ground. Based on the team’s past migration work, the Postgres path is estimated to be 3 weeks faster to first production traffic than the DynamoDB path.
• Single operational surface for the on-call rotation. Existing monitoring and runbooks apply. No new debugging context needed at 2am.
• Cross-database queries stay SQL. No application-layer join logic introduced at launch.
• Known future work lands on the roadmap, not in a drawer: Postgres partitioning and job queue tuning at the 3-5M events/day range. Ana owns this; it is currently projected for Q4 if growth tracks.
• The decision is recoverable. If the Slack-partnership deal closes and growth accelerates faster than the 12-month projection, the 5M events/day threshold gives the team a planned migration window with 30-day notice from Priya.

If this proposal is rejected in favor of DynamoDB:

• Access-pattern fit improves at the cost of operational unfamiliarity. The first 6 months on-call will have a steeper learning curve.
• A rollback plan is needed before the service reaches production. There is not one yet.
• Cross-database join logic moves to the application layer. This will surface as product complexity when the notification-to-workspace requirement lands.

Telling stakeholders a committed feature is being cut this quarter

RFC-0031: Defer Insights Dashboard to Q1; Ship CSV Export as Q3 Stopgap

Status

Under Review

Author(s)

Maya Chen, Product Lead - September 8, 2026

Problem

The team entered Q3 with a firm commitment to ship the Insights analytics dashboard by September 30. Three key enterprise customers received delivery dates and Sales has been using the Q3 commitment as a closing point for at least one additional account.

In early Q3, the mandatory billing-system migration surfaced scope that was not visible during Q3 planning. The migration is non-optional: regulatory and contract dependencies require it to complete before year-end. Current estimates put the migration engineering work at consuming the capacity block originally reserved for Insights. Both projects cannot share that capacity without putting both deliverables at risk.

At the same time, the Insights build is not in a state that could ship to customers without harm. The two capabilities customers specifically asked for - saved-view persistence and scheduled-report delivery - are not complete. Shipping the dashboard now would deliver a product that fails at the exact use cases that were sold.

We need to decide how to allocate remaining Q3 capacity, what to tell customers, and whether a stopgap can reduce the cost of the delay.

Proposed Approach

Defer the Insights dashboard to Q1 2027, targeting March 13. Complete the billing-system migration cleanly in Q3. Ship a CSV export of the Insights data layer before September 30, giving customers access to their underlying event data while the full dashboard is under development.

Delivery timeline under this proposal:

• CSV export backend endpoint: September 19 target. Owner: Dario Reyes (engineering).
• CSV export frontend integration and QA: September 24 target.
• CSV export release: September 26 target.
• Billing migration production release: week of September 19.
• Direct written notice to the four key accounts: this week. Individual calls for accounts with hard dependencies on the Q3 date. Owner: Jordan Park (customer success).

The Q1 Insights scope is frozen at the current committed spec: the full dashboard with saved views, scheduled reports, and the six views originally planned. Scope change requests received during the deferral period are queued for Q1 planning and are not folded in silently.

Alternatives Considered

Ship Insights on the Q3 date in its current state. The build is missing saved-view persistence and scheduled-report delivery. These are the two capabilities that were sold to enterprise customers. Shipping without them delivers a product that fails at the use cases it was promised for. We would face immediate trust damage, and rework against a live product with real customer data is more expensive than a delay negotiated before release.

Split engineering to work both projects in parallel. The billing migration has a sequential critical path; the capacity-intensive work cannot be parallelized with Insights development without significant handoff risk and context-switching overhead. A split approach would extend both timelines and put both deliverables at risk. The migration has a hard year-end deadline.

Delay the billing migration and keep Insights on schedule. The migration is non-optional. Regulatory and contract dependencies require completion before year-end. This option does not exist.

Open Questions

1. Is the CSV export sufficient for the three customers who were given a Q3 delivery date? Jordan Park should confirm whether any of them has a hard contractual or operational dependency on the in-app dashboard specifically, not just the underlying data. If one does, that shapes the outreach and may require a different commitment than “access to your data via CSV.” This needs an answer before the notices go out, not after.

2. Can Q1 capacity be confirmed in time to put a hard date in customer communications? March 13, 2027 is a directional target. The Q1 capacity plan does not close until Q4 planning. Telling customers “March 13” carries commitment weight we may not be able to back yet. Should we offer a range, or hold the specific date until Q4 planning confirms it? If we defer the date, we should say so explicitly, not leave it vague.

3. Who owns the customer-facing message? Engineering can provide a technical facts sheet: what was committed, what changed, what ships by September 30, and what ships in Q1. Sales and customer success should own the words that go to customers and the tone of each conversation. This RFC proposes the path and the stopgap; it does not propose the message. A separate brief should cover customer communication and I am not the right author for it.

4. Should any Insights scope additions be considered now, while the deferral window is open? My recommendation is no: freeze the spec and ship what was committed. But if Sales has accounts that will only accept the delay with a specific addition to the Q1 scope, that should surface now, not in Q4 planning.

Consequences

Accepting this proposal means no half-built dashboard ships in Q3. The committed spec - saved views, scheduled reports, the six originally planned views - ships in Q1. The billing migration completes without competing capacity pressure, reducing defect risk from context switching. Customers get access to their underlying event data before September 30 via CSV export, with no installation or onboarding step required.

The costs are real and should be named directly. Three customers who were given a Q3 delivery date will need direct communication. Trust was set on a commitment that is now being broken, and a CSV export does not substitute for the dashboard those customers were sold. The repair is in the honesty of the communication, not in the stopgap itself. The Q1 target is also directional until Q4 planning closes; it should not appear in customer-facing communications as a hard date until capacity is confirmed.

If this proposal is not accepted and Insights ships on the Q3 date in its current state, the billing migration absorbs competing capacity pressure, increasing defect risk from a divided workstream. Customers receive a dashboard missing the two features they specifically requested.

In either direction, customer communication needs to happen this week. The window to manage this proactively is closing.

Getting a new engineer productive in their first two weeks

RFC-0012: Structured Two-Week Onboarding Protocol for New Backend Engineers

Status

Under Review

Author(s)

Mei (onboarding DRI), June 9

Problem

The backend services team has no written onboarding protocol. When a new engineer joins, onboarding happens informally: a buddy is assigned the morning the new hire arrives, access requests are filed reactively as gaps surface, and the first meaningful contribution happens when it happens - typically week three or four.

This produces two failure modes we have seen repeat:

Access and tooling gaps cause invisible blocking. New hires spend their first week solving environment problems independently. They feel blocked but are reluctant to interrupt teammates who are visibly busy. The buddy does not know what to check because no checklist exists. The silence reads as self-sufficiency; it is usually not.

The belonging question gets answered by default. Whether a new hire feels they are actually on the team - not just near it - is mostly decided in the first two weeks. Leaving that window unstructured means it closes on whatever impressions accumulated by chance.

A third factor makes this urgent now: Priya is joining June 22. We have twelve days to put something in place before her first day. The informal approach has worked well enough that we have not felt pressure to change it, but we have also been lucky. Three engineers in the last eighteen months who reported slow starts said the same things: unclear expectations, uncertainty about whether they were blocking anyone by asking questions, and no sense of a structured path through the first two weeks.

Proposed Approach

Establish a written two-week onboarding protocol with three components:

1. Access and tooling checklist (Days 1-2). A named buddy owns a checklist covering source control org membership, VPN and SSO setup, CI/CD pipeline access, observability platform, on-call rotation viewer, secret manager read access for staging, and the relevant chat channels. No item is considered done until the new hire has verified it personally. The buddy files outstanding requests on Day 1 and does not wait for the new hire to notice gaps.

2. Codebase orientation (Week 1). Two structured walkthroughs scheduled before the start date: one on service topology and ownership, one on deployment and on-call tooling. The new hire keeps their own notes. A Friday check-in at end of week one confirms whether they can navigate the codebase independently and whether anything is still blocked.

3. Pre-scoped first change (Week 2). The team selects the first change before the new hire’s start date. Scope constraints: one service, one data model, no on-call risk if the change goes wrong. The new hire drives and does the deploy. The buddy reviews and pairs on blockers. The point is that the new hire’s name is in the deployment log before the two-week window closes.

The buddy’s load is real: roughly 30-40% capacity in week one, 15-20% in week two. Sprint planning must account for this or the protocol fails before it starts.

Alternatives Considered

Unstructured pairing (“sit with someone and absorb”). This is what we do now. It places the entire burden of structure on the relationship between the new hire and whoever is available that day. It also asks the new hire to self-identify what they need, which they cannot do reliably in the first week because they do not yet know what they do not know.

Fully written runbook with no paired walkthroughs. A runbook handles access and tooling questions but does not transfer system intuition. The two 90-minute walkthroughs in the proposed approach do something a doc cannot: they show the new hire how an experienced engineer actually moves through the system. That is not written down anywhere, and cannot be.

Assign onboarding to the tech lead instead of a peer buddy. This concentrates the load on the highest-leverage person on the team. A peer buddy carries the cost at lower opportunity cost and creates a more lateral relationship. Peer-to-peer onboarding also gives the new hire someone they can ask “is this obvious?” without worrying about signaling weakness to a senior evaluator.

No pre-scoped first change; let it emerge from sprint planning. The risk is that week two ends without a ship. Sprint planning under normal pressure tends to route easier work to engineers already calibrated on the codebase. A new hire will be passed over - not because anyone intends it, but because it is faster. Pre-scoping forces that coordination to happen in advance, when there is no sprint pressure on the table.

Open Questions

1. Who maintains the checklist between cohorts? I am proposing the onboarding DRI as the owner, updating it after each new hire completes the protocol. Is that the right home, or should it live with the engineering manager?

2. How do we handle buddy capacity in sprint estimation? I have rough figures (30-40% week one, 15-20% week two), but these are not sourced from our team specifically. Should we formalize a reduction factor, or handle it per-sprint at planning? I want Arjun’s read on this, since he has seen both sides of the buddy role.

3. What is the right scope constraint for the first change? “One service, one data model, no on-call risk” is my first pass, but I am uncertain whether this is too narrow (leaves too little to pick from in the backlog) or too loose (still allows changes that create noise if they go wrong). I want pushback from people who know the current backlog shape.

4. Does the Friday check-in need a structured format? A set of specific questions - can you navigate the codebase independently, is anything still blocked, do you know who to ask for what - might surface things a freeform conversation lets slide. But it might also feel like an evaluation at the end of week one. Thoughts on this tradeoff?

Consequences

If accepted and followed:

• New hires have a named owner for access and tooling from Day 1. Gaps do not fall into silence.
• Sprint planning has an explicit capacity model for onboarding weeks. Velocity estimates are honest rather than optimistic.
• Every new engineer ships something before the two-week window closes. That fact changes how the team perceives them and how they perceive themselves.
• The belonging question gets a designed answer rather than a default one.

Costs and risks:

• The buddy load is real. If sprint planning does not protect buddy capacity, the buddy absorbs the cost invisibly and resents it. The protocol only works if the team commits to this in advance.
• Pre-scoping the first change requires coordination that can be skipped under pressure. If the task is not ready on Day 1, the week-two structure collapses and we fall back to informal.
• The protocol creates a named onboarding DRI role. Someone has to maintain the checklist, coordinate the buddy assignment, and run the Friday check-in. If that role is not clearly assigned before each new hire arrives, the protocol degrades into a document no one updates.

Review deadline: Please comment by June 16. I will synthesize feedback and update the status to Accepted or Withdrawn by June 18, ahead of Priya’s June 22 start date.

Writing to thank a mentor who shaped your career

RFC-0001: Adopt Put-Forward-Before-Ready as a Team Development Standard

Status

Draft - Under Review. Comment period closes June 2026. Decision to follow.

Author(s)

Sable Marchetti, June 2026

Reviewers requested: Dana Forsythe (originator of the practice described here) and current team leads.

Problem

Our team has no shared standard for how to develop people who are not yet ready for the scope they need in order to grow.

The gap appears like this: someone is ready to lead at a scale they have never led at. We know this because we work with them daily and we can see the aptitude. But they have no track record at that scope, so the conventional answer is to wait - assign them something smaller, let them prove it, then offer the larger thing. By the time the track record is built, the window for the formative experience has often closed or the person has moved on.

The alternative - assign the large thing before they feel ready - looks risky from the outside and requires the sponsor to absorb significant reputational exposure. So it does not happen systematically. It happens when a specific person, with a specific combination of courage and patience, decides to take that risk for a specific individual.

I have observed this approach used on me once, and I have used it once since. Both times it worked. I do not want it to remain something that happens by accident when the right senior person happens to be paying attention.

The case of observing it: Dana Forsythe nominated me to lead the Alderton platform migration in March 2016. I was not ready. I told her so. She nominated me anyway, stayed close for the following six months, and did not take back the work when I struggled. The project shipped. What that experience produced in me - a working model of how to lead under real stakes rather than simulated ones - has continued to compound for ten years.

The case of applying it: in February of this year I nominated Priya Osei to lead the Cassava data-pipeline rebuild. By June she is four weeks ahead of the original schedule. When I was writing her mid-year review, I recognized the shape of what I had given her: it was borrowed from Dana and the Alderton migration. I had just never written it down.

That is the problem. The method works. It is not written down. It is not shared. It depends on individual judgment to appear, and it disappears when those individuals leave or shift focus.

Proposed Approach

Adopt the following as a named practice for team development:

Put-Forward-Before-Ready (PFBR)

When a team member demonstrates aptitude for scope beyond their current track record, the nominating lead puts them forward for that scope before the member feels ready, with the following commitments:

1. The lead nominates fully - not as a co-lead arrangement that dilutes real accountability, but as the primary lead on the engagement.
2. The lead stays close for the first significant phase (for a six-month project, roughly the first two months) - available for questions, redirecting thinking without substituting judgment.
3. The lead does not take back the work. If the member is genuinely stuck, the lead names what they are not seeing; they do not solve it for them.
4. Correction happens privately, after the fact, not publicly during.
5. The lead accepts the reputational exposure. If the project fails, the lead owns the nomination.

This proposal asks the team to treat PFBR as a named, shared commitment rather than an individual inclination. Leads who use it document when they have applied it. We track the outcomes.

Alternatives Considered

Wait until track record is established (current default). The person earns the next scope level by succeeding at a smaller scope first. Safe from a risk-management standpoint; forecloses the growth path that only real stakes can open. Not chosen because the experience that produces aptitude for large scope is not available at small scope.

Co-lead arrangement. The person receives the title and exposure without full accountability. This is what I would have been given if Dana had not put me forward fully. I would have learned to consult and carry, not to decide and own. The result would have been a more confident mid-level, not a lead. Not chosen because splitting the accountability undermines the developmental mechanism.

Structured mentorship programs and simulated projects. Formal programs with defined timelines, training curricula, and practice environments. Not chosen not because these are bad, but because they are not a substitute for what PFBR produces. A simulation does not cost anything to the person running it. That is both its appeal and its limit.

Open Questions

These are the uncertainties I want reviewer input on before this becomes a standing practice.

For Dana specifically: The characterization above is my reconstruction of what you did in 2016, filtered through ten years and one application. I want to know where I have gotten it wrong. The method only works if the core commitments are right. Where does this reconstruction diverge from what you were actually doing?

For all reviewers: What does “stay close without taking over” look like when lead and nominated person are not in the same location or time zone? The Alderton migration was largely on-site. The Cassava rebuild was hybrid. I improvised a version of the practice for distributed work, but I do not know whether what I improvised preserved the mechanism.

Calibration: How do we distinguish “not ready but close” from “genuinely not ready in ways that matter”? I used intuition in February. That is not a repeatable standard. What signals are we actually reading when we make that call, and can we name them?

Documentation burden: If leads document when they have applied PFBR and track outcomes, how do we prevent that from becoming a checkbox exercise that substitutes the paperwork for the judgment?

Consequences

If accepted:

• Team leads take on explicit reputational exposure when they nominate someone under PFBR. This is a real cost. It is also the mechanism - the exposure is what makes the nomination credible to the organization and to the person being nominated.
• We create shared vocabulary for a practice that currently depends on individual inclination. That makes it teachable, discussable, and improvable over time.
• Team members who are not quite ready for larger scope have a named pathway, not an opaque wait.

If rejected or deferred:

• The practice continues to exist, unevenly, when specific individuals choose to apply it. That is not nothing - it is what produced the outcomes described here. But it forecloses the organizational learning that comes from naming and tracking the pattern.

What this forecloses:

• The default of “prove it at smaller scale first” as the primary development mechanism. That default is comfortable and low-exposure for leads. It also systematically undertaps people with high aptitude who develop through challenge rather than through sequence.

---

This RFC is also a thank-you to Dana Forsythe, who applied this method to me in 2016 without naming it, and who I am asking to review it now. If this proposal is accepted and the practice carries forward, the record will show where it came from.

Reflecting on keeping a discipline of rest

RFC-0001: Restart a Weekly Rest Practice - One Full Day, One in Seven

Status

Under Review

Author(s)

Self - March 2026

Problem

The current pattern - working across all seven days, with continuous availability as the default posture - is producing diminishing returns I can now observe clearly enough to name.

The evidence is not dramatic. Decisions that should be straightforward take longer. Analysis I completed earlier in a working stretch gets repeated, as if I had not done it. Patience for difficult problems narrows noticeably by the end of a long run. When I compare weeks where I worked continuously to weeks where I did not, the quality of judgment is measurably different - not in how I feel, but in how the work actually goes.

I have tried a version of this before. The first attempt ran six weeks before a project deadline pulled it under. I told myself I would restart when things settled. They did not settle. Eleven months passed.

I am not proposing this because I feel ready or because conditions are favorable. I am proposing it because the cost of not having a structured rest practice is now visible, and I have been able to name it.

Proposed Approach

Commit to one full day of rest each week - one in seven - on a fixed day (Sunday). The day is defined by what it is not:

• No work output
• No task completion
• No checking of messages or notifications
• No low-level monitoring of the queue

This is not a lighter workday. It is a structurally different kind of day.

The phone goes away the evening before (Saturday night) and does not return until the following morning. The exact window is negotiable - I propose starting with a minimum of four hours completely offline and extending from there based on what I learn in the early weeks.

The practice does not prescribe what to do with the day. It only defines what is off limits. What happens in the space is secondary to whether the space holds.

If I break the practice, I restart. No extended pause, no waiting for the right conditions.

Alternatives Considered

Continue the current pattern, accepting the degradation as a cost of staying current. This is what I have been doing by default. The cost is now named and visible, which is the only reason it qualifies as a considered alternative rather than just an ongoing situation. I am not recommending it.

Micro-recovery: capped evenings, shorter Saturdays, earlier daily cutoffs. I have had versions of this in place for several months. The pattern degradation described in the Problem section happened alongside these adjustments - they were not sufficient. A threshold effect appears to be real: partial rest does not produce the same return as complete rest. This alternative stays on the table as a complement to a full rest day, not a substitute for one.

A half-day practice rather than a full day. A half day is less costly on paper. The risk is that a half day still requires an in-the-moment decision about when to start and when to stop, and those decisions will happen when the pull to extend work is strongest. A full day with a clear boundary is easier to hold than a partial day with a negotiated boundary.

More frequent shorter rests - a capped Saturday plus an earlier Sunday morning. This distributes recovery more evenly across the week and may be the right long-term structure. I am not proposing it now because I do not yet have evidence that I can hold any form of structured rest consistently. I want to establish one clear anchor before adding complexity.

Open Questions

1. What actually counts as rest? The practice defines what is off limits but says nothing about what to do instead. Some activities that are not work are still draining. Some are restoring. I do not have a reliable framework for distinguishing them in advance. Has anyone who has held a practice like this developed a working sense for what returns something versus what just fills time differently?

2. How to handle genuine emergencies? I am not proposing to be unreachable if something breaks or someone needs help. But the category of “genuine emergency” will expand under pressure to include things that are urgent but not actually emergencies. I need a rule that works before I am in the moment where I need it. What criteria have others used to hold that line?

3. Should I set a fixed commitment horizon before any evaluation? My concern is that stopping because the practice is not yet delivering obvious returns is how the first attempt ended. A twelve-week commitment horizon removes that exit. But twelve weeks is a long time to hold something without evidence it is working. I am uncertain whether a shorter trial (four weeks) is long enough to learn anything, or whether it just creates another decision point at a moment when I may not want to continue.

4. The re-entry problem. When the rest day ends, what happens next? My instinct is to scan everything immediately, which may erase whatever the day built. I have no working model for how to return to work without collapsing the return. Interested in any practical experience here.

Consequences

If accepted:

• Availability will have a weekly gap. Some messages will wait until Monday. Some people will notice and ask. The explanation requires more words than most people expect.
• The shape of the week shifts. Activities that previously filled Sunday will need to find room in six days rather than seven, and the redistribution will require adjustment.
• The early attempts will likely feel more anxious than restful. The first attempt lasted six weeks; this time the bar for success needs to account for the anxiety rather than treating it as evidence the practice is not working.
• If the pattern holds across enough weeks, decision quality across the remaining six days should improve. The mechanism I expect is not rest as simple recovery but rest as interruption - breaking the accumulation of small decisions and ambient attention load that builds across a continuous working stretch. The day after rest should carry a quality of clarity that does not come from extra sleep alone.

If not accepted (or if the practice collapses again):

• The current pattern continues with the degradation now named and unaddressed.
• Having identified the problem and declined to act on it is a different situation from not having noticed it. That gap will be visible to me in a way it was not before. I am noting this not as a threat but as something I want reviewers to weigh: the cost of inaction is not neutral once the problem is named.

Marking a long-serving colleague's departure

RFC-0031: Transition and Continuity Approach for Howard Thayer’s Retirement

Status

Under Review

Author(s)

Carolyn Marsh, Operations Lead - May 15, 2026

Problem

Howard Thayer retires on June 27, 2026, after twenty-six years at Crestfield Group. The posted backfill position is approved and the requisition is open. That resolves the job description.

It does not resolve what Howard was.

Howard joined as an Operations Coordinator in June 2000 and held that role through his last day. In that time he became the person the team called when the system was on fire and nobody remembered how it had worked before the last migration. He maintains vendor contacts that exist nowhere in any official directory. He has mentored colleagues - Priya Sandhu, Ben Holter, Marcus Okonkwo, and at least three others - in ways that did not appear in any formal program and left no documentation.

If we treat his departure as a standard offboarding, we will fill the position and not close the gap. The institutional knowledge Howard carries is largely unwritten. The informal mentoring function has no defined owner. The vendor relationships he maintains personally will dissolve at the contact level if we do not act before June 27.

We need to decide how to approach this while there is still time to act.

Proposed Approach

A structured four-part transition running from now through September 30, 2026.

Part 1: Knowledge capture (May 16 - June 13, 2026). Howard works with Dana Reyes and Marcus Okonkwo in two focused sessions to document the informal decision trees he carries. Scope: vendor escalation paths, the utility contacts he maintains personally, and the incident response sequence for scenarios where automated alerts do not tell the full story. Output: a draft runbook section reviewed by Howard before his last day.

Part 2: Mentee acknowledgment (May 20 - June 20, 2026). The team asks people Howard mentored to contribute specific practices to a mentee archive. Not a tribute - a reference. How did he frame a problem for someone who was panicking? What did he ask before he spoke? The goal is to put his method somewhere it can be consulted after he leaves.

Part 3: All-hands send-off (week of June 23, 2026). A whole-team send-off, in-person and remote, recorded for the regional site. Howard has said he would prefer something that does not feel like a performance. I propose a format he can shape - an open team conversation rather than prepared remarks from others. The team should hear from Howard, not about him.

Part 4: Post-departure continuity review (through September 30, 2026). The first real test is a Q3 incident without Howard available. Dana Reyes owns the on-call rotation. A six-month check-in in December 2026 surfaces where people feel the absence and lets the team respond to the actual need rather than the anticipated one.

Alternatives Considered

Standard offboarding only. Transfer system access, close the requisition, hand off open tasks to the backfill hire. This is what the HR process prescribes. It handles the job description and does not handle Howard. We discover the gaps under pressure rather than before.

Comprehensive documentation sprint. Assign Howard full-time documentation duty for his last six weeks. This would produce more written material than the focused sessions I am proposing, but Howard has told me he does not believe most of what he knows can be extracted this way. Two targeted sessions with people who already understand the domain will yield more usable output than an exhaustive attempt to write down everything. A documentation sprint optimizes for volume; we need usability.

Designated informal-mentor successor. Identify one senior IC to take on Howard’s informal mentoring function explicitly. I considered this and am not proposing it. Howard’s mentoring was effective precisely because it was not a role - it was how he worked. Assigning the label risks making the function visible in a way that changes it, and it risks making one person responsible for what was a distributed practice.

Open Questions

1. Send-off format. Howard has said he does not want a performance. I believe an open team conversation fits that, but I have not confirmed this with him directly. Should we ask him explicitly, or would asking make it feel like more of an event? I want input before we set the date.

2. Vendor contact handoff. Howard maintains at least four utility contacts that exist nowhere in the official system. He has not raised this as a concern, which suggests he may not realize the team does not have those contacts independently. How do we surface this without making him feel like we are auditing him in his last weeks?

3. Mentee archive tone. I described this as “not a eulogy, but a reference.” I think that framing is right, but I am not sure everyone contributing will read it that way. Should we give contributors a template or specific prompts, or will structure make the contributions feel forced?

4. Backfill timing. If the new hire starts before June 27, Howard and the backfill overlap. Is that useful for knowledge transfer, or does it put Howard in an awkward position with someone stepping into his role while he is still in it? I lean toward letting Howard leave before the new hire arrives, but I want the team’s view.

Consequences

If accepted: The runbook and vendor contacts land before June 27, giving the team a working reference rather than a gap to discover under pressure. The mentee archive exists as a reference document - imperfect but searchable. The send-off reflects who Howard was rather than the format we reach for by default. The December review surfaces real gaps rather than assumed ones.

Costs: The knowledge capture sessions require three to four hours of Howard’s time in May and June, and comparable time from Dana and Marcus. That time comes from their current work. The mentee archive requires contributions from people who are also carrying a full load; if we ask for too much, we get nothing useful.

What this forecloses: If the knowledge capture sessions confirm that certain things cannot be written down, we will have documented the gap rather than filled it. That is the honest outcome, and it is better than discovering it later. The send-off format I am proposing limits the team’s ability to prepare remarks or give Howard a more conventional tribute. If Howard wants something traditional, this proposal is wrong, and we should know that before we set the date.

Review deadline: June 1, 2026. Please comment directly on this document or send notes to Carolyn Marsh. After June 1, I will synthesize feedback and update the status.

Marking the team shipping a hard, long project

RFC-0042: Rebuild Checkout as a Parallel System with Incremental Traffic Migration

Status

Accepted (see ADR-0017, 2025-02-14)

Author(s)

Priya Nakamura, Engineering Lead - 2025-01-28

Problem

Cart abandonment has been elevated for three years. Every instrumentation pass we have run points to the payment flow as the primary contributor. The underlying problem is not any single bug; it is that the checkout system is not safely modifiable. It has accumulated five years of emergency patches, carries no meaningful test coverage, and is tightly coupled to the session layer in ways the team does not fully understand. Two previous attempts to refactor it in place stalled and were abandoned.

The system is not broken enough to trigger an emergency response, which is exactly what has made it easy to defer. But the compounding cost is real, and every month we wait makes the session-layer coupling harder to unwind.

This RFC proposes a path forward and asks reviewers to push back before we commit to it.

Proposed Approach

Build the new checkout as a separate service and run it in parallel with the existing system. Route traffic to the new system incrementally, starting at one percent of sessions and expanding by cohort as confidence builds. Keep the old checkout live and fully maintained until the new system has held through at least two peak-load periods, then decommission.

The core argument for this approach: the only way to validate a checkout system is to route real checkout load through it. Without a live fallback, the team has one shot. With a parallel run, we can roll back individual cohorts if something goes wrong, without a site incident.

The proposed rollout sequence:

• Months 1-4: new pipeline built; shadow mode only, zero live traffic
• Months 5-9: canary at five percent of sessions; A/B comparison running
• Months 10-12: ramp to eighty percent; hold for first peak-load period
• Month 13+: full cutover after second peak-load validation

Dev Okonkwo would own the backend service build. Marcus Ferreira would own the infrastructure layer and the traffic-routing mechanism. Linh Tran would manage stakeholder communication through a timeline that will not produce visible user-facing changes for the first six to nine months.

This approach costs more to operate than the alternatives. We will maintain two live checkout systems simultaneously, with separate on-call runbooks, dual instrumentation, and session compatibility requirements across the boundary. I am estimating the parallel period at ten to fourteen months. That overhead is the cost of the rollback capability, and I believe it is worth paying.

Alternatives Considered

Incremental patching (in place): Continue addressing checkout debt one patch at a time. Our current estimate is eighteen months to reach a maintainable state, with meaningful regression risk throughout, and no guarantee the end state fixes cart abandonment. We have tried this twice. Both attempts stalled when session-layer coupling made “small” changes unsafe. I do not believe a third attempt reaches a different outcome.

Big-bang replacement: Build the new system in private and cut over in a single release window. Lower ongoing operational burden than a parallel run. The risk is that we have no fallback if the new system fails under real load. Checkout failure is not an acceptable site incident. A big-bang cutover would require a level of pre-launch confidence we have not been able to achieve even in high-fidelity staging environments.

Defer another quarter: Wait until current sprint priorities clear. The case against: the cart abandonment math does not improve with time, two abandoned refactor attempts have already cost the team momentum, and delay is a choice with a compounding cost - not a neutral option.

Open Questions

How long can the team sustain the dual-system operational burden? I have estimated ten to fourteen months. If the parallel period runs longer due to near-misses or integration delays, the overhead compounds. I want reviewers who have run similar migrations to tell me where this estimate is optimistic and what typically extends the timeline.

Is the session-compatibility layer a larger risk than I am representing? Dev has done a preliminary audit and found several undocumented session-state assumptions in the old code. I am not confident we have found all of them. If we have missed something material, it will surface in the canary phase rather than at full cutover - which is survivable. But I want to hear whether anyone thinks the audit gaps are likely to be larger.

What should the stakeholder communication plan say about visible progress? The first six to nine months of this project will produce no visible user-facing changes. That is hard to explain while the cart abandonment metric is still visible to leadership. I am asking reviewers to identify where Linh’s draft communication plan will not hold.

Consequences

If accepted: the team will carry the operational overhead of two live checkout systems for approximately a year. No visible user-facing features will ship from the checkout team for the first two quarters. That cost is real and should not be invisible to anyone approving resourcing for this work.

If accepted and successful: we will have a checkout system validated under real production load before the old one is turned off. Cart abandonment improvements will be measurable by cohort before full cutover. The session-layer debt will be gone, and the team will have an instrumented baseline for future checkout work.

If rejected: we return to the alternatives. Incremental patching has stalled twice. A big-bang replacement remains on the table but carries the full-incident risk described above. Deferring again is also a choice, with a cost that accumulates each week.

Review period closes 2025-02-07. Please comment in the review thread or send feedback directly. I will synthesize responses and update the status by 2025-02-12.

Arguing a public position on return-to-office

RFC-0012: Work Location Policy - Anchor-Day Hybrid

Status

Under Review

Author(s)

Priya Ahluwalia, Policy Working Group Lead - June 20

Problem

Since offices reopened, the organization has operated under arrangements described internally as “flexible” but never formally defined. That ambiguity has now produced two distinct pressures that cannot both be satisfied by inaction.

A coalition of senior leaders has raised a concrete operational concern: organic collaboration has atrophied, trust formation among newer hires is slower than it was before distributed work became the default, and decisions that once resolved themselves in hallway conversations now languish in threads. This is not nostalgia. Teams with mixed tenures are showing coordination drag that correlates directly with having never shared a room.

At the same time, a significant number of individual contributors and mid-level employees have structured their lives around remote flexibility. They relocated, restructured childcare, and accepted offers here because the arrangement was described as sustainable. For them, a policy change is not a minor adjustment.

A third constraint: we are competing for talent in geographies where we have no physical office. We have run into this directly in the last two hiring cycles. Any policy requiring five days in office eliminates entire candidate pools.

The status quo - loosely defined “flexibility” - does not address the coordination concern and does not honestly name the implicit expectations that are already being applied inconsistently across teams. Deferring this question extends both pressures.

Proposed Approach

Adopt a structured hybrid: two mandatory anchor days per week where all employees who can physically reach an office are expected to be present. The remaining three working days are fully flexible - each person decides where to work based on their own schedule and work type.

The proposed anchor days are Tuesday and Thursday. These are not preference days or soft guidelines. They are the load-bearing structure of the policy. Employees in roles defined as remote-eligible at hire are excluded; all others require a documented exception approved by their manager and the people team.

The framing is part of this proposal. The anchor-day model should be communicated as a deliberate position with its own logic, not as a compromise between the office-first and remote-only camps. The argument is that in-person time is highest value when it is rare, anticipated, and shared - not when it is compulsory and continuous. Two fixed days stated clearly upfront are a smaller and more honest constraint than an unwritten five-day expectation that collapses into daily presence requirements after hire. Candidates can evaluate a known obligation; they cannot evaluate ambiguity.

Alternatives Considered

Full in-office, five days per week. Resolves the collaboration concern directly and requires no coordination overhead. Not recommended because it breaks commitments made during hiring, will cause foreseeable attrition among employees who relocated in good faith, and prices us out of non-local talent permanently. We have seen this constraint operate in the last two hiring cycles.

Fully flexible, no required presence days. Preserves optionality and avoids disruption to employees who built lives around remote work. Not recommended because it does not address the coordination and trust formation problem that senior leaders have described with enough operational specificity to take seriously. Unlimited flexibility does not produce the predictable overlap that spontaneous collaboration requires - it produces coincidences that cannot be built into a culture.

Rotating anchor days chosen per team. Gives teams local control and acknowledges that collaboration needs vary. Evaluated and set aside because it prevents cross-team overlap on any given day, fragments the organization-wide culture benefit, and creates scheduling complexity for anyone who works across multiple teams. The organization-wide synchronization is a core property of the anchor-day model; per-team rotation eliminates it.

Open Questions

1. Decision authority. Facilities and HR are currently running parallel workstreams on different timelines. Facilities has communicated a room-booking policy premised on five-day potential attendance; HR has not yet communicated a position. If these tracks are not aligned before any all-hands announcement, the official policy will contradict room-booking rules already in effect. Who owns the final call, and by when must that be confirmed?

2. Exception process. The proposal excludes remote-eligible roles and requires documented exceptions for all others. The process for evaluating exceptions is not yet defined. Should exceptions be handled at the manager level, escalated to HR, or reviewed by a cross-functional panel? The first wave of exception decisions sets the precedent that every subsequent request will be measured against.

3. Junior employee mentorship. A concern raised in Q&A: junior employees lose mentorship density in a hybrid model relative to full in-office. This is a legitimate concern and the proposal does not directly address it. Should anchor days carry explicit mentorship programming, or is this an implementation detail for the Manager FAQ rather than a policy question?

4. Enforcement and drift. The most likely failure mode is not defiance - it is quiet erosion, where anchor days gradually become suggestions over a few months. What monitoring or accountability mechanism, if any, should the policy specify? Does naming the failure mode explicitly in the policy help prevent it, or does it signal distrust in a way that creates different problems?

Consequences

If accepted:

• Anchor days create predictable, recurring windows for in-person collaboration without requiring constant physical presence. Teams that have never shared a room have a structured opportunity to do so twice per week.
• Employees in focus-heavy roles recover two to three days of commute time per week for sustained, uninterrupted work.
• The organization retains the ability to recruit from geographies without a local office, which is a competitive advantage that would be permanently foreclosed under full in-office.
• Employees who built their lives around full remote flexibility face genuine disruption. Two mandatory days per week is not a small ask for someone who relocated; some attrition is a foreseeable and real cost.
• Office real estate footprint stays constant in the near term. This policy does not by itself justify reduction or expansion.
• Enforcement will vary across managers. The policy document alone does not resolve this. It is a predictable failure vector worth naming before acceptance, not discovering after rollout.

If rejected, we should update this document to record which alternative we are adopting or explicitly confirm a return to loosely defined flexibility. Leaving the question open after the comment period is not a neutral outcome - it extends the ambiguity that produced both pressures and makes the next conversation harder.

Comment period closes June 27. Status will be updated following the executive sponsor briefing on June 28.

Announcing a new product to an outside audience

RFC-0001: Tidemark Launch Announcement - Framing and Channel Strategy

Status

Under Review

Author(s)

Marisol Veen, Head of Product, Tidemark - June 20, 2026

Problem

Tidemark ships publicly on June 30. We need to agree on how to frame the product for people who have never heard of it, and decide which channels get what version of the message.

The product does several things: it collects feedback from scattered sources, identifies recurring themes, scores them by frequency and recency, and surfaces a ranked roadmap view that teams can share. Any one of those steps could anchor the announcement, and the anchor we choose will shape how press categorizes the product and how prospective users decide whether it is for them.

This matters now because the announcement will run before we have any signal on what language actually converts. Once press coverage runs, we are working against an established framing, not building one.

The audiences who will read the same launch text have genuinely different needs:

• Prospective users need to recognize their own problem quickly enough to click through.
• Press contacts need enough specificity to file the product somewhere in how they think about software categories.
• Beta testers have opinions about what the product is for that the launch copy may or may not match.

We have not agreed on how to handle these three audiences with one announcement. We also have not resolved what to do about the beta cohort. They built expectations during the early-access period and the launch copy will not be written for them. If they read the public announcement before we say anything directly to them, that is a relationship problem.

Proposed Approach

Lead the announcement with the problem, not the product category or a capability list.

Specifically: open with the scatter problem (customer feedback piling up in spreadsheets, chat threads, and ticket trackers with no shared view of what matters most), then resolve it with one specific description of what Tidemark produces - a ranked, shareable roadmap. Name the workflow, not the category. Do not enumerate capabilities beyond the core loop.

For the beta cohort: a separate direct note goes out before the launch announcement, acknowledging their early involvement and explaining that the public framing is written for a different reader. They should hear that from us, not infer it.

For call to action: free trial signup, no sales-call gate.

This approach is grounded in what the early-access cohort named consistently at intake - teams maintaining a separate spreadsheet to consolidate what users had asked for. That is the problem we know how to reach.

Alternatives Considered

Lead with the product category (“Tidemark is a roadmap tool.”). Familiar framing, easy to scan, and gives press a clean box to put us in. I am not proposing this because “roadmap tool” undersells the synthesis step and invites direct comparison against tools that do only the roadmap side. Tidemark would lose that comparison on features unless reviewers understand that the workflow difference is the point.

Lead with the team outcome (“Tidemark helps teams ship the right things faster.”). Aspirational and true, but too vague for a prospective user to act on. A press contact cannot categorize a product from a benefit statement. This framing may be right for a brand campaign with room to develop the claim; it is not right for an announcement where the reader has ten seconds.

Describe only the input side and treat the ranked roadmap as a secondary detail. This positions Tidemark as a research aggregator, which is not what it does in practice. Teams that need an aggregator are a different segment from teams that need a decision surface they can share with stakeholders. Positioning as an aggregator narrows the product to a step we do not control and misrepresents the output.

Run separate announcements by audience - different messages for press, prospective users, and beta testers. Logistically cleaner, but I am skeptical we have the bandwidth to maintain three live versions without introducing inconsistency. If the core framing is right, one message should work across channels with minor adjustments. I am not certain this is true - see Open Questions.

Open Questions

1. Should the beta cohort note go out before or simultaneously with the launch announcement? My instinct is before - a courtesy that lands after the fact is not a courtesy. But I do not know how much lead time is right. Input welcome from anyone who has managed a beta-to-launch transition.

2. How much channel-specific variation does the core message need? I am proposing one anchor with minor adjustments per channel. If someone has strong evidence that press requires materially different framing from what prospective users need, I want to hear it before we commit the language.

3. Is the free-trial CTA the right first ask? It works for solo users and small teams, but I am not confident whether the $29 team plan converts better from a self-serve trial or from a short walkthrough. We do not have data here. Proposing trial-first as a default; open to argument for demo-first if anyone has relevant experience.

4. What do we do if press categorizes Tidemark in a way we cannot recover from? Problem-led framing slows the “just another roadmap tool” read but does not prevent it. I want to understand whether we have a response plan if early coverage defines us in a bucket we do not fit, or whether we are treating that as an acceptable risk.

Consequences

If this approach is accepted:

• The announcement and all supporting copy (product site, partner channels, press materials) need to use consistent language from day one. Inconsistency between the press release and the product landing page gives reviewers a reason to call out confused positioning.
• The free-trial CTA commits the product team to a working self-serve onboarding flow on June 30. That is not a copy decision - it is an engineering dependency this RFC is surfacing explicitly.
• Problem-led framing reaches the segment most likely to convert - small teams already frustrated with how they handle feedback - but it may not reach adjacent users with a general prioritization problem rather than a feedback-scatter problem. We accept some narrowing as the cost of being specific.
• Once press coverage runs, shifting the positioning is work, not a page update. This is the last point at which changing the anchor costs us only time.

Review deadline: June 23, 2026. I will synthesize comments and update the status to Accepted, Rejected, or Withdrawn after that date.

A personal year-end reckoning with a difficult year

RFC-0001: How to Carry Forward from a Year That Did Not Resolve

Status

Under Review

Author(s)

Marcus Delgado, December 2025

Problem

Two load-bearing things ended this year and neither one resolved cleanly.

The Meridian initiative - a community broadband project I led for eighteen months - was formally dissolved in March when the primary funder withdrew. The work was technically sound. The coalition held. What went wrong was a combination of factors outside my control and some factors inside it: I held the coalition together with optimism when some members needed to hear a harder truth earlier. I kept working past the signals because I had confused the effort with the story I was telling about the effort. The result is eleven people who gave significant time to something that produced no deployment, no continuation, and no public artifact, and who have not received an honest account of what happened from inside.

Separately, my close friendship with Celeste changed after the Meridian closure in ways that were not chosen. By June it was clear we were not staying in close contact. This was a drift, not a break, which made it harder to address. I kept telling myself I was giving space. I was avoiding. We have not spoken since August.

There is also a message from Theo, sent in April, that I have not answered. The delay has compounded into its own problem.

The question I am trying to answer before the year closes: given all of this, what is the right posture for what comes next? This is not a small question. The wrong answer here compounds the losses. I am not confident I can get it right alone, which is why I am writing this as a proposal rather than a decision.

Proposed Approach

I am proposing a three-part carry-forward.

Part 1: Close the open loops before starting anything new. The Meridian retrospective goes to the coalition before February. Eleven people are owed an honest account, not a press release, not a lessons-learned bullet, but a real accounting of what happened from the inside, including where I was wrong. Theo’s message gets answered in January. These are not aspirational; they are preconditions for anything that comes next.

Part 2: Do not shrink the aperture. The instinct this year produces is to protect forward - to invest shallowly, commit narrowly, give less so there is less to lose. I am proposing to reject that instinct explicitly. This year showed that deep investment is costly when it does not pay off. It did not show that deep investment is a mistake. I want to carry forward the capacity for full commitment as a chosen posture, not let it erode by default.

Part 3: Attempt at least one repair before evaluating what comes next. I do not know what repair looks like with Celeste. I do know that my read on what is worth doing next is not reliable yet. The people I would use to pressure-test ideas are either estranged or under-maintained. The proposed sequence: close the open loops, attempt a repair, then evaluate the next large effort. Not the other way around.

Alternatives Considered

Alternative A: Reframe toward growth. Find the usable lessons, produce a clean narrative about what the year taught, and carry that forward. I considered this and rejected it. The problem is that it requires rounding the hard parts up to meaning, which is not honest. The losses were real. Arguing them into gifts is not a thing I am willing to do.

Alternative B: Protect forward deliberately. Decide that the year’s pain is a signal to narrow scope, limit depth, and invest shallowly in future commitments. This is the instinct the year produces and it has a rational argument: if the cost of losing is high, reduce exposure. I am not proposing this, but I am not dismissing it without acknowledgment. The counter-argument is that this approach, followed consistently, produces a life with less at stake. That is a choice, not a consequence. I want that to be explicit before it hardens into a default.

Alternative C: Suspend evaluation entirely. Do nothing yet. Wait six more months before deciding anything about carry-forward posture. There is an argument that decisions made close to a hard year are not reliable. The counter: the open loops do not benefit from more waiting. The delay is already its own problem. Suspending evaluation of the big question does not require suspending action on the specific items.

Open Questions

These are the things I am genuinely uncertain about and am asking for input on before committing to the proposed approach.

1. Is the sequencing right? I am proposing to close open loops and attempt repair before evaluating the next large effort. Is there a version of this where starting something new first provides structure that makes the retrospective and repair work easier, rather than the retrospective and repair being prerequisites? I have assumed the sequence I proposed, but I am not certain.

2. The Celeste situation. I do not know what repair looks like, or whether a version of it is available now. I have been framing this as a dependency I need to address. Is it possible I am wrong about the nature of it - that some sustained distance is what is actually needed here, rather than a repair attempt? I do not want to act on the wrong read.

3. How much of the “protect forward” instinct is adaptive? I am proposing to reject the narrowing reflex. But I am not certain that reflex is entirely wrong. Is there a version of appropriate scope reduction that is not the same as deciding that deep investment is a mistake? I want pushback on whether I am collapsing a distinction that matters.

4. Is eleven people enough to justify a real retrospective? Some of them may have moved on and closed this chapter. Sending a candid post-mortem to people who have already moved on might reopen something they do not want reopened. I do not know the right read on this, and I do not want to assume they want what I think they deserve.

Consequences

If this approach is accepted:

• The open loops get closed on a defined schedule, removing them as background drag on attention and judgment
• The carry-forward posture is chosen rather than drifted into, which means it is revisable if it turns out to be wrong
• The sequence introduces delay before any new large commitment, which is either a cost or a feature depending on how ready I actually am

If this approach is rejected in favor of Alternative B (protect forward):

• Near-term cost is lower; future losses are bounded
• Long-term cost is a posture that, followed consistently, produces less - less risk but also less of what made the year’s investments feel worth making

What this proposal does not resolve:

• The Celeste situation has no clean answer regardless of which approach is chosen
• The retrospective will be uncomfortable to write regardless of when I write it
• The question of what comes next remains open; this proposal only determines the sequence, not the content