On the way I sat beside the chief of staff, and we talked about finding hobbies. We agreed that when life is this busy, it’s hard to find a hobby you can enjoy on your own. On this topic, we discussed our university life. Interestingly, she was an artist and enjoyed making 3D art. But the constant demand to make art didn’t seem to match her lifestyle, as she explained. So, I jokingly suggested that she make a piece for our somewhat sterile office environment. Haha

We arrived at the cafe and immediately found a table large enough for all of us. It was great to be able to talk about the things that matter to us.

Furthermore, everyone was very respectful of one another’s opinions, and the CEO and moderator kindly led the event to ensure we finished on time for our next activity.

The next activity was a visit to a whisky distillery! I am a keen whisky drinker, and this was the perfect opportunity to show my somewhat greater-than-average knowledge of the process of making whisky and tasting it. The tour guide took on the challenge of explaining the distillery in English and Korean. We first looked at the process of adding the wheat to the vat and soaking it to extract the sugars. Afterwards, we also got to see the product after it had been fermented for approximately a couple of days. Lastly, we saw the still, which was described as looking like a giant chocolate drop. Inside, it was approximately 30 degrees, so it was very relieving when the tour guide asked us to go outside to see the storage buildings.

The barrels were stacked to the roof with various kinds of wood. Some of the ends of the barrels were labelled with Gochujang, which was a Korean-inspired fusion. We were even given the chance to try the whisky straight from the barrel, which is approximately 60% alcohol by volume! Everybody’s throats were on fire!

To finish up, we had the chance to try their final products, whiskies aged in different barrels. We also got to try their gin, which in hindsight was a mistake: it had a strong mushroomy note.

To wrap up the day, we travelled back to Seoul in the van, found a bar and had a few quiet ones together before everyone went back to their homes. We did so much in one day, and I think we learned a lot about each other while enjoying the activities together!

If you are ever looking for a workplace in Korea, reach out to me!

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’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.

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.