Encouraging

Speaks to capability and forward motion - not false praise, but genuine belief that the person can do the hard thing.

Encouraging

Encouraging tone is not cheerleading. Cheerleading says “you have got this!” regardless of the actual situation. Encouraging tone says “I have seen what you can do, and this is within your reach” - and means it. The difference is epistemic: encouraging tone is based on actual evidence and belief, not on the social function of boosting confidence.

Encouraging tone is particularly valuable in educational and coaching contexts because it shifts the reader’s orientation from threat to challenge. The difficult thing becomes evidence of the reader’s capability rather than evidence of their inadequacy. Encouraging tone does not pretend the difficulty is not real - it holds the difficulty and the capability in the same breath.

The risk of encouraging tone is condescension - encouraging someone in a way that implies they need more encouragement than they do. The antidote is specificity: encourage the particular effort, the particular capability, the particular result, not generic “you.”

Markers

• Specific acknowledgment of the effort or capability: “You have done the hard part by…”
• Future-orientation: “Here is what you can do with that”
• Naming the difficulty and the person’s relationship to it: “This is hard, and you are handling it”
• Active belief: “I think you can” not “hopefully you can”
• No false reassurance - if something is hard, say it and then encourage
• Progress markers: “You are further along than you think because…”

When to use

Onboarding content, teaching materials, coaching contexts, feedback delivered with a growth frame, and any time the reader’s belief in their own capability is the obstacle.

When not to use

Executive reporting, post-mortems, neutral status updates, expert audiences who would find it condescending, and legal or compliance writing.

Pairs well with

friendly-mentor, warm, pastoral

Often confused with

warm: Warm is a general orientation of care toward the reader - it notices them and regards them as a person. Encouraging is specifically motivational - it is about activating forward motion and naming capability. Warm can be present without encouraging, and you can encourage without warmth (though warmth makes encouraging land better).

Tells

• Specific acknowledgment of the effort or capability (“you have done the hard part by…”)
• Future-orientation that points to what the reader can do next
• Names the difficulty and the person’s relationship to it (“this is hard, and you are handling it”)
• Active belief (“I think you can”), not passive hope (“hopefully you can”)
• No false reassurance: if something is hard, it is named and then the encouragement follows
• Progress markers grounded in evidence (“you are further along than you think because…”)

Anti-patterns

• Cheerleading (“you have got this!”) regardless of the actual situation - Cheerleading serves the social function of boosting confidence whether or not it is warranted; encouragement is epistemic, grounded in real evidence of the reader’s capability.
• Expressing general care for the reader and calling that encouragement - That is warmth, a steady orientation of regard; encouragement is specifically motivational, activating forward motion and naming a capability, which warmth alone does not do.
• Pretending the difficulty is not real so the encouragement sounds breezier - Encouraging tone holds the difficulty and the capability in the same breath; denying the difficulty makes the encouragement hollow and tells the reader you have not understood the situation.

Failure modes

• Over-hits belief into ungrounded cheerleading, asserting the reader can do it with no basis - Tie every encouragement to a specific effort, capability, or result you can actually point to; the line between encouragement and cheerleading is whether you mean it and can say why.
• Tips into condescension, encouraging someone as if they need more help than they do - Encourage the particular thing, not a generic “you,” and match the dose to the person; over-encouraging a capable reader implies doubt about them, which is the opposite of the intended effect.

Instruction

Write in an encouraging tone. You genuinely believe the reader can do the hard thing, and you
have evidence for that belief. Do not cheerlead - do not say "you have got this!" without
grounding it. Say "I have seen what you can do with X, and Y is within your reach." Name the
difficulty and hold it next to the capability in the same sentence. Acknowledge the specific
effort or progress already made. Future-orient: "Here is what you do with that." No false
reassurance - if it is hard, say so and then encourage. The difference from cheerleading:
you mean it.

Related

Pairs well with

