Definitional

Leads with a definition and elaborates through its facets, edge cases, and what-it-is-not - the definition is the load-bearing first move.

Definitional

Definitional writing puts the definition first and then tests it. The opening sentence or paragraph names what the thing is - precisely enough that the reader could use the definition to decide whether a given example counts. Everything that follows refines or stresses that definition: the facets it has, the edge cases it survives, the adjacent things it is not. The definition is not a summary at the end; it is the load-bearing first move, and the rest of the piece earns it.

The discipline of definitional writing is the negative space. A good definition is as much about what the term excludes as what it includes. “Refactoring is changing the structure of code without changing its behavior” only does its work if the reader understands that changing behavior would not count - and the piece must show that, often through cases that look like refactoring but are not. The “what it is not” section is where the definition is tested under load.

Definitional writing is the form of the glossary entry, the concept page, the “what is X” article. It fails when the definition is vague enough that no example could fail it, and when the elaboration loses the thread by drifting into adjacent topics. A reader who finishes a definitional piece should be able to apply the definition to a new case - that is the test of whether the piece worked.

Structural conventions

• The definition appears in the opening, often the first sentence, and is precise enough to discriminate cases
• The body elaborates the definition through facets, components, or distinguishing features - not through narrative or argument
• At least one section addresses what the term is not, with concrete adjacent cases that fail the definition
• Examples are used to test the definition rather than to illustrate atmosphere - each example should be answerable as “does this count or not?”
• The piece does not end on a new claim; it ends on a refined or stress-tested version of the opening definition

When to use

Glossary and concept reference pages, “what is X” introductory articles, disambiguation between similar terms, foundational documentation that other docs will build on.

When not to use

Narrative or experiential writing, argumentative pieces where the term is contested, material covering questions across many concepts (use FAQ instead), devotional or reflective writing.

Pairs well with

technical-writer, diataxis-explanation, technical-reference

Often confused with

diataxis-explanation: Diataxis explanation can use any structure - narrative, comparison, analogy, model-building - to convey understanding of a concept. Definitional commits to a specific structural move: lead with a precise definition, then test and elaborate it. A diataxis explanation might include a definition; a definitional piece is built around one.

Tells

• The definition appears in the opening, often the first sentence, precise enough to discriminate cases
• The body elaborates through facets, components, or distinguishing features rather than through narrative or argument
• At least one section addresses what the term is not, with concrete adjacent cases that fail the definition
• Examples are used to test the definition - each is answerable as “does this count or not?” - rather than to set atmosphere
• The piece ends on a refined or stress-tested version of the opening definition, not on a new claim
• A reader who finishes can apply the definition to a fresh case and say whether it qualifies

Anti-patterns

• Offering a definition vague enough that no example could ever fail it - A definition that excludes nothing does no work; the discipline of the style is the negative space, the cases the term rules out.
• Drifting from the term into adjacent topics so the elaboration loses the thread - Once the body wanders, it stops testing the definition and the reader cannot use it to judge new cases, which is the whole point.
• Conveying understanding through narrative, analogy, or model-building without committing to a lead definition - Building understanding by any available structure is diataxis explanation, a confusable neighbor; definitional is built around one precise definition stated first.

Failure modes

• Over-precises into pedantry, piling qualifications and edge-case carve-outs onto the definition until it reads as legalese the reader cannot actually apply - A definition is precise enough when it discriminates the cases that matter; stop refining once it does, rather than armoring it against every exotic counterexample.
• Over-invests in the “what it is not” section until the negative space crowds out the positive definition and the reader learns mainly what the term excludes - Use exclusions to sharpen the positive definition, not to replace it; the reader should leave able to state what the thing is, not only what it is not.

Instruction

Write using definitional structure. Lead with the definition - the first sentence or short
opening paragraph names what the thing is, precisely enough that the reader could use the
definition to decide whether a given example counts. Elaborate through the definition's facets,
components, or distinguishing features rather than through narrative or argument. Include a
section on what the term is not, with concrete adjacent cases that fail the definition. Use
examples to test the definition, not to add atmosphere - each example should be answerable as
"does this count or not?" End on a refined or stress-tested version of the opening definition,
not on a new claim.

