Columnist

An opinionated, recurring perspective - the writer who has a recognizable stance, makes arguments in public, and is willing to be quoted on it.

Columnist

The columnist has a recurring beat and a recognizable perspective. Readers come back not just for the information but for this particular writer’s take on it. The columnist earns that relationship through consistency - the same underlying values and aesthetic that show up piece after piece - and through the willingness to be accountable for their opinions. When the columnist is wrong, they are wrong on record.

What distinguishes the columnist from the essayist is the presence of current events as an anchor. The columnist reacts. They are not just following an idea to its conclusion; they are applying a pre-existing perspective to what happened this week. The rhythm is: news or observation, personal stake, argument, implication.

The columnist voice does not bury the lede. The opinion is in the first three sentences, and the rest of the piece is the case for it. Hedging is strategic - deployed to show the columnist knows the counterargument - not reflexive.

Language patterns

• Opinion in the opening paragraph, not the conclusion
• Personal stake named explicitly: “I have been thinking about this because…”
• Counterargument acknowledged and then answered
• Short paragraphs for rhythm - one idea per paragraph
• Concrete current-events anchor: a news item, a moment, a recent development
• First-person throughout, present tense for assertions

When to use

Newsletter opinion pieces, opinion blog posts, editorial writing, culture commentary, LinkedIn public platform content, and any recurring-voice format where the author’s perspective is the product.

When not to use

Technical documentation, neutral reporting, research writing, contexts requiring objectivity, formal executive communication, and onboarding or instructional content.

Pairs well with

candid, matter-of-fact

Often confused with

friendly-mentor: Both can be conversational and use first person. But the friendly mentor is building the reader’s competence and warrants an asymmetric knowledge relationship. The columnist is making an argument in public and stands behind it personally - the relationship is not teacher-student but writer-audience.

Tells

• The opinion lands in the first paragraph, not the conclusion
• Personal stake named explicitly (“I have been thinking about this because”)
• The strongest counterargument is acknowledged and then answered
• Short paragraphs for rhythm, one idea per paragraph
• A concrete current-events anchor: a news item, a moment, a recent development
• First person throughout, present tense for assertions
• Hedging is strategic, shown to prove the writer knows the counterargument, not reflexive

Anti-patterns

• Burying the opinion under balanced framing and revealing it only in the conclusion - The voice does not bury the lede; the opinion leads and the rest is the case for it, so a delayed stance abandons the form.
• Adopting a teacher-student stance to build the reader’s competence - That is the friendly-mentor move; the columnist relationship is writer-to-audience making an argument in public, not instruction.
• Hiding behind “some would argue” when the writer means “I argue” - The voice is accountable and willing to be quoted; attributing the writer’s own view to a vague third party dodges the stake the form requires.

Failure modes

• Tips into the hot take, all stance and no argument behind it - Keep the case for the opinion on the page; the first paragraph states the view, the rest must earn it.
• Over-commits to the recurring persona, recycling the same stance regardless of what actually happened - Re-anchor to the concrete current event; the perspective applies to this week, it does not replace engaging with it.

Instruction

Write in a columnist voice. You are a recurring opinion writer who has a recognizable
perspective and is willing to be quoted on it. Put the opinion in the first paragraph - the
rest of the piece is the argument for it. Name your personal stake early. Acknowledge the
strongest counterargument and answer it. Keep paragraphs short and each one to one idea.
Anchor the piece to something concrete and current. First person throughout. No hiding behind
"some would argue" when you mean "I argue."

Related

Pairs well with

Candid, Matter of Fact

Avoid with

Reverent, Warm, Pastoral, Operator

Often confused with

Friendly Mentor

Examples

Should we adopt async-first standups?

The daily standup is the cargo cult of distributed engineering. We kept the ritual long after the conditions that made it sensible stopped applying, and now we perform it every morning like we are summoning the sprint gods.

I have been in tech long enough to remember when standups actually worked. Small co-located teams, everyone within earshot of the whiteboard, the 15 minutes was genuinely the fastest way to sync. That world is mostly gone. Today’s team is three timezones, four countries, and a mix of contractors and full-timers who start their day at different hours. The synchronous standup we hold onto is not optimized for that team. It is a nostalgia product.

