I’m a New Zealander based in Seoul. This is what it has looked like from the inside, from both sides of the hiring table, and what I’d tell anyone thinking about the move.

How I got here

#

My route in was a master’s in computer science at Kyung Hee University, from March 2017 to February 2019, after a BSc at Waikato and a year in network operations at a telco back home. Every semester our lab went to KSC and KCC, two domestic computing conferences. At KSC 2018 in PyeongChang the sponsors included several of Korea’s biggest tech companies, and there were recruitment booths for anyone job hunting, which is worth knowing if you’re a grad student here.

Since then:

The engineering was the familiar half. The support startup is where I learned how much of shipping software is actually operations, and the creator platform’s backend ran on more stacks than I’d choose today. The local differences sit at the edges. Naver is a search engine you have to care about: when I launched a new website for Kiwi Alumni, I did its SEO for Google and Naver both. Korean platforms crawl under names you won’t guess (Naver’s crawler is Yeti, and Kakao’s link previews come from one called kakaotalk-scrap). And Korean online banking still wants its own security software installed on your computer.

None of that is the hard part, though.

What 눈치 is, and why “optics” isn’t it

#

눈치 is the sense for what other people think, want or expect, picked up from the situation rather than from anything they’ve said. 눈 means “eye”, and Euny Hong, whose 2019 book The Power of Nunchi is the best-known English introduction, translates the whole word as “eye-measure”. It turns up in a few everyday phrases. Someone who is 눈치가 빠르다 is quick to read a room. Someone who is 눈치가 없다 can’t read one at all, and it isn’t a compliment. And 눈치를 보다 is keeping an eye on how others are reacting, usually someone senior, and adjusting to stay on the right side of it.

The English word people reach for is “optics”, and it’s the wrong one. Optics is how something looks from outside, whatever it actually is: “the optics of announcing bonuses in the same week as the layoffs”. It’s about appearances, and it’s managed by whoever is being looked at. 눈치 mostly points the other way. It’s about how well you see other people, not how you look to them. The two only meet in 눈치를 보다, where you watch everyone else in order to manage how you look to them, and that’s the version that turns up in articles about Korean offices.

The examples in those articles are much the same each time: not leaving before your team lead does, the 눈치 people feel about actually taking their annual leave (연차), knowing when you’re allowed to go home from a 회식 (a team dinner), and deciding whether to contradict a senior in the meeting or quietly afterwards. Whatever you make of them, they share a shape. Each is a rule that everyone follows and nobody states.

It’s a separate problem from the language, too. Korean is in the words. 눈치 is in everything around them.

Where it shows up on a dev team

#

That shape is what dev teams run on. A few months into my first management job I wrote a post about team norms that began with this: most of the friction I dealt with wasn’t technical. It was people running on different unspoken assumptions about how fast a code review should come back, what “done” actually means, and whether it’s rude to ping someone twice. I didn’t use the word then, but that list is what 눈치 reads, every line of it. Each one is a rule a team agrees on without saying, and a newcomer can only pick it up by watching.

In the same post I grumbled about new hires learning the norms “as folklore instead of hearing them explicitly during onboarding”, and about global teams assuming their baseline is everyone’s. Folklore is the best English word I’ve found for what 눈치 runs on. When you’re the foreigner on the team, yours is the baseline that’s off, and the folklore isn’t written down anywhere you could read it.

The standup is where it costs the most. In 2023 I wrote about a project I was leading that fell behind while I waited for someone to ask about it. Someone finally did, three weeks later, and by then it was a disaster. Good 눈치 doesn’t fix that. Reading the room tells you what nobody wants to hear; it doesn’t tell you to say it anyway. The habit I took away is the opposite of waiting. Say it first, in writing, before anyone asks: “This is taking longer than I thought. Now looking at 8–10 days instead of 5. Want me to cut scope or push the deadline?”

When you’re the one being read

#