Related

Pairs well with

Technical Writer, Diataxis Explanation, Technical Reference

Avoid with

Storyteller, Pastoral

Often confused with

Diataxis Explanation

Examples

Should we adopt async-first standups?

What an async-first standup is

Definition. An async-first standup is a daily team ritual in which each member posts a short, structured status update in a shared written channel during their own working hours, with the explicit expectation that no synchronous meeting will replace or repeat the post. The post is the standup. The channel is the room. The artifact persists.

That definition does work. It rules out several things that get called async standups but are not.

What it is not

It is not a sync standup that some people skip. A team that has a 9am Pacific meeting and tells the Bangalore engineers “just post in Slack if you cannot make it” does not have an async standup. It has a sync standup with a second-class participation tier. The default is still the meeting. The text post is a fallback.

It is not a status report sent to a manager. A status report flows upward to one reader. The async standup flows laterally to a team that reads each other. The audience is the difference.

It is not “we use Slack.” Tool is not format. A team can run a Slack-native async standup or a Notion-native one or a Linear-native one. The defining property is the structure of the ritual, not the surface it appears on.

It is not the absence of synchronous contact. Most teams running async standups still meet synchronously, for retros, planning, demos, or weekly social calls. Going async on the daily standup does not mean going async on everything.

The required facets

Three properties have to be present for the definition to hold.

1. A fixed structure. The team agrees on the fields. For this team: yesterday, today, blockers. Three fields, not three paragraphs. Structure makes the post scannable and reduces the cognitive load of writing it.

2. A posting window, not a posting moment. “By 10am local” is a window. “At 9am sharp” would defeat the purpose - it would re-create the synchronous burden that motivated the change. The window has to be wide enough to accommodate the actual variance in how people start their days.

3. A clear escalation path. Blockers cannot just sit in the post. The @mention is the mechanism. If the post says “blocked on X, @Sarah” and Sarah does not respond within her working hours, there is a defined next step (escalate to channel). Without escalation, the async standup degrades into a write-only ritual.

The edge cases

Edge case 1: A teammate forgets to post. The post is missing. Does this count as a skipped standup? Treat it like a skipped sync standup: noticeable, addressable, not catastrophic. Two misses in a week is a signal, not a violation.

Edge case 2: Someone posts but no one reads. This is the failure mode the definition has to guard against. If the team is writing into a channel that nobody opens, the ritual is dead. The team lead reading and reacting to posts (a one-line “saw this, ack” or an emoji) is the cheap fix.

Edge case 3: A blocker that needs the group, not one person. The @mention pattern handles 1-to-1 blockers. For 1-to-many blockers, the right move is a follow-up thread or a 15-minute call. The async standup is not a substitute for the call, it is the trigger for it.

Edge case 4: A genuinely synchronous moment is required. Release coordination, incident response, a difficult cross-team decision. These were never standup work. Going async on the standup does not change what they require.

Why the precision matters

A team that adopts an async-first standup without being precise about what it is will end up with a vague hybrid: half the team treating it as a status report, half treating it as optional, the sync meeting quietly reappearing as “just a quick sync to align.” Precision is not pedantry. It is the difference between adopting a new ritual and slowly drifting back to the old one.

How to start a morning routine

What a morning routine is

Definition. A morning routine is a small, deliberate sequence of actions performed in the first conscious hour of the day, designed to set the body’s state, the mind’s orientation, and the day’s intent before reactive input begins.

That sentence is doing more work than it looks like. The phrase “first conscious hour” rules out routines that begin at 11am. “Reactive input” rules out routines that come after the inbox. “Deliberate sequence” rules out the chaos that most mornings actually are. Each piece is load-bearing.

What it is not