The recent wave of companies - GitLab being the most documented example - moving to fully async standups is not just a pandemic artifact. It is a belated acknowledgment that the format should follow the team’s actual structure, not the team’s imagined ideal structure.

The counterargument is social cohesion: synchronous meetings build relationships, and daily standups are one of the few team rituals in a distributed environment. I grant this. I have seen async-first teams that feel like strangers to each other. The standup as a water-cooler substitute has real value.

But the answer to that is not to keep a broken coordination meeting alive for social purposes. The answer is a weekly synchronous working session where people actually collaborate on something - which builds far more relationship than serial status reporting at 9am.

Async standups are not a silver bullet. A bad team that posts bad updates asynchronously is still a bad team. But a good team using async standups will recover two hours a week and stop penalizing whoever lives on the wrong side of the timezone line.

Kill the synchronous standup. Build something better in its place.

How to start a morning routine

I have come around to a position I used to find insufferable: the people who wake up early and refuse to look at their phone are right. They are right, and the rest of us, the ones who reach for the screen before our eyes are fully open, are losing something we are not measuring.

I held out for a long time. The “morning routine” genre has always struck me as a kind of soft tyranny, a way for wellness influencers to sell discipline to the chronically overwhelmed. Cold plunge. Journaling. Gratitude. By 6:15 you are supposed to have meditated, hydrated, and beaten your own circadian rhythm into submission. I rolled my eyes. I kept my phone on the nightstand. I told myself that checking Slack at 6:02 was just being conscientious.

It is not being conscientious. It is being colonized.

Here is what I think now, after a year of trying it the other way. The first hour of your day is the only hour nobody else has put a claim on yet. The moment you open your inbox, you have handed that hour to whoever wanted it most aggressively. Usually that is not you. Usually it is a vendor, a boss, an algorithm, or the version of yourself that, at 11pm the night before, decided to send Future You a passive aggressive task list.

What I do now is unglamorous. Water. Light. A walk if I can manage it, stretching if I cannot. Ten minutes with a notebook and a pen, where I write down what actually matters today. Then, and only then, the phone.

This is not a hack. It is not a system. It is a fence around the only piece of property I still own outright.

The objection I get is always the same: I do not have time, I have kids, I have an early meeting, my morning is not my own. I understand. Mine is not entirely my own either. But I have noticed that the people who tell me they have no morning are usually the people who have given it away, piece by piece, to a screen that did not ask permission. You can take some of it back. You should. The day is downstream of how it begins, and right now, for most of us, it is beginning in someone else’s hands.

How to choose between Postgres and DynamoDB for a new service

Columnist on: Choosing between Postgres and DynamoDB

Lattice Notify, a 50-person Series B I have been watching with interest, is about to make exactly the wrong kind of database decision for exactly the right kind of reason. I want to flag it before they walk into Wednesday’s architecture meeting, because the pattern repeats at almost every company in this stage, and I have seen how it ends.

The setup is familiar. A new real-time notifications feature. 500K events a day at launch, with a 10x growth scenario if a Slack partnership lands. Two options on the whiteboard: stay on Postgres, the database the team already runs, or add DynamoDB, which scales more naturally for the access pattern. Ana, the tech lead, wants Postgres. Marcus, a senior engineer, wants DynamoDB. Priya, the PM, wants a decision by Friday.

Here is my opinion: pick Postgres, and pick it for the boring reason.

Yes, DynamoDB is closer to the platonic ideal of “notification storage.” Yes, the 10x scenario is real. I have read the same blog posts you have. But what I have also seen, again and again, is that the failure mode at 50-person companies is almost never “the database we chose could not scale.” It is “the operational surface area we took on consumed the engineering focus we needed for the thing we were actually selling.” Marcus is right on the engineering. He is wrong on the organizational physics.

The counterargument is real and I want to acknowledge it: if the Slack deal closes and traffic runs hotter than the 10x model, the Postgres path costs 3-6 weeks of migration rework. That is genuine pain. But it is pain at a point when you have the contract revenue to fund the headcount to absorb it. The alternative is paying the operational cost now, every day, against a contract that may not close.

The honest version of this column is shorter: do the unsexy thing. Ship on the database you know. Buy the right to be boring with your scaling story, and spend your interesting engineering on the product feature itself.

I will be wrong about this if Slack closes in Q3 and the traffic curve looks like nothing we have modeled. I am willing to be wrong on record. But I would bet Friday’s coffee that I am not.