In February 2024 I started managing an engineering team at a Seoul software company, and 눈치 turned round. As a developer I’d been the one reading the room. As the manager, I was the room. What I said in a meeting, what I didn’t, how quickly I replied and what time I went home were all things other people could now read.

A lot of what I’d written as a project lead applies with more force once you’re the manager. If people don’t feel safe telling you what’s broken, you’ll be the last person to find out. Sit on information too long and people can sense it, and the rumour mill fills whatever silence you leave. “I don’t know” feels like failure when five people in a meeting are waiting on your answer, which is exactly why it’s worth saying. And the line I keep coming back to: people can’t read your intent, only your words. In a team that runs on 눈치 they’ll try anyway, from your face, from what you skip and from when you leave, which is a good reason to give them less to guess.

What I leaned on was unglamorous. One-on-ones with everyone, kept about the person rather than the sprint, with the plain question that does most of the work: “Is there anything you need from me or the team to help with your tasks?”

A short list of team norms, three to five of them, written where everyone could see them, including what happens when the manager breaks one. Going to ask the people who will never speak up in a room of eight, instead of waiting for them to. And an honest “no, and here’s why” in place of a “we’ll see” that never comes up again, because a vague answer is just one more thing to read the room for. A month in, the product team’s outing started at a café with a workshop on each other’s values and team norms, which is about as direct an answer to 눈치 as a company can give: a morning spent saying out loud the things that usually go unsaid.

Being hired as a foreigner

#

I don’t have a recruiting playbook for Korea. What I have is the hiring manager’s side of it, and the advice that falls out of that is 눈치 pointed at the employer before you sign.

When I was hiring as a manager, the developers I most wanted were never on the job boards, and founders, as I’ve written before, would much rather hire someone they’ve already worked with. So the best way in is anything that lets people see you work first. An internship at a small company has a habit of quietly turning into a job offer. A hackathon gives you a whole weekend of it: in 2023 I was on a team of four that won the Seoul Tech Impact Hackathon, hosted by Lunit Global, with an app for finding street food vendors, who in Korea don’t have addresses.

Then there’s the coffee chat. I wrote that how someone behaves in a relaxed conversation tells you more about working with them than a rehearsed interview ever will, and that it runs both ways. For a candidate it’s the one chance to read a team before you’re inside it. The questions I’d ask from the candidate’s chair: what’s the biggest challenge the team is facing right now, why did you join and what’s kept you here, and what’s something about working here that might surprise me. That last one is a polite way of asking for the 눈치 up front. Evasive answers about turnover or direction tell you plenty on their own.

If you’re hiring a foreign developer

#

If you run a team in Korea and you’re hiring a developer from somewhere else, the most useful thing you can do is the phrase from that norms post: make the implicit explicit. Don’t leave them to learn your rules as folklore. Tell them in the first week how fast reviews are expected back, what “done” means, whether a second ping is rude, what time people actually go home, and whether taking leave involves anything beyond the form. The last two are the classic 눈치 questions, the ones nobody inside the team thinks to say.

After that it’s the boring habits that leave less to read. Tell people before they ask; a Friday email to stakeholders with three bullets (what shipped, what’s next, anything you’re worried about) takes ten minutes. Ask the quiet ones directly rather than waiting for them in the meeting. Give real answers, “no” included, with the reason attached. And interview every candidate with the same questions against the same rubric. That one took me a while to learn, but it’s the only fair way to compare people; otherwise you end up favouring whoever you spoke to most recently. It also means the candidate who doesn’t know your team’s unspoken rules gets asked exactly what the one who does gets asked.

The New Zealand community here

#

In 2018, while I was still a student, I took the photos at a Kiwi Chamber leadership breakfast, and wrote afterwards that I really enjoy volunteering for events that promote the relationship between the two countries. Since January 2020 I’ve chaired Kiwi Alumni, a community for New Zealanders in Korea and for people who studied in New Zealand and now live and work here. It’s a volunteer role, and mostly people work: organising events and building relationships with the New Zealand Embassy and education institutions, plus unglamorous jobs like a new logo and a website members can actually find things on. In 2023 we ran Kiwi Alumni Night with the Embassy, and it ended up on KTV.

