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.

The boring name for the fix is team norms. The Center for Creative Leadership defines them as “a set of rules or operating principles that shape team members’ interactions”, which sounds like HR paperwork but really just means writing down the things everyone assumed were obvious.

The research that sold me

#

Google’s Project Aristotle studied 180-odd of their own teams to work out what made the good ones good. The answer surprised them: who is on a team matters far less than how the team works together. You can stack a team with talent and still get mediocre results if the working agreements are a mess.

The study identified five dynamics that set the strong teams apart: psychological safety, dependability, structure and clarity, meaning, and impact. Psychological safety, being able to ask a dumb question or own up to a mistake without paying for it, did the heaviest lifting. The numbers attached to it are hard to argue with: 43% higher performance variance explained, 19% higher productivity, 31% more innovation, 27% lower turnover.

What I like about that list is that none of the five are personality traits. They’re all things a team can deliberately build, and norms are how you build them.

What norms look like day to day

#

Meetings are the easiest place to start because the bad habits are so visible. Agendas go out in advance, meetings start and end on time, and people summarise what they heard before they argue with it. I’m fond of the blunt version of the agenda rule: no agenda, no meeting.

Communication norms matter more but are harder to see. Mine boil down to: over-communicate by default, write decisions down where everyone can find them, and don’t let meetings be the only channel. Some people will never speak up in a room of eight, so go and ask them directly. There’s plenty of evidence that teams with varied perspectives beat homogeneous ones, but only if those perspectives actually get said out loud.

For disagreements: assume good intent, argue with the problem rather than the person, and dig for what people actually need instead of the positions they’ve staked out. The rare fight that won’t die gets a neutral third party.

How to set them without it turning into bureaucracy

#

The approach CCL recommends starts from experience rather than theory, and it’s the one I’d use. Everyone describes the best and worst teams they’ve been on, the group digs into what made each of them that way, and the patterns become proposals: concrete behaviours for this team, debated and agreed rather than handed down. Then decide up front what happens when someone breaks one (including when it’s the manager), write the norms somewhere visible, and revisit them now and then.

The one rule I’d add: start with three to five. Norms only work once they’re habits, and nobody builds ten habits at once.

Where it falls apart

#

The fastest way to kill norms is a leader who ignores them. If I skip the agenda rule because I’m busy, the team clocks it immediately and the whole exercise becomes theatre. Consistency from whoever’s in charge matters more than the wording of any norm.

A few other traps worth watching: new hires learning the norms as folklore instead of hearing them explicitly during onboarding, global teams assuming their baseline is everyone’s baseline (make the implicit explicit), and people who see the whole thing as process for its own sake. For that last group, involving them in writing the norms works far better than lecturing them.

It also helps to know where norms actually get reinforced. Research on high-performing teams keeps finding the same three habits: proper kickoffs, regular one-on-ones, and retrospectives. That’s where agreements get made, tested and quietly renegotiated, not in a policy doc.

I don’t think norms are magic. But Google’s data points the same way as my experience so far: how a team works together beats who’s on it. So we’re keeping ours short. A handful of agreements, written where everyone can see them, reviewed when they stop being true. Ask me in six months whether they stuck.

Since taking over an engineering team earlier this year, performance reviews have gone from something that happens to me to something I’m responsible for running. I’m writing this partly to organise my own thinking, so take it as notes from someone figuring it out rather than gospel.

Why bother with reviews at all?

#

The purpose, at any level, comes down to two things: help people keep learning, and make sure the ones performing beyond their role actually get rewarded for it.

Plenty of small companies claim they don’t have the time or resources for reviews, and quietly fall back on tenure as the only signal for who’s ready for a senior role. That’s a mistake, and not just because tenure is a lazy metric. Skipping reviews removes the two-way channel between employer and employee, and the working relationship suffers for it.

It cuts in both directions. An engineer can be working in what they honestly believe is the best way for the company while their habits, methods, or communication style drift somewhere unhelpful — without feedback, nobody catches it. And employers who never hear from their people in a structured way stay comfortably oblivious to what those people actually think of the company.

What each side should walk in expecting

#

From the employee’s side the list isn’t complicated. They want to know how their work lines up with the team’s goals, what they’re doing well, and where to improve — specifically, not “communicate better”. They want their contributions recognised, a real conversation about career progression and training, and a process that’s fair and based on their work rather than office politics.

From my side of the table, I expect people to arrive with a self-assessment: their own view of what went well and what didn’t. I’m hoping for openness to feedback rather than a defence lawyer’s opening statement, a genuine discussion about future goals, and honest insight into how they feel they fit into the team. Reviews are also when I do my own planning — team composition, potential promotions, who needs what kind of development.

One framework won’t fit every engineer

#

