I can speak to the onboarding on the Eng side:

* Good readmes. Every project is required to have a readme.md that's not boilerplate. Since every team is different, the quality of the readmes range from well-organized to stream of consciousness. But the point of the readme is that it's the very first document when on-boarding and contains instructions to set the project up, as well as git blame information so the new person can find the right person to bug for more information.

* Pair programming. There's no silver bullet for onboarding and you just need to accept the friction. Having new devs pair with experienced devs as they go through their daily workflow is the most useful way, IMHO, to get comfortable with the codebase and transmit cultural norms and values.

One thing that I find helpful in readmes is an ordered list of pointers to particular parts of the codebase that one should read to get an understanding of the overall structure. This is particularly helpful if the walkthrough of the conceptual framework of the project hosted externally on sites like https://docs.djangoproject.com/en/2.0/intro/tutorial01/ because that conceptual framework was designed specifically for this project.

We have some people working remote and it´s difficult to include them. But we skype with them for face-to-face meetings and at the beginning, everyone is saying something about himself. I would also recommend communicating via Chat like Slack or something similar. If there is an upcoming team event I would also consider to send them an invitation regardless if they are able to come but they might feel more like they are welcome. We also give them a briefing with some research tasks to get to know the company and the new job. Afterwards, the team leader will get in touch with them, explain everything and help them settle down into the team.

For collaboration, task management and project management we use our own tool Zenkit (https://zenkit.com). It´s easy to get started because you can use different views. If you used another tool, it´s more likely that you want to use the same view in Zenkit to get started.

You can do the 2 weeks onsite onboarding thing, the issue is that once you starting hiring developers with families, that becomes a negative more than a positive.

We use a combination of a good quality trello board with some standard activities, good 1o1 scheduling for the first 2 weeks, and scoping out small independent tickets that gives an engineer a solid base to build on.

Slack has been invaluable, and also setting a standard of face to face webcam meetings being non optional. Yes even in a remote role.

Even in 2018, theres no replacement for being able to look at someone face to face and ask them "anything on your mind ?"

Other good things, having a regular all hands to get the entire team on the same page, and scheduling company retreats

I currently have 12 direct reports, approximately 50/50 split between remote and HQ engineers.

Onboarding: I create onboarding documents for every incoming engineer broken down by week with 1 or 2 "people to meet" items in the checklist. There is one person in HQ, one person remote (if available) for a remote engineer onboarding. If the engineer is in HQ, they don't have a remote person assigned but they're tasked to meet with everybody on the team. The expectation is within the first couple of weeks to have met at least once with everybody on the team. There are some suggested questions only if they ask (I like to let people feel around and will ask if they feel comfortable talking to strangers, etc).

Management: I'm fairly process oriented, but believe in very light weight processes where every step in the process has some value to an actual person. When we plan our tasks, I ask for rollups on what we're really trying to do and why. This enables me to talk about people's work and know what I'm talking about. The benefit is that we give coherent answers, and have a list of things that are ongoing that are at a higher level than tasks and lower than long-term plans (2 week segments).

For growth, every half I ask a series of questions about their aspirations for the next 6 months and align them to our company's evaluative criteria. I write it down, share with them to edit and correct (this makes sure I understand it). Then at the end of every month, we spend time in our 1:1 to read through and make changes. It goes from a fictional forward looking statement to a writeup of what's been done. It helps frame the larger items that are easy to forget, and a place to put in the small unexpected wins. At the end of the half it is a great asset to see what they've done and for me to bring into performance review conversations.

For culture and team-building, I push for quarterly get togethers (which turns into every 6 months, coordinating a lot of people is hard). Mostly I try to make sure folks are working together and not just adjacent (working on different things in a team is not teamwork). The team also drives conversations to email or scheduled conversations, so folks don't have to be watching Slack to see a decision that may impact them and be lucky they're around (we have a lot of timezone spread, too).

Hope this helps!

Been working remotely since the turn of the century. The answers to all these depend on whether there is a place where most of the team is located, or whether it's a totally distributed team. Also depend on whether the new person is new to your team but not the company and/or new to working remotely from their team, and working from home versus working in a remote site. So adapt as needed.

For on-boarding, if there is a large mass of people in one site, then bringing the person in relatively early in on-boarding is really helpful. It builds connections that can make it easier to ask questions after the new hire has returned home, and allows for faster acclimation to startup, plus a way to peek over other people's shoulders to see how they use tools, interact, mannerisms, etc. Makes it easier to feel like a part of the team.

If there's not a site where there's a critical mass of employees, but there is one or more colleagues nearby, it can be worth it to set up a welcome lunch get together just so that the new employee has at least one IRL contact. If not, well, that's fine too.

As manager/team lead, spend lots of time with the new person on tools, culture, etc. Introduction, video chat, etc. from the start, plus your communication tools (hangouts, skype, GoToMeeting, whatever for collaboration). Everything you'd do for an employee on-site (if that's a thing), plus more frequent check-ins because you can't see face and body language as easily, and are not necessarily yet as familiar with communication patterns. Establish your minimum requirements for things like status/tasks/synchronization. You'll learn to interpret your new hire's patterns (is that silence because she's thinking or because she's distracted or because she disagrees) over time, but at first, ask and wait, especially if your new employee is new to remote work and doesn't yet know how to maintain communication from afar. But that's part of any on-boarding.

Make sure that the kit that the new hire gets includes a decent headset from the start - this is critical for participating fully.

For a distributed team, getting together can be crucial, but there have also been times when I haven't gotten together with teammates for a couple of years, and some I've never met IRL. Different continents, too costly, etc. If/when you do get everyone together, plan for real work as well as downtime and team building, and remember that folks who work remotely aren't necessarily used to being surrounded by their colleagues and always being "on" in the same way. Plan meals and expect some to opt out. Allow for jetlag if people are coming from far-away places. Have an agenda, and also have time for some sort of team-building activities, even if they're simple things like a picnic in the park or a play or beach outing or something.

Also, if you're doing a retreat type thing or renting house/resort together for out of town folks, please be cognizant of individual differences, and any outliers. The lone vegan or omnivore or person with hearing challenges or mobility issues doesn't have any issues working at their regular location, but at a group gathering, those challenges can loom large enough to be serious impediments to the goal of connecting coworkers. I'm often the only woman in the call or on the conference room, but there is no way I will be the only woman in the house so don't rent a single AirBnB and expect me to attend comfortably while sharing a bathroom with my male colleagues and eating breakfast in our jammies. OTOH, being the only one NOT in the house is just as bad as still being remote. Of course, other individuals not have an issue with these sorts of things. So think through these F2F meetings, especially for smaller companies. As with all remote worker issues, the key is to make it visible by talking with everyone involved about issues and concerns before the get-together.

Fly them in

Any ideas where flights are cost prohibitive?

Google hangouts / Slack is very common in my office for remote workers. But they were onboarded in person. YMMV