What I wrote after that night is the nearest thing this post has to a thesis. People who’ve lived in both Korea and New Zealand understand how to bridge the differences, because they’ve experienced both cultures. If you’re coming here to work, find those people, wherever you’re from. They’re the ones who’ll tell you in plain words what the room was saying.

Freelancing from Seoul

#

I went freelance in October 2025, after leaving the manager’s job. In practice that’s contract DevOps and MLOps work, mostly on-premise: a high-availability PostgreSQL cluster, then serving infrastructure for LLMs on the same hardware. More of it has turned out to be quality control than plumbing, watching traces and multi-turn conversations to find where model output drifts. Since February 2026 I’ve also been building a marketplace and community app of my own, on the side.

Freelancing doesn’t get you out of 눈치; it changes what you read. The first thing I look at anywhere I land is the monitoring, because it tells you more about a team than the README does. That’s 눈치 for systems: reading what a team actually does rather than what it says it does.

What I’d tell someone considering it

#

1. Come in through a door where people see you work before they hire you. Mine was a master’s. A hackathon, an internship at a small company or your own country’s community here do the same job, and the community is where you’ll find the people who’ve lived on both sides.
2. Don’t rule out small companies; most of my career has been at them. At a ten-person company there’s nobody to hand the boring work to, and what you build actually goes live.
3. Read the team before you join. Use the coffee chat, ask what would surprise you about working there, and take evasive answers about turnover seriously.
4. Don’t wait to be asked. A slipping estimate, a risky change, a decision someone else depends on: say it first, in writing.
5. Ask for the unwritten rules out loud: how fast reviews come back, what “done” means, whether a second ping is rude. If nobody has written them down, offer to.
6. Learn the stack around your stack. Naver and Kakao matter here in ways your Google habits won’t cover.

The engineering is the half you can prepare for before you arrive. 눈치 is the half you learn on the job, and the quickest way I know to learn it is to ask people to say the quiet part out loud, and to say yours first.

I’ve been thinking about this a lot lately because I’ve been leading projects myself, and the temptation to bluff is real. When someone asks you a question in a meeting and five people are waiting on the answer, “I don’t know” feels like failure. It isn’t. Most of the time it’s the strongest thing you can say, as long as you follow it with what happens next: who you’ll ask, or when you’ll come back with the answer.

Bluffing gets found out

#

Software moves too fast for anyone to hold it all in their head, and engineers can smell a bluff from across the room. The first time your team catches you pretending to know something, they quietly downgrade everything else you say. Whereas a manager who admits a gap and then goes and closes it earns the opposite: people trust their actual answers, because they know a real answer when they hear one.

It’s a starting point, not an answer

#

The trick is what comes after. “I don’t know” followed by nothing is just shrugging. What good managers do next is ask better questions — “how does this compare to what we’re using now?”, “what breaks if we’re wrong about this?” — and then point those questions at the right people. Every team has someone who practically lives in the database, someone who knows all the ugly frontend edge cases. You don’t need to know everything; you need to know who does, and to actually ask them.

How to say “I don’t know” at work without sounding unprepared

#

The rule I try to follow: “I don’t know” is never the end of the sentence. A few versions that work out loud:

• “I don’t know yet. I’ll find out and get back to you by Thursday.”
• “Not sure, but Sam built that service. Let’s ask them.”
• “My best guess is X, but I’d want to check Y before we commit to it.”
• “I don’t have that number to hand. I’ll post it in the channel after this meeting.”
• “I haven’t looked into that properly, so I’d rather not guess. Give me until tomorrow.”

Is it rude? Not when there’s a next step attached. What people find rude, or at least frustrating, is a shrug that leaves them no further along, or a confident answer that turns out to be made up. Job interviews work the same way: if you don’t know, say so, then talk through how you’d find out. That tells the interviewer more than a guess would.

Decisions come out better

#

