RFC: 10x-ing engineering onboarding #379
Conversation
|
|
||
| 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 |
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.
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.
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
and i have been pleasantly surprised that it works so well
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)
|
|
||
| 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. | ||
|
|
||
| 6. **Scheduling headache for offsites.** Coordinating onboarding offsites is a logistical pain when people start at different times and are spread across teams. |
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
but also with Claire at uni it's been a wild ride
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
|
|
||
| **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. |
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?
i strongly feel we shouldn't lose in-person onboarding
but we also obvs aren't going to ask people to start a remote job by spending 3 weeks in person 😅
There was a problem hiding this comment.
yeah so my vision is more like:
- the cohort of new hires goes to a spot along with several existing onboarding buddies (similar to our current strategy, my idea would be that the team leads of the teams looking to hire new engineers from this cohort will function as the onboarding buddies)
- everyone works together for a week
- then people head back to their various homes and continue to work through different types of good first issues (or harder things as they go), and then the onboarding buddies still exist as the first point of contact for these new hires.
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.
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)
|
|
||
| **"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. |
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
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.
There was a problem hiding this comment.
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.
yeah, i've started fighting my tendency to try and fix everything just so i have a list of things folk could work on 😅
I think there are a lot of issues across many teams that go untouched by us and could be cleaned up,
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)
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
but we level up the idea of the onboarding buddy so it's real concrete support whereas i bet that is very variable right now
There was a problem hiding this comment.
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.
IMO this doesn't sound like any less work than what we have right now
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
|
|
||
| 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. |
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
|
|
||
| 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. | ||
|
|
||
| 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. |
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.
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"
|
|
||
| 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. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
This is a reasonable argument
|
|
||
| 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. | ||
|
|
||
| 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. |
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.
|
|
||
| **Implementation details:** | ||
|
|
||
| - **Cohort formation:** Everyone starting within a 2-week window onboards together |
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
| - **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** |
There was a problem hiding this comment.
- 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
We should do these things regardless!
| - **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** | ||
| - **Cohort-based offsites** that are easier to schedule and more cost-effective |
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
|
|
||
| **"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. |
There was a problem hiding this comment.
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.
IMO this doesn't sound like any less work than what we have right now
There was a problem hiding this comment.
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.
We don't see our hiring increasing drastically beyond what we will do in Q4.
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.
|
There's so much good stuff in this but fundamentally this seems, to me, like it's how we optimize "teams" at PostHog and not optimizing PostHog. Our business model is to build lots of products and continue to add lots of value by having more products. If we have a team-first attitude we won't grow PostHog as a whole as well. If we need to move people around for the overall benefit of PostHog, we should do this. We also want to lean into the philosophy of small teams so when a product team gets to 5 people, it's likely to split up so something similar would happen anyway. I think cohort-based onboardings is not the way forward here, it feels like it slows us down, avoids a why not now for great people and seems and over the top correction here. Where I agree here massively is that a lot of teams do wing it when it comes to onboarding and they don't structure this properly. I think we can 100% learn from this and make sure we replicate the successful teams and make this waaaayyyy more intentional and this should hopefully lead to having to do less of this, but it won't stop this happening altogether. @dmarticus do you think the current onboarding guidance in the handbook reflects the level of onboarding you are going to to ensure team members are onboarded well? If not, I suggest you either update the handbook directly to reflect that or download that to @TaraZAH and/or @CarolDonnelly1228 who can do that. |
|
Thanks everyone for reading and weighing in – I appreciate the thoughtful feedback and brainstorming. I think @fraserhopper cut through the noise to the most salient point here – there are some things we should more explicitly codify within our existing onboarding process to help improve + standardize the experience across all new hires, but we don't need to overhaul the onboarding process as it stands. I'll give this another read and see which points were particularly resonant with folks and then draft a PR to the handbook encoding them – probably worth announcing whatever changes we do make in #tell-posthog-anything so that folks who haven't been following along with this closely can stay in the loop. Thanks again! |
|
I am happy to share some further thoughts on this and have @PostHog/people put some extra time into this in q4 to help nail this! |
Decision maker the blitzscale fols (mostly @timgl and @raquelmsmith )
Deadline: Next Friday (October 3)?
Overview
This RFC was inspired by a conversation I had with @raquelmsmith about how one of the strategies we've employed to staff new product teams is to "over-hire" onto teams that have a strong onboarding culture, and to then poach those onboarded engineers onto different teams. During this convo, we mentioned that Meta used an "engineering bootcamp" approach to solve this problem when they hit Dunbar's number of engineers (this was back in 2008, and they still do this!), but since we weren't explicitly talking about onboarding, we didn't dive deeper into the topic.
But I couldn't stop thinking about it, and later that week I talked with @Gilbert09 and @EDsCODE about this topic more, and an idea began to form about how we could improve engineering onboarding to (1) standardize the experience (2) minimize "team poaching" in favor of building a more cohesive onboarding experience for all new hires (3) provide a better benchmark for assessing engineers going through probation, and (4) foster more collaboration amongst new hires joining different teams.
So here's my pitch – I want to create HogBoarding; a PostHoggy onboarding program for new engineers to help solve some of these problems. This RFC describes what this program could look like, but doesn't go into too much detail about what implementation would look like. Would love to hear from folks about it, though!