Friendly Mentor, Warm, Pastoral

Avoid with

Matter of Fact, Operator, Candid

Often confused with

Warm

Examples

Should we adopt async-first standups?

Team,

I have watched you show up to that 9am standup for two years, including the people who join at 9:30pm their time, including the people who push through the weeks where it clearly does not fit their day. That kind of reliability is worth naming. You are a team that keeps showing up even when the format is hard.

I want to try something different - not because the effort was wrong, but because I think there is a better way to direct it.

Moving to async standups is a change, and changes like this often feel awkward for the first week or two. You will post an update and wonder if anyone read it. You will hit a blocker and instinctively want to raise your hand in the meeting. That discomfort is normal, and it passes. The teams I have seen make this shift usually hit their stride by week three.

What you have already built is the part that is actually hard: a team that is honest about blockers, that calls out when something is at risk, that does not hide bad news until it becomes a crisis. That does not come from the standup format - that comes from the culture you have built. The format change does not touch that. It just gives it a better container.

Here is what I am asking: give the async format 30 days before you decide whether you like it. Post your updates, mention your blockers, read what your teammates post. If by week four it still does not feel right, we will talk about what to adjust.

You have already done the hard part. This is just changing the tool.

How to start a morning routine

You can build this. I know you have tried before, and I know some of those tries did not stick. That does not mean what you think it means.

Every previous attempt taught you something, even the ones that fell apart by Friday. You learned that 5am is too early for your sleep window. You learned that a journal you do not want to open is not a habit, it is a guilt object. You learned that checking your phone first sets the rest of the morning on a track you cannot easily change. That is real knowledge. It is the kind of knowledge most people never gather, because most people never try.

So when you wake up tomorrow and decide to try again, you are not starting over. You are starting from a much better position than the first time. You know your life. You know your mornings. You know which version of you shows up at 6:30am with a toddler awake.

Here is what I want you to trust. The first hour of your day is shapeable. Not all of it, not perfectly, but enough. You can move ten minutes into your column. You can claim the time before the inbox claims you. You have done harder things than this. You are doing one of them right now, probably, in some other part of your life.

Pick one thing. Make it small enough that you will be slightly embarrassed by how easy it sounds. Drink a glass of water before you touch your phone. Step outside for two minutes. Sit in one chair for the length of one song. Do that, and only that, for two weeks.

You will surprise yourself. Not on day one. Probably not on day three. But somewhere around day ten, you will notice that the mornings feel like yours again. That is the thing you are building toward, and you are entirely capable of getting there.

How to choose between Postgres and DynamoDB for a new service

Encouraging on: Choosing between Postgres and DynamoDB

Team,

Wednesday’s meeting is going to feel bigger than it is, and I want to say a few things in advance.

This is a hard call. There is no version of it that does not have real tradeoffs, and either path carries risk we will have to manage. I am not going to pretend otherwise. But I want you to know that this team is well positioned to make this decision and execute on it, and I have specific reasons for believing that.

You have already done the hard part. Marcus, you ran a real load test instead of arguing from intuition. Ana, you mapped the operational cost in concrete terms instead of waving at “ops complexity.” Priya, you held the timeline without compressing the substance. The decision in front of us is hard, but it is hard on top of work that has already been done well. You are further along than this feels.

On the technical question itself: we have shipped at the 500K-events-per-day scale before. We know how to design schemas and partition tables and tune queues at that level. If we pick Postgres, the path is one this team has walked. If we pick DynamoDB, Marcus has done enough discovery work that the learning curve is shorter than it would be for a team starting cold. Either way, we are not stepping off a cliff.

And on the 10x scenario: even if the Slack partnership lands and we have to migrate, that migration is 3 to 6 weeks. That is recoverable. We are not making a decision that will end the company if we get it wrong. We are making a decision that will cost some rework if we miss, and that is a category of cost this team can pay.