Decisions in software tend to stick around, so it’s worth being honest about which parts you’re sure of and which parts you’re guessing. Admitting the gaps up front means you gather what’s missing before deciding instead of after, and it gives people who disagree with you room to say so — which is exactly when you most need to hear it. Once you’ve decided, explain the why. And if it turns out you were wrong, say that too. Nothing kills a team’s honesty faster than a manager who can’t admit a bad call.

None of this is complicated. Ask questions, listen to the people who know more than you (there are always people who know more than you), and be upfront when you’re guessing. “I don’t know, but let’s find out” has done more for my credibility than any answer I’ve ever bluffed my way through.

Why openness is still my default

#

The standard arguments for transparency are all true, and I’ve seen each of them play out. When people understand the reasoning behind a decision, they trust it, even when they don’t love it. When they have the same information I do, they make good calls without waiting on me. And nobody enjoys discovering they were out of the loop on something that affected them.

Where raw transparency goes wrong

#

Three ways, mostly.

Volume. Forwarding every half-formed update buries the things that actually matter, and people learn to tune out.

Context. Raw information without the surrounding story breeds confusion. “We’re reviewing the roadmap” means one thing with an explanation attached, and something much scarier without one.

Timing. Share something before it’s actually decided and the team spends a week speculating about outcomes that were never on the table. Half-decided news can eat more energy than the final decision ever does.

Waiting isn’t the same as hiding

#

Choosing the moment to share something sounds manipulative. Done honestly, it’s the opposite: it’s making sure news arrives with enough context to be understood. Bad news lands softer when it comes with a plan attached. Good news lands better when it isn’t buried in a Friday afternoon dump.

But waiting has a cost, and it compounds. Sit on information too long and people can sense it. The rumour mill fills any vacuum you leave, and rumours are reliably worse than reality. And if someone is consistently the last to know, they read it as a statement about their worth. Fair enough, too — it usually is one.

How I decide now

#

Before sharing (or holding back) something sensitive, I run through a few questions. Does the team need this to do their jobs, or do I just want it off my chest? Can I explain the context properly yet, or would I be handing over raw fragments? And how is this likely to land — do I have answers ready for the obvious follow-up questions?

Then, whichever way I go: deliver context along with the information, make it easy for people to ask questions afterwards, and pay attention to how it went so the next call is better calibrated. Different people want different amounts of detail, and you only learn that by watching and asking.

Default to openness, add context, and think for a minute about how it’ll land before you hit send. That covers most situations I’ve run into so far.

I’ve been finding that line the hard way. I’m a developer who ended up leading a project team, not someone who trained for this, so most of what follows was learned by getting it slightly wrong first.

What empathy in leadership actually means

#

Empathy in leadership means understanding how the people on your team are actually doing, and letting that carry real weight when you make decisions, give feedback, or decide how the team works. It isn’t agreeing with everyone, and it isn’t being pleasant in meetings: you can understand someone’s situation completely and still say no. When people can tell their situation gets factored in, they relax, they speak up earlier, and the work genuinely goes better. That part of the standard advice holds up.

Too little hurts. So does too much.

#

The failure everyone warns you about is the cold manager who treats people as resource allocations. That one’s real: ignore what’s going on in someone’s life and they go quiet, morale drops, and you find out about problems months late.

The failure nobody warns you about is the opposite. If you accommodate everything, boundaries blur. Deadlines turn into suggestions. And the people quietly holding the standard start to resent covering for the ones who aren’t held to it. I’ve caught myself over-accommodating because it felt kind in the moment — it wasn’t kind to the rest of the team.

Examples of empathy in leadership, done well and overdone

#

The difference is easier to see side by side. None of these are rules, just the shape I’d aim for:

Everything in the overdone column has one thing in common: it feels kind in the moment, and it pushes the cost onto later, or onto someone else.

Check-ins do most of the work

#

What keeps me somewhere near the right balance isn’t a philosophy. It’s a recurring calendar slot. Regular one-on-ones mean small problems surface while they’re still small, instead of arriving all at once as a resignation letter.