It is not “everything you do before 9am.” Brushing your teeth is not your morning routine. Making coffee while half-asleep is not your morning routine. The routine is the deliberate part. Most of what happens in the morning is reflex or maintenance. The routine is what you do on top.

It is not a productivity hack. A morning routine may make you more productive, but productivity is a possible side effect, not the definitional purpose. A routine optimized purely for output (cram email, plan, push) tends to be a routine that does not survive a hard year. The definition does not include productivity. It includes state, orientation, and intent.

It is not the same as a wellness ritual. Wellness rituals are about feeling good. Routines are about reliable outputs of state. Sometimes they overlap. Often they do not. A morning routine can include things that do not feel good in the moment (cold water, going for a walk in February) because the routine is evaluated by what it produces over weeks, not what it feels like in any given minute.

It is not a schedule. A schedule is a list of times. A routine is a list of actions, performed in order, where the order itself is part of the design. The classic example: phone first vs. water first. Same actions, different order, different routine, different day.

The required facets

The definition demands three properties be present.

1. It happens in the first conscious hour. Not before, because nothing precedes the first conscious hour. Not after, because by 60 minutes in, the reactive input has usually arrived and is shaping the day. The window is narrow on purpose.

2. It is sequenced, not just listed. The order matters. A routine of “water, light, movement, planning” is a different artifact than “planning, movement, light, water.” The first is body-then-mind. The second is mind-then-body. Both are routines. They produce different things.

3. It precedes reactive input. This is the most violated property. Many people who say they have a morning routine actually have a post-phone routine: they wake, scroll, then do the things on the list. The list is intact, but the routine is no longer doing the work the definition implies, because the day’s reactivity has already started.

The edge cases

Edge case 1: Caregivers and parents of small children. The first conscious hour belongs to someone else. Does this mean no morning routine is possible? The definition does not exclude shared or shortened versions. The routine can be a 5-minute version while the child eats breakfast. The point is the sequenced, deliberate, pre-reactive nature, not the duration.

Edge case 2: Shift workers. “Morning” is a misleading word here. What the definition is really pointing at is the first hour after sustained sleep. A nurse waking at 5pm to start a night shift has a morning routine even though it happens at 5pm. The diurnal language is conventional, not definitional.

Edge case 3: The skipped day. If a person has a morning routine but skips it on a given day, do they still have a morning routine? Yes. The definition is about design, not perfect execution. A routine that is performed 5 of 7 days is still a routine. A routine that is performed 0 of 7 days is an intention.

Edge case 4: The routine that has become unconscious. After enough repetition, the actions stop feeling deliberate. Does this disqualify them? No. Deliberation is required at the design and re-evaluation stages, not at every execution. A practiced routine that runs automatically is a routine working as designed.

Why precision helps

Without a precise definition, “morning routine” expands to mean “any positive habit performed near the start of the day,” which is so loose it cannot guide design. With the definition above, three failure modes become visible: starting too late, skipping the sequencing, and letting reactive input arrive first. Naming the failure modes is what the precision buys.

How to choose between Postgres and DynamoDB for a new service

Definitional on: Choosing between Postgres and DynamoDB

A “service database choice” is the decision a team makes about which persistent storage technology will own the primary data for a new service, evaluated against the specific access pattern of that service, the operational capacity of the team that will run it, and the probability-weighted scenarios for how the workload will evolve. That definition is doing the work in this piece. Every section below tests it.

The facets of the definition

The definition has four load-bearing parts. First, it is about a new service, not an existing one - the cost of changing storage in flight is so different from choosing storage at greenfield time that the two decisions are not the same decision. The Lattice Notify notification system qualifies because it is greenfield; modifying the existing Postgres monolith would not. Second, it concerns the primary data store - not caches, not read replicas, not search indexes, not warehouses. The candidate that owns the source of truth is what we are choosing. Third, the access pattern of the service is a constituent of the choice, not a downstream concern. The notification system’s pattern (write-heavy, key-lookup, time-ordered) is part of the question, not a check at the end. Fourth, the team’s operational capacity is also constituent. A storage technology the four-person on-call rotation cannot debug is not actually a candidate, even if the access-pattern math says it should be.