Engineering teams span different cultural backgrounds, experience levels, and specialities, and the same review script doesn’t work for everyone. Equal treatment and fair treatment aren’t the same thing; the approach has to flex with each person’s needs, career stage, and contribution. The baseline is making sure every engineer’s role and responsibilities are clearly defined and actually match their compensation.

The place this bites hardest is titles and pay. When someone is unsure about their title or feels ready for promotion, vague encouragement is poison. What works is concrete: agree on specific challenges or project goals that serve as the benchmark for the next rank, so advancement has objective criteria instead of vibes. Same for compensation — if someone feels underpaid or wants more responsibility, put measurable targets into their plan that spell out what needs to happen before the next review to justify the change. Then actually hold both sides to it at that review.

Improvement feedback needs the same treatment. A specific training programme, workshop, or project aimed at a specific gap is useful. “Keep growing your skills” is not.

Benchmarks start at the first meeting

#

The first review meeting with a new report is mostly about setting the baseline. Walk through what the role actually involves and how it feeds team and company goals. Agree on the measurable outcomes performance will be judged against. Set goals for the near term and further out. It’s also the right moment to talk about culture and expected behaviour, how and when feedback will arrive, what resources and mentorship are available, and what the career path from their seat looks like. None of this is thrilling, but every later review is easier because it happened.

The agenda I use after that

#

1. Small talk. It sounds trivial, but it takes the tension out of the room, and the rest of the conversation is more honest for it.
2. Run through the agenda so nobody gets ambushed by a topic.
3. Growth since the last review — name the progress explicitly. People rarely notice their own.
4. Current performance, strengths first.
5. Areas for improvement, each with a specific, realistic target attached.
6. Career plans, and whether the current work actually points at them.
7. Targets, goals, and actionable items for the next review.

KPIs only work if they’re personal

#

For engineers on a product team, KPIs have to fit both the team’s objectives and the individual. Front-end, back-end, and full-stack roles differ; junior and senior roles differ more. Commit volume might tell you something about a junior developer, and it tells you nothing about a senior engineer whose main output is architectural decisions. That’s why KPIs get set in a conversation, not copied from a template.

The areas I look at:

• Quality of code: error rates, adherence to standards, how often their work needs bug fixes
• Project delivery: milestones and deadlines met
• Innovation and problem solving: efficiency improvements, hard problems actually resolved
• Collaboration: peer reviews, contribution to team goals and discussions
• Personal development: learning goals hit, certifications, new technologies picked up
• Customer impact: feedback from users, engagement with the features they shipped

On the measurable side, unit testing is an input I’ve been warming to. This article from InfoQ looks at folding unit testing into performance reviews — the mechanics of it, and what it does to team culture — and argues for mixing qualitative and quantitative measures of code health. Worth a read if you’re hunting for KPIs that don’t reduce engineers to line counts.

Whatever you pick, agree on it together in the review or a 1:1, and revisit it as roles, projects, and technology shift. A KPI nobody agreed to is just a stick.

The template I fill in

#

I keep one document per person and add a section per review, so the history is in one place. This is the skeleton:

## Performance review: [Name], [period]

**Role and level:** [title, and what that level means on this team]
**Goals from last review:** [copied from the previous section]

### Self-review (filled in by the engineer beforehand)
- What went well, with an example or two
- What didn't, and what they'd do differently
- What they want to be doing in a year

### Progress on last review's goals
- [Goal]: met / partly / not met, with the evidence

### Strengths (specific examples)
- [What they did, when, and what it changed]

### Areas to improve (each with a target)
- [Behaviour or skill] → [what "better" looks like] by [date]

### Career and level
- Where they are against the next level, and what's missing

### Goals until the next review
1. [Measurable goal]
2. [Measurable goal]

### Agreed actions
- [Who] will [do what] by [when]

The self-review comes in a day or two before the meeting, never during it. Reading it first changes the conversation: half the time the engineer has already named the thing I was going to raise, and we can spend the meeting on what to do about it.

Questions for the self-review

#

These are the prompts I send ahead of time. They’re open on purpose, so the answers tell me how someone sees their own work, not just what they did:

• What are you most proud of since the last review, and why that?
• Where did you get stuck, and what would have unstuck you sooner?
• What feedback have you had from teammates or reviewers that stuck with you?
• Which of last review’s goals do you think you met, and which do you want to drop or change?
• What do you want to learn next, and is your current work giving you a chance to?
• What should I be doing differently as your manager?

The last question gets the most awkward pauses and the most useful answers.

What specific feedback sounds like

#

Most bad review feedback isn’t harsh, it’s vague. Here’s the difference, with examples of the kind I try to write:

Each specific version names an event, says what it changed, and points at something the person can do next. It takes longer to write, which is exactly why I make myself collect examples through the quarter instead of trying to remember them the night before.

Write it down

#

After the meeting, write a summary: the key points discussed, any issues raised, the action items, and the objectives both of you agreed to. It sounds bureaucratic, but the written record is what prevents the “that’s not what we agreed” conversation six months later. Documented issues get tracked instead of evaporating, action items hand the next review its opening agenda, and people take goals more seriously once they’re on paper.