Mine loosely cover the same ground each time: what’s blocking you, what’s gone well lately, how the team is working together, where you want to grow, and what I could be doing differently.

The most useful question I’ve found is a plain one: “Is there anything you need from me or the team to help with your tasks?” It sounds mundane. It isn’t. It signals that I expect to be part of the solution, and the answers are almost always concrete things I can actually fix — access to someone, a decision that’s been floating, an hour of pairing.

Being straight when the answer is no

#

Check-ins generate requests, and you can’t grant them all. How you handle the ones you can’t is where trust gets made or lost.

What works for me: take the request seriously and say so, explain why it can’t happen right now, offer whatever partial alternative exists, say when you’ll look at it again — and then actually come back to it, even if the answer hasn’t changed.

None of that makes a “no” fun to deliver. But people handle an honest “no, and here’s why” far better than a vague “we’ll see” that’s never mentioned again.

That’s about as close to a formula as I’ve got: care about how people are doing, be honest about what the work needs, and check in often enough to notice when you’ve drifted too far in either direction.

The slowest part of most projects I’ve worked on wasn’t the code. It was the queue: decisions stacked up behind one manager’s calendar, waiting for a nod that took three days to arrive. Async communication and autonomous teams are the standard fix, and I’m a believer, but the shift is mostly a trust problem dressed up as a tooling problem.

Why everything needs a sign-off in the first place

#

It’s worth being fair about where approval culture comes from. Control feels like precision — if every decision crosses the manager’s desk, nothing drifts off course. A bad call doesn’t just dent the project, it dents the manager’s reputation, so fear does a lot of the work. Sometimes there’s genuine doubt about whether the team has the experience to decide well. And sometimes it’s pure residue: the org chart has always worked this way, so it keeps working this way.

Notice that only one of those four reasons is actually about the team. The rest are about the manager.

What autonomy actually requires

#

Autonomy without alignment is just chaos with better morale. If people genuinely understand the objectives, their independent decisions mostly point in the same direction — that’s the whole trick. Training matters too, because a well-equipped person is easier to trust than an enthusiastic one. And keep some boundaries: certain decisions genuinely should stay with management, and saying which ones out loud prevents the worst surprises. After that, let the feedback loop run and treat the inevitable mistakes as tuition rather than evidence.

If trust has already been damaged — and in teams crawling out of approval culture, it usually has, in both directions — there’s no shortcut. Name the problem in an open conversation, let management own its share of the mistakes first, and then be boringly consistent for months. Clear roles and regular check-ins do more repair work than any grand gesture.

The async part is the easy part

#

Tools first, but briefly: Slack or Microsoft Teams will do fine. The real work is documentation — when nobody’s in the same room or the same timezone, written decisions become the team’s memory. Set response norms so async doesn’t quietly become unresponsive; “within a day” beats “whenever”, and they belong in the team’s communication plan next to who gets which update. And actually teach people to write a good async update, because the skill isn’t innate: enough context to decide, the decision needed, and a deadline. Something like this:

Decision needed by Thursday: payment retries
Failed card payments currently retry once, after 24 hours, and “where’s my order?” is now our most common support ticket.
Option A: retry three times within 24 hours (about half a day’s work). Option B: leave it and email the customer instead.
I’d go with A. Details and numbers are in the linked doc.
If there are no objections by 5pm Thursday, I’ll start on A.

Anyone can read that at 7am or 11pm, in any timezone, and answer it without a meeting.

You can roll out Slack in an afternoon. The trust takes months, and it’s the part that decides whether any of this works. Get the objectives clear and make mistakes cost a lesson instead of a career — the async part mostly takes care of itself after that.

Most of the project messes I’ve been pulled into weren’t caused by bad code. They were caused by the right information not reaching the right person until it was too late. Since stepping up as project lead at work, I’ve been keeping notes on how I’d want to run communication if I ever end up in the CTO seat. Here they are.

Decide who needs to know what

#

