Knowing when

The problem

GI is a small team hiring for very different roles at once. Two people run ops, and there's an event every few weeks. Finding people who could do a job is mostly solved. Knowing when to talk to them isn't.

The best person for a role usually has a job and isn't thinking about GI. Then something happens, like their paper coming out or their company getting bought, and for about a month they're much easier to reach. After that the window closes.

Right now GI writes to people whenever someone has a spare hour. Most of those notes land outside the window, and most of them go nowhere.

I think three things cause this.

• The signals are all over the place. A paper goes up on arXiv, a release on GitHub, a launch on X, layoffs in the news. Nobody can check all of that for every person every day.
• The window is short. A moment stays special for a few weeks. By the time it's obvious to everyone, every other lab has already written.
• Attention is what's scarce. GI's brief puts it well: far more information than attention. Every cold note spends a bit of goodwill, so a note at the wrong time is worse than no note.

So the job is to tell two busy people which few notes are worth sending this week, and otherwise keep quiet.

What it watches

My first instinct was to capture every signal I could. I ended up with 42 detectors in 11 families, covering everything from paper acceptances and product launches to layoffs, SEC filings, co-authors leaving and how long someone's been in their seat.

A lot of them turned out to be noise, and some pointed the wrong way. Time in a seat and retention cliffs are really guesses about who's about to leave. Those guesses are shaky, a bit creepy, and they don't give you anything to say. The brief lists "two years in a seat" as a moment, and that's the one place I went the other way.

So I used one test. A signal only counts if it gives GI something true and specific to say. "I saw your paper" passes. "I noticed you've been at your job for two years" doesn't.

Here's what made the cut.

1. Their work just went public. A paper, a release, a launch, or a public question GI could answer. For about 30 days that's a real reason to write about their work, and it's enough on its own.
2. Their own words. They said they're open, posted their last day, told GI when to try again, or told someone from GI at an event. That's enough on its own too.
3. Something changed around them. Their manager or co-authors left, or their company was bought or hit by layoffs. It only counts while it's fresh, about three weeks for a headline and a few months for a filing. Next to a fresh paper or launch, it turns a note about their work into a note about the role. Company news needs each person's employer on file, and none is on file yet.

Not everyone posts, and some of the best people barely exist on social media. So posts are only one input. A paper or a code release counts the same, and neither needs the person to say a word. News about their company will too, once each person's employer is on file.

Makes it wait

Their launch week, a recent promotion, their first year in a new job, a fresh equity grant, or saying they're not looking.

Never a reason

Time in a seat, retention cliffs, the pattern of their past moves, and looking like people GI already hired. They show up as context and nothing more. A code push, or someone's work slowly drifting toward world models, only backs up a real moment. It never starts one. A path like the one GI's own people took can be why I suggest someone for the watchlist, never a reason to write. They still need a public trail and linked profiles to get on, and nobody joins without a yes. An early sign in their own posts, like work in progress or a question GI could answer, can start a note about their work, never a pitch.

Each role counts different things, too. For a researcher the moment is usually a paper. Designers don't publish papers or push code, so for them it looks at launches, design talks and their own posts about what they shipped.

How it works

Here's the loop, from GI's job posts to a note someone at GI actually sends.

1Start from GI's own job posts

I started with three of GI's open roles: Member of Technical Staff (the research role), Senior / Lead Backend Engineer, and Product Designer. The JDs come straight from GI's job posts on Ashby. For each one it works out who GI is looking for, what would make that person reachable, what doesn't count, and what it can't watch.

Adding a role works the same way. Paste in the JD, pick the role, and you get the brief. Paste a sales JD and it lists plainly what it can't watch for that role, like CRM quota or referral networks.

2A watchlist for each role

Each role has its own watchlist of people who might fit it, 16 across the three roles right now. To get on it, someone needs at least 12 public things of their own from the last year, and every profile it reads has to be tied to them by their own links.

3A talent database, read every morning

So on top of the timing engine, it's really a talent database. It keeps a private record of each watched person's public posts, releases and papers, each dated to the moment it went public. Every morning at 7:30 it reads what's new from their X, LinkedIn and GitHub. A model reads each new post for the role, so a launch counts and a lunch photo doesn't. It never hands a login, cookies or a fake account to anything.

4It makes a call on each person

Reach now, check first, wait until a date, or stay quiet. Every call has the seven parts GI asked for: the person, the role, what changed (with a source you can click), why now, how sure it is and what would prove it wrong, a draft, and the way in. Most days, for most people, the answer is not yet.

5Ask it about anyone

Each person comes with four questions it answers from what it's already stored, citing every source: how their work lines up with the JD, how close they are to GI's team, what they've shipped lately, and the way in. It won't guess at pay, plans or anything personal.

6It picks the sender and the way in

The draft comes from someone at GI who has worked with them, or else from whoever writes for that role. For research, that's the researcher whose work is closest to theirs. It's written as them and signed with their first name. It has to pass the brief's own test: swap in someone else's name and it should stop making sense. The way in has to be a real path, like a GI researcher who wrote a paper with them, or the site where they actually talk. If there isn't one, it says "none found" and doesn't make one up.

7It lands in Slack

Ops gets a card in #weekly-recap with who, why now, how sure, the way in, the draft and, when GI's job post gives one, the role's posted pay range. It has three buttons: I sent it, Not now, and Do you know them? Every press goes into the contact ledger. Nothing reaches the person until someone at GI sends it.

8It knows when to stay quiet

The brief asks what stops it firing on the wrong person, at the wrong moment, or twice. Every card has to get through four checks in order, and most people stop at one of them, which is fine.