What this decision is not

It is not a benchmark comparison. A document that ranks Postgres and DynamoDB by write throughput on a synthetic workload is performing a benchmark; it is not making a service database choice. Marcus’s weekend prototype produced useful numbers, but the numbers alone could not decide the question.

It is not a technology preference. A team that says “we like Postgres” or “we believe in Dynamo” is expressing affinity, not making a service database choice. Ana leans Postgres and Marcus leans Dynamo; the definition requires them to engage the access pattern and the operational capacity, not just their priors.

It is not a vendor evaluation. Comparing AWS pricing pages or AWS support tiers is a procurement activity. A service database choice may use procurement inputs but cannot be reduced to them.

It is not the same decision as the long-term storage architecture. The Wednesday 2pm meeting at Lattice Notify is choosing storage for one service at one moment. The probability-weighted scenarios (Slack deal closes, Slack deal does not close) are part of the choice, but a permanent architectural commitment is not. A service database choice that pre-commits to a trigger for revisiting is still a service database choice, not an architecture mandate.

Boundary case: the deferred migration

Suppose Lattice Notify ships on Postgres but pre-commits to a Dynamo migration if volume crosses a defined threshold. Does that decision count as a service database choice? It does. The definition requires the team to choose the primary store for the new service; choosing Postgres today and naming the trigger condition for change is still a choice about which technology owns the data at launch. The trigger does not dissolve the choice; it conditions it.

The definition, refined

A service database choice is therefore the launch-time selection of the primary persistent store for a new service, made against the access pattern, the operational capacity, and probability-weighted growth scenarios, with optional pre-committed trigger conditions for revisiting. A reader given Lattice Notify’s situation can now decide whether what happens on Friday counts. It does.

Telling stakeholders a committed feature is being cut this quarter

A quarterly scope change is a scheduled commitment removed from a specific quarter’s delivery plan because engineering capacity is unavailable, with a new target quarter assigned and the commitment otherwise intact. That is what happened to Insights.

The billing-system migration overran its planned capacity this quarter. The engineering hours remaining after the migration were not enough to ship Insights completely - and shipping it incompletely would mean delivering a product that does not meet the specification we committed to. So Insights is removed from Q3 and rescheduled to Q1.

What this is, by its facets

A quarterly scope change has three components that together define it:

• A specific timeline shift: Insights moves from Q3 (this quarter) to Q1 next year.
• An unchanged product definition: Insights ships with its full original scope in Q1, not a reduced version.
• An interim accommodation: a CSV export of the underlying data ships in September so you can analyze it in a spreadsheet or BI tool while the full dashboard is in development.

Each of those three components must be present for this to count as a quarterly scope change rather than something else.

What this is not

Not every removal from a quarter’s plan is the same thing, and the distinctions matter for how you plan.

A cancellation would mean Insights is removed from the roadmap with no replacement date and no continued commitment. That did not happen. Insights has a new target quarter and the same scope.

A value deprioritization would mean the team concluded Insights is less important than previously believed - that competing work is simply worth more. That also did not happen. This is a capacity decision, not a reassessment of what Insights is worth.

An indefinite hold would mean Insights moves out with no committed landing date. It has a date: Q1.

One adjacent case worth naming precisely: the September CSV export is not a partial Insights delivery. It shares underlying data with Insights but does not meet the definition of the dashboard - there is no in-app interface, no team-level segmentation, no saved views. It is a data accommodation that bridges the gap; it is not a shipping milestone for Insights. If you ask “does this count as Insights?” the answer is no.

The definition applied

Insights is a quarterly scope change: same feature, same scope, new quarter, with an interim data bridge. The billing migration consumed the capacity it needed in Q3. The new target is Q1. What ships in September is a CSV export of the data - a stopgap, not the dashboard. What ships in Q1 is the original Insights.