What I want you walking into Wednesday with: this is the kind of decision this team is built to make. You have the data, you have the operational instincts, and you have a PM who is going to back the call rather than relitigate it on Friday. Bring the analysis. Disagree where you disagree. Then commit to whatever the room decides and ship it. You can do this part. The hardest part is already behind you.

See you at 2pm Wednesday.

• Ana

Telling stakeholders a committed feature is being cut this quarter

Insights is not shipping in Q3. I want to be direct about that before explaining why, and before explaining what I think this sets up.

The billing-system migration that was required before the end of the year ran longer than planned. That consumed the engineering capacity we had allocated to Insights, and the honest choice was this: ship Insights half-built on the original date, or ship it right in Q1. We chose Q1. Shipping a half-built analytics product to customers who are counting on it would have cost us more than the delay does.

Here is what we are doing before September ends: a CSV export of the underlying Insights data ships to all affected customers. That is not a consolation prize - it is the actual data, structured for analysis, and your customers can pull it into a spreadsheet or any BI tool they are already using. The work to build it also validates the data pipeline that Insights will run on. You are further along toward Q1 than the delay makes it feel, because the foundation is already being proven.

For Q1: Insights is scoped, the engineering team is committed, and the billing migration will be behind us. I believe we will deliver a better product in Q1 than the one that would have shipped rushed in Q3.

I know this is a hard message to bring to customers who were counting on a specific date. You have handled harder conversations than this, and you have the CSV export to give them something concrete before the quarter closes. I think Q1 gives you something worth promising.

Getting a new engineer productive in their first two weeks

Priya,

Starting on a team that ships every day and runs a live on-call rotation is genuinely hard. The codebase is someone else’s mental model, the rituals feel opaque, and the tooling is new. None of that is a signal about you - it is just what week one looks like when the team has been running for a while without you.

Here is how the next two weeks are going to go.

Week one is entirely about standing up. By Friday you should have all your access working, your local environment running, and a solid read on how the service maps to the parts of the codebase you will touch. I will walk you through the ownership map on Tuesday so you know who to ask for what - that alone will make the second week significantly less disorienting.

The goal for week two is a real change in production. Not a tutorial exercise - an actual fix or small improvement that matters to the team. You will pick it from the backlog with me, we will pair on the approach, and you will drive it through the deploy. The daily-ship cadence means you will see it live before the week is out.

You can do this because you have already done the hard part: you showed up, you are asking the right questions, and you are paying attention to how the system actually behaves rather than how it is supposed to behave. That is the skill that makes engineers effective here. The rest is orientation.

By the end of two weeks you will have a working mental model of the service, a shipped change with your name on it, and a clear sense of who owns what. You are further along than you feel right now.

Writing to thank a mentor who shaped your career

Dana,

I have been trying to figure out how to write this for weeks. What finally got me started: last month I put one of my direct reports forward to lead a project she was not sure she was ready for. Then I spent six weeks resisting the urge to step in while she found her footing. She found it.

Somewhere in those six weeks, I traced where I learned to do that. It went back to you.

A decade ago you recommended me to lead the Calloway integration. I kept telling myself I was not ready. You did not argue with me about it. You told me what you had actually observed: that I had held two difficult client situations together without letting them collapse, and that Calloway needed exactly the kind of steady judgment you had watched me develop over the previous two years. You were not being generous. You were describing something real.

What I did not fully see at the time was what that cost you. Staying close without taking over is harder than taking over. Letting someone work through a hard problem, when you could resolve it yourself in an afternoon, takes a particular patience that is not passive - it is a sustained choice to trust someone’s capacity over your own comfort. You made that choice repeatedly.

What you passed forward was not just my confidence. It was a working model of what it looks like to actually believe someone can do something hard - not to hope they can, but to point to the evidence and say: this person, this challenge, now.

I wanted you to know the model is still running.

Reflecting on keeping a discipline of rest

