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.

A coffee chat is 30–45 minutes, informal, at a café or over a video call. No whiteboard, no panel, no trick questions. I talk about what we’re building and why, they talk about what they’re working on and what they’d want next, and both of us leave knowing whether a deeper conversation makes sense. Hiring is a matching problem more than a selection problem, and this is the fastest way I know to trade the information that matching actually needs.

Why I bother

#

I’ve stopped thinking of these chats as recruiting. They’re just conversations, and every so often one turns into a hire — sometimes eighteen months later, when the person’s circumstances change. The pipelines that reliably produce good hires are built out of relationships like that, not out of job ads.

They also fix the job-description problem. JDs are generic by necessity. Over coffee, a candidate can ask the questions that actually matter to them: what does success look like in the first six months, who would I be working with, what’s the hairiest technical problem on the team right now. People who hear honest answers to those questions self-select well.

And a chat shows your culture instead of describing it. Whether you turn up prepared, curious, and respectful of someone’s time says more than any careers page. It runs both ways, too — how someone behaves in a relaxed conversation tells you more about working with them than a rehearsed interview ever will.

The moments where a coffee chat earns its keep: approaching someone who isn’t looking, warming up a referral before anything formal, and talking with someone weighing a career shift — IC to management, startup to enterprise, or the reverse. In a tight talent market, that covers most of the people you want.

How I run one

#

The first message decides everything. Generic outreach gets deleted. Do your homework and be honest about your intentions:

“Hi Sarah, I noticed your talk on distributed systems at QCon and your blog posts on event sourcing. We’re tackling similar challenges at [Company] as we scale our payment infrastructure. Would you be open to a 30-minute coffee chat? No interview agenda—just curious to hear your perspective and share what we’re working on.”

That works because it’s specific, upfront, and offers something (a conversation about interesting problems) rather than only asking for time. Then make it easy: offer a few time options, pick a spot convenient for them or a video tool that doesn’t need a download, and send a proper calendar invite so nobody’s guessing.

The chat itself only needs a loose shape. A few minutes of real small talk and why you reached out. Then their story — current work, what they enjoy, what frustrates them, what they’d want in the next thing — where your job is mostly to listen. Then yours: the mission, the team’s actual challenges, hard parts included, because candidates respect transparency and can smell a sales pitch. The most valuable stretch is the open one near the end: what would need to be true for them to consider a move? Close with explicit next steps, even if the next step is just “let’s stay in touch”.

Follow up within 24 hours with a short note that references something specific, and deliver anything you promised — an intro, a link, whatever. The boring aftermath is the real culture demo.

If you do this more than occasionally, keep a simple spreadsheet of who you’ve talked to and check in every so often, even with no role open. And it needn’t be a manager-only activity — some of the best chats happen when your engineers grab coffee with impressive people in their own networks. That’s where good referrals come from.

Questions that earn their slot

#

Ones I ask:

• “What’s been the most interesting problem you’ve worked on recently?”
• “What would you want to be different in your next role?”
• “What’s your learning style? How do you like to grow professionally?”
• “What questions do you have that would help you evaluate whether this could be a fit?”

Ones I’d ask if I were on the other side of the table:

• “What’s the biggest challenge the team is facing right now?”
• “How do you measure success for this role?”
• “What does the path to promotion look like?”
• “Why did you join the company? What’s kept you here?”
• “What’s something about working here that might surprise me?”

If you’re the one invited

#

Most people who look up what a coffee chat is are on the other side of the table from me: someone has asked them for one, and they want to know what they’re walking into. Here’s what I’d tell you from the side that sends the invitations.

It isn’t an interview. Nobody is scoring you and there’s no test, so you don’t need to prepare answers. It is still a first impression, though, so treat it like meeting a future colleague rather than a friend of a friend. The difference from an interview is that you’re allowed to be curious, and you’re expected to ask as much as you answer.

Wear what you’d wear to work there on an ordinary day. If you don’t know, smart casual is never wrong. On a video call, have the camera on and find a quiet room; that matters more than the shirt.

Preparation takes about half an hour. Read what the company makes and anything the person has written or built. Have a two-minute version of what you work on now and what you’d want next, because that question is coming. Bring two or three of your own questions; the list above is a fair start.

As for what to talk about: your work, what you enjoy about it, what you’re curious about in theirs. Leave salary for later unless they raise it. It’s perfectly fine to ask whether there’s a role in mind and what the process would look like if there were.

Whoever did the inviting usually pays. Offer, but don’t make a thing of it. Send a short thank-you within a day that mentions something you actually talked about, and you’ve done more than most.

And if you want one yourself, ask. Keep the message short, say why that person, and make it easy to say yes: “I’ve been following your team’s work on the new search, and I’m thinking about moving into platform engineering. Would you have 30 minutes for a coffee or a call in the next few weeks? Happy to work around you.” Most people say yes to a request that specific.

Ways to ruin it

#

The fastest is turning it into a stealth interview. Start quizzing someone on technical skills or sliding in behavioural questions and you’ve broken the implicit deal — save that for the formal process. Over-selling is a close second: the hires that stick are the people who joined with clear eyes about the hard parts. Turning up unprepared, or going silent afterwards, does quieter damage; every chat shapes what that person tells their network about you.

