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

Why they gave up on meetings

#

Their starting point will sound familiar. Nobody comes prepared, the meeting starts late, and the loudest voice wins whether it’s right or not. An hour later you’re more confused than when you walked in and wondering if there’s any paracetamol left in the drawer.

Alan tried fixing meetings first — 15 minutes max, clear agenda, decision required. It didn’t hold. Discussions drifted, nobody could remember what was said, and absent or remote people were simply out of luck. So they moved the whole thing into writing.

The claims they make for it ring true to me. Writing forces you to slow down and actually think, so the discussion gets more nuanced and better argued. Everything is documented instead of half-remembered. It stops being an eloquence contest. And because the forum is open to the whole company, anyone can contribute — not just whoever happened to be in the room.

GitHub as the company forum

#

The forum itself is GitHub, a platform built for code review that Alan cheerfully hijacked. The setup is almost embarrassingly simple:

1. Create a GitHub account.
2. Create a private repo with no code in it (theirs is called “Topics”).
3. Add a labelling system to categorise conversations.
4. Use the Issues tab: open issues are live discussions, closed ones are decisions made.

They’ve passed 17,000 issues. That’s a lot of meetings that never had to happen, and — the part I find most appealing — a searchable history of why every decision went the way it did. If you want to challenge an old decision, you can first read which arguments won last time.

When to open an issue

#

Not every decision earns an issue. Their filter is four questions: who will be affected? how reversible is it? how urgent is it? do I need more context before deciding?

Broadly, high-impact and hard-to-reverse decisions go to the forum; the rest can stay in Slack. They lean on the one-way vs two-way door distinction: a one-way decision (too expensive or painful to reverse — their example is a price increase) gets the full written treatment, while a two-way decision (cheap to undo, worst case you lose some energy) doesn’t need the ceremony.

LOCI: who does what

#

Every discussion assigns roles using the LOCI model — Lead, Owner, Consulted, Informed.

The Lead is accountable for the decision’s success and makes sure the context is understood across the team. They say upfront how involved they want to be, then trust the Owner and take responsibility for what the team produces, speaking up only when they strongly disagree. One Lead per discussion.

The Owner makes the final call and drives the project. They keep contributors informed and contributing on time, investigate the problem, open and close the issue, and share the decision. If they hit a wall they can’t get past, they go to the Lead. One Owner per decision.

Consulted people are the ones whose input genuinely matters to the trade-off. They’re expected to contribute promptly — even if only to say “nothing to add” — and to raise the alarm (escalating to the Lead if needed) when they think the decision is badly wrong. Alan caps this group at about six, because more input starts costing schedule.

Informed people simply get told, usually once the decision is made. One-way communication, nothing expected back. The Owner decides who’s affected enough to be notified.

That works decision by decision. For a whole project, I write the same thing down once, as a project communication plan: who needs to hear what, how often, and who tells them.

The anatomy of an issue

#

Every issue uses the same template, which both sharpens the thinking and quietly teaches junior people how to break a problem down:

• Scope — the “why” of the discussion, including the underrated line “this issue is NOT about…”
• Context & materials — links to prior discussions and documents
• LOCI — who’s Lead, Owner, Consulted, Informed
• A deadline — when to contribute by, when the issue closes, when a solution is needed
• A solution proposal — one suggested answer, or options to choose between
• Questions — aimed at specific people to confirm or refute specific assumptions, so the issue isn’t a message in a bottle

Writing rules that keep things moving

#

A written debate can drag just as badly as a spoken one, so they have rules. Be concise — they quote Boileau: “What is well conceived is clearly stated.” If you can’t write it simply, you’re not actually sure of it yet. Apply the “So what?” test to everything you write; if the implication of your comment isn’t obvious, spell it out.

For the Owner, the follow-up matters as much as the opening. Keep the discussion pointed at the million-dollar question — the one sticking point that actually matters — rather than letting it dissolve into details. Recap regularly what’s been agreed and what’s still open. And treat Slack reminders as a last resort, reserved for overdue contributions or genuine urgency.

Owners also hide comments that don’t move the conversation forward, and everyone is expected to know their way around GitHub’s formatting — headings, footnotes, tables, keyboard shortcuts — because in writing, form carries almost as much as substance.

No consensus, no spectators

#

Two rules stop this from turning into decision-by-committee.

First, the Owner decides as what Alan calls an “enlightened despot”. They investigate ideas, measure risks, question peers — but they don’t seek consensus and they don’t have to implement everything they’re told. Alan is blunt about not being a democracy: every employee is a shareholder, and the company’s interest comes before the team’s or the individual’s. When the Owner is reasonably sure of the right bet, they decide, everyone tries it, and once the impact is visible they review whether it was the right call.

Second, contributor numbers are controlled. Jeff Bezos’ two-pizza rule applies to async work too: the more people on an issue, the less each one contributes. Past about six contributors, the spectator effect kicks in and participation quality drops. Notifications follow the same philosophy — Alan trusts everyone to have configured their own GitHub notifications (Settings, then tick “Web and Mobile” under both “Participating” and “Watching”), so direct tags in the Questions section are kept to a minimum.

What I’m taking from it

#

You can never fully explain a meeting to someone who wasn’t there, but anyone can read a decision. Alan doesn’t claim this is the best or only system — just the one that fits them: fewer interruptions, less spectator effect, and decisions made with a step back and the facts written down. I’m not about to move every decision my team makes into GitHub issues, but the template below is going straight into our repo.

The template, as a GitHub issue template

#

Save this as .github/ISSUE_TEMPLATE/decision.md in whichever repository you use as the forum, and GitHub offers it every time someone opens a new issue. The sections are Alan’s; the LOCI lines and the label are my additions.

---
name: Decision
about: Propose a decision and collect input in writing
title: "[Decision] "
labels: decision
---

## Scope
- The goal of this issue is ...
- This issue is NOT about ...

## Why I'm opening this issue

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## Timeline
- Contributions by:
- Decision by:

## Context and materials

## Proposal

## Questions

GitHub Issues or GitHub Projects?

#

If you’re thinking about GitHub for project management more broadly, the two pieces do different jobs. Issues hold the discussion and, once closed, the decision. A GitHub Project is a board or table laid over issues from one or more repositories, with your own fields for status, owner or deadline. For a decision forum like Alan’s, labels and the issue list are enough. Add a Project when you want every open decision on one screen, sorted by the date it has to be made, and when you start tracking delivery work in the same place, which is where most teams end up using both.

The idea

#

Street food vendors in Korea don’t have addresses. A pojangmacha sets up wherever it sets up, and unless you already know the spot, you won’t find it online. Our app puts vendors on the map — literally. That’s good for the vendors, and good for anyone hunting down late-night tteokbokki.

The weekend itself

#

The hackathon was hosted by Lunit Global, who put up the office space. Teams from all sorts of backgrounds, most of us working straight through the night, and organisers who kept everything running smoothly. The kind of event where you look up and it’s suddenly 4am.

The team

#

The team was Sharon Levy, Jonothan Sue, me, and Tiaan van der Riel. Everyone brought something different, so splitting the work was painless. The pitch landed with the judges, I think, because the problem doesn’t need explaining — say “street food vendors are invisible online” out loud and the solution suggests itself.

What’s next

#

We’re working on getting the app into the stores. It started as a weekend project, but the problem it solves is real enough that stopping now would feel like a waste.

If it’s your first hackathon

#

If you’ve never done a hackathon, I’d recommend it. You build something fast with people you’ve never worked with, find out how you actually handle pressure, and once in a while you walk out with something worth continuing. Worst case, you get a weekend of free snacks and a working prototype nobody asked for.

A few things worth knowing before you go:

• Pick a problem you can explain in one sentence. If the judges spend the first minute working out what the problem is, they aren’t listening to your solution.
• Split the roles early, ideally in the first hour: who builds, who designs, who owns the pitch. Working that out at 2am costs far more.
• Build the demo path first. Get the one flow you’ll show on stage working end to end before you add anything else.
• Rehearse the pitch out loud, with the live demo, at least twice. Pitches nearly always run longer than you think.
• Sleep a little. Even a couple of hours makes the morning’s decisions, and the pitch, noticeably better.

Links:

#

https://lnkd.in/drMXUgPB