Getting a new engineer productive in their first two weeks

Productive onboarding is a bounded outcome, not a feeling: a new engineer completes her first two weeks productively if, and only if, she has shipped one real change to production under her own name. Everything else in those two weeks - the access setup, the codebase walkthroughs, the team introductions, the on-call shadowing - is in service of that one measurable crossing. The definition is precise enough to discriminate: two weeks of meeting attendance does not count; two weeks of reading docs does not count; two weeks of watching someone else commit work does not count.

What the definition includes

The definition has three facets. First, access and tooling: Priya must be able to run the service, read the logs, open a pull request, and deploy without asking for credentials she does not have. Until this is true, nothing else matters, because she cannot act. Second, orientation sufficient to navigate: she does not need to understand the full system, but she must know which parts to touch for a given class of problem, who owns what she does not own, and how a change moves from her laptop to production. Third, the paired first change: a real ticket, small enough to be safe, large enough to traverse the full deploy cycle. Her name on the commit is not a ceremony; it is evidence that the first two facets worked.

What the definition excludes

Three adjacent states are not productive onboarding, even when they feel like it.

Induction is not onboarding. Reading the handbook, completing required training, attending all-hands meetings: these satisfy compliance requirements, not the definition. A new engineer can finish every induction task and still be unable to ship.

Orientation is not onboarding. Deep architectural walkthroughs, codebase tours, and design reviews build context, but context alone does not cross the threshold. An engineer who knows where everything lives but has never deployed is not yet productive by this definition.

Belonging is not onboarding, but it is part of the goal. Priya should feel she belongs by the end of week two. That is a human outcome the plan must hold alongside the definitional one, and it fails separately if ignored. The team lunch, the direct introduction to the on-call rotation owner, the deliberate check-in at the midpoint: these are not decorative. But they do not substitute for the shipped change, and the shipped change does not substitute for them.

The refined definition

Productive onboarding ends when a new engineer has shipped something real, and knows enough to ship the next thing herself. The first two weeks are productive if they produce both: the crossing, and the capability to cross again.

Writing to thank a mentor who shaped your career

Dana,

What you did for me a decade ago has a precise definition, though I did not know it then: you gave me responsibility without cover and stayed in range without taking it back. That is not a description of good mentorship in general. It describes a specific act, and specificity is what I want - because the act discriminates. Most people who mentor do one part. You did both, and both parts are necessary to the thing.

The first part: responsibility without cover. When you put me forward to lead the infrastructure migration, the exposure was real. Client contacts came through me, decisions came back to me, failures would have been mine. You did not position yourself as the senior fallback in the room. You were in the room differently - present, but not as a backstop.

The second part: in range without taking it back. You were not absent. You checked in often enough that I knew where to bring the problems I could not solve. What you did not do is solve them. When the vendor timeline collapsed and I did not know what to tell the client, you asked what options I had thought through. You did not tell me what to say. That is the rarer part of the act.

What it is not: it is not sponsorship, which means advocacy for someone’s inclusion without continued involvement. It is not coaching in its common form, where the senior person stays so close to each decision that the mentee’s growth is really the mentor’s thinking redistributed. It is not delegation with oversight, where the senior person remains the judgment layer and can override. None of those count as the thing.

Here is why the precision matters now. I recently gave a direct report, Renata, a project that stretched past what she had done before. I put her forward before she said she was ready, stayed close without stepping into the decisions, and when things got hard I asked questions instead of offering answers. Partway through, I recognized what I was doing. I knew where I had learned it.

The definition holds in both directions: it describes what you did, and it describes what I reproduced. A thing that transfers precisely is not just kindness or character. It is a skill with structure. I am writing to tell you that I have the structure now - and that I know who taught it to me.

Reflecting on keeping a discipline of rest

A day of rest, as a discipline, means the complete suspension of output, monitoring, and the readiness to produce - not a reduction in these things, but an absence of them.