From my side of the table, the warning signs are a candidate with no curiosity about anything, a conversation that feels purely transactional, or someone who describes every past employer with the same bitterness. Candidates should keep their own list: a rep who can’t explain why the work matters, evasive answers about turnover or direction, and anyone more interested in selling you than understanding you.

Not every chat leads anywhere, and that’s fine — most don’t. The point is that the next time you need to fill a critical role, you’re not starting from a blank job ad. You’re starting from a stack of real conversations. Reach out with an invitation to coffee, not a job description.

Further Reading

#

Related Articles on This Site:

• Using the STAR Method for Developer Interviews - for when the chat turns into a formal interview process
• Three Things I’m Focusing on as a New Engineering Manager - what makes teams work, which is what you’re matching for
• Why You Should Intern at a Startup - useful context when chatting with someone weighing a startup move

External Resources:

• First Round Review: Hiring Engineers - startup hiring guides from experienced operators
• Lara Hogan’s “Questions for Our First 1:1” - written for 1:1s, works brilliantly over coffee
• Patrick McKenzie on Salary Negotiation - worth reading to understand the candidate’s side of the table
• Who: The A Method for Hiring - Geoff Smart and Randy Street’s framework for systematic hiring
• Harvard Business Review: Hiring and Recruitment - research-backed pieces on talent acquisition

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

Nobody enjoys being asked “how’s it going?” — and as the one leading a project at work, I still need to know how it’s going. My compromise is the git graph: I look at it before I ask anyone anything, and most of the time it already has the answer. It shows commit activity, branching and merging at a glance, and nobody has to sit in a meeting for it.

What the graph actually tells you

#

If you haven’t looked at one closely: every node is a commit, every divergent path is a branch, and the whole thing reads as a timeline of the project. That layout carries a surprising amount of information:

• A glance shows how many branches are active and how often commits are landing.
• A branch that suddenly goes quiet, or one that hasn’t merged for weeks, usually means someone is stuck. That’s an early warning worth having.
• Merge frequency tells you how the team collaborates. Frequent merges mean work is actually being integrated; long-lived branches usually mean someone has drifted off into siloed work.

Fewer interruptions, better conversations

#

The obvious win is that I don’t have to interrupt anyone to know where things stand. The bigger win is what happens when a conversation is needed: it starts from the graph rather than from assumptions. “This branch hasn’t moved since Tuesday — anything blocking you?” is a much better opener than “any updates?”

It also helps to make the routine explicit. Mine is a quick glance most mornings and a proper look once a week. The team knows that’s the rhythm, so nobody gets surprised.

Don’t turn it into surveillance

#

This is the part I have to keep reminding myself of. Commit count is not value — one thoughtful commit can beat fifty noisy ones. Seeing every commit doesn’t entitle you to question every decision; trust the team and step in only when a pattern genuinely looks like trouble. And when you do bring the graph into a conversation, it’s a starting point for feedback, not evidence for a prosecution.

Viewing the graph in the terminal

#

Nothing to install, just Git:

git log --graph --oneline --all --decorate

What each flag does:

• --graph draws the branch and merge lines down the left-hand side.
• --oneline puts each commit on one line: its short hash and the first line of its message.
• --all shows every branch and tag, remote ones included, instead of only the branch you’re on.
• --decorate prints branch and tag names next to the commits they point at. Recent versions of Git already do this when the output goes to a terminal, but the flag keeps them when you pipe the output somewhere else.

Nobody wants to type that every morning, so make it an alias:

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

On a long-lived repo the full graph scrolls forever. A few ways to cut it down:

git graph --since="2 weeks ago"    # only the last two weeks
git graph -20                      # only the last 20 commits
git log --graph --oneline main..feature                # on feature, not yet in main
git log --graph --oneline --left-right main...feature  # both sides, marked < and >

The last two compare two branches, and they use plain git log rather than the alias because --all would pull every other branch back in. Two dots shows what feature has that main doesn’t. Three dots with --left-right shows what each side has that the other doesn’t, which is a quick way to see how far a long-lived branch has drifted.

Viewing the graph in VS Code

#

VS Code has a graph built in. Open the Source Control view (Ctrl+Shift+G) and the Source Control Graph is one of the sections in that panel; it has been there since version 1.93 (August 2024). By default it follows the current branch and its remote, and the branch picker in the graph’s title bar adds others. For a quick look, that’s all you need.

For every branch at once, install the Git Graph extension by mhutchie (search for “Git Graph” in the Extensions view). Open it from the Git Graph item in the status bar, the Git Graph icon at the top of the Source Control view, or the Command Palette with Git Graph: View Git Graph (git log). Click a commit to see the files it changed, or click one commit and Ctrl/Cmd-click another to compare the two. It hasn’t had a release since 2021, which is one more reason the built-in graph is worth knowing about.

If the Git Graph button doesn’t appear, the extension probably hasn’t found a repository. By default it only checks the folders you opened, not their subfolders, so open the repository’s own folder or raise git-graph.maxDepthOfRepoSearch in the settings.

Other tools

#

Most Git tools draw a graph somewhere. gitk --all is Git’s own history browser. GitHub, GitLab and Bitbucket each have a “network” or “graph” view on the repository page. And the desktop clients, SourceTree (free, from Atlassian), GitKraken, Tower and TortoiseGit on Windows, all have one too.

Whichever you pick, the goal is the same: understand the progress, don’t count the commits.