That’s the whole system, really: clear expectations from day one, KPIs shaped to the person, everything documented, and follow-up on every action item. A review that isn’t a two-way conversation with measurable outcomes is a checkbox exercise, and engineers can smell a checkbox exercise from the calendar invite.

I started managing an engineering team this month, a few weeks after writing about what changes going from software engineer to engineering manager. The thing nobody warns you about is how urgent everything feels: new team, new company, and a to-do list that existed long before I did. I can’t do it all at once, so I’ve settled on three things to get right before anything else.

Getting to know the team

#

I’m booking 1:1s with everyone, and I’m trying to keep them about the person rather than the sprint. What do they want out of their career? What’s been frustrating them? What would they change tomorrow if they could? My job in these is mostly to shut up and listen. Trust isn’t built in week one, but it can definitely be lost in week one.

People also work in very different ways. Some want detailed direction, others do their best work when you stay out of it, and treating one like the other goes badly for everyone. Camille Fournier’s “The Manager’s Path” is good on this. Empathy and actually listening turn out to be most of the job.

Learning why things are the way they are

#

Every process and every odd bit of architecture is a record of some old decision. Before I change anything, I want to know what’s been tried, what failed, and what the company genuinely cares about.

Every company also has unwritten rules about how decisions really get made. The faster I work those out, the more I can actually get done for the team. Andrew Grove makes this point in “High Output Management”: you can’t align your team’s work with the bigger picture until you understand the picture yourself.

Reading the code

#

I don’t need to be the strongest coder on the team anymore, but I do need to understand the architecture, the pain points, and where the technical debt is buried. So I’m reading code, poking at the deployment pipeline, and asking people what they’d fix if they had a free week. The answers to that last question are usually the most honest roadmap you’ll get.

It also signals something to the team: that I care about the work itself, not just the process wrapped around it.

Then get out of the way

#

Once that foundation is there, the plan is simple: set context, share the goals, and let the team make the technical calls. My job isn’t to approve every PR. It’s to make sure people have what they need and are pointed in the right direction. “The Phoenix Project” by Gene Kim makes the same argument: teams that own their decisions move faster and build better software than teams waiting on sign-off from above.

Books for new engineering managers

#

The three books I’ve mentioned, in one place:

Two others come up whenever people ask what a new engineering manager should read: Will Larson’s An Elegant Puzzle, on the systems side of the job (sizing teams, planning, organisation design), and Lara Hogan’s Resilient Management, a short, practical book on getting to know your team, setting clear expectations and communicating well.

Ask me in six months how it’s going.

I’m about to make this move myself, so I’ve spent the last while talking to people who’ve done it and reading whatever I could find. The clearest lesson so far: going from engineer to engineering manager isn’t a step up. It’s a step sideways into a completely different job. Your output stops being code and becomes whatever your team produces. Everyone says this, and from what I can tell, everyone still underestimates it.

What actually changes

You stop solving technical problems directly and start solving people problems. The calendar fills up with 1:1s, planning meetings, and cross-team alignment. Hiring and performance reviews land on your desk. Most of the job becomes making sure the team has what it needs — context, clear priorities, and as little nonsense as possible — to get on with the work.

The awkward part is that you still have to stay technical enough to hold your own in architecture discussions and make sensible judgment calls, while accepting that you can’t be the one writing the code anymore. The managers I’ve watched try to do both usually end up doing both badly.

Engineer vs engineering manager, side by side

The feedback loop is the row people warn about most. As an engineer you get a small win most days. As a manager the wins are real but slow, and you have to get used to not knowing for a while whether a decision was right.

The skills that seem to matter

Communication is most of it. You become the translator between your team, product, and leadership, and a surprising amount of the job is making sure those three groups are talking about the same thing. Trust matters more than any process: if people don’t feel safe telling you what’s broken, you’ll be the last person to find out. Your calendar will genuinely try to eat you alive, so protecting time to think — and time for your team — is a constant fight. And you need to understand what the business is actually trying to do, or you can’t point anyone in a useful direction.

Preparing before the title arrives

The advice I keep hearing, and the bit I can already vouch for: start leading before anyone gives you the title. Run a project, mentor someone, organise something. I’ve spent the past year acting as a project lead, and that experience is doing far more for me than any book. That said, books help — “The Manager’s Path” by Camille Fournier is the one everybody recommends, and having read it, I see why. Keep your technical skills sharp, because the architecture debates don’t stop. And find a mentor who’s already made the transition; they’ll steer you around mistakes that only look obvious in hindsight.

The trade-off

More influence over how things get built, but you’ll rarely build them yourself. I expect some days that will feel great, and other days I’ll badly miss writing code. Everyone who’s done this tells me that’s normal. Ask me again in six months.

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.

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.

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.