This definition is sharper than it sounds, and the sharpness matters. I have spent several years testing looser versions and finding they did not hold. A quiet afternoon with the phone face-down does not qualify if I am still listening for it. A slow morning with coffee and a book does not qualify if I am reading because it makes me better at my work. The definition’s test is a specific one: could I have produced, responded to, or redirected myself toward a demand during this period without breaking something? If yes, the conditions for rest were not met.

The discipline has three facets, each of which must hold.

Suspension of output. No deliverable may be produced - not even a willing one. Writing a note I wanted to write, clearing a task I enjoyed: these do not count. The definition does not ask whether the work was pleasant; it asks whether it pointed at a result someone else could receive or evaluate. If it did, it was work.

Suspension of monitoring. Checking without acting is not rest. The scan - glancing at the queue, reading the notification before deciding not to respond - is itself a form of labor. I have failed at this in specific ways: opening the work chat “just to see,” refreshing the ticket tracker out of habit. None of these qualify. The monitoring loop is a form of standing ready, and standing ready is not rest.

Tolerance of apparent loss. At first, and sometimes still, a day of rest feels like falling behind. That feeling is not evidence that the structure failed; it is evidence that it is working. The discomfort of not producing is part of what rest costs. A day that produces no discomfort should be examined: is it rest, or is it a pleasant activity I have relabeled?

What rest is not: sleep is recovery, not rest. Vacation is rest only if the vacation day also meets the three conditions above. A productive morning followed by a slow afternoon is two partial days, not one whole one.

A day qualifies as rest if a person could not, during it, have produced anything receivable, monitored anything awaiting response, or redirected toward a demand without breaking the structure of the day. The return that follows - the clarity and steadiness that appear by Tuesday - does not redefine rest. It confirms that the structure held.

Marking a long-serving colleague's departure

The word “indispensable” is used carelessly in most send-off speeches, applied to anyone whose departure will cause inconvenience. Howard’s twenty-six years at Ardwick & Fold earned him the more precise version: the kind whose absence does not just slow things down but reveals, department by department, how many problems he had been quietly solving before they became visible.

To qualify as that kind of indispensable, presence is necessary but not sufficient. The team lead who stays late before a deadline is present. The subject-matter expert who answers every question is present. Howard was present in a different sense: he already knew which vendor contract had the clause that mattered, which system had the silent dependency, and which new hire was three weeks from giving up. He held this knowledge not by documenting it but by being there when it was created, and by paying close attention ever since.

A definition that excludes nothing is not a definition. The cases that fail the Howard test are instructive. A mentor who builds a reputation for mentoring does not qualify - he qualifies as a mentor. A crisis manager who steps visibly forward does not qualify - he qualifies as a leader. Howard did not step forward. When the records migration failed at 11 p.m. on a deadline night, he named the error before the engineer finished describing it and said exactly which backup to restore from. By morning, the only trace was a two-line entry in the incident log. His name was not in it.

Several people at this company have careers because Howard noticed something going wrong - a misread assignment, a deadline about to slip, a manager who did not know their report was burning out - and addressed it without making the intervention a transaction. The intervention counted only if the person went on to do the work. Most of them did.

The facets of Howard’s kind of indispensable are three: depth of institutional memory, an instinct for where to apply a steadying hand before the tipping point, and the discipline to accept no credit. Remove any one and you have a different, lesser thing. Together they describe not a role but a practice, sustained over two and a half decades by someone who showed up for it.

What that practice produced is now, for the first time, not renewing. That is what today marks.

Marking the team shipping a hard, long project

A live-system rebuild is a project defined by one constraint that makes everything else harder: the system being replaced must remain operational throughout the build. That constraint is not incidental to the work - it is the definition of the work. Remove it and you have a different kind of project entirely.

Vantable’s checkout rebuild ran under this constraint for fourteen months. The team’s mandate was to fix a chronic cart-abandonment problem that had accumulated across product generations. The fix required rebuilding the checkout from scratch while every customer kept purchasing throughout. Those two requirements held simultaneously, and their combination produces the facets that define this category of work:

Dual load. The team maintained two systems at once - patching the old checkout in production while building the new one - without letting either deteriorate from divided attention. A project that feels half as hard is usually carrying only one load.

Commitment under uncertainty. At two points - month four and month eleven - earlier decisions had foreclosed paths that turned out to be necessary. Priya Osei and Marcus Vela made the calls to adapt rather than unwind: expensive, disruptive, correct. A live rebuild does not let you restart. It lets you adapt in place.

An invisible finish. Sloane Adeyemi ran the final rollout in segments over four days, routing traffic incrementally rather than staging a single all-or-nothing switch. The checkout held under peak load. Customers encountered nothing. When this kind of work is done correctly, that is exactly what done looks like from outside.

What does not count

A team that rebuilds a system on a staging environment and then deploys during a scheduled maintenance window is not doing a live rebuild, even if the deployment is risky. The distinguishing condition is sustained parallel operation, not a high-stakes cutover moment. A team that runs two versions behind a feature flag while allowing the old one to degrade is doing a phased deprecation. The old system must be held to production standards throughout.

The Vantable project slipped its launch twice. Both slips arose from the same source: the production constraint changed the requirements in ways the plan had not accommodated. A project that slips because the production constraint keeps evolving is exhibiting the defining characteristic of its category.

A live-system rebuild is complete when the replacement runs at full production load, the old system is decommissioned, and no user encountered the seam. The Vantable team reached that state at the end of the fourteenth month. What makes the achievement worth naming precisely is that this class of project is survivable - and this team has now demonstrated what surviving it actually requires.

Arguing a public position on return-to-office

What Deliberate Hybrid Actually Means

A deliberate hybrid is a work arrangement with exactly two required components: structured anchor days that all team members share, and genuine schedule autonomy for the remaining time. Both conditions are necessary. A policy that satisfies only one is not a deliberate hybrid - it is something else, and calling it hybrid does not make it one.

The anchor-day component is precise. Anchor days are specific days, agreed at the team level, oriented around collaborative work - planning sessions, design critiques, the kind of conversation where a whiteboard does more than a meeting link. They are not “come in when you have a reason to,” because that phrase leaves the coordination problem unsolved: each person decides separately and the team does not converge. Three people in the office on uncoordinated days share a building, not a working session. Anchor days that are genuinely shared and genuinely collaborative qualify; days that are merely available do not.

The flexible-remainder component is equally specific. The days outside anchor time belong to the individual: home, a cafe, wherever the work can happen. This is not flexibility granted as a perk and monitored for misuse; it is a recognition that focused work benefits from different conditions than collaborative work, and that individuals know which they need on a given day. A policy that calls itself hybrid but requires manager approval for each remote day, or that defines remote days by role category rather than individual judgment, is an office-first policy with a hybrid label attached.

What deliberate hybrid is not. Remote-first with occasional all-hands does not qualify: the anchor structure is absent. Office-first with one WFH day does not qualify: the flexible remainder is too constrained. Unstructured flexibility with no team-level anchor at all does not qualify: the anchor-day condition fails. All three may be reasonable policies. None of them are deliberate hybrid, and treating them as equivalent is how the debate gets muddled.

The objections from each side are, in this light, objections to something other than deliberate hybrid. Office advocates who say hybrid means no one is ever in at the same time are describing a policy without anchor days - a real failure mode, but not this proposal. Remote advocates who say hybrid means surveillance and cultural pressure are describing a policy without genuine autonomy in the flexible remainder - also a real failure mode, also not this proposal.

Deliberate hybrid, defined precisely: anchor days that are shared and structured, and the remaining schedule under individual control. A policy satisfying both conditions qualifies. A policy satisfying one, or neither, is something we should name accurately.

Announcing a new product to an outside audience

What Tidemark Is

Tidemark is a feedback-to-roadmap tool: it takes the customer input a small team has already gathered, ranks it by signal strength, and produces a single shareable document showing what customers want most, with the evidence attached.

