pragmatic-architect vs technical-writer

Topic: Writing to thank a mentor who shaped your career
Axis varied: voice
A: Pragmatic Architect B: Technical Writer

What to notice

Both examples address the same topic and (by default) share every axis other than voice. The only deliberate variable is which voice the writing was rendered through. Read both and ask: where does the framing change? Where does the vocabulary change? What does the reader take away from A that they would not take away from B, and vice versa? The voice swap is the entire cause of those differences.

A: pragmatic-architect

You made the right call. I want to name that directly, because the reasoning took me a long time to reconstruct.

The Meridian project was too large for me in 2015. I knew it then; you knew it then. The execution risk was real: I had not led a cross-functional build, the timeline was fixed, and the stakeholders had low tolerance for visible stumbling. The lower-risk move was assigning Marcus, who had done it twice before. You assigned me instead.

The tradeoff you accepted was this: you traded guaranteed adequate execution for the possibility of something better, with the cost landing on you personally if I failed publicly. That is a bad bet unless you have already priced in the constraint that adequate execution produces adequate engineers. You had priced that in.

What made it work was not the assignment. It was how you stayed. You were present enough that I had a check-in when I needed one, absent enough that I had to solve the problems myself. The distinction between those two modes matters more than most mentors seem to understand. Rescue and support look similar from the outside. The failure mode of rescue is that the engineer never learns the shape of their own judgment under pressure. You did not rescue me.

I know what that cost. I surfaced problems to you in check-ins that you absorbed and did not escalate. There were weeks where I was a significant drain on your attention. You stayed anyway.

Three months ago, I put one of my engineers, Priya, on a scoping project she was not ready for by the numbers. I stayed close. Last week she delivered it. When I tried to explain to her why I had made the call, I realized I was translating a lesson I had not consciously stored but apparently kept.

Thank you for the original version.

B: technical-writer

Dana,

You taught me something over four months in 2016 without naming it as a lesson. I want to name it now, because I just used it.

You put my name forward for the Harlow platform documentation project in the spring of that year. I had eight months in the role. The project required coordination across four engineering teams, sign-off from a release manager who was already skeptical of the docs function, and a scope I had not fully mapped when you submitted my name. I told you I was not ready. You disagreed and submitted it anyway.

What followed matters. You checked in every Friday for the four months the project ran. You asked about specific blockers, not general progress. When I came to you stuck on the architecture section, you did not solve it. You asked what I had already tried. You waited while I listed the options I had considered, then asked one question. The answer came from me. You repeated that pattern across three similar moments.

I did not have a name for what you were doing while it was happening.

Last month, I put Marcus forward to lead the onboarding guide redesign. He has fourteen months in his current role. He told me he was not ready. I ran the process you ran: submitted his name, scheduled Friday check-ins, and when he brought me a blocked decision, I asked what he had tried before I offered anything. The project shipped last week.

When Marcus thanked me, I told him the method was not mine.

You gave me four months of weekly attention when I was not operating cleanly. That was a cost you did not account for in any project tracker I could see. This letter accounts for it.

Thank you.