If the data is active, it's not enough to just throw more storage on the server. More storage means more of other things: Memory. I/O bandwidth. Processing power. Could keep adding those as well, but eventually it's faster and much cheaper to add additional servers.
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.
Way late on this, but this thread has been referenced in things like Oren Ellenbogen's Software Lead Weekly, so maybe the reference will help someone...
Bob Sutton's "The No Asshole Rule" calls this TCA - total cost of assholes. TCA incorporates the cost to replace people who leave because of the asshole, time spent by manager calming people down and cleanup, customer relastionship issues, etc.
Tandem computers did not run software in lockstep to achieve fault tolerance. They were shared-nothing parallel clusters before shared-nothing parallel clusters were cool, with message-based communication between processes independent of the node each was running on. This gave near-linear scalability as the number of nodes grew. I worked on parallel sorting and parallel data loading back in the 1980s, scaling up to 256 nodes, and Tandem's NonStop SQL developed and commercialized similar parallel database query evaluation in the late 1980s, ahead of its time.
I've worked remotely for nearly 20 years in various configurations (all team remote, team collocated and I was the lead and remote, some local and some remote, as lead and as a team member) and this is spot on. My current situation is one where it's actually harder to be remote than it was when we all worked for a giant company that was openly hostile to teleworkers (If you're not in the office everyday, you're part of the problem). Even though I'm in a smaller company and an environment that brags about its startup culture and flexibility.
In my current iteration, information does not flow naturally, but rather 1:1 and in-person along restricted paths, making it much harder to work remotely. So to build up a picture of what's going on, I connect with several other teleworkers and we try to compare notes on "what have you heard about X" and "who's working on y."
If the whole team is remote or acts like it (open communications, info flowing visibly, etc.) then remote working, remote bonding, remote team-building is natural and easy. I know; I've done it for years, building high-performance teams that see each other once or twice a year.
If you're the outlier and most everyone else is local, it takes a lot more effort, and even then can be very, very hard.
Some places are just easier to work for than others.
When my kids were younger, the curriculum that their school used was more about the aha!s and connections than about rote recipes. I volunteered in one's first grade math class where they spent 20 minutes of the 45 minute math period learning to draw puppies and kitties so they could answer the question, "Sue has 15 puppies and kitties. How many of each does she have?" The goal was to get the kids to come up with every combination from 0 puppies and 15 kitties through 15 puppies and 0 kitties, and first graders are still mostly concrete thinkers and need those pictures.
At this level, getting 3+2=5 was MUCH less important than being able to explain in writing that 3 apples and two bananas added up to a bunch of fruits in words. 4, 6, 8, 5, whatever. Alas, they never got 3+2=5 hardwired in this curriculum. But they were better artists for it!
And my kids did not learn math, because the curriculum was more about writing than math and explaining reasoning (I called it "math for people who don't like math and would rather write about it than do it"). So in elementary school, I taught my kids math using Singapore Math curriculum and let the school do its thing so it was balanced, and I volunteered weekly in math during the elementary school years so I was on top of what they were learning and how.
In addition, we always did math at home in informal ways without being explicit about it, from counting lug nuts on cars when they were toddlers through guessing the color of the next car to go by the stop sign on our walks to estimating which box of cereal was cheapest without a calculator to noting that the arrival rate at a traffic signal wasn't random in one direction because the only way cars could get to it was by going through another signal. Heck, even counting in binary using the 3 lights above an airplane row on visits to the grandparents - Look, with three lights I can only count to 8! And now with high schoolers and college kids, math jokes like log(fu) = log(f) + log(u) are the height of hilarity, or at least lighten the mood at exam time.
Point is - there is "studying math" (with whatever curriculum and rubrics) and there is "playing with math." As a parent, especially with younger kids, I found that it was great to establish both. Math isn't a "thing", it's part of life.
On the total flip side I remember when studying math in high school most of the other students HATED the math questions that required writing. It was like by that point they preferred the memorization. Maybe because that is what they were used to. Having to think about how to actually apply math was difficult for most of them.
Trafodion is Apache Trafodion (incubating), providing a fully distributed transactional ANSI SQL on top of HBase for OLTP and operational workloads. The link is incorrect as well. Instead use the Apache link: http://trafodion.apache.org .