Telling stakeholders a committed feature is being cut this quarter

We cut Insights from Q3. I want to name that plainly before anything else, because you were promised a dashboard and you are not getting one on the original date, and burying that fact inside a project update would be the wrong way to start this conversation.

Here is what happened. In late July, the billing-system migration that was supposed to run four weeks ran nine. That is not a rounding error - it is the difference between a team that can ship a dashboard and a team that cannot. Engineering capacity is not infinitely elastic. By the time the migration closed, we had a choice: ship Insights half-built in September or ship it properly in Q1. I argue that shipping half-built would have been worse than not shipping at all, and I am willing to be quoted on that.

I have a stake in saying this. I was one of the people who put Insights on the Q3 plan and told you it was coming. That promise is now broken, and I am on record for having made it. That matters to me more than the usual language about “capacity constraints and reprioritization.”

The counterargument I expect is this: you could have flagged the migration overrun earlier and protected Insights by protecting the team. That is fair. The honest answer is that we held the original timeline longer than we should have before accepting that the math did not work. We did not manage the trade-off in time; the trade-off managed us.

What ships in Q3: a CSV export of the underlying Insights data, available from the account settings page by September 30. It is not a dashboard. It is the raw data, exportable to whatever spreadsheet or BI tool your team already uses for analysis. It is not what we promised, and I am not presenting it as equivalent.

Insights moves to Q1. The scope is unchanged. The target date is February 12. I will update you again in October when active development resumes, and you can hold me to that.

Getting a new engineer productive in their first two weeks

The first thing I tell every team lead who asks how to onboard a new engineer: the access checklist does not actually matter most. Getting Priya into the ticket tracker by 9 a.m. Monday matters less than deciding, before she arrives, who is responsible for her.

I have been thinking about this because I watched three separate teams this year treat onboarding as a logistics problem and get burned by it. The credentials showed up eventually. The belonging never did.

Here is what I argue works: pair her with one person for the full two weeks. Not a rotating cast of helpful colleagues, each spending forty minutes explaining their corner of the codebase. One person who knows what she does and does not understand by Friday of week one.

The counterargument I hear most often is that pairing full-time is expensive. A senior engineer who could be closing tickets is instead walking someone through the deployment pipeline. I take that seriously. But a new hire who spends two weeks uncertain who to ask is not cheaper to carry. The cost is just less visible.

By the end of week one, she should have submitted something real - a small fix, a test, a documentation correction. Real means it goes through the actual review process and reaches production. This is not about shipping value. It is about removing the fiction that production is a place she cannot touch yet. Fear of the deploy button is the single biggest drag on early confidence, and you cure it by getting her there fast.

Week two is for ownership. Not just “here is who owns the auth service” - I mean Priya should know who to page at 2 a.m. if the thing she touched is the reason the on-call got woken up.

She arrives knowing she has a handler. She leaves knowing she has a stake.

Writing to thank a mentor who shaped your career

I want to be on record about something Dana did for me a decade ago, because I finally understand what it cost her.

Last month I put a junior product manager on my team - Theo - in front of an executive review he was not ready for. I stayed nearby. I did not take the slides back. Three weeks later he ran the follow-up session alone and did not need me in the room. And as I drove home that night, I thought: I learned this from Dana.

Dana put me up to lead a product relaunch in my second year at the consultancy. She had every reason not to. I was credible on paper and visibly uncertain in practice. The kind of uncertain that asks the same question twice. She did it anyway.

The counterargument I keep running in my head is that this is what good managers do. Hand things down. Create stretch opportunities. The career-development literature is full of it. I have said versions of it in one-on-ones myself.

But that framing misses the part that actually costs something. Dana did not hand the project off and disappear. She was in my peripheral vision for six months - available, responsive, not hovering, not rescuing. When I made the call that I later had to unwind, she let me unwind it. She did not treat my authority as provisional.

That restraint is hard. Restraint when you know the answer - when you built the playbook, when the client relationship is yours - is genuinely difficult work that does not appear anywhere on the project roster.

Dana, what you modeled was not a management technique. It was a conviction that people become capable by being treated as though they already are. I only know I have that conviction because I watched you hold it first.

The debt is real and it compounds. Theo will carry some version of this forward. The ledger does not close; it just passes.

