Hey!

Welcome back to another week of musings.

When you're reading this, I'm actually on a flight to Tokyo! My first trip to any Asian city. I'll be spending a few days here.

I hope your weekend was uneventful, and you managed to rest for the week ahead.

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• How to spot strategic drift in software programs. This one made me think about how easy it is for us to drift in communication even when we have good intentions.
• Today's topic made me remember the book High Output Management by legendary Andy Grove.

Lately, I've been reflecting on something that keeps showing up in my work: I struggle to keep a consistent message when I feel pressure to accommodate everyone in the room.

Sometimes I also do it to keep options open in case an unknown arises later in the project.

So I start a meeting saying, "We will migrate to this new platform," and then I end with, "Let me work on the follow-up tasks," in a way that sounds like we are still evaluating many options.

The issue is not just wording. That inconsistency creates uncertainty for people trying to plan dependencies, timelines, and staffing. People will never be fully sure if the project is starting, ongoing, or when it will be delivered.

Why does this happen (to me)

In my case, it usually comes from a few places:

• I want to avoid some level of conflict.
• I want to be collaborative, so I try to be flexible.
• I try to avoid unknown unknowns before they are real.
• I get pulled by deadline pressure, leadership expectations, and "where is the plan?" urgency.

None of those are bad intentions. But the result can still be confusing for everyone else.

What I'm trying to improve

The main shift I'm working on is separating clarity from flexibility in execution.

Clarity (for me) means I clearly state what was decided, why, and what would have to be true to revisit it.

Execution flexibility means we can still adjust sequencing, ownership, and implementation details without reopening the whole decision every week.

Practices that are helping me

• Anticipate questions before the meeting. I now write down possible questions beforehand, distinguishing between "decision-changing" and "implementation details."
• Pre-align with key people. A short async check-in before the meeting helps avoid live surprises that derail the message.
• Use explicit language in the room. I try to say: "The decision is X. Open items are A, B, and C."
• Close meetings with committed next steps. Instead of "I'll follow up," I aim for "By Friday, I'll publish the migration phases and owners."
• Document decision boundaries. If a new unknown appears, I define what threshold is enough to reopen the decision.

A reminder I'm keeping for myself

Being consistent does not mean being rigid.

It means people can trust what I said last week still means the same thing this week, unless there is a clearly stated reason to change it.

That's the kind of consistency I want to build.

Your turn!

Have you ever caught yourself mixing a clear decision with open-ended language at the end of a meeting? What helped you stay consistent without becoming inflexible? Let me know your thoughts by replying to this email!

Happy coding!