Northwind Analytics runs its 8-week engineering onboarding from a single Bitir group

Priyanka leads a team of six engineers at a 180-person data company in London. Her onboarding used to live in Notion, Slack, Linear, and her head. Bitir replaced the "in her head" part — and the rest followed.

The "in her head" problem

Priyanka had been running engineering onboarding at Northwind for three years. The formal documentation was solid — Northwind had a dedicated Notion space with environment setup guides, a reading list, an architecture overview, team conventions, a buddy system, and a 30/60/90 template. On paper, the onboarding looked great. In practice, Priyanka had been quietly carrying the real structure of it in her head.

"The doc said week one was for environment setup and the architecture overview. That was accurate. What the doc did not say is that on day three, the new hire usually hits a specific confusion about how our event pipeline handles late-arriving data, and that I need to preempt that with a 20-minute whiteboard session. The doc also did not say that if you skip the Tuesday lunch with the data platform team in week two, the new hire misses the one conversation that tells them how our on-call rotation actually works. I had these twenty or thirty tacit things in my head. Every time I onboarded someone, I would remember fifteen of the twenty and forget five. Different five each time."

She had tried encoding the tacit bits into the Notion doc. The Notion doc then became unreadable — a 40-page wall of defensive footnotes that new hires bounced off completely. She had tried a Linear project with tickets per onboarding task. The Linear project worked for the concrete tasks ("set up laptop", "get AWS SSO") but did not fit the conversational, week-by-week rhythm that the rest of the onboarding actually needed.

Why none of the usual tools fit

Priyanka is technical and sceptical of tools. Before choosing Bitir she evaluated:

• Extending Notion. Notion is where the canonical documentation lived. But Notion does not have a native concept of "this week's prompts" or "reply-to-me privately". Attempting to force week-by-week onboarding into a database in Notion produced a structure that nobody read.
• A private Slack channel per new hire. This is what many teams do. It works for ad-hoc questions. It does not work for structured week-by-week progression, and the "what did I promise I would cover" problem persists — Slack has no goal-tracking layer.
• A Linear project per new hire. Linear handled the concrete tasks well. It handled the "how are you feeling about the codebase" weekly reflection not at all. Ticket-based tools assume the work is ticketable. Onboarding is largely not ticketable.
• A dedicated employee-onboarding SaaS. She looked at two. Both were oriented at HR onboarding (benefits, payroll, compliance), not engineering-specific onboarding. Both required Northwind to buy a seat per new hire and wire the tool up to their HRIS, which the People team was not going to do for a six-engineer team.

She came across Bitir because a friend of hers — a clinical psychologist in Bristol — had mentioned using it for her therapy groups. Priyanka's first reaction was "that is clearly not for me". Her second reaction, after looking at the feature list, was that the abstract shape of "manager runs a structured time-limited programme with week-by-week posts, private member reflections, and shared celebrations" happened to be a perfect match for engineering onboarding.

How she structured the group

Priyanka set up one Bitir group called "Northwind Eng Onboarding — Rolling Cohort". Every new hire joins the same group on their start date and leaves on week eight. At any given time, the group has between one and four active members.

Inside the group:

• A pinned welcome post explaining the onboarding arc, the weekly cadence, what is expected, and what "done" looks like at week eight.
• A weekly Monday post from Priyanka with the focus for the week, a reading list, the two or three things the new hire should be trying to accomplish, and — this is the critical part — the specific "tacit traps" she used to carry in her head, now written down.
• A weekly Friday private-member prompt. Each new hire answers four short questions privately to Priyanka: what went well, what is confusing, what did you spend the most time on, what would you change about this week's onboarding. These are private by default and go to Priyanka only.
• A shared celebrations channel where every first — first PR merged, first incident paged, first cross-team meeting chaired, first production push — gets posted publicly and reacted to by the rest of the cohort and Priyanka.
• A goals view with three Northwind-specific onboarding goals per new hire: (1) first production PR merged by end of week 3, (2) first on-call shadow shift completed by end of week 5, (3) first end-to-end feature owned and shipped by end of week 8. These are the concrete anchors that everything else supports.

What the weekly Friday prompt did

The four-question Friday reflection turned out to be the feature Priyanka found most unexpectedly valuable.

She had expected the reflection to tell her how each new hire was doing. It did. What she had not expected was that across multiple cohorts, the same two or three confusions came up in week two, the same four confusions came up in week four, and the same one confusion came up in week six. The Friday reflection became a longitudinal dataset about her own onboarding programme.

After cohort three, she had enough signal to rewrite the week-two Monday post to preempt the two most common week-two confusions. After cohort five, she had done the same for weeks four and six. The onboarding got visibly better at each cohort, not because she was working harder but because the reflection layer was telling her exactly where the programme leaked.

The "first PR merged" number

Northwind had a rough internal benchmark that a new engineer on Priyanka's team should have their first production PR merged within three weeks of their start date. Across the two years before Bitir, the median for her team was 18 working days — comfortably within the three-week target. Across her first six cohorts on Bitir, the median is 14 working days.

Four working days is not a small number. It is roughly the difference between a new hire shipping something before their first 1:1 retrospective and shipping something after. The psychological impact on the new hire is significant — engineers who have merged a production PR feel like engineers at the company; engineers who have not yet merged one feel like candidates still being evaluated.

Priyanka attributes most of the four-day reduction to three things: the Monday post now preempts the week-two confusions that used to cost two days each; the shared celebrations channel creates visible momentum so new hires push to get their first PR out; and the Friday reflection means Priyanka catches "I am stuck on X" on a Friday instead of discovering it in a 1:1 the following Wednesday.

Results after seven months

What Bitir replaced, and what it did not

Priyanka is careful to point out that Bitir did not replace Notion, Slack, or Linear at Northwind. The canonical architecture documentation is still in Notion. The day-to-day team chat is still in Slack. Engineering tickets are still in Linear.

What Bitir replaced was the missing layer between all of those tools: the week-by-week rhythm of onboarding, the private reflection channel, the visible celebration of firsts, and — most importantly — the "in her head" list of tacit traps that used to live nowhere.

"Bitir is not trying to be Notion, and I would not want it to be. What I needed was a scaffold for the human side of onboarding that the engineering-tooling stack does not provide. Bitir is that scaffold."

The thing she did not expect

The surprise benefit was for cohort members. New hires who started in the same week as another new hire found the shared group surprisingly comforting. Priyanka had not designed the group as a peer-support mechanism; she had designed it as a programme container. But two new hires a week apart will quietly watch each other's weekly reflections not be submitted, realise they are not the only one struggling with the event pipeline in week two, and message each other about it.

Priyanka now deliberately staggers hires by one week rather than starting everyone on the first of the month, specifically to create this peer-overlap effect. "A new hire who is two weeks ahead of another new hire is the single best mentor that new hire will have. Better than me. They remember being stuck on the thing yesterday."

What she would tell another engineering manager

• Do not try to replace your documentation stack. Keep Notion as the source of truth for architecture. Bitir is the scaffold, not the library.
• Write down the tacit traps — the things you know from experience but never put in the doc. Put them in the weekly post, not the Notion page, because weekly posts get read and Notion pages get bounced off.
• Make the Friday reflection four questions, not ten. Four questions get answered. Ten do not.
• Celebrate firsts publicly. Engineers pretend they do not care. They care.
• Stagger hires by a week if you can. The peer-overlap effect is the highest-leverage thing in the whole programme.

Related reading: our three-layer goal-setting model for groups, and the seven assignment patterns that drive completion.