Comment by jobu

This is really interesting, my self-onboarding process is completely different, but seems to serve the same purpose.

1) Look at the bug backlog and pick one that's obvious and reproducible

2) Set up the environment(s) and start to debug (It's surprising how painful this step can be in some organizations, but for any team it will showcase a number of pain points for the developers and testers.)

3) Skim the related code history and make a list of people to talk to from the commits.

4) Informal meetings with those people to ask questions about the product, codebase, and what they see as major problems or bottlenecks.

Step three from the article ("ask who else you should talk to") is something I hadn't thought of before:

The third question will give you a valuable map of influence in the organization. The more often names show up and the context in which they show up tends to provide a very different map of the organization than the one in the org chart.

In large organizations there are often a number of lynchpin-type people (often in non-senior roles) scattered across teams that everyone respects and goes to for information and advice. Finding these people early saves a lot of time and frustration.