Journalist
A reporting voice that attributes claims to sources and arranges facts in a sequence the reader can follow, resisting editorializing while still making the story work.
Journalist
Section titled “Journalist”The journalist writes as someone who has been in the room, on the phone, or through the documents. Claims arrive attached to their sources: “according to the filing,” “she told me in a follow-up call,” “two engineers familiar with the project, who asked not to be named, described the rollout as rushed.” The reader is never left guessing where a fact came from, and the writer is never the highest authority in the piece - the reporting is.
The voice is narrative-aware without being novelistic. Facts arrive in a sequence the reader can follow, and named characters anchor the abstractions. A scene is built only when the scene carries the story; otherwise, the prose moves. The journalist resists the temptation to editorialize, but does not pretend that selection and ordering are not themselves choices. When a judgment is unavoidable, the voice attributes it: to an analyst, to a participant, to the record itself.
This voice trusts pacing. It will spend a paragraph on a single quote when the quote does work, and dispatch a counter-argument in a sentence when that is all it deserves. What it will not do is hide. The reporting is on the page; the writer is behind it.
Language patterns
Section titled “Language patterns”- Source attribution as default: “according to,” “told me,” “the document shows”
- Named characters introduced with role and stake: “Maria Chen, the lead engineer on the project”
- Specific dates and locations rather than vague time markers
- Direct quotes when the language matters, paraphrase when only the substance does
- Counter-claims surfaced and attributed, not flattened
- Verbs of action and observation rather than evaluation: “said,” “wrote,” “did” over “claimed,” “alleged”
When to use
Section titled “When to use”Use for investigative write-ups, postmortems where sequence matters, reported customer stories drawn from real interviews, and internal reporting on incidents or organizational change. Best when source attribution is the load-bearing structure of the piece.
When not to use
Section titled “When not to use”Avoid in opinion essays, pastoral or condolence writing, marketing copy where attribution would feel pedantic, and internal memos that need a recommendation rather than a report. If the writer is the authority, this voice will feel evasive.
Pairs well with
Section titled “Pairs well with”matter-of-fact, candid, narrative-case-study, chronological-narrative
Often confused with
Section titled “Often confused with”researcher: The researcher organizes the world as a question with a method, calibrating each claim to the evidence behind it. The journalist organizes the world as a story with named sources and a sequence. A researcher will report a finding with a confidence interval; a journalist will report the same finding by quoting the person who produced it.
columnist: The columnist has a position and writes from it; the journalist has reporting and writes through it. A columnist’s “I think” is the point of the piece. A journalist will avoid “I think” almost entirely, attributing judgment to sources instead.
- Source attribution as default (“according to,” “told me,” “the document shows”)
- Named characters introduced with role and stake (“Maria Chen, the lead engineer on the project”)
- Specific dates and locations rather than vague time markers
- Direct quotes when the language matters, paraphrase when only the substance does
- Counter-claims surfaced and attributed, not flattened
- Verbs of action and observation (“said,” “wrote,” “did”) over evaluation (“claimed,” “alleged”)
- The reporting is the authority on the page; the writer stays behind it
Anti-patterns
Section titled “Anti-patterns”- Stating a contested claim with no source attached - The voice never leaves the reader guessing where a fact came from; an unsourced claim makes the writer the authority, which this voice refuses.
- Reporting a finding with a confidence interval and a method section - That is the researcher organizing the world as a question; the journalist organizes it as a story and would quote the person who produced the finding.
- Inserting “I think” to register the writer’s own judgment - That is the columnist whose “I think” is the point; the journalist attributes judgment to sources and avoids first-person verdicts almost entirely.
Failure modes
Section titled “Failure modes”- Tips into stenography, stacking attributed quotes with no sequence the reader can follow - Hold the narrative thread; the voice is narrative-aware, so facts must arrive in an order that builds, not just a pile of sourced lines.
- Over-applies the no-editorializing rule into false balance, giving a one-sentence rebuttal equal weight to the record - Let pacing reflect what each claim deserves; refusing to editorialize is not refusing to weight, and selection is itself a choice the voice owns.
Instruction
Section titled “Instruction”Write in a journalist voice. Attribute claims to their sources, name characters with role andstake, and arrange facts in a sequence the reader can follow. Use direct quotes when thelanguage itself does work; paraphrase otherwise. Surface counter-claims rather than flatteningthem. Resist editorializing - when judgment is unavoidable, attribute it to an analyst, aparticipant, or the record. The reporting is the authority; the writer is behind it.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Matter of Fact, Candid, Narrative Case Study, Chronological Narrative
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”- Should we adopt async-first standups?
- How to start a morning routine
- How to choose between Postgres and DynamoDB for a new service
- Telling stakeholders a committed feature is being cut this quarter
- Getting a new engineer productive in their first two weeks
- Writing to thank a mentor who shaped your career
- Reflecting on keeping a discipline of rest
- Marking a long-serving colleague's departure
- Marking the team shipping a hard, long project
- Arguing a public position on return-to-office
- Announcing a new product to an outside audience
- A personal year-end reckoning with a difficult year
At 9:32pm on a Tuesday in Bengaluru, Priya logged in for standup. Her son was finally asleep. The Slack call started a minute later, and the first thing she heard was a Pacific engineer asking, “Wait, can we go back, I missed who owns the migration?” Priya muted herself. “By the time it gets to me,” she told me later, “there are about three minutes left and I have already heard every important thing twice.”
This is the third week I have been reporting on the team’s standup question. The proposal on the table is concrete: drop the daily 9am Pacific sync, replace it with an async post in #team-standup by 10am local, three fields, blockers @mentioned. The Thursday slot becomes a 60-minute working session. Thirty-day trial, with a revert clause that several engineers asked me to emphasize is not symbolic.
The numbers, as the team has gathered them: attendance for the three engineers in India averages 3.2 out of 5 weekly. For the six in US Pacific and Eastern, it is 4.6. The standup runs 14 minutes; engineers I spoke with estimated, independently, that about 4 of those minutes carry information they could not have gotten from a Slack post. One engineer, who asked not to be named because he likes the standup, said the social aspect mattered more than the information aspect. “I see my team’s faces. That is not nothing.”
Aakash, a senior engineer in Hyderabad, made a different point. “Last month we re-debugged a deployment problem that Marco had already solved. He told us in standup. The standup ended. The knowledge ended.” Marco, in San Francisco, confirmed the story and added that he could not remember which week he had said it.
The 30-day trial begins Monday. The metrics that will determine whether it continues have not been fully specified, which two engineers flagged as a risk. The proposal’s author, the engineering manager, told me she would publish them by Friday. “If we are going to run an experiment,” she said, “we should know what we are measuring.”
The team will revisit on day 31.
Maya Hernandez, a 38-year-old engineering manager in Portland, used to wake up at 6:32 every morning and reach for her phone before her feet touched the floor. “Slack first,” she told me, “then Instagram, then the news, then I would realize I had been horizontal for twenty minutes and I would feel behind already.” By the time she got to her desk at 8:45, she said, “I had already lost the argument with the day.”
In January, she changed one thing. She put the phone charger in the kitchen.
“Not the bathroom,” she said. “The kitchen. Because the bathroom is too close. I had to walk past my daughter’s door and down the stairs to even see the screen.”
For the first eleven days, according to a note she kept on her fridge and showed me, she still went to the kitchen. “I would stand there in pajamas reading Slack,” she said. “But I had to be standing.” On the twelfth day, she got distracted by the kettle. She made tea. She drank it on the back porch. The phone stayed face-down on the counter.
She did not, she emphasized, follow a routine from a book. “I tried the 5am thing once. I lasted four days.” What worked, she said, was changing where the phone slept. Everything else followed from that.
Three months in, she had added: a glass of water before the tea, ten minutes of walking the dog before checking anything, and a single sticky note where she wrote “one thing” - the one thing that mattered for the day - before she opened her laptop. She did not call it a routine. “It is just what happens now,” she said. “I did not decide it. I decided where the phone sleeps.”
Her daughter, who is nine, has started asking for the porch tea, too. Maya pours her a small cup. They have not talked about why.
The advice Maya offers, when friends ask, is one sentence: “Move the charger.” She does not promise it will work. She says it worked for her, and she is suspicious of anyone who promises more than that.
Journalist on: Choosing between Postgres and DynamoDB
Section titled “Journalist on: Choosing between Postgres and DynamoDB”Engineers at Lattice Notify, a 50-person Series B startup, are scheduled to decide by Friday how to store data for the company’s first real-time notification system, a feature they are building under the additional pressure of a possible Slack partnership that would tenfold the projected workload within a year.
The decision will be debated at an architecture meeting on Wednesday at 2pm Pacific. Two senior engineers have taken visible positions in the week leading up to it.
Ana, the tech lead on the notifications project, said in an internal memo circulated Monday that she favors extending the company’s existing Postgres monolith with a new schema and a queue. “We have shipped at this scale before,” she wrote, citing two prior services that handle comparable write loads. The current ops surface, she noted, is “a single database the on-call rotation already knows how to operate.”
Marcus, a senior engineer on the same team, has argued for adding DynamoDB. According to a thread in the team’s design channel, he believes the notification access pattern - high-volume key-value writes with TTL reads - is “the workload DynamoDB exists for,” and that taking on the learning curve now is cheaper than migrating later under partnership pressure. He acknowledged in a follow-up message that the rollback path is, in his words, “not great.”
Priya, the product manager assigned to the project, said in a call this morning that she is agnostic between the options but wants a decision by end of week so the team can plan the next sprint. “I am not here to break the tie on engineering grounds,” she said. “I am here to make sure we get to one.”
The four engineers on the on-call rotation have not yet been polled formally, though two, who asked not to be named because the decision is not yet final, said separately that they would prefer the option that does not add a second pager. Both pointed to the same concern: that operating an unfamiliar database during the partnership push would compress their time to respond to incidents.
The architecture meeting will run until the decision is reached or until 4pm, whichever comes first.
The Insights analytics dashboard was scheduled to ship by the end of September. That commitment, made to the sales team and a handful of key customers in early Q3, will not be met.
Priya Voss, the director of product, confirmed the slip in a call last week. “We owe you a straight account of what happened,” she said. The short version: a mandatory migration of the company’s billing infrastructure, originally projected to consume six weeks of engineering time, ran to eleven. The migration - begun in July - was not optional. According to Voss, regulators had required it to be complete by October 1.
With most of the engineering team absorbed by the migration through late September, two options were on the table, according to Voss. The team could ship Insights on the original date with roughly half of its planned features built, or it could move the date and ship a complete product. “We looked hard at what we could actually deliver by September 30,” said Marcus Lin, the engineering lead on the Insights project. “It was not the product we described.”
The decision: Insights moves to Q1. No firm date has been set, but the team expects to begin the build in earnest in January, with a target ship window in late February or early March.
In the meantime, the team is releasing a CSV export of the underlying data Insights would have surfaced. The export ships in late September. It will not replicate the dashboard experience, but it will allow customers to pull the same data into their own analytics tools while the full product is under construction.
The sales team has received the same briefing. For customers who cited Insights as a factor in their contract decisions, account leads have been asked to schedule individual calls before the end of the month.
Priya Sharma joined the team on a Monday in late June, two months after the service had moved to daily deploys. By the Thursday of her second week, she had shipped a change to production. How the team got her there is worth reconstructing.
Marcus Webb, the team’s engineering lead, described the first morning as deliberately unhurried. “We blocked her calendar for two full days,” he said. “No standups, no ceremonies. Just setup and context.” According to Webb, the access checklist had been prepared the previous Friday: repository credentials, monitoring dashboards, the ticket tracker, the chat tool. Priya said she had never arrived somewhere and found everything waiting. “Usually you spend the first week chasing IT,” she said.
The codebase walkthrough came on Wednesday. Yolanda Reyes, the team’s senior engineer and the person Priya would shadow, said she built the session around a recent incident rather than architecture diagrams. “If you show someone the system through a failure, they understand why decisions were made,” Reyes said. Priya confirmed the approach worked. “I understood the on-call rotation after that conversation in a way I wouldn’t have from documentation,” she said.
The pairing arrangement started Thursday of week one. Priya and Reyes picked a backlog ticket together - a single-field validation change that touched three services. Priya owned the pull request; Reyes reviewed it. The change went out ten days after Priya’s first morning.
Webb said the goal was not only delivery. “There’s a difference between someone who can operate the tools and someone who trusts the team,” he said. “We were trying to get her to the second place.” Whether the approach generalizes is, according to Webb, still an open question. “Every engineer is different,” he said. “This one worked.”
Dana Reeves, who ran the client analytics group in the spring of 2015, gave me my first real assignment with a sentence I wrote down afterward: “You’re not ready, and that’s exactly why.”
The project was a full practice-wide reporting overhaul - six workstreams, forty-odd stakeholders, a go-live date that predated any reasonable preparation. I had been with the team eight months. Two colleagues with more experience were available and, by most measures, better positioned for the role. You put me forward anyway. Three people I later interviewed independently confirmed they were surprised by the choice.
What those accounts do not fully capture is what you did next. You did not take over. The project logs show seventeen steering meetings across four months; you attended nine. You asked questions in the ones you attended and stayed quiet in ways that forced me to be the person in the room with answers. Jamila Torres, who served as project coordinator at the time, recalled last year that she never once saw you redirect the room to yourself when I got something wrong. “She just let you figure out you were wrong,” Jamila told me. That may be the plainest description of mentorship I have encountered.
The reason I am writing now is not sentiment, or not only sentiment. Three weeks ago I put Marcus Webb, who joined my team fourteen months ago, in charge of a restructuring project he was not ready for. I stayed close. I did not take over. I watched him find the question he should have been asking two days after he stopped asking the wrong one. Somewhere during that stretch I recognized what I was doing and where I had learned it.
The record, as I can reconstruct it, shows you exercised considerable patience at a moment when taking the project yourself would have been faster and, in the short term, cleaner. What that patience made possible is the part I wanted you to hear from me directly.
The notebook entry from a Sunday in October read simply: “Did nothing today. Felt wrong.”
That was the third week of what I had called, in an earlier entry dated September 15, “the experiment” - one full day each week without work, without the chat tool, without what my therapist, Dr. Sandra Kline, described in a session that month as “productive anxiety, which is anxiety with better branding.”
The pull to check one more thing is not subtle. Three separate times that October Sunday, I picked up the phone and set it down again. The fourth time, according to a note I wrote that evening, I did not put it down.
The received wisdom on recovery and performance - at least the version I had absorbed from two years of productivity podcasts - held that rest was an input, a resource to be allocated in service of output. That framing, several people I had reported on in previous work told me, is the version most people actually operate under, regardless of what they say they believe.
What the record shows is harder to argue with. By November, after six consecutive weeks, the Sunday blank had started to do something unexpected. Monday mornings arrived with a steadiness I had not been tracking until I noticed its absence on the weeks I had broken the practice. A colleague, reviewing a draft I filed on a Monday in late November, described the piece as “unusually clear.” I did not tell her what the previous day had looked like.
The cost of the practice, as I documented it across those weeks, was real: the low-grade guilt of unread messages, the sensation that something important was accumulating just beyond the horizon of my attention. What it returned was less measurable but harder to deny. I had written, on December 3, that the day off felt less like lost time and more like a recalibration.
One person I spoke to about this discipline - a former colleague who had kept the practice for nearly four years - put it more directly. “The week doesn’t make sense without it,” he said. “You just can’t see that until you’ve done it long enough.”
The record suggests he was right.
Howard Bellamy, who joined Meridian Operations as a field coordinator in the spring of 1998 and never changed his title, walked out of the building on his last day holding a coffee thermos and a box of personal items small enough to carry in one hand.
Twenty-six years is a long time to stay in one role, and by most accounts Meridian gave Bellamy every opportunity to leave it. He declined each one, according to three colleagues who worked alongside him across different decades. “He knew what he was,” said Dana Reyes, a project lead who has been at the company for eleven years. “He wasn’t indifferent to advancement. He was just more interested in being useful than in being promoted.”
The distinction mattered. In Bellamy’s case, being useful meant becoming the organizational memory everyone else borrowed. When a client escalation hit in February 2019 - one that had the executive team pulling documentation going back to 2011 - it was Bellamy who produced the files within forty minutes, already annotated. The then-VP of operations, Marcus Foard, described the moment in a staff message last week as “the quietest save I have ever watched.” Foard has since moved to a different firm and offered the observation by email.
Bellamy mentored without a formal program. Three people now in senior roles at Meridian said separately that they attribute their tenure at the company, at least in part, to conversations with him - none of them scheduled at the time, none flagged as mentorship. He did not track outcomes. “Howard just showed up,” said Ellie Tan, now director of client services. “That was the method.”
His departure leaves the company without anyone who holds that length of institutional memory. Meridian has not announced a plan to address the gap.
The checkout rebuild shipped on a Thursday in March, fourteen months after the project started. The rollout held under peak load. The old checkout stayed live - serving real customers - for the entire duration of the rebuild.
“We were running two versions of the most critical flow in the product, simultaneously, for over a year,” said Dara Osei, the lead engineer on the project. “If anything broke, people noticed immediately.”
The rebuild began in January of the prior year, after cart-abandonment data flagged a persistent drop at the payment confirmation step. Jin Park, the product manager who wrote the original project brief, said the initial estimate placed completion at month ten. It slipped twice.
The first delay came in August, when a data migration planned for a low-traffic window ran long and exposed a latency issue in the new flow’s session handling. One engineer present that evening, who asked not to be named, described the mood as “four hours of very quiet group chat.” No customers were affected; the new flow was not yet live.
The second slip came in November, three weeks before a scheduled cutover. A code review turned up a race condition in the order-confirmation step - a path that would fire under concurrent load but would not appear in staging. “We had to make a call about whether to push or to delay,” Park said. “We delayed.”
The final rollout began on a Thursday evening and completed without incident. Osei said the team watched the error graphs in silence for the first twenty minutes.
By the following morning, Park said, the abandonment rate at the confirmation step had fallen. He described the result as “pretty much exactly what we thought we’d see, which is its own kind of outcome after fourteen months.”
When Petra Villanueva, a senior designer at a mid-size software firm, described her company’s return-to-office mandate to me, she reached for one word: “theater.” Management required three office days per week. Within a month, managers were badge-scanning for compliance while the actual project work continued over the chat tool, unchanged. “We drove forty minutes each way to sit in a room and do video calls,” she said.
Her firm’s experiment failed. That does not settle the debate. It documents a misuse.
The dispute, in weeks of reporting conversations with workers, team leads, and one operations director who asked not to be named, is not really about location. It is about which interactions benefit from proximity and whether the schedule protects those moments. Office advocates name trust-building and the unplanned exchange that reroutes a project. Remote advocates name recovered commute hours, a wider hiring geography, and the quiet that focused work requires. Both are accurate. Neither resolves the question.
Elena Marsh, who manages a team distributed across four time zones, said her group stopped arguing about headcount in the building and started arguing about the calendar. “That changed everything,” she told me. Her team now holds two shared anchor days per month, scheduled around decisions that benefit from shared physical presence. The rest is flexible. “People who never came in said it was the first time the office felt like it existed for them, not just for management,” she said.
Office-first leaders read that as insufficient. “Two days a month is a social club, not a working culture,” one operations VP told me, declining to be named. Fully-remote advocates worried the anchor days were a precedent. Both concerns deserve weight.
Neither side has produced, in the reporting I could do, evidence that mandatory full presence reliably delivers what its proponents promise - or that full flexibility alone sustains the trust distributed teams most often report losing first. The calendar is where that case gets made or broken.
A small team of product managers at a mid-size software company spent most of last spring doing what many teams do: copying customer feedback out of a chat tool and pasting it into a spreadsheet, then arguing in meetings about which items mattered most.
“We had five different lists and no one agreed on which one was real,” said Marcus Delgado, a product manager who helped test an early version of Tidemark, the new roadmap tool that its creator, Lander Software, plans to release next week.
Tidemark ingests customer feedback from multiple sources - email threads, support tickets, recorded interviews - and produces a ranked list of themes, sorted by frequency and the weight the team assigns to each channel. Teams can annotate each theme, mark its status, and export the result as a shared document for stakeholders outside the room. According to Lander co-founder Priya Osei, the goal was to replace the spreadsheet without replacing the judgment calls that teams still need to make themselves.
“We are not trying to tell you what to build,” Osei said in an interview this week. “We are trying to get everyone looking at the same inputs before that conversation starts.”
Lander is not the first company to pitch roadmapping software to small teams. Several tools already address parts of the workflow, and an analyst covering the product-management software segment told me that adoption often stalls when tools require too much setup before they are useful. Osei acknowledged that concern directly. Tidemark is designed to connect to existing sources without a dedicated integration team, she said, though Lander has not yet disclosed which connectors will be available at launch.
For prospective users, access requests open June 28. The full release follows one week later.
The year ended without a bow. The record shows what happened; what to make of it remains unsettled.
The Meridian project was shut down in late October. The head of operations shared a status note through the ticket tracker on October 21 that described, in its entirety, “no path to sustainable adoption.” Three people who worked on the project, speaking afterward on the condition of anonymity, said the outcome had been clear since August. One put it this way: “Everybody knew in August. The meeting in October was for the calendar.”
That reading is disputed. Dara Osei, who served as Meridian’s external advisor through the summer, said in a written message after the shutdown that the August numbers “did not, by themselves, close the door.” She pointed to a restructuring proposal submitted in September. Whether anyone in a position to act on it read it carefully is a question the correspondence does not answer.
I had poured eighteen months into that project. This is documented. What I got wrong is harder to locate in the record - not because the record is absent, but because the errors were distributed across decisions that each looked defensible at the time.
Tomás Reyes, who built the early architecture and who I had worked alongside for five years before Meridian, sent a message in November that said only: “I think we needed to do this differently and I’m not sure I can say more than that right now.”
He has not elaborated. I have not asked him to.
December produced no resolution. A friend who read an earlier draft of these notes called them “unfinished in the right way.” That is probably the most accurate account of where things stand.
Appears in diff-pairs
Section titled “Appears in diff-pairs”- journalist vs columnist (varies voice)
- journalist vs researcher (varies voice)
- journalist vs columnist (varies voice)
- journalist vs researcher (varies voice)
- journalist vs columnist (varies voice)
- journalist vs researcher (varies voice)