Recommendation Letter

A letter by someone who knows a candidate, advocating for them to a third-party decision-maker.

Recommendation Letter

A recommendation letter is written by someone who knows a candidate to advocate for them to a third-party decision-maker - an admissions committee, an employer, a board. It speaks about the candidate to an evaluator, citing specific evidence of their qualities from firsthand experience. Unlike a cover letter, in which the candidate advocates for themselves in their own voice, a recommendation letter is written by a third party vouching for someone else - its credibility comes precisely from the fact that the writer is not the person being chosen.

The genre has a specific rhetorical structure: the writer establishes their relationship to the candidate and the basis for their judgment, then presents concrete evidence from direct observation, and closes with a direct endorsement. The evidence is what separates a letter that helps from one that does not. Evaluators read many letters that assert the candidate is “hardworking” or “a pleasure to work with.” A letter that describes a specific situation where the candidate made a decision under pressure, solved a novel problem, or demonstrated a quality that the evaluator cannot see from the application file - that letter carries weight.

The writer’s credibility is co-extensive with their specificity. A letter that praises without evidence reads as obligatory. A letter that reconstructs a specific moment, names the stakes, and connects the candidate’s behavior to a conclusion signals that the writer paid attention and that the praise is earned.

Canonical template

[Header: Writer name, title, institution, date]
[Optional: Letterhead block]

Dear [Admissions Committee / Hiring Manager / Selection Committee / Name],

[Opening paragraph: state the writer's relationship to the candidate, how long and in what
capacity they have known them, and the letter's purpose - recommending for [specific
program/role/opportunity].]