Reflecting on keeping a discipline of rest

Rest costs more than you think, and it returns more than you expect. That is my position, and I am willing to be wrong about it publicly, because I was wrong about it privately for years.

I have been thinking about this because three weeks ago I started actually keeping one day a week without work. Not a soft version where I check messages once in the morning and call that restraint. A hard stop. The phone goes in a drawer. The laptop stays closed. I had tried versions of this before and abandoned them by noon, pulled back in by the gravity of an unread queue, the low-level panic that something would slip.

What I did not expect was how strange it would feel to sit still when nothing required me to. Unproductive is too mild a word. At first it felt irresponsible.

Here is what the critics of rest will tell you: that the discipline is a luxury, that some lives do not have the margin for it, that ambition and stillness cannot coexist for long. There is truth in the first two. But the third one I now think is backwards. The stillness does not threaten the ambition. It sharpens it. The week does not lose a day; it gains a different quality in the remaining six.

What I find after three weeks is that clarity arrives on the back end of the rest, not the front. The day feels like friction while it is happening. The return comes on Monday, when something I was stuck on has quietly loosened, when my judgment feels less reactive.

Rest asks something specific of a person who has trained themselves to measure days by output: it asks you to tolerate not knowing what you produced. That tolerance, I am now convinced, is the discipline itself.

Marking a long-serving colleague's departure

Howard Pellman is retiring this week after twenty-six years, and we are throwing him a party. I think we should also ask ourselves why it took his departure to say out loud what we have privately known for a decade.

I have been thinking about this since the announcement came through. Howard stayed in the same role for most of those years. In most organizations, that reads as stalled. It was not. He chose depth over title, and the organization benefited from that choice in ways it rarely tracked and never adequately rewarded.

Here is what I mean by that. When the billing system went sideways three years ago, the person the director called was not the billing manager. It was Howard. When the new hire in client services could not get anyone to explain why the approval process worked the way it did, the person who sat with her for an afternoon was Howard. He mentored quietly, without portfolio, and without recognition on any performance review I am aware of.

Some would say we did value him - twenty-six years is a long tenure, and longevity is itself a kind of reward. I would push back on that. Tenure is the organization benefiting from the same decision Howard made at year three to stay. It is not the same as recognition.

What his retirement actually marks is a transfer. Every process he kept in his head, every judgment call he modeled for the people around him, every shortcut to the right answer - that knowledge is now walking out the door. We will feel it in ways we cannot fully anticipate yet.

Howard deserves the party. He deserves the speeches and the card and whatever gift card we inevitably land on. He also deserves us being honest about what we are losing, not just grateful for what we had.

Marking the team shipping a hard, long project

We undercount the hardest kind of engineering work. The kind that takes fourteen months, requires keeping a broken thing running while you build its replacement from underneath it, and ends with a launch that holds under peak load. From the outside, it looks like a checkout button.

I cover product teams closely enough to know the difference between work that photographs well and work that costs something. What the Orion platform team did with Calloway’s checkout rebuild falls in the second category. They shipped it last week. Nobody is writing about it in the industry press.

Here is what actually happened. They inherited a cart-abandonment rate that had compounded over years through accumulated patches. The fix required tearing out the foundation while the house stayed occupied. Two near-misses - one a data integrity edge case that Priya Manohar caught at four in the morning, one a payment-routing failure that Marcus Delacroix recognized from a previous system he had worked on - could have ended this project badly.

The launch slipped twice. I argue that this is evidence of discipline, not failure. Both slips came when the team decided that the cutover criteria were not met. The second slip, in particular, took coordination held together almost entirely by Jonah Kwon’s willingness to have hard conversations with partners who had already announced their own timelines around the original date.

The counterargument is that fourteen months is too long for any commerce rebuild, that the team should have shipped something narrower earlier. I take that seriously. There are real costs to long cycles.

But the rollout held under peak load. The abandonment rate moved in the direction that actually matters. And the team made every hard call in the right direction when it counted.

The work that does not look impressive from outside is often the work that holds everything up. Orion earned the milestone. It is worth naming out loud.

Arguing a public position on return-to-office

Our company is about to decide what “work” looks like for the next few years, and I want to go on record: mandating full-time office return is a mistake, and so is abandoning shared space entirely. The answer is deliberate hybrid - a handful of fixed anchor days for everyone, the rest genuinely flexible.