The unglamorous foundation is a communication plan: who needs to be informed, what they need, how often, and through which channel. I’d push for one at the start of every project, with names attached — communication that’s everyone’s job ends up being no one’s job. The same goes for stakeholders: work out who actually cares about the project, learn how each of them prefers to be updated, and don’t send the CEO the same update you post in the dev channel. Finally, set a few explicit protocols — expected response times, what counts as urgent, which channel is for what. Most “communication problems” are really just unstated expectations.

An example communication plan for a software project

#

This is the plan I’d start with and then adjust. Each row is an audience, not a meeting:

Underneath the table go the protocols, written as plainly as possible: urgent means it blocks a release or a customer, so call rather than message; questions go in chat, decisions go in the tracker; replies within a working day. For the decision log I use decision documents, kept as GitHub Issues so they sit next to the work.

Two things make a plan like this work. Every row has a name in the last column, and the leadership update is written rather than spoken, so it can be forwarded without losing anything.

Tools and rhythms

#

Tools matter less than people argue about them. Slack for chat, Trello for tasks, Zoom when a conversation needs faces — pick what fits the team and move on. Rhythm matters more: daily stand-ups if you’re working agile, weekly updates on longer cycles, and actually holding to them. And write things down. Decisions, changes, action items — into Notion or Jira, as part of the process rather than an afterthought. Six months later, the doc is the only memory anyone has.

The soft parts are the hard parts

#

Everything above is mechanics. The harder work is asking the team whether the communication is actually working, and changing it when it isn’t. It’s training people up, too — teams come from varied backgrounds, and not everyone has seen a well-run project before. It’s listening properly instead of waiting for your turn to talk, and dealing with conflict early, while it’s still small. None of it stays solved, either: what worked last quarter quietly stops working, so keep checking.

Working as a distributed/asynchronous development team

#

This talk is worth your time if your team is remote or async-heavy:

I don’t do all of this perfectly — nobody does. But every project that went smoothly for me had most of these in place, and every one that hurt was missing at least three.

That’s the short version. The longer one is below, because I’ve had feedback conversations go wrong the same way more times than I’d like to admit: I raise something, the other person’s shoulders go up, and from that moment neither of us is really listening.

Why people get defensive in the first place

#

Defensiveness isn’t stubbornness, or at least it rarely starts that way. It’s what people do when they feel threatened, and feedback threatens more than we tend to think. You’re nominally talking about a pull request or a missed deadline. What the other person hears is a question about whether they’re good at their job, whether they belong on the team, whether you’ve been quietly thinking this for months.

Once someone feels that, their attention goes to protecting themselves, not to the point you’re making. Arguing harder only confirms the threat. So most of what works below is about lowering the stakes first and only then getting to the substance.

It also helps to remember that some people come into these conversations already bruised. A previous manager who only ever spoke up to criticise, a culture where mistakes got people sidelined. You can’t fix that history in one meeting, but it explains why a mild comment sometimes gets a much bigger reaction than it deserves.

Before the conversation

#

Most feedback conversations are decided before they start. A few things I do now that I didn’t used to:

I pick one thing. If I’ve saved up five issues, the person hears a prosecution, not feedback. The other four can wait, and often turn out to be symptoms of the first one anyway.

I do it soon. Feedback about something that happened six weeks ago lands as “why are you only telling me now?”, which is a fair question with no good answer. A day or two after the event is about right: soon enough that it’s fresh, late enough that neither of you is still hot.

I do it privately, and I don’t do it over chat if I can avoid it. Written feedback loses tone, and a defensive reader fills the missing tone in with the worst possible version. If it has to be written because the team is remote or across timezones, I keep it short and offer a call.

And I check my own state. If I’m annoyed, the other person will pick it up within the first sentence, whatever words I use. Some feedback I’ve given would have gone much better if I’d waited until I’d stopped being irritated.

What to actually say

#

The structure I keep coming back to is the one usually called situation, behaviour, impact (SBI): when it happened, what they did, and what it caused. The point is that each part is observable. There’s nothing in it about who they are, only about what happened.