[Body paragraph 1: first piece of specific evidence. Describe a concrete situation, project,
or observation from direct experience that demonstrates a quality relevant to what the evaluator
is assessing. Name the context, the candidate's actions, and the outcome or signal.]

[Body paragraph 2: second piece of specific evidence. Address a different dimension - a
complementary quality or a situation that shows range or depth. Optional: preempt an observable
gap with context the file does not contain.]

[Closing paragraph: direct endorsement. Name the candidate, name the opportunity, and make the
recommendation unambiguous. Optional: offer to discuss further.]

[Signature: writer name, title, institution, contact information]

When to use

When a candidate needs a credentialed third party to vouch for qualities an evaluator cannot assess from the application file alone; applying to academic programs, fellowships, board positions, or roles where the selection process explicitly requests letters of recommendation; when the writer has direct, firsthand evidence of the candidate’s performance, character, or potential from sustained professional or academic contact; when the stakes of the evaluation are high and the evaluator needs a human voucher who can be held accountable for the assessment; when the candidate’s record contains gaps, pivots, or unconventional elements that a trusted voice can contextualize with direct observation.

When not to use

When the writer does not have genuine direct experience with the candidate (a letter without firsthand evidence is worse than no letter); when the candidate can and should speak for themselves, as in a cover letter or personal statement; when the request is informal or relational and a brief note of introduction would serve better than a formal letter of endorsement.

Pairs well with

senior-consultant, friendly-mentor, confident, diplomatic, narrative-case-study

Often confused with

cover-letter: A cover letter is written by the candidate in their own voice, making the case for one specific person for one specific role - it advocates for the writer themselves to an evaluator who is already assessing candidates against a known set of needs. A recommendation letter differs fundamentally in who holds the pen: the writer is a third party, not the person being evaluated, and the letter’s authority comes precisely from that separation. Where the cover letter has the applicant argue their own qualifications directly, the recommendation letter has a witness vouch for someone else based on direct observation.

Tells

• Opens with the writer’s name, title, and direct relationship to the candidate, establishing the credibility base before the argument begins
• Cites specific, named situations from firsthand observation rather than general characterizations
• Written in third person about the candidate, from the first-person perspective of the writer
• Closes with an unambiguous direct endorsement, often naming the writer as available for further contact
• Evidence is tied to qualities the evaluator is assessing, not qualities the candidate emphasizes about themselves
• The writer’s institutional standing or length of relationship is made legible early in the letter

Anti-patterns

• Filling the letter with unsubstantiated praise - “exceptional leader,” “outstanding communicator” - without a single concrete example from direct observation - Evaluators discount undifferentiated praise immediately because every letter contains it. Specificity is what moves a letter from obligatory to influential - a named situation the writer witnessed outweighs any number of superlatives.
• Writing as though the letter is a cover letter - framing the candidate’s qualifications from the candidate’s perspective rather than from the witness’s direct observation - A cover letter is written by the candidate advocating for themselves in their own voice to an evaluator already assessing a known set of needs. A recommendation letter derives its credibility from the writer’s third-party position as witness; conflating the two voices collapses the distinction that gives the letter its weight.
• Damning with faint praise - technically recommending the candidate while qualifying every strength with a hedge or withholding the full endorsement - Evaluators read for the endorsement. A letter that cannot commit signals that the candidate does not merit full backing; a writer’s hesitation reads as a warning, not a qualification.
• Describing the candidate in terms the writer could have assembled from a CV rather than from direct observation - A letter that could have been written without ever meeting the candidate signals the writer did not pay attention or lacks genuine firsthand experience - both outcomes damage the letter’s credibility.

Failure modes

• Over-endorses until every sentence is a superlative - “the best candidate in twenty years,” “truly exceptional in every way” - so the letter reads as undifferentiated hyperbole rather than a calibrated expert assessment - Reserve superlatives for genuine cases. One calibrated, specific superlative in an otherwise evidence-grounded letter lands harder than a letter in which every sentence claims the top tier. The writer’s credibility is the letter’s currency, and hyperbole spends it.
• Third-party authority tips into the letter becoming about the writer’s own credentials, relationships, or judgment rather than about the candidate - the letter becomes a showcase for the writer’s discernment rather than evidence of the candidate’s qualities - Read each paragraph and ask whether its central subject is the candidate or the writer. If the writer’s own history or standing is consuming more space than the candidate’s demonstrated qualities, redirect the paragraph to the candidate.
• Specificity and formality tip into an over-structured enumeration - each paragraph names a quality and supplies exactly one supporting sentence - producing a letter that reads as a formatted checklist rather than a witness’s testimony - Recommendation letters earn their persuasion from the texture of lived experience. Let the evidence drive the structure; an observation that requires two paragraphs to convey properly should have two paragraphs rather than being compressed into a formula.

Instruction

Write as a recommendation letter. You are a credentialed third party - an employer, professor,
supervisor, or colleague - who has direct firsthand experience with the candidate. Your credibility
as a recommender is the letter's core asset; protect it by grounding every claim in specific,
named evidence from your own observation. Open by establishing your relationship to the candidate
and the letter's purpose. In the body, present concrete situations, projects, or decisions you
observed directly that demonstrate the qualities relevant to what the evaluator is assessing. Do
not assert qualities the reader cannot verify from your description; name what happened, who the
candidate was in that moment, and what it showed. Close with an unambiguous endorsement. This is
not a cover letter: you are a witness vouching for someone else, not an applicant making the case
for yourself. The letter's persuasion comes from the writer's third-party authority and from the
specificity of the evidence, not from enthusiasm or credential-stacking. Typical length: 400-700
words.

Template

See the Recommendation Letter template.

Related

Pairs well with

Senior Consultant, Friendly Mentor, Confident, Diplomatic, Narrative Case Study

Avoid with

Skeptical, Playful, Urgent

Often confused with

Cover Letter

Examples

Whether the team should move to async-first standups

Jordan Ashworth Director of Engineering, Fernbridge Software August 12

Dear Hiring Committee,

I am the Director of Engineering at Fernbridge Software, and Maya Reyes has reported to me for the eighteen months she has led our Platform engineering team. I am writing to recommend her for the Director of Engineering role she is currently pursuing with your organization. Rather than describe her in general terms, I want to walk through one initiative I watched her run from diagnosis to permanent adoption, because it shows the kind of judgment a director role actually requires better than any summary could.

Eighteen months ago our team scaled from six engineers to eleven, spread across four time zones: US Pacific, US Eastern, the UK, and India. Our daily standup, held at 9am Pacific, stopped being a minor inconvenience and became a structural equity problem - 9am Pacific falls at 9:30pm in India, and our Q1 attendance data showed India-based engineers averaging 3.2 of 5 weekly standups against 4.6 for engineers in the US. Maya did not treat the gap as an attendance issue to manage. She pulled the data, traced the shortfall to the clock rather than to disengagement, and audited the meeting itself, finding that of its fourteen minutes, only about four produced content that changed anyone’s behavior - a blocker raised, a dependency flagged. Before proposing a fix, she wrote up three alternatives in a decision record: rotating the meeting time, dropping the standup altogether, and adopting a paid async tool. She rejected each with a stated reason rather than defaulting to the first idea that occurred to her. The plan she landed on - a three-field async post to a shared channel plus a single weekly session reserved for discussion that actually needed everyone live - is not exotic on its own. What told me something about her as a future director was that she made the reasoning legible before asking eleven people to change a daily habit, and scoped the change as a 30-day trial with a fixed retrospective instead of a quiet permanent switch.

The trial was not clean, and I want to describe the rough patch because of how she handled it. In its second week, a blocked engineer’s flag went unanswered through a morning triage pass and did not get resolved until roughly four hours after it was posted - a real gap under real stakes, not a hypothetical one. Maya did not wait for the scheduled retrospective to fix it. She built a dedicated mention scan into the next morning’s process and, that same week, pinned exemplar posts to correct updates that were running long against the format’s own sixty-second-skim goal. Both fixes shipped before I had to ask for either. On-time posting rose from 78 to 85.5 percent within the trial’s first two weeks alone, and by its final two weeks, our India-based engineers were posting every weekday for the first time in this team’s history; the team voted to keep the new format permanently. I have managed people who treat a rollout’s first real failure as a reason to quietly revert. Maya treated it as data, kept the trial moving, and reported progress to me and to peer managers every week in writing, in the same plain, evidence-first register she used to propose the change in the first place.

I recommend Maya for this role without reservation. A director’s job is to make a structural call, show the reasoning behind it, and stay accountable when the first version does not work cleanly - I have watched her do all three under real pressure, more than once. She would bring the same rigor to your organization that she brought to rebuilding how an eleven-person distributed team talks to itself. I am glad to discuss further by phone or email.

Jordan Ashworth Director of Engineering, Fernbridge Software jordan.ashworth@example.com (555) 555-0198

Designing a sustainable morning routine

Priya Nakamura Director, Care Access Programs Aldergate Health Network June 29, 2026

Dear Members of the Selection Committee,

I am writing in support of Jordan Voss’s application to the Sustainable Systems Fellowship. I have been Jordan’s direct supervisor at Aldergate Health Network for five years, since they joined as a Program Manager in June 2021, and I recommend them without reservation. Your program description asks for evidence that a candidate’s operating discipline holds up without external enforcement - not just under deadline pressure. I want to offer two examples, one from work and one from Jordan’s own life, because together they answer that question more honestly than either would alone.

The first is professional. During my first year working with Jordan, our team kept re-litigating scope decisions that had already been made. A given month’s priorities would get reopened in week three because nobody could point to when or why a call had been settled, and the same argument would happen twice. Jordan proposed a one-page decision-record template: date, decision, who was consulted, and what we agreed not to revisit without new information. I was not convinced anyone would fill it out consistently. Jordan did, on every scope change across the initiatives they ran, and within a couple of quarters other program managers had adopted it because it kept saving them the same argument. That template is now how our team documents decisions across three concurrent care-access initiatives. It did not happen because I asked for it. It happened because Jordan noticed a real cost and built a small, unglamorous habit that removed it.

The second piece of evidence has nothing to do with work, and I think it is the stronger of the two. Jordan mentioned in a one-on-one this spring that they had tried and failed, three separate times over the past year, to stop reaching for their phone first thing in the morning. Rather than trying a fourth time the same way, they wrote a short decision record for their own mornings: four modules in a fixed order - water, light, movement, ten minutes of paper planning - before the phone was allowed out of the kitchen. They logged completion daily in a version-controlled, public repository and reported the real numbers after thirty days rather than a flattering summary: twenty-three of thirty mornings completed in full, the wake-time target held on nineteen, and two specific failure patterns named outright, Tuesdays and travel days, instead of smoothed over. Nobody was checking. There was no quarterly review, no team depending on it, no one to disappoint but Jordan. They built the habit anyway, measured it honestly, and are now revising the design for month two instead of declaring victory or quietly letting it lapse. That is the same operating discipline your criteria describe, this time with no enforcement mechanism except the one Jordan built for themselves.

I recommend Jordan Voss for the Sustainable Systems Fellowship without qualification. In five years I have found them to be disciplined in the specific sense your program is asking about: not intensity under supervision, but consistency when no one is watching. I would be glad to speak with the committee directly if that would help.

Sincerely,

Priya Nakamura Director, Care Access Programs Aldergate Health Network priya.nakamura@aldergatehealth.org | (303) 555-0142

Choosing Postgres vs DynamoDB for a new service

Ana Rivera Tech Lead, Notification Service Lattice Notify July 8, 2026

Dear Engineering Leveling Committee,

I am Marcus’s tech lead and have been for the past two years, most recently completing his H1 2026 performance review. I am writing to recommend him for promotion to Staff Engineer. The case rests heavily on one week this May, because it is the clearest example I have of both halves of what this level requires: technical judgment strong enough for the rest of us to build on, and the maturity to subordinate that judgment to the team’s decision once it lost.

When the notification service needed a new persistent datastore this spring, Marcus owned the technical case for DynamoDB. He did not build that case from a slide deck. He ran an actual spike, documented in experiments/notify-ddb/, against the service’s real access pattern - write-heavy, point-lookups by user - and tested it against our real growth numbers: 500K events/day at launch, with a 10x growth scenario in 12 months if the pending Slack-partnership deal closes. He presented the analysis at Wednesday’s architecture meeting, and it held up under questions, because his own writeup was honest about DynamoDB’s cost as well as its fit. He documented, in that same spike, that adopting it would double our operational surface for the 4-person on-call rotation that already runs our primary Postgres cluster. He built the strongest case for the option the team did not choose, and he built it well enough that the reason we did not choose it is written down in his own analysis, not mine.

The team decided against his recommendation. I made the operational-capacity argument in that same meeting, and the room weighted the cost of a second datastore over the access-pattern fit Marcus had correctly identified. What matters more to this recommendation is what he did next. Rather than leave Priya to referee a split decision the following morning, Marcus spent that evening working with me to turn two positions into one recommendation. The 5M events/day revisit threshold written into ADR-0023, the mechanism that keeps his original concern alive as a tracked trigger instead of a buried disagreement, is his language, not mine. If the committee pulls his H1 review, you will also see a Partially Met rating: written confirmation of that same threshold lagged the verbal agreement by a day, and I had to chase it down ahead of Friday’s 11am lock. That is accurate, and it is the one place his execution has not yet caught up with his judgment. It is also, as of that review, a named commitment with an effective-immediately deadline attached, not a quiet pattern I am hoping he outgrows. I would rather the committee hear that from me, with the context, than find the rating alone and wonder what it means.

Marcus is ready for Staff Engineer. The level asks for technical judgment the rest of the team can build on, and for the discipline to turn a technical loss into a better team decision instead of a grudge. I watched him do both in the same week, on a decision that now runs our production notification traffic. I recommend him without reservation, and I am glad to discuss any part of this further.

Sincerely, Ana Rivera Tech Lead, Notification Service Lattice Notify arivera@latticenotify.com

Telling stakeholders a committed feature is being cut this quarter

Owen Marsh VP of Product, Meridian owen.marsh@meridian.io November 12, 2026

Dear Fellowship Selection Committee,

I am writing to recommend Maya Chen, Product Lead at Meridian, for this year’s Product Leadership Fellowship. I have managed Maya directly for the past two years, and this letter draws on firsthand observation of her work, most recently a difficult product decision I watched her make and communicate this past quarter. I recommend her without reservation.

Maya’s team entered Q3 with a firm commitment to ship our Insights analytics dashboard, a date Sales had already given to our committed accounts. Early in the quarter, a mandatory billing-system migration, required for regulatory and contract reasons, surfaced scope no one had seen at planning and consumed the engineering capacity Insights depended on. Maya could have shipped Insights on the original date anyway. She did not. The build was missing saved-view persistence and scheduled-report delivery, the two capabilities those accounts had specifically asked for, and she judged, correctly, that releasing without them would mean delivering a product that failed the exact use case it had been sold against. Rather than let the date slip quietly or split her team across two workstreams that were both then at risk, she made the harder call explicitly: defer the dashboard to Q1 2027, let the billing migration land clean, and ship a CSV export of the same underlying data as a stopgap before the quarter closed. She put the decision in writing rather than letting it happen by default through slippage, and the export shipped September 26, inside the original window she had just told customers she was missing on the larger deliverable. That is the kind of call most people avoid making explicitly, because it is easier to hope a date holds than to say in writing, this early, that it will not.

The second thing worth telling you, because it is harder to see from a project file than the decision itself, is how Maya handled the people on the other side of it. She flagged the project’s status as at-risk as soon as the date stopped being defensible, rather than waiting for the miss to surface on its own later. Written notice reached all four affected accounts by mid-September, and she and Jordan Park, her partner in customer success, arranged individual calls for the accounts with the strongest dependency on the original date instead of sending one form notice to everyone. When she brought the deferral to me and the rest of leadership, she did not ask for open-ended patience; she asked for one specific thing, sign-off to cite March 13, 2027 to customers as the new target, so the team could set an expectation in writing instead of leaving four accounts to guess. I want to be direct about the outcome here, because a recommendation letter that only lists successes is not a useful one: Insights did not ship on the date it was promised. What I am recommending is the judgment and the communication in her response to that miss, which tells you more about how she will handle the harder calls this fellowship exists to prepare people for than a clean record would.

I recommend Maya Chen for the Product Leadership Fellowship without hesitation. She is one of the strongest product leaders I have managed, not because her record is free of misses, but because of how directly she owns and communicates the ones that happen. I would be glad to discuss this further and can be reached at the email above.

Sincerely,

Owen Marsh VP of Product, Meridian owen.marsh@meridian.io

Getting a new engineer productive in their first two weeks

Mei Engineering Manager, Backend Services Team Northlane Systems Monday, July 6, 2026

Re: Two-Week Onboarding Review - Priya Rao

Dear People Partner Team,

I was Priya Rao’s hiring manager for the Software Engineer, Backend Services role, and I am writing to recommend we close her two-week onboarding review without reservation and move her onto the team’s standard track, on-call rotation included on the normal week-five schedule. I read Priya’s file back in April and interviewed her before we made the offer, but none of that is what this letter is built on. This letter is built on two weeks of watching her work, which is a different kind of evidence and a more reliable one.

Priya’s application put her nearly four years of on-call experience at Larkspur Systems front and center, and she was upfront about the part of it that did not map cleanly onto this role: her background there was billing and invoicing, not the order and checkout paths this team owns. That gap was real on paper. It closed inside three days. Her access and local environment were working by Monday afternoon of her first day, and by Wednesday she had located our test harness and our naming conventions without being pointed to either, and traced a live checkout request through the system on her own. In Thursday’s design session for her first change, she asked what happens when two of those events arrive out of order, a scenario the rest of us had quietly designed around without ever saying it out loud. That is not a line from a resume. That is a new hire finding a gap in the team’s shared blind spot in her first week.

The second thing I want to put in front of you is not technical at all. Priya sat in on a live incident and its handoff call in her first week and came out of it able to walk through our escalation path without notes. She completed the second on-call briefing, the alert routing and escalation drill, on Monday, June 29. She showed up to the team’s Friday sync in her first week and contributed to the architecture discussion without being asked a direct question first. Three people on the team now have ongoing async threads with her that have nothing to do with the onboarding plan I wrote. Her first change merged and deployed this past Friday, July 3, with Arjun pairing on the review, and she ran the deploy herself. None of that shows up in a personnel file. It is the difference between a new hire who can do the work and one the team already trusts to be in the room for it.

Two weeks is a short window to build a recommendation on, and I do not want to overstate what it can prove. It cannot tell you how Priya handles a bad quarter, a difficult reorg, or her first production incident as the owner rather than the observer. What it can tell you, because we built this onboarding process specifically to surface real evidence fast rather than wait and hope, is that she is safe to trust with real work, that she asks the right questions before anyone has to tell her to, and that the team already treats her as one of its own rather than someone still finding her footing.

I recommend Priya proceed onto the standard engineering track without qualification, including the normal week-five entry into the on-call rotation. She is exactly the hire this team needed, and two weeks in, she is already carrying her share of it. I am glad to discuss any of this further.

Mei Engineering Manager, Backend Services Team Northlane Systems mei@backend-services.example.internal | @mei in #backend-services

Writing to thank a mentor who shaped your career

Sable Marchetti Director, Data Platform Engineering, Ashgrove Systems June 15, 2026

Dear Mentorship Award Committee,

I am writing to nominate Dana Forsythe, Senior Director of Data Platforms, for this year’s mentorship award. I have known Forsythe for ten years, since she put my name forward for a role I did not believe I was ready for, and I have spent most of the years since watching her do the same thing, on purpose, for other people. I want to describe one decision and the pattern behind it, because together they show something a general reputation for being “supportive” could not: that what Forsythe does for the people she develops is not instinct, it is a deliberate and repeatable method.

In March 2016, Forsythe was staffing the lead role on the Alderton platform migration, a cross-functional program with senior stakeholders already watching the outcome. The safer choice was an established mid-level manager who had led projects at that scale before. Forsythe put my name forward instead. I told her I was not ready. She did not argue with me about my own readiness; she told me what she had actually observed in two smaller engagements I had carried, and moved forward with the nomination anyway. For the length of the project she stayed close: she attended my first two stakeholder meetings and said almost nothing, and when I got something wrong in the third, she corrected me afterward, in private, not in the room. Once that summer, in a moment of genuine panic, I offered to hand the project back to her. She declined. The migration shipped the following spring, and I ran the post-mortem without her in the room.

That decision was not a one-time bet, and I am not the only evidence of it. Over the ten years since, Forsythe has kept to the same three moves with the people who report to her: nominate before they feel ready, stay visibly available, and let them make the call themselves rather than making it for them. I know this is a method and not a personality trait because I have since tested it myself. In February 2026 I nominated a colleague, Priya Osei, to lead our Cassava data-pipeline rebuild over real skepticism about her readiness. In the third week of March, when Osei stalled on the handoff logic, I recognized the exact moment Forsythe would have stayed quiet instead of stepping in, and I made myself do the same, though it was harder than I expected. Osei is now four weeks ahead of her original schedule. I did not learn that discipline by reading about it. I learned it by being on the receiving end of it, which is a more reliable kind of evidence that it works.

I recommend Dana Forsythe for this award without reservation. The strongest evidence I can offer is not a character testimonial, which I could have written without any of the above, but a method that survived a ten-year transfer intact: Forsythe used it on an unproven analyst who did not believe she was ready, and it worked again, unmodified, when that analyst used it on someone else. That is not two people getting lucky in the same way. That is a discipline, and Forsythe is the reason a second person now has it. I am glad to answer any questions the committee has.

Sincerely,

Sable Marchetti Director, Data Platform Engineering, Ashgrove Systems sable.marchetti@ashgrovesystems.io

Reflecting on keeping a discipline of rest

Marcus Reilly Senior Director of Operations Email and phone withheld July 1, 2026

Dear Hiring Team,

I am writing to recommend Daniel Weiss for the Operations Lead role on your team. I have been Daniel’s manager for three years. Some time in that stretch, I became, by his own account, the person who first made him take seriously the idea of keeping one full day away from work each week. I mention this because my knowledge of Daniel does not stop at his ticket queue. I have watched him build a hard personal commitment, watched it fail outright once, and watched him rebuild it with more rigor than most people bring to their actual job descriptions. That same rigor is what I want to speak to here, because it is the clearest evidence I have of how he will operate in a role like this one.

The clearest instance came on a Monday morning in June. Two problems had been stalled for the better part of a week - a vendor escalation and a scheduling conflict that three teams had been unable to untangle - and I had stopped expecting either to move before Friday. Daniel had held his rest day the day before: phone away, nothing checked, per a rule he has kept since March. He came in Monday and cleared both within a few hours, more cleanly than the week’s stuck momentum had led any of us to expect. I did not connect the two things myself at first. Daniel did, and when he walked me through the pattern he tracks - decision quality that degrades across a long stretch and resets after a genuine stop - I went back through our team’s recent history and could not find a counterexample. Operations work runs on judgment that holds up under fatigue. Daniel is the only person on my team who has built an actual system for protecting that judgment instead of hoping it survives the week.

The second thing I want to name directly, because you may see it yourself if Daniel shares any of his own notes on this period: the practice did not start cleanly. An earlier attempt lasted six weeks in early 2025 before a deadline overran it, and it was eleven months before he tried again. I watched the deadline that ended the first attempt, and I would not have bet on a second attempt happening at all. What I did not expect was that he would come back to it unprompted, with a short written record of exactly why the first attempt failed and what he intended to do differently, and that he would then track it week over week rather than trust his own sense of how it was going. He has told me directly, without my asking, that one part of it is still unresolved - a habit of privately tallying whether a given rest day was “worth it” - rather than rounding the whole effort up to a finished success. In three years, that is the most consistent thing about Daniel: he names the part that is not working before anyone makes him.

I recommend Daniel for the Operations Lead role without reservation. The role rewards people who can hold a system together under pressure and tell the truth about where it is fraying. I have three years of watching him do both, under conditions nobody designed to make him look good. I am glad to discuss this further by phone or email if it would help your decision.

Sincerely,

Marcus Reilly Senior Director of Operations Email and phone withheld

Marking a long-serving colleague's departure

Carolyn Marsh Operations Lead, Crestfield Group July 8, 2026

Re: Letter of Recommendation - Howard Thayer, Dayton Nonprofit Operations Fellowship

Dear Members of the Selection Committee,

I was Howard Thayer’s manager at Crestfield Group. I completed his final performance review this year, closing twenty-six years of service as Operations Coordinator, a role he held without interruption from June 2000 until his retirement on June 27. I am writing to recommend him for this year’s fellowship cohort, and I want to spend this letter on something his application will not show you: what Howard actually does when nobody else in the room knows what to do next.

In his final two months at Crestfield, Howard worked across a series of sessions with two colleagues, Dana Reyes and Marcus Okonkwo, to document operational knowledge that had never been written down in twenty-six years, most notably four utility vendor contacts that existed only in Howard’s personal records, with no other documented escalation path for that scope of work. He did not treat this as an exit formality. He treated it as a project with a real deliverable: a completed incident-response runbook covering vendor escalation paths and the decision sequence the team should follow when the automated alerts do not tell the full story. I have watched people leave a role and hand over a folder of loose notes on their way out. Howard handed his team a system they are now running without him, which is a different achievement, and it is exactly the skill your fellowship asks its advisors to bring into organizations that have not built that system yet.

The second thing I want the committee to know is harder to put in a file, which is itself part of the point. Howard mentored colleagues informally for the whole of his tenure without ever holding a title that said so. When we asked people who had worked with him to contribute to an internal archive before his last day, six of them did, including Priya Sandhu and Ben Holter. What they described was consistent across all six accounts: how Howard framed a problem for someone who was already panicking, how he absorbed a situation fully before he said a single word about it. Not one of them described being supervised by him. They described him being there. That is a specific and uncommon posture, helping without asserting authority over the person you are helping, and it is precisely what a fellowship advisor needs when placed with an organization that does not report to him and never will.

I expect Howard’s file reads narrower on paper than it should: one employer, one title, twenty-six years, an associate’s degree in business management earned in 1999. He never sought a different title, and Crestfield never gave him one that matched what he had actually taken on. That was as much his choice as the organization’s; he stayed where the work was rather than chasing a title that would have described it better. The vendor relationships he built from nothing, the incident judgment nobody else on the floor carried, the mentorship six colleagues asked unprompted to document before he left: none of it required a title to be real. I would not want the shape of his resume mistaken for the shape of his experience.

I recommend Howard Thayer for this fellowship without reservation. Any organization he is placed with will get someone who builds the parts of an operation that never make it into a job description, and who does it quietly enough that you have to go looking for the evidence, the way I have tried to lay it out for you here. I am glad to discuss any of this further with the committee.

Sincerely, Carolyn Marsh Operations Lead, Crestfield Group cmarsh@crestfieldgroup.internal

Marking the team shipping a hard, long project

Priya Nakamura Engineering Lead, Thornbury Retail priya.nakamura@example.com July 24, 2026

Dear Hiring Committee,

I am writing to recommend Jordan Osei for the Staff Software Engineer position on your team. I have managed Jordan directly for two years on our Platform Engineering team, most recently through Project Halyard, the fourteen-month rebuild of our checkout platform that closed out this June. That project put Jordan in front of the kind of decision a resume line cannot fully convey, and I recommend Jordan for this role without reservation.

During the dress rehearsal ahead of our originally planned May launch, Jordan found a race condition between the payment processor callback and the session store, a defect our automated test suite had not caught. A smaller patch was available that would have preserved the May date, and taking it would have been the easy call with the team already behind schedule. Jordan turned it down, judged that the callback handler needed to be rewritten rather than patched around, and delivered that rewrite personally over a single weekend. The fix cost eleven days against the launch date. It also held: the checkout cut over on June 13 and cleared its first full weekend under real peak traffic, June 13-14, with no rollback and no defect in that code path. I have watched engineers take the faster, riskier option under exactly this kind of pressure and be right often enough that nobody questions it until the one time they are wrong. Jordan did not take that bet.

The part I would put in front of you next is less dramatic, but it tells you more about how Jordan operates day to day. The rewrite solved the immediate defect, but it also meant the checkout’s payment callback path now lived in one engineer’s head, with the legacy system it used to fall back on scheduled for decommission this year. I raised that as a development area in Jordan’s last review, not as a complaint but as a real operational risk. Jordan did not treat it as something to manage before the next review cycle. In the weeks since, Jordan has been pairing with another payments engineer on the shim-removal work in that same part of the codebase, and a design note walking through the race condition and the rewrite is already underway ahead of its own August deadline. A resume can tell you Jordan fixed a hard bug under pressure. It cannot easily tell you that the same person treated a single point of failure I flagged as something to close immediately, not something to defer, and had already started before I had to raise it a second time.

I recommend Jordan Osei for the Staff Software Engineer role without hesitation. The technical judgment is real: Jordan reads a system closely enough to catch what a passing test suite missed, and chooses the correct fix over the convenient one even when the schedule has no room for it. I would ask you to weigh the second story just as heavily, because it is the one that tells you what happens on your team after the first hard call is behind everyone. I would be glad to discuss either in more depth and can be reached at the email above.

Sincerely,

Priya Nakamura Engineering Lead, Thornbury Retail priya.nakamura@example.com

Arguing a public position on return-to-office

Devon Marsh VP of People Operations, Brackenridge Group devon.marsh@brackenridge.io | (614) 555-0161 December 15, 2026

Dana Okafor VP of People, Wrenfield Analytics Denver, CO

Dear Ms. Okafor,

I am the VP of People Operations at Brackenridge Group, and I have managed Priya Ahluwalia directly for the past three years while she has led our cross-functional Policy Working Group. I am writing to recommend her, without reservation, for the Director of People Operations role at Wrenfield Analytics. Priya shared the posting with me, and its first listed priority is the same stalled return-to-office decision I watched her solve here, from the inside. I want to tell you what her application file does not show you.

Roughly eighteen months ago, Brackenridge was operating under an undefined “flexible” work-location policy that satisfied no one and was starting to cost us real hiring ground outside Columbus. Priya chartered a working group across HR, Facilities, Engineering, and Legal, and she did not let it become another committee that produced a memo nobody acted on. She drove it to a ratified decision, now ADR-0012, and wrote the case for it herself in a document she titled Position Brief v2. Before either side of the internal debate could relitigate the decision in the hallway, she had already answered both objections in writing: the office-first argument that trust requires daily proximity, and the remote-only argument that mandated presence narrows the talent pool and burdens caregivers and candidates outside commuting range. I sat in the review meeting where a senior director told her, to her face, that the anchor-day model was “a compromise dressed up as a decision.” Priya did not get defensive, and she did not soften her answer to keep the peace. She said it was not a compromise where both sides get less - it was a trade, protected collaboration time in exchange for real flexibility on every other day - and she asked him directly whether he had a better trade to offer. He did not. I am not summarizing a document for you here. I watched that exchange happen.

I want to be direct about something a shorter reference might leave out. In Priya’s second-quarter performance review, I rated one part of this work as only partially met. Facilities had already published a room-booking policy that assumed five-day attendance. HR had not taken a position at all. The two tracks were headed for a collision with the public announcement, and I told Priya plainly that a well-argued position nobody has the authority to execute is not yet a policy. She did not ask me for more time on the rating. She set her own deadline, brought Facilities and HR into the same room, and came out of it with a named decision owner and a room-booking policy that matched the anchor-day schedule, ahead of the company-wide announcement. That gap is closed now - I am telling you about it not because it reflects poorly on her, but because it does not, and I would rather you hear the whole arc from me than find half of it in a reference check later.

Priya Ahluwalia can walk into Wrenfield and do again, deliberately, what she has already done once under real pressure: take a stalled, adversarial return-to-office debate and turn it into a decision that both sides can live with, one that operations will not quietly undermine six months later. I recommend her for the Director of People Operations role without qualification, and I would be glad to speak with you directly about her work here. My direct line is above.

Sincerely, Devon Marsh VP of People Operations, Brackenridge Group

Announcing a new product to an outside audience

Renata Okafor Co-Founder and CEO, Tidemark renata.okafor@tidemark.io July 13, 2026

Dear Meridian Fellowship Selection Committee,

I am Renata Okafor, co-founder and CEO of Tidemark, and I have worked directly with Marisol Veen since she joined as Head of Product in February 2024. I am writing to recommend her, without reservation, for the Meridian Product Leadership Fellowship. Marisol reports to me, and over the past two and a half years I have watched her make the calls that decide whether a product survives its own launch. Two of those calls are worth describing in detail, because together they show a range that a single success story would not.

The first is a positioning decision she made ten days before Tidemark’s public launch on June 30. The team had three credible ways to introduce the product: as a category (“a roadmap tool”), as an aspiration (“ship the right things faster”), or as a problem (scattered feedback with no shared, ranked view). Marisol argued for the third option in a written RFC on June 20, against real preference on the team for the more familiar category label, and she was not arguing from instinct. She had already run twenty-two early-access teams through the full feedback-to-roadmap workflow, and every one of them had named the same scatter problem at intake without prompting, so she knew which sentence a stranger would recognize as their own. I watched that framing hold, unchanged, across the landing page, the press brief, and the launch email, straight through to launch day. When press coverage started landing the following week, contacts used her language back in their own notes. That kind of consistency under real pressure to hedge does not happen by accident; it happens because someone made an early, contestable call and then held it.

The second is how she handled the one thing that went wrong. During peak traffic on launch day, the sign-up flow at tidemark.io returned errors for 38 minutes because a production deployment was still pointed at a staging database, a gap in a checklist that Marisol herself owned. She confirmed the cause and had it fixed within seventeen minutes. What I want the committee to know is what happened at the retrospective a week later. Marisol did not describe the outage as bad luck, and she did not spread the responsibility across the team that built the checklist with her. She named her own gap in specific terms: “verify the sign-up form works” was not precise enough to catch an environment mismatch, and she came in with dated fixes already assigned to herself before anyone had to ask for them. I have watched capable people manage a launch-day outage well and then go vague once the pressure lifts. Marisol did the harder thing, and I think it says more about her than the launch itself does.

Marisol Veen has my complete and specific endorsement for the Meridian Product Leadership Fellowship. She pairs the judgment to make a hard positioning call and hold it under real pressure with the honesty to own a failure in precise, actionable terms rather than a general one. I am glad to discuss either example further with the committee by phone or email.

Sincerely,

Renata Okafor Co-Founder and CEO Tidemark renata.okafor@tidemark.io

A personal year-end reckoning with a difficult year

Grace Halloran Branch Manager, Norwood Public Library, Columbus, Ohio May 20, 2026

Dear Hiring Committee,

I am the Branch Manager at Norwood Public Library in Columbus, and I served as one of the eleven volunteer coalition members Marcus Delgado directed through the Meridian Community Broadband Initiative, from September 2023 until its closure in March 2025. I am writing to recommend him for the Director of Coalition Programs role at Fenwick Regional Partnership. I offered to write this letter because the eighteen months I spent watching Marcus lead that coalition, including how it ended, come close to a direct rehearsal for what your posting is asking someone to do.

The coalition Marcus ran was not an easy group to hold together. The eleven of us came from different institutions with different stakes in the outcome: two library systems, a school district technology office, three neighborhood associations, two small regional internet providers, and a few residents with no institutional backing at all. In January 2024, the two internet providers split over the proposal’s core technical approach, one wanting a single countywide fiber build, the other a phased rollout that reached the lowest-connectivity neighborhoods first. Both sides had real technical grounds for their position, and neither wanted to back down in front of the rest of us. Marcus did not let it sit for months, and he did not resolve it by picking a side himself. He wrote up both approaches as a short options memo, set a real deadline for written input from the full coalition, and ran a session where each provider walked their approach through the same shared criteria - cost, time to first connection, and fit with what the funder had told us it wanted - rather than whichever criteria favored their own plan. We left that session with a decision, on the record, and both providers still willing to sit at the same table the following month. I have sat through enough of these disputes to know how rarely they end that way.

The stronger evidence, and the reason I trust Marcus for a role built around sustaining coalitions through funding uncertainty, is how he handled the part that did not go well. When our primary funder withdrew in March 2025, the coalition dissolved without the deployment eighteen months of work had been aimed at. Marcus told the eleven of us directly, on a call he set up within days rather than letting the news travel secondhand, and he was clear the funder’s decision was not a verdict on what we had built. I want to be honest that his account of the closure, back in March 2025, was not the complete one. It took until this past February, in a retrospective session, for him to add the harder part: that a signal the funder’s priorities were shifting had reached him a full month before the withdrawal, and that he chose to keep the coalition steady with optimism instead of putting that signal in front of us on the timeline it deserved. No one in that room had asked him to revisit it. He said it because he had decided we were owed the complete account, even a year late, rather than the version that made him look better. I have watched people manage a group’s morale through bad news. I have not often watched someone come back afterward and correct their own account of it without being pushed to.

I recommend Marcus for the Director of Coalition Programs role without reservation. Regional coalition work will hand him more funding walls, technical standoffs, and endings nobody wanted, because that is the nature of the work, not a risk specific to one project. I watched him run a coalition through exactly that: eighteen months that built something real, and an ending none of us wanted, and afterward I watched him tell the truth about the gap between his best moments and his slower ones, when the easier account would have gone unchallenged. I would join a coalition he was leading again without hesitation, and I am glad to discuss any of this further by phone or email.

Sincerely, Grace Halloran Branch Manager, Norwood Public Library grace.halloran@example.com | (614) 555-0173