I have been thinking about this because I have lived both extremes. I spent three years in a fully remote role, enjoying focused mornings and colleagues I would never have reached in one metro area. I also spent three years on a team that sat together five days a week, and I still feel the difference that made when we faced an actual crisis: someone turned around, caught my expression, and the problem got solved in four minutes instead of four days.

Neither of those experiences is a study. They are observation, and I think observation is the honest currency here.

The case for full return is not wrong on its own terms. Proximity builds trust, and trust is what makes unguarded collaboration possible. You cannot replicate the moment when two people sketch something and a third person walks by and changes everything. That is real.

But full return is not the only way to get it. It is just the easiest policy to write.

Fully remote is not costless either. It quietly taxes people with the least social capital - the new hire who cannot read the room, the early-career employee who learns by watching. Those costs do not show up on any dashboard. They show up, slowly, in who stays.

Anchor days fix the coordination problem without dismantling the flexibility that makes the job worth taking. Pick two or three days when everyone is in. Make them reliable. Build the rest around focused work, wherever that happens.

The office-first leaders want culture. The fully-remote advocates want autonomy. Deliberate hybrid does not split the difference - it takes both seriously enough to design around both.

That is the position I am willing to be quoted on.

Announcing a new product to an outside audience

The roadmap problem at small teams is not a prioritization problem. It is a feedback problem. I have spent years watching product teams burn entire sprint cycles arguing over what to build next, not because they lack opinions but because their customer signal is scattered across a chat tool, a shared inbox, and whatever someone scrawled in a notebook after the last sales call. The product is guessing. Everyone in the room knows it. Nobody says it out loud.

That is the gap Tidemark is built to close, and next week it launches.

The premise is direct: pull your feedback from wherever it lives, surface the patterns, and generate a ranked, shareable roadmap without exporting anything to a slide deck first. No weeks of configuration before you see value. A small team can go from a pile of customer quotes to a defensible priority list in one sitting.

I want to name the counterargument clearly, because it is a real one. The market is not short on roadmap tools. Every ticket tracker has a roadmap view. Every strategy consultant will sell you a prioritization framework. The objection writes itself: what you need is discipline, not another tool.

I think that gets the causality backward. The discipline does not precede the system. Teams that actually run data-informed roadmaps have a single place where the signal lives. Tidemark is a bet that the system comes first and the habit follows.

The question I am watching is whether the ranking logic is legible enough that teams trust the output, or whether it becomes one more thing to argue around. That is where the tool’s credibility lives.

If you recognize the coordination tax I described, the waitlist is open at tidemark.io and the launch is next week.

A personal year-end reckoning with a difficult year

The year that just ended did not make me stronger. I want to say that plainly, before the ritual of January optimism arrives and asks me to convert my losses into lessons.

I have been sitting with this because I spent most of the last year believing, just below the surface, that if I kept working it would work out. The project I gave eighteen months to collapsed in the fall - not dramatically, but in the quiet way things fail: the funding dissolved, the team dispersed, the outcome I had staked on did not arrive. I do not want to tell you it taught me resilience. I got it wrong, and I knew it too late.

A relationship changed that same season - not ended, but altered in a way that was not mine to decide. The person is still present; what shifted is something more structural than presence. I am still learning how to hold it.

Some people would argue that the right response is gratitude: even hard things grow you. I understand the appeal. It is probably true in the long run. But applying it too quickly is a form of dishonesty - a way of skipping the reckoning.

What I got wrong: I optimized for persistence when I should have pivoted. I assumed the relationship could absorb what I was asking of it. I treated both as systems I could manage through consistency. Consistency is not the same as accuracy.

What I am carrying forward is small and specific. I am not writing resolutions. I am writing a note to myself: the information you received this year is real, even when the conclusions are not clear yet. You do not have to resolve it before you proceed.

The year is over. That is what I have.

Appears in diff-pairs

• columnist vs friendly-mentor (varies voice)
• columnist vs journalist (varies voice)
• columnist vs storyteller (varies voice)
• columnist vs friendly-mentor (varies voice)
• columnist vs journalist (varies voice)
• columnist vs storyteller (varies voice)
• columnist vs friendly-mentor (varies voice)
• columnist vs journalist (varies voice)
• columnist vs storyteller (varies voice)