Here’s the difference in practice. Say a developer merged a change on a Friday afternoon without waiting for review, and it broke checkout over the weekend.

The version that gets walls up: “You always rush things out. You need to be more careful.”

The version that has a chance: “On Friday the payment change went in without a review, and checkout was down for a few hours on Saturday. I’d like to understand what happened, because I don’t think it was carelessness.”

The second one names one event, says plainly what it cost, and ends by assuming good intent. “Always” and “never” are the words that do the most damage. They turn one incident into a judgement of character, and the other person will immediately think of the counterexample that proves you wrong.

I also try to own the observation. “I noticed” and “I’m concerned” are honest about the fact that this is my view, offered from my side, and they leave room for me to have missed something. Often I have.

Then I stop talking and ask. “How did it look from your side?” There’s usually context I didn’t have, like a deadline someone else set or a reviewer who was off sick. Even when there isn’t, the question tells the person this is a conversation and not a verdict.

Feedback also lands far better with a way forward attached. Not a list of problems but “next time, could we…”. Better still if the way forward comes from them.

When they push back anyway

#

You can do everything right and still get resistance. It tends to come in a few recognisable forms, and each one needs a slightly different response.

The most common is denial: “that’s not what happened.” Don’t argue about it. Go back to what you both can see, like the commit, the message or the date, and ask what you’re missing. If the facts really are disputed, it’s fine to say “let’s both look at it again and pick this up tomorrow.”

Then there’s deflection, as in “well, the requirements kept changing” or “so-and-so does it too”. There’s often some truth in it, so acknowledge it rather than dismissing it: “That’s fair, and we should fix the requirements problem too.” Then bring it back gently: “Separately from that, I want to talk about the review step.”

A counter-attack, like “you merge things without review all the time”, is the hardest one not to match. Take a breath. If they’re right, say so, because it’s the fastest way to lower the temperature, and you’ve just shown the openness you’re asking them for. Then come back to the original point.

Shutting down, whether that’s silence or “fine, whatever you say”, looks like agreement and isn’t. I’ll name it softly, something like “it seems like this didn’t land well, and that’s okay”, and offer to continue later. Forcing a response from someone who’s withdrawn just gets you a fake one.

Over-apologising (“I’m terrible at this, I’m so sorry”) is defensiveness too, just pointed inwards. The person is protecting themselves by getting the criticism in first. Reassure them that it’s one specific thing and not their whole performance, and move on to what happens next.

Through all of these, the one rule I try to hold is not to match their energy. When someone gets defensive, my instinct is to get defensive right back, and that’s the one move guaranteed to sink the conversation. If I stay level, the temperature usually comes down on its own. It helps to say the feeling out loud, something like “I can tell this is frustrating to hear”, rather than pretending the tension isn’t in the room.

Know when to stop

#

Sometimes none of it works and the walls stay up. Pushing harder at that point achieves nothing. It’s fine to park the conversation and come back in a day or two once things have settled. The feedback will still be true tomorrow, and people are often much more reflective once they’ve had a night to sleep on it. Some of the best follow-up conversations I’ve had started with the other person saying “I’ve been thinking about what you said.”

That one took me the longest to learn.

After the conversation

#

What happens in the following week matters as much as the conversation itself. If the person changes the behaviour, say you’ve noticed, explicitly and soon. That’s how they learn feedback from you isn’t only ever bad news, and it makes the next conversation easier.

And ask, when it fits, how the feedback landed. “Was that fair?” balances things and shows the openness you’re hoping for in return. When I moved into management I started doing this routinely, and it caught a couple of times where I’d been clearer in my head than out loud.

In short

#

Lower the threat before you raise the issue. Pick one thing, raise it privately and soon, describe the behaviour and its impact rather than the person, and ask for their side before suggesting a fix. When they push back, don’t match it. Acknowledge the feeling, return to the facts, and be willing to stop and pick it up another day. Then follow up, because the conversation after the conversation is where trust gets built.