Do you need to bring onboard new employees and get them productive fast? Are you a business that frequently sources your hiring needs with temporary hires? If the answers are a yes, you’ll find this success story very interesting because here at the Citrix XenApp engineering offices in Ft Lauderdale, we were having the same problems. We came up with a great solution that reduced the onboarding cost from 3 weeks to just 2-3 days, and one that is flexible enough that it can be easily tailored to meet your company’s specific needs.
For many types of projects, firms look to temporary workers or contractors to meet their hiring needs. At Citrix, we keep a watchful eye on our contractor budgets to ensure they are spent efficiently. Given that the tenure of contractors is usually in the order of only a few months, it’s important that their ramp-up period is as short as possible so we can effectively amortize the fixed cost over their short tenure.
Before we came up with the solution I’m about to describe for one of our development projects, we carefully studied the current problem. We observed that there were two components to the bring-up costs:
- The hourly contracting dollars that are paid to the contracting company mostly go in setup costs in the first 2-3 weeks – setting up the development environment for the engineer, which includes setting up development tools, debugging utilities, setting up source control, syncing source code and compiling it – several thousands of lines!
- The opportunity costs of knowledgeable full-time employees in the time they spend in hand-holding the contractor, answering questions like:
--“Where do I go to install Visual Studio from?”
--“Ok, I installed Visual Studio, but what should be the path to the Perforce depot?”
--“I’m missing a service pack. Can you please come down to help me?”
These are all very legitimate questions for a contractor to ask, but ones that steal time away from valuable full-time employees.
Our solution was very simple. Since setup was the biggest component of the bring-up, we created a “Dev Machine” that contractors could then “check out” from our internal cloud called SkyNet, a massive XenServer pool. Nicely pre-packaged and pre-configured into this dev machine were all those pieces I described in the earlier section that would normally take a new person a long time to setup and configure (It took me, an 8 year “veteran,” about a week.) Putting ourselves in the shoes of a developer, we created “one-click build scripts” that started the lengthy but necessary process of syncing hundreds of lines of source code for all our technology components – HDX, IMA, Single Sign On, Management Components etc., all with the click of a single button.
This “Dev machine” is actually a shared hosted desktop on XenApp. On the first day, this entire desktop was delivered to the contractors who could then use their own laptop or a Wyse terminal as a thin client.
You could always customize a solution like this for your organization based on the unique software needs of your enterprise.
- Contractors can get on-board quickly and work on actual business issues on the first or second day (instead of a two-week long setup). Huge cost savings!
- Your full-time employees can focus on their high-value added tasks without disruptions.
- No need to provide the contractor with a physical workstation – it’s basically BYOC.
- Security policies (e.g. limiting Client Drive Mapping or Clipboard functionality) can be set in a way to prevent source code from being stolen, thus preserving the company’s intellectual property.
- A great morale booster – whether you are a new hire or a temp worker, what’s more satisfying than adding value on Day One! You get a great feeling of accomplishment right away.
- You get all the TCO benefits of centralized management (upgrade once, use many).
- Developers are very creative. Less than a week after we announced this, full-time developers who’ve been with Citrix for a long time, found a great use for these “Dev VMs.” They’ve now been regularly using it for doing “buddy builds” to validate their code changes before submitting them to source control – just this time around the buddy is our dev VM instead of a real developer!