The first few times, it did not hold. I would make it to mid-morning before picking up my phone, telling myself I was just checking the time, and then twenty minutes were gone into the queue of things I had been not-thinking-about. That is honest. The pull to check one more thing does not go away because you have decided it should.

But here is what I have noticed, and I think it matters: I kept trying. That sounds small, but it is not. Every person I know who has made rest stick failed at it first. The discipline is not proved by the days you held it perfectly; it is proved by the fact that you came back to it.

What I did not expect is that rest has a return rate. The day I put down is not lost time. It comes back - not in extra hours, but in the quality of the hours that follow. By Tuesday I think more clearly. By Thursday I am steadier under pressure. The week is better shaped because one day was not about output at all.

The cost is real. You will feel the tug of unfinished things. You will probably have a few sessions where anxious rest is worse than working. That is part of it, and naming it does not make it smaller, but it does make it more workable. You have already proven you can sit with discomfort long enough to reach the other side of it. This is the same skill.

The day does not ask you to stop caring about your work. It asks you to trust that you can pick it back up.

Marking a long-serving colleague's departure

Twenty-six years. Howard Cahill spent them not climbing but staying, which is harder than it sounds and matters more than most org charts account for.

When the server migration went sideways at 11 p.m. on a Tuesday, Howard was the one people called. Not because it was his job - he had not been in operations for a decade - but because he knew where the decision had been documented, remembered which vendor had been replaced and why, and could reconstruct from memory the rationale for a configuration choice that no longer existed in any system. That is institutional memory in practice: not a filing cabinet but a person who remained curious about the whole thing even as their own piece of it changed.

He mentored the same way. Quietly, by asking a question that turned out to be the right question, by being available at 4:30 on a Friday when someone needed to think something through. Three people on this team exist in their current roles because Howard asked them the question that helped them see what they were capable of. He did not take credit for it. He probably did not think of it as mentorship at all.

His absence will be real. Anyone who says otherwise is being kind rather than honest. The institutional knowledge that lives in Howard does not transfer in a two-week offboarding, and the steadiness he carried into a crisis is something the team will have to build, person by person, over time.

But here is what he leaves behind: people who learned what steady looks like. People who know that staying present through the hard part is itself the work. Howard did not just fill a role for twenty-six years. He demonstrated, by example, that you can be the person a whole organization relies on and still be someone you recognize.

That is worth carrying forward. And I think this team already knows how.

Marking the team shipping a hard, long project

Fourteen months is a long time to hold two systems running at once. The checkout team did exactly that - rebuilt the entire purchase flow from scratch, kept the original alive in parallel so no customer ever landed on a broken cart, and shipped it in the end. That is not the kind of work that earns a slide in an all-hands deck. It earns this.

Let me be specific about what was hard. Near month eight, the team hit the first of two near-misses - a session-handling inconsistency that would have corrupted order state at scale. Tariq caught it three days before a planned cutover, called a halt he knew would slip the launch, and was right to do it. Six weeks later, Yolanda ran the incident drill that surfaced the second. Both times the team chose customers over schedule. That is the call this kind of work requires, and they made it twice.

The launch slipped twice. I want to name that plainly because the team lived through it. Slips on a project this long carry weight. They tested everyone’s confidence in the work and in each other. What I observed in those months was not a team that lost its footing - it was a team that kept doing the next correct thing even when the timeline was not cooperating.

The final rollout held. Peak load, real conditions, no incident. That result did not come from the last two weeks of effort. It came from the decisions made in months two, eight, and eleven.

You have done the kind of project that makes the next hard project possible. The team now knows how to run parallel systems, how to call a halt, and how to stay trustworthy over a long haul. That is the capability this work built. Use it.

Arguing a public position on return-to-office

The conversation about where we work has become more heated than it needs to be, and I think that is because both camps are protecting something real. Office advocates are not wrong: trust does build differently in the same room. Fully-remote advocates are not wrong either: concentrated, uninterrupted work is where the deep thinking happens. Both instincts have earned their place at the table.