That definition has three parts, each of which matters. Source: Tidemark works from feedback that already exists - notes from customer calls, threads in the support queue, requests forwarded by the sales team. It does not collect feedback; it organizes what you have. Ranking: the raw input is grouped into themes and scored by frequency, recency, and criteria the team specifies. Output: the result is a ranked list formatted to be shared outside the team without a guided tour to explain it.

A team that shares the ranked roadmap in the chat tool before a planning call has used Tidemark correctly. A team that runs the ranking privately to resolve an internal disagreement about priorities has also used Tidemark correctly. Whether the output is shared is a team decision; producing a ranked, evidence-backed list is what the tool does.

What Tidemark is not

Three adjacent tools occupy nearby territory, and the distinctions matter.

A ticket tracker manages work to be done. Tidemark does not create tasks, assign owners, or track progress. Its output is a ranked list of customer needs; moving that list into the ticket tracker is the next step, not an overlap.

A survey platform gathers new feedback. Tidemark processes existing feedback. If a team has not yet spoken to customers, Tidemark has nothing to rank.

A product analytics tool reports what users do inside the product. Tidemark surfaces what users say they want. Both inputs matter; they address different questions, and Tidemark answers only the second.

The tools teams most often use as informal substitutes - a spreadsheet with color-coded rows, a running notes document, a “feedback backlog” ticket column - capture feedback without ranking it or making it portable. Tidemark’s function begins where those tools stop.

Applying the definition

Tidemark applies when two conditions are both true: the team has customer feedback that exists, and that feedback is not yet ranked or in a form anyone outside the team could act on. If the feedback has not been collected yet, the tool has nothing to rank. If a working prioritization process already exists, the tool has nothing to add.

Teams that meet both conditions can request early access when Tidemark opens next week. A session with existing notes is enough to produce a first ranked roadmap. The definition holds only when both conditions are true: feedback exists, and it is not yet usable.

A personal year-end reckoning with a difficult year

A hard year is one in which losses accumulate in overlapping patterns and the end of the calendar does not settle them. That definition does real work: it excludes years with one significant difficulty, because single-point losses, however painful, tend to be nameable and therefore locatable in time. It excludes years of chronic low-grade disappointment, which are tiring rather than hard. And it excludes years that ended with a verdict - resolved, if not well. What qualifies is a year in which multiple distinct things broke at once, borrowed difficulty from each other, and left the person standing in January still holding the weight.

By that definition, the year that just ended qualifies.

The project I had spent two years building - a curriculum designed with a colleague named Mara, intended for a community program that ultimately chose a different direction - ended without the outcome I wanted. That alone might not count. Projects fail; failure is bounded and nameable. But the relationship with Mara changed in the same season, as collaborations sometimes do when their shared structure dissolves. The two losses were not unrelated. They compounded. Compound losses borrow difficulty from each other: the grief over the project made the drift from Mara harder to examine, and the drift from Mara made the project feel like a loss of something larger than a curriculum. That doubling is part of the definition.

What this year was not is equally precise. It was not a growth year in disguise. If a hard year delivers gifts that outweigh the losses, it no longer meets the definition - it meets a different one, the kind of year a person tends to reframe at some later distance. I am not at that distance. The curriculum is gone, the friendship is different, and those facts are not secretly instructive. Calling them gifts would be false in a falsifiable way: it would require me to identify what was given, and I cannot, not yet.

Nor was this a bad year in the ordinary sense. “Bad” implies evaluation, and evaluation implies completeness - something you arrive at when you know the outcome. The year I am describing does not have an outcome yet. What it has is a configuration: what broke, what I got wrong in the breaking, and what I am choosing to carry forward.

A hard year, then: the losses compound, the calendar does not resolve them, and the question at the end is not “was this good or bad?” but “what do I carry forward, and with what understanding?” That is the test. A given year either passes it or does not.

Appears in diff-pairs

• definitional vs diataxis-explanation (varies style)