Leading through words
Parag Chitnis spent two decades building the software behind international roaming, then became a coach. His argument is uncomfortable: when your message doesn't land, it is never the listener's fault.
Watch the full episode on YouTube
Executive summary
Parag Chitnis started in defence software, moved into telecommunications, and spent roughly two decades at an enterprise building the platform services behind international roaming — which means if you have ever used your phone abroad, you have probably touched his work without knowing it. He is now a professional coach and a writer.
The episode is a masterclass, but not a comfortable one, because its central claim removes every excuse available to a frustrated leader:
"The entire responsibility of communication resides with the speaker."
Not shared. Not mostly. Entirely. Which means "they didn't get it" is a statement about you, and the correct sentence when a message fails is "this is not what I meant" — never "you misunderstood me."
From that single principle, everything else in the conversation follows. If the responsibility is yours, you have to know what the listener needs to hear rather than what you know. You have to choose their words rather than the ones that are clear to you. You have to slow down enough to respond instead of react. And you have to give feedback as observation rather than verdict, because a verdict is about you and an observation is usable by them.
Three things here are worth the price of admission on their own. The skeleton method — strip a message to its bare bones, let the obvious questions surface, answer each, then stitch it back — is a five-minute practice that makes a message genuinely hard to misunderstand. The acceptance trap explains why your team stopped bringing you ideas: not because you rejected them, but because you improved them. And a single naval signal from 1805 explains, in nine words, the difference between compliance and willing effort.
The story
The most instructive story in this episode is about a message that was never sent.
Roughly a decade ago, Parag — an architect at the time — got looped into what he calls a strange email thread. A client had asked one of their support engineers to share the company's source code. They were a product company. The code was their IP. They did not share code, and everyone in the organisation knew they did not share code.
The engineer was new. He did not understand how things worked, and he agreed.
What happened next is the part every operator will recognise. The discussion turned inward. "Everybody now started discussing: okay, now that we have agreed, how do we handle it?" It moved from one department to another, growing as it went, consuming more people and more hours, until it finally trickled down to engineering — where Parag read the thread and had the obvious reaction:
"There was no way we were going to share code, and everybody knew that. So what are we discussing?"
The blocker was not technical, contractual or commercial. It was that going back to the client meant saying we made a mistake, we agreed without understanding — and nobody was willing to be the person who said it.
With a small amount of nudging, the right people eventually had the conversation. It lasted moments. It turned out not to have been an official request at all — just another engineer on the client side who was curious how things worked. When it was explained that this is not something they do, and here is how the business is structured, the reply was, in effect, oh, okay, fine.
"That was the end of that. Had the conversation happened immediately, a lot of people would have been able to spend their time and energy on meaningful things."
Sit with the arithmetic. Weeks of senior attention across multiple departments, consumed entirely by the unwillingness to send one short message. The problem was never the mistake. It was the silence after it.
Clarity is not a writing skill — it is these four things pointing the same way.
That story sits at one end of a career-long shift in how he approached communication at all. He describes the change in a single sentence:
"As an engineer, you work on things that don't talk. As you go higher, you start dealing with people who will talk back — and all they do is talk."
Early on, communication meant transmission. "What I saw me doing as an engineer — what I talked about, what I wrote — it was about telling people the things I knew." The change was not that he learned to speak better. It was that the subject changed:
"It became less and less about what I knew. The focus shifted from what I knew to what the person in front of me needs to hear. It no longer became about me."
And then a second shift, subtler and harder, which he considers the real work of a senior leader:
"It's about separating out all the background noise from what matters, and shining a spotlight on what is really important. There is noise all around. A good leader is able to distinguish what matters from the noise — and is able to show that to the people around him or her."
The senior job is not producing more information. It is deciding what everyone else can stop looking at.
He is careful not to present any of this as revelation. "It did not happen overnight. It happened through a variety of different experiences. It happened through a whole lot of stumbling around — but it happened slowly and steadily."
Key shifts
Shift 1 — From transmitting what you know to serving what they need
The engineer's instinct is to be correct and complete. The leader's job is to be understood, which is a different target and often requires saying less.
His measure of effectiveness is worth adopting verbatim: a message works when it is understood the first time, every time. Not eventually. Not after a follow-up call. The first time.
Shift 2 — From reacting to responding
He identifies the exact mechanism, and it will be familiar to anyone with an inbox:
"You receive an email. You hate that email. You start writing a response, a minute later you hit send, another minute later you go — oh my God, what have I done."
The email was a trigger. The reply was a reaction. The regret was the consequence. His fix was not a technique but a permission:
"I told myself: you don't have to reply to every email in ten minutes. You don't have to answer every question immediately."
What the pause buys is not calm — it is capacity. It creates room to run the imagined conversation in your head before it happens in public. And it lets you notice something you cannot notice while talking: "I was able to observe what my audience was doing, how they were reacting to my message, whether the message was actually landing."
When asked in the rapid-fire round for the single habit that improved his communication most, he notes the irony of the answer's timing: slowing down.
Shift 3 — From verdicts to observations
Early in his career, feedback sounded like praise or its absence. "Oh, what an excellent speech." Or: "Oh boy, that didn't work out."
"Slowly I realised this kind of feedback does not translate into any useful actions."
The replacement is precise. Instead of a verdict, describe what you saw:
- "When you introduced your real topic too late, I could see the audience had already lost connection."
- "I observed you were pausing after explaining each point — that helped the audience understand a difficult topic."
The distinction he draws is the important one: good and bad is about the feedback giver. Observation is about the receiver. Only one of the two can be acted on.
Shift 4 — From owning outcomes to owning words
His definition of effective business communication rests on two words that sound similar and are not:
- Responsibility — measuring your words, being deliberate about what you say.
- Ownership — standing behind those words irrespective of whether they land or not.
Ownership is the one that decays under pressure, and its absence is what quietly destroys credible people:
"A lot of times people lose credibility when they fail to take ownership of their words — especially when things go wrong. When you blame others, when you give excuses. When your team sees that you don't stand behind your own words, the image in their head takes a hit. And slowly, every time you do that, that image becomes smaller and smaller."
He is explicit that this is not about being right: "People fail, people make mistakes. But leaders stand behind their mistakes. They own them, they learn from them. They don't hide from it. They don't give excuses."
Mental models
The responsibility axiom
Everything else in this episode is downstream of this one line. It is not a statement about fairness — sometimes the listener really is distracted, or hostile, or wrong. It is a statement about leverage. The listener's attention is not yours to control. Your words are.
The practical test comes when something goes wrong. The instinctive sentence is "you misunderstood me." The correct one is "this is not what I meant."
"The words are important here. I am not making the statement that you misunderstood me. I am saying this is not what I meant. It is limited to me. It is about me. Why? Because the responsibility of understanding rests with the speaker."
It costs nothing and it changes the room. One version starts a defence; the other starts a repair.
Nine words at Trafalgar
He is a history enthusiast, and he reaches for the Battle of Trafalgar in 1805 — Nelson's fleet of 27 ships facing the combined French and Spanish navies. Before it began, Nelson signalled every ship. The message had to be short:
"England expects that every man will do his duty."
Parag's reading is a lesson in word choice:
"Note the words. He did not say I expect every man to do his duty. He did not say you have to do your duty. In fact, he did not even tell them what they needed to do. All he did was remind them of a higher power."
Three refusals in nine words: no first person, no imperative, no instruction. What remains is an identity people wanted to live up to.
"That is the difference — the ability to touch people, the ability to reach their hearts. When you are able to do that, people want to do what they are doing. You don't have to force them. They follow you willingly."
The acceptance trap
This is the model most likely to change how you run your next one-on-one, because almost everyone reading this is guilty of it and believes they are doing the opposite.
Someone offers an idea. A manager responds in one of two ways: outright rejection — "no, no, that will not work" — or, far more commonly, enthusiastic improvement: "excellent — but you know what, let us also do this."
The second one feels generous. Parag argues it is not:
"You have accepted the idea and you have improved it. Especially when you do it with people under you — you have taken somebody else's idea and made it yours. To the person who delivered the original idea, it is as good as a rejection. It tells them that their original idea wasn't good enough. Hence it had to be improved."
The remedy is almost insultingly small. You do not have to agree with every idea or implement every piece of feedback. You have to accept it:
"All you say is thank you for the idea. Thank you for the feedback. Thank you for telling me that. That's all it takes."
Without that, he says, a culture of communication is just words — "it will stay in email."
Culture is imitation, not instruction
"How does a two-year-old learn to talk? By observing their mom and dad, observing the people around. Adults are no different."
Which means a communication-driven culture cannot be announced. "These things don't happen by telling people. When they see you do it — when they see you communicate with them, when they see you communicate with your peers — that is where they will automatically start doing it."
You have to communicate the big things, the small things and the tiny things, visibly, before anyone believes it is safe to do the same.
Presence is corroboration
Tone, body language and volume are not decoration. They are the evidence that your words are true. He demonstrates with two apologies:
- "I'm sorry."
- "I'm really very sorry. I was out of line."
Only one of those reads as an apology. As he puts it, the first one "requires another apology."
This also explains why written communication is disproportionately hard: "Without those visual and audio cues, the words are just not enough. When you are apologising over email, you have to add a whole lot more words for the apology to feel real."
Remote work as a forcing function
He declines the usual complaint about hybrid work. Yes, accessibility is gone — you can no longer walk into a room and spend hours explaining something five different ways at a whiteboard.
"In a way that is also a good thing. Because it now makes you prepare better. The lack of accessibility forces you to prepare better."
His prediction for what distributed teams will actually have to improve is not tooling. It is preparation.
Frameworks
Framework 1 — The skeleton method
For any message that must not be misunderstood.
Take the statement you intend to send. In the episode, the example is:
"We held product trainings for the application team in order to prepare them for the upcoming project."
Now strip it to bone. What are you actually saying?
"We had some trainings."
Deliberately incomplete — and the incompleteness is the tool, because the gaps immediately announce themselves as questions:
| The skeleton says | The listener asks | Your answer |
|---|---|---|
| "We had some trainings" | Which trainings? | The product trainings |
| For whom? | The application team | |
| Why? | To prepare them for the upcoming project |
Stitch the answers back together and you have the original sentence — except now you have already had the entire back-and-forth in your head.
"Now you have a message that is difficult to misunderstand. Of course you may go wrong, but you are way better off than you were earlier, because now you are putting yourself in your audience's shoes."
Framework 2 — Speak to the responsibility, not the person
For any message crossing functions.
Each stakeholder owns something different, and the same fact should be expressed in the currency they are accountable for.
| Stakeholder | What they own | How the message lands |
|---|---|---|
| Project manager | Dates | "If we do this, the date is in jeopardy" |
| Account / sales manager | Revenue | "This may affect quality, and that affects revenue" |
| Engineer | The code, the effort | "Effort is high and time is short" |
His illustration is the engineer's classic reply to do more with less — "I can't do it, the effort is high and the time is less."
"It's a very mathematical answer, and the thing is, only engineers understand this answer. It doesn't work on anybody else."
The content does not change. The currency does. He is careful not to oversell it: "I'm not in any way saying this is a magic bullet." But when you speak in what matters to them, the odds improve.
Framework 3 — Align privately, convene publicly
For any decision spread across multiple stakeholders.
The default approach — get everyone in a room and hash it out — is the one he abandoned:
"There are just too many viewpoints being thrown from here and there and it's chaos. You spend a lot of time reaching common ground."
The replacement:
- Meet each stakeholder one-on-one first. Discuss the problem individually.
- Hear the reservations. Let the objection surface where it is cheap to handle.
- Resolve what you can, and bring them on board privately.
- Only then convene the group — and make that meeting about how you are all aligned and how everyone benefits.
The group meeting stops being a negotiation and becomes a confirmation. The disagreement still happened; it just happened where it could be handled properly.
The episode also offers an unexpected data point from the host's business programme: a 24-hour capstone with 25 senior participants, where the professor's design allocated twelve hours for alignment and twelve for the actual work. Alignment was not overhead in the schedule. It was half the schedule.
Framework 4 — Building your own voice
The habit he started with emails and then applied to everything.
- Write the raw thoughts down. Paper or text file. "That is your first draft. It is usually a bad draft."
- Read it out loud. Not in your head — aloud. "Often words look okay on paper. They feel okay when you read them in your mind. But as soon as you hear them, they will seem off. They will even seem ridiculous."
- Refine. Second draft, third draft, until "the message feels spot on inside."
- Deliver it. Discussion, speech, email — whatever the medium.
- Take the feedback and observe the impact.
- Use it next time. Then do it again, and again, and don't stop.
The requirement running underneath is authenticity: "The words have to be yours. They have to be accurate. But they still have to be unique to you." And the two-sided test — the words must have the right impact inside and outside. If either fails, the communication fails.
Framework 5 — Communicating under pressure
For escalations and crises.
Be direct, and do not show doubt.
"You are not talking to infants here. There are adults here. Tell them what has happened, straight."
He tests it with two versions of the same update:
Version 1: "Yeah, I think we are in a decent stage. I think we should go ahead with the launch."
Version 2: "We are ready. We should go ahead."
The second one is the one a client can act on. The difference is the word think, twice.
The nuance matters, though — this is about delivery, not deception. "I don't mean hide it. In order to show no doubt you have to be confident inside. But it is imperative that you deliver the message without doubt." And confidence is never claimed: "You don't have to tell people using the words 'I am confident' or 'I am sure.' The words you say and the body language you exude have to bring it up."
Framework 6 — The ten-minute pre-meeting list
Deceptively small, and he rates it highly. Before any important conversation — boardroom, strategy session, escalation — spend five to ten minutes writing two lists:
- The things you want to tell them.
- The questions you want to ask.
"I have seen that when I enter a discussion with this list in hand, discussions usually turn out better. When you are clear in your mind on where you stand and what you want to say, the rest of it automatically takes place."
The leadership triangle
Asked what young professionals should build to future-proof their leadership, he offers a shape rather than a list:
- Skill — your domain, the technology, the business, the vision you hold.
- Ownership — "what differentiates a manager from a leader. When you stand behind your words irrespective of the result."
- Empathy — "the emotional link between you and the people you want to impact. Without this link, the two of you will walk alone."
The instruction is to be deliberate about the balance. Over-index on skill and you are a brilliant individual contributor with a title. Over-index on empathy without ownership and you are pleasant and unreliable.
And then a coda that reframes the whole conversation:
"A true leader is never focused on leading. They are focused on getting the job done. When you are focused too much on leading, you lose track of the goal."
"A true leader knows they cannot lead in every single thing. There are going to be times when you have to step back. You have to let others do their thing. You have to let others shine. But if you are focused entirely on leading, you won't be able to do that. Leading is not the goal. Leading is what you do in order to reach your goal."
On storytelling — and its limits
Storytelling gets treated as the master skill of modern leadership. He is more measured, and the qualification is the useful part.
Where it works: abstract messages. "Imagine you want to tell your team: I want you to be extraordinary. How do you define extraordinary? How do you explain where ordinary ends and extraordinary begins? You do that by telling a story of the extraordinary, and the story makes it clear what extraordinary is."
Where it fails: "It is one technique amongst many. Don't make it the only tool in your toolbox. There are times when you have to be direct — you have to tell people do this, don't do that. That's when a story can actually dilute the message."
And the constraint most advice ignores: "Use the technique that you are strong at. If you can tell stories well, do it. Otherwise, do it differently. Whatever it is, do it your way. Only then will you be effective."
Lessons
Communication
- The entire responsibility for being understood belongs to the speaker.
- When a message fails, say "this is not what I meant" — never "you misunderstood me."
- Effectiveness means understood the first time, every time.
- Clarity has to run through thought, words and action together, or it is not clarity.
- The words that are clear to you may not be clear to your audience. Use theirs.
- Answer the why, not just the what and the how.
- Strip a message to its skeleton and let the questions rebuild it.
- Express the same fact in the currency each stakeholder is accountable for.
- Read anything important out loud before sending it.
- Under pressure, be direct and remove hedges — "I think" is where confidence goes to die.
- In writing, add more words than feel necessary; there are no tone or body-language cues to carry you.
Leadership
- Senior communication is mostly subtraction — separating noise from what matters, then pointing at what matters.
- Introduce a pause between the trigger and your reply. Consequences of a response beat those of a reaction.
- Give feedback as observation, not verdict. Verdicts are about you; observations are usable by them.
- Accepting an idea and improving it reads, to its author, like rejection. Say thank you first.
- Culture is copied from what you visibly do, not from what you announce.
- Align stakeholders one-on-one before you convene the group.
- Spend ten minutes before any important meeting listing what to say and what to ask.
- Own your words when things go wrong — that is the whole of credibility.
- Leading is not the goal. Getting the job done is, and sometimes that means stepping back so someone else can.
Actionable advice
This week
- Take the next message you are nervous about and run the skeleton method on it. Strip it to one bare sentence, write down the questions that surface, answer them, stitch it back.
- Read your next important email out loud before sending. Notice how much you rewrite.
- Replace one verdict with an observation in your next piece of feedback. Describe what you saw, not whether it was good.
This month
- Catch yourself in the acceptance trap. The next time someone offers an idea, say thank you before you say anything else — and notice how hard that is.
- Introduce a deliberate delay on one channel. No same-hour replies to email. See what changes in the quality of your responses.
- Before your next multi-stakeholder decision, do the one-on-ones first. Make the group meeting a confirmation rather than a negotiation.
This quarter
- Audit your own triangle. Which of skill, ownership and empathy are you leaning on, and which have you let go slack?
- Find the conversation nobody in your organisation is willing to have — the code-sharing email of your own company — and have it. Measure the hours it was costing.
- Start the voice habit properly: draft, read aloud, refine, deliver, observe, repeat. Give it a quarter before you judge it.
Final thoughts
The seductive reading of this episode is that communication is a craft you can polish — better words, better structure, better stories. All of that is in here, and all of it works.
But the through-line is heavier than craft. Every technique Parag offers is a way of moving weight onto yourself. The skeleton method is you doing the listener's interrogation on their behalf. The pause is you absorbing the cost of a slower reply so the reply is worth reading. Observation-based feedback is you giving up the satisfaction of a verdict. "This is not what I meant" is you taking a hit that could have been theirs. The acceptance trap is you swallowing a better idea so that the person who offered the first one keeps offering.
None of it is free, and that is exactly why it is rare. It is much cheaper to send the email, deliver the verdict, improve the idea and conclude that people should listen better.
The code-sharing thread is the whole argument in one story. Nothing technical had gone wrong. A mistake had been made, everyone could see it, and the only thing standing between the organisation and a two-minute resolution was that no one wanted to be the one who said we got this wrong. Weeks of collective time, spent on a sentence nobody would say.
"An answer, or a good answer, demands an equally good question."
Parag Chitnis spent two decades in enterprise platform services, working on the systems behind international roaming, before moving into professional coaching. He writes at paragchitnis.com.