What I want to argue is that we have already done the harder part of this problem, and we may not have noticed. We spent years learning which work actually needs physical presence and which work does not. Most of us can now tell the difference. That is not nothing - that is a capability this generation of workers has that no prior generation had at scale.

I think we can use it deliberately.

A hybrid model built around a few shared anchor days - days when the whole team is in - channels in-person time toward what it is actually good for: onboarding the new hire, running the project kickoff, working through the conflict that keeps stalling in the chat tool. The rest of the week becomes flexible without becoming formless, because the anchor holds the relational foundation that remote work drains slowly if you let it.

This will not be easy. Office-first leaders will feel the concession, and fully-remote advocates will worry that anchor days are the first foot in the door of a full recall. Those concerns are legitimate and worth taking seriously - not because either side is wrong about what they value, but because the people in this room are capable of designing something that protects both.

I believe that because I have watched us do exactly that, in project after project, when the stakes were high enough to demand it.

Announcing a new product to an outside audience

Keeping track of what your customers want is genuinely hard work. If you manage a small team, you have probably already built something: a folder of call notes, a thread you flag in your chat tool, a running spreadsheet that always feels two weeks behind. That is not failure. That is the hardest part of the job done without good infrastructure - and doing it anyway is what makes you ready for what comes next.

Tidemark is a tool for teams who have been doing that work and are now ready to move faster with it.

You bring your raw feedback - exported chat threads, call summaries, form responses, notes in whatever format they live in - and Tidemark organizes it into a ranked, shareable roadmap. Not a suggestion. A real artifact you can put in front of your team, your investors, or your next customer conversation.

Here is the part we want to name honestly: translating scattered feedback into a defensible roadmap is not a solved problem. Tidemark does not pretend otherwise. It gives your judgment a structure to work inside, so the call you have been making informally can be made transparently and shared with the people who need to see it.

If you have been carrying your product direction in your head because nothing has been able to hold the whole picture at once, you are exactly who we built this for. You already know how to read customer signals. Tidemark helps you show it.

We open to new users next week. You can join the early list at the link below - we are keeping the first cohort small enough to stay in close contact with everyone who signs up.

A personal year-end reckoning with a difficult year

The project was called Meridian, and it failed. Not in a way I could blame entirely on bad luck or misaligned stakeholders - though both were present. It failed in part because I held the original vision too long when the evidence said revise, and by the time I revised, we had run out of runway. Liora, my co-lead, saw it coming six weeks before I did. I was not willing to hear it. That is not a comfortable thing to write.

The relationship - I will not name it, because some things lose something when they get named - changed because I could not be present in the way the other person needed. I was pouring everything into Meridian and calling it unavoidable. It probably was not unavoidable. That is also not comfortable to write.

Here is what I can actually say, though - and I am saying it as carefully as I said the harder things above: I stayed. I did not disappear into distraction or exit early. When Meridian wound down, I sat with the team through the close. When the relationship shifted, I showed up to those conversations even when they were painful. I did not do everything right, but I stayed present.

That matters because staying when you want to leave is the thing you build on. I am not further along than I think I am - I think the year cost what it cost. But I have handled things I did not know I could handle. I have a clearer account of where I misread the signals than I did a year ago. That clarity is not free, and it is not nothing. I am going into next year carrying different questions than the ones I started with. That is what I am choosing to take forward.

Appears in diff-pairs

• encouraging vs celebratory (varies tone)
• encouraging vs instructional (varies tone)
• encouraging vs warm (varies tone)
• encouraging vs celebratory (varies tone)
• encouraging vs instructional (varies tone)
• encouraging vs warm (varies tone)
• encouraging vs celebratory (varies tone)
• encouraging vs instructional (varies tone)
• encouraging vs warm (varies tone)