• Wrong person. The same name on two sites can easily be two people. Every profile it reads has to link back to them, or the call turns into Check first.
• Wrong moment. Never in their launch week, their first year in a new job, or right after a promotion. A moment more than three weeks old gets checked before anyone writes.
• Twice. One hiring card per person, ever, across every role, and at most four hiring cards a week. Anyone GTM wrote to is held from hiring for 90 days. Not now holds someone until the date they gave, or 90 days by default.
• What it refuses. It never uses a guess about who'll leave as a reason. Tenure and signs like it are listed, never a reason. It doesn't estimate anyone's pay or invent a way in, and it never contacts anyone itself.

If there's nothing worth saying, it says nothing, and a quiet day posts no card.

The hard parts

“The timing engine is built for a longer horizon than a week, and we're aware of the tension. If you find a way around it, that's interesting in itself.”

GI's case-study brief

A timing engine proves itself over months, and I had about a week. This is how I got around that.

1. I rewound it. Every event it stores is stamped with the moment it went public, so I can rewind the engine to any past morning and let it see only what was public by then. I replayed four months that way, 120 mornings on 38 people: the 16 I watch plus 22 past cases whose moments I already knew. It made 6 cards, none were held, and no rail broke.
2. I checked early signs against GI's own people. Early signs are harder, because there's no date to check them against. So I searched the public trail of eight of GI's people by hand. Four had a clear one, and three of those four are GI's founders. Each had put out a playable demo or code on the work GI now does, 7 to 15 months before their place at GI was public. Search found no post from any of them about wanting to leave, though it can't see everything they posted. Four people make a hunch, not a finding. So I tested the early signs with a method written down before the run, and so far they don't beat random timing (p = 0.36). An early sign in someone's own posts can open a short note about their work, but it never gets anyone pitched for a role. That's why the calls lean on moments anyone can check.
3. I leaned on what can be checked today. A paper or a release from the past month is real, dated and one click away. Every reach-now this week is tied to one.
4. I graded its judgment on invented cases. 54 invented scenarios, each with a fixed expected answer. It gets all 54. They check that the rules behave, not that the timing is right.
5. I ran it for real. Its scheduled morning read runs on its own (today's ran at 7:30), and real cards went to Slack this week: two for hiring and two for GTM.

A few other problems came up along the way.

• Noise. A model reads each post for what matters to the role, and the pages quote only the person's own words, never the post they were replying to.
• Identity. This was harder than timing. A matching name proves nothing, so a profile only counts once it links back to the person.

Beyond hiring

That's the timing engine. But hiring is more than knowing who to write to. It's also getting the right people in the room and making sure it all fits the month, the quarter and the year. That's most of an ops team's week, so I built that too.

• Events. GI already runs an event every few weeks, and an invite is a timing call too. The Events page picks who to invite next, from the watchlist and from companies GI could hire from, each with a draft from the GI person who knows them, or else from a host whose topics fit. It shows the cost per event from past ones, briefs the hosts, and takes door notes that go back on each person's timeline. Sometimes the right move is an invite instead of a message.
• The Monday brief. The few decisions worth ops' attention this week, most urgent first: who to reach, who to check first, waits ending, follow-ups due, invites for the next event, and anything over budget. It's built to post to #weekly-recap each Monday and to stay silent when there's nothing to decide. For now I read it in the web app.
• The hiring budget. Each role's first-year cost: GI's posted pay range, overhead, and the cost of finding the hire, whether through GI's own outreach, a GI event or an agency. You plan hires by start month and office against the year's people budget and current payroll. It prices roles, never people.
• New starts. From accepted offer to first day: start date, visa, relocation, desk, laptop and accounts, each with an owner and a due date. Visa and relocation are only what the candidate says at the offer, never a guess.
• The monthly one-pager. For the founders: pipeline per role, spend against budget, and what's slipping, on one page.

In the demo, event spend and payroll are invented. Only GI's posted pay ranges are real.

The same engine for GTM

All of that is ops. The same timing logic works on companies, so I pointed it at them too. The idea is the same: write to a company when something just happened there that GI has a real reason to talk about.

What it watches. 57 companies, each labeled by how GI might work with them, or as a rival to watch. For each one it reads papers their people publish on GI's topics, their public job boards, and news like a funding round or a new leader.

What counts. Five kinds of moment, each with its own window to write in: a paper on GI's topics (60 days), a job post for work GI does, a funding round or acquisition, a new autonomy or robot-learning lead, and a public ask GI could answer, which for now someone adds by hand.

Who hears from GI. A new lead or a public ask gets written to that person. A paper goes to one of that paper's own authors, never just the company's most prolific one. Anything else goes to someone GTM already talks with there, or else to the account's champion, often the person there with the most papers on GI's topics. It never writes to someone hiring is watching.

How it gets there. Each card says why now, who writes to whom, the way in, what would change the call, and a write-by date. The way in is real: a conversation GTM already has going, someone at GI with a public tie to them, or an investor that backs both companies. Each draft comes from a GI writer and states only public facts about GI.

How often. At most three a week and one note per account a month, in GTM's own channel, #gtm-accounts.

Hiring and GTM share one contact ledger, so nobody gets two asks from GI at once. Anyone GTM wrote to is held from hiring for 90 days, and GTM only sees that another team holds someone, never why. One company event could matter to both teams, and the Company moments panel is a first look at that. It lays out what just happened at the companies GI hires from and marks GI's collaborators and accounts. It's a preview. It sends nothing and changes no call.

What's next

Next is the call log. It's built to record the engine's call on every watched person each morning, each line chained to the one before, so any later edit would show. Next I switch it on and have it record every message and reply too. Over time that shows how GI actually hires and who writes back, and I'll build the algorithm on top of that.

It watches the people and companies GI cares about, says when a note is welcome, and hands the right person a checked draft. The rest of the time it stays quiet.