RFC: 10x-ing engineering onboarding #379
There are no files selected for viewing
|
Member
There was a problem hiding this comment. Based on our discussions previously I think the hardest part of losing Andy, which I think is where this RFC came from, was that you invested time and emotion into an employee and then that employee was moved from your team, so your time and emotional investment felt wasted. I don't think that this RFC would change that situation or how you felt about it - you might have spent 3 fewer weeks with Andy, but I don't think that would have changed much in the end. I also don't think Andy would have gone to product analytics platform initially instead of Flags - flags was the right place for him at the time, but right now we just have a stronger need on the analytics platform team. A challenge we are looking at with onboarding lots of new engineers and starting lots of new teams is that we need team leadership to come from somewhere. I don't think that after 3 weeks we'd trust/expect a totally new employee to go off on their own and run a new team. We did this with arthur and it was hard on him and on Sandy, who was on a different team but was his long-term onboarding buddy. So that leaves two options - either get new hires fully spun up before moving them to a new team, or take existing fully spun up people out of existing teams. Actually there is a third option, and that's to incubate new teams and product areas inside another team for a while, until natural fault lines develop and the team starts asking to be split so they can get more headcount. This is how we did things a few times here at PostHog (flags/experiments/surveys all used to be in one team, replay/error tracking came from one team) and these splits felt the most natural. The downside with that approach is that sometimes we want things to happen fast, and to be a team's full focus, and it's hard to focus on something when your attention keeps getting pulled to other responsibilities of the team (like support). If we say "just let them do their own separate thing but be on the same team" we're just placating ourselves - this should be a separate team. Maybe placating is okay and it's how we deal with the emotional toll of splitting teams or taking high performers to start new projects/products/teams, but we should be honest with ourselves about what the goal there is. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,88 @@ | ||
| # Request for comments: 10x-ing PostHog's engineering onboarding | ||
|
|
||
| **Decision maker:** Engineering team leads + the blitzscale folks | ||
|
|
||
| ## Overview | ||
|
|
||
| Our engineering onboarding is inconsistent and doesn't scale. Teams handle it in isolation, creating wildly different experiences that make it impossible to assess performance or teach our ways of working effectively. | ||
|
|
||
| This RFC proposes cohort-based onboarding (HogBoarding) that standardizes the experience while building stronger cross-team connections. | ||
|
|
||
| ## Why now | ||
|
|
||
| 1. **We're hiring rapidly** and inconsistent onboarding amplifies all the problems | ||
| 2. **Recent onboarding failures** - several new hires haven't ramped effectively, leading to longer time-to-productivity and people leaving during probation | ||
| 3. **Internal poaching is breaking down** - we've moved people from overstaffed teams (Feature Flags) without communicating expectations upfront, creating confusion about hiring plans | ||
|
Member
There was a problem hiding this comment. To be fair, when we decided to go back to the method of onboarding new engineers into existing teams, then moving them out after onboarding, we decided we'd be really clear with leads about this plan. It's not poaching - it's using a spun-up well-functioning team to onboard a new person, with the understanding that they or another team member will soon leave to work on new things. The recent move of Any to product analytics platform was NOT this - it was a different situation entirely.
Author
There was a problem hiding this comment. yeah, that's a good point, in hindsight I regret using "poaching", that's a bit of a charged word. Really, what I'm looking to do is standardize "using a spun-up well functioning team to onboard a new person" across the org.
Member
There was a problem hiding this comment. my expectation has been (admittedly from the benefit of watching this play out) if a team gets to 4 or more people it is not long until the axe comes that said i've not been on one of those teams during the years of the axe and i heard a similar sentiment from product analytics so maybe there is expectation setting to be done here (with the added tension of "how do you build a team if you know you won't be a team for long" - not impossible but needs considering) |
||
|
|
||
| ## Problem | ||
|
|
||
| Current onboarding has too much variance in quality, operates in silos, doesn't teach the PostHog way effectively, creates an "onboarding tax" on high-performing teams, and makes inefficient use of our technical debt. | ||
|
|
||
| **More details:** | ||
|
|
||
| 1. **Variance in quality.** Some teams have well-thought-out processes, others wing it. New hires get wildly different experiences depending on which team they join, making it impossible to assess performance consistently or ensure everyone learns our core ways of working. | ||
|
|
||
| 2. **Teams operate in silos.** New engineers only meet their immediate team members during their first weeks. This limits cross-team collaboration and means people miss out on learning from other parts of the product and codebase. | ||
|
Member
There was a problem hiding this comment. +1 to meeting people i go out of my way to arrange in-person onboarding in "hub" cities so that new hires meet other people so we picked london or munich over my default of italy 😅 i'd recommend the same in the US if we're not doing that |
||
|
|
||
| 3. **Not teaching the PostHog way effectively.** Our core values around autonomy, ownership, and development practices are best learned through experience, but we're trying to teach them within the narrow context of a single product area. | ||
|
Member
There was a problem hiding this comment. This one doesn't resonate for me - I think people can learn autonomy and ownership and dev practices in a single product area.
Author
There was a problem hiding this comment. yeah, I don't like this much on a second read either – I think the point I'm trying to make is "it's not a requirement for a person to learn autonomy, ownership, and dev practices by remaining in a single product area" |
||
|
|
||
| 4. **"Onboarding tax" on high-performing teams.** Teams with strong onboarding culture (e.g. Feature Flags) end up overhiring, expecting that ramped-up engineers will get poached by teams that need them. This creates weird expectations—how do teams know they're supposed to overhire? It also unfairly burdens teams that invested in good onboarding processes. | ||
|
Member
There was a problem hiding this comment. This is a reasonable argument |
||
|
|
||
| 5. **Inefficient use of starter tasks.** We have technical debt and starter tasks across all products, but currently these only get tackled by people on those specific teams. We're missing an opportunity to pay down this debt while giving new hires diverse learning experiences. | ||
|
Member
There was a problem hiding this comment. I feel like we never actually have that many starter tasks (as "debt") because lots of simple things just get done. Though I do think we could have better hygiene around creating github issues for things we aren't going to just do and labeling them as good-first-issue so they are easier to find. |
||
|
|
||
| 6. **Scheduling headache for offsites.** Coordinating onboarding offsites is a logistical pain when people start at different times and are spread across teams. | ||
|
Member
There was a problem hiding this comment. i'm going to plus 1 this point by the end of this year i'll have been away from home for ~7 weeks i like the travel and i value it
Member
There was a problem hiding this comment. a friend of mine was at a consultancy while it scaled very fast and they only did onboarding in preset weeks so e.g. new starters start the first week of the month, ready to start today - tough, wait until the first week of the month. i.e. you didn't start at the earliest availability, you started at the next running onboarding. which would naturally group people. and then you could have the EU onboarding and the US onboarding in the first week of month X which makes each individual in-person onboarding harder to plan, but reduces logistical load across them - since now you're just hitching to an existing onboarding There was a problem hiding this comment. another +1 to this, an easy improvement to the current process would be to have all the onboardings and small team offsites in the "In-person Onboarding & Small Team offsites" - a lot of them seemed to be missing from that when I've checked before, and it's hard to go dig up random slack channels for offsites - if they are there it makes it easier to coordinate and team up for offsites, which is very helpful to give new folks a deep dive into a few different areas of the product, meet a more people and feel a part of the wider posthog team |
||
|
|
||
| ## Proposal: HogBoarding | ||
|
|
||
| **Core principle:** Teach the PostHog way first, then specialize. | ||
|
|
||
| **The system:** New engineers onboard in cohorts of 3-6 people for a standardized 2-3 week period, then transition to their specific teams with a solid foundation. | ||
|
Member
There was a problem hiding this comment. who is leading this? if the argument is that i get time back because i'm not travelling to 6 offsites, but i'm leading a 3 week onboarding programme then i probably didn't get time back plus my experience home-schooling compared to reading to a class of kids at a school - it is very _very+ different to teach one person than it is to teach six presumably part of this is physical and part remote?
Author
There was a problem hiding this comment. yeah so my vision is more like:
The tricky part that I don't fully grok is how it works with 1:1s, check-ins, etc – ideally all the new hires have a single onboarding buddy they can work with, but it might get tricky if they start working on projects outside the scope of their team specifically. I think I need to think this through a bit more.
Member
There was a problem hiding this comment. there will be definite overlap with work and thinking that people and ops are doing here... you should deffo ping them for opinions! There was a problem hiding this comment. Yeah, when reading this RFC I thought the same: who is going to be in charge of leading the onboarding to a big group of people? It is not only the time they have to take away from home, it's also the responsability and being busy without being able to do their "regular" tasks. What about PRs and stuff? I think I am biased because I really enjoyed my onboarding and I always say it was one of the best way to start at PostHog: being able to meet in person my team, and being educated about the platform, what's expected for me to do, how my team works, etc., all of that was great (though I am a bit different because I am not a Product Engineer and I work mostly in the Billing repo, so my experience may be different). I think this proposed solution sounds good on paper but the logistic/implementation may not be as easy, and it's also missing a few pro of the onboarding-with-your-team plan. (Not saying there is not a problem with what Dylan explained, just that this may not be a better approach) |
||
|
|
||
| **Implementation details:** | ||
|
|
||
| - **Cohort formation:** Everyone starting within a 2-week window onboards together | ||
|
Member
There was a problem hiding this comment. we're currently closing anywhere from 0-2 engineers per week I think, so I'm not sure this cohort situation every 2 weeks would actually make things much easier right now. We might need to start something like this later when we have more volume. There was a problem hiding this comment. +1 to this - it feels manageable-ish at our current scale how it is (at least the last couple onboardings I have been to felt like a good vibe and that they worked well), but there probably is a need for this kind of thing later down the line |
||
| - **Rotating leadership:** If 4 product teams are hiring, any mixture of those team leads can run onboarding (spreads load, prevents burnout, ensures knowledge sharing) | ||
| - **Standardized curriculum:** Development practices, architecture overview, core tools | ||
| - **Cross-product work:** Rotating pool of "good first issues" across all products | ||
| - **Pair programming and code review sessions** with onboarding buddies who work together rather than in isolation | ||
| - **Cross-team social activities and team introductions** | ||
|
Comment on lines
+45
to
+48
Member
There was a problem hiding this comment.
We should do these things regardless! |
||
| - **Cohort-based offsites** that are easier to schedule and more cost-effective | ||
|
Member
There was a problem hiding this comment. I think having consistent onboarding plans, including locations, hotels, weworks/offices, etc would be a good thing to have |
||
| - **Clear handoff process** from cohort onboarding to team-specific integration | ||
|
|
||
| ## Benefits | ||
|
|
||
| **TL;DR:** Consistent experience, cross-team connections from day one, better cultural transmission, pays down technical debt, scalable, and easier logistics. | ||
|
|
||
| **Detailed benefits:** | ||
|
|
||
| 1. **Consistent, high-quality onboarding.** Every new engineer gets the same foundational experience, making it easier to assess performance and identify areas for improvement. | ||
|
|
||
| 2. **Stronger cross-team connections.** People build relationships across the engineering org from day one, improving collaboration and knowledge sharing. | ||
|
|
||
| 3. **Better cultural transmission.** Teaching autonomy and ownership across multiple product contexts helps new hires internalize these values more effectively. | ||
|
|
||
| 4. **Efficient use of starter tasks.** We systematically pay down technical debt across all products while giving new hires diverse learning opportunities. | ||
|
|
||
| 5. **Scalable and sustainable.** The rotating team lead model prevents onboarding from becoming one person's full-time job while ensuring institutional knowledge is preserved. | ||
|
|
||
| 6. **Enhanced team bonding.** Cohort-based onboarding creates stronger peer relationships (we can include custom cohort merch!) and shared experiences. | ||
|
|
||
| ## Why not? | ||
|
|
||
| **"We want hires shipping ASAP - this approach might slow them down"** | ||
|
|
||
| Fair concern, but the current system is already slow due to inconsistency. Some teams ramp people in days, others take weeks or months. HogBoarding frontloads 2-3 weeks of structured learning, but people transition to teams with a much stronger foundation. The goal is faster time-to-meaningful-contribution across the entire engineering org, not just for teams that already have good onboarding. | ||
|
|
||
| **"Hard to assess autonomy if folks are going through a bootcamp - it's a facsimile of real work"** | ||
|
|
||
| True, bootcamp work isn't the same as real product work. But autonomy isn't just about working independently - it's about judgment, asking good questions, and understanding our systems. The current approach makes it impossible to assess these consistently since everyone has different experiences. HogBoarding gives us a shared baseline to evaluate from, then teams can assess real autonomy during the transition period with actual product work. | ||
|
Member
There was a problem hiding this comment. do we also lose signal. 3 weeks is a large chunk of someone's probation if that is bootcamp work before they hit product work we've lost signal about how they'll behave in a team and looking at who we hire. i had a sequence of tasks building up to a hard thing for Tue - and he quickly said "i want to start the hard thing" - are we slowing people down if we have a long onboarding i _think _replay onboards well, but we've just cut to three days in person because the last day or so felt like sight-seeing not work
Author
There was a problem hiding this comment. yeah I think the really important bit here is that I don't want the bootcamp to be make work – it's real shit (ideally starting with "good first issues" but ultimately turning into more involved projects. 3 weeks is probably too long though, but I think the tricky part is figuring out how to get people ramped up onto doing things the PostHog Way ™ without coming up with tons of work for them. FWIW, though, I think there are a lot of issues across many teams that go untouched by us and could be cleaned up, and I think you can get a lot of signal from candidates based on how they tackle relatively simple changes. My vision was that we'd use onboarding as a way to pay down these issues across products rather than having them stick to the same one.
Member
There was a problem hiding this comment.
yeah, i've started fighting my tendency to try and fix everything just so i have a list of things folk could work on 😅
my worry would be that the untouched things are inherently tricky or frustrating and folk are not touching them because their spidey sense has warned them not to wrestle the pig... but that's a "careful about how to implement it" not an "omg don't do this" :) i could totally get behind, "everyone" does an in-person onboarding, and then also has 2 weeks where they have an assigned buddy, and we make sure that the buddy has something clear to achieve and it's treated as real work. (everyone is in quotes since e.g. Kim is in the US and is starting middle of october and we have travel to italy in november and it would have been hard for them or me to travel in october so we've punted to november - with the agreement we need to be careful we don't miss a trick, i.e. there are no hard rules expect the rule that there are no hard rules)
Member
There was a problem hiding this comment. that is they're in the team and get support from the team lead and peers as usual
Member
There was a problem hiding this comment.
IMO this doesn't sound like any less work than what we have right now
Member
There was a problem hiding this comment. no, i guess i was only saying that being clear that being an onboarding buddy is a real thing and shouldn't be an after thought ... but then if there are some people doing that they should receive feedback |
||
|
|
||
| ## Implementation | ||
|
|
||
| **Pilot approach:** Start with 2-3 cohorts to test the approach and refine the curriculum. Create standardized onboarding materials that any team lead can pick up and run with. | ||
|
|
||
| **Success metrics:** Track time-to-first-meaningful-contribution, cross-team collaboration frequency, and new hire satisfaction to measure effectiveness and iterate on the process. | ||
|
|
||
| ## References | ||
|
|
||
| This approach is inspired by [Facebook's Engineering Bootcamp](https://engineering.fb.com/2009/11/19/production-engineering/facebook-engineering-bootcamp/), adapted for PostHog's culture and scale. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this up Dylan, appreciate the effort to come up with something that works better for everyone.
I will say that I'm not certain that this path is the right one for us right now. But I think a lot of the things you mention should be implemented today to make this better.
Why not cohort-based onboarding? I think the numbers just don't make sense. We're currently bringing 0-2 new engineers onto the team per week right now, I think this pace will continue at least through the next quarter, it might ramp up in Q1. @couaphang what are our hiring projections for Q4 and beyond? Either way, I think it's still super valuable for new joiners to actually meet their team in person, not just random people from PostHog. So would they do two in-person onboardings?
I think a consistent curriculum and onboarding agendas (including location, places to stay, etc) would be beneficial. People can't always travel to the "hubs" (eg for visa reasons) but those times can be exceptions. The alternative side is that we've said new joiners should travel to the onboarding buddy's location, so PostHog employees don't have to travel so much - focusing on the hubs adds that expectation back on to the current employee to travel again.
RE first issues - We can also have people work on whatever good first issue is available even if it's not in their product area, but IMO there is a lot of benefit to just getting straight into the product area. Working on the simple things gets you started on working on the more complex things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't see our hiring increasing drastically beyond what we will do in Q4.