The idea of a sabbatical is simple: take an extended paid absence from your career to achieve something. Sabbaticals are common in academia, where a professor might take one to do intensive research or write a paper, and they are even popping up in other industries[1]; software development in particular. I’ve been thinking about this trend, and how it relates other goal driven perks like Google’s famed “20% Time”[2] (now defunct?/reimagined?).
There are two obvious challenges with directly porting the sabbatical from education to software development. First off, how do you time it? There’s generally some requirement for years of work before being eligible for a sabbatical, and additional restrictions around duration of said sabbatical. Add in pay rate during sabbatical and this relationship can be quite complex (see: Stanford’s sabbatical policies[3]). This sort of complexity would be cumbersome for many companies, and given the current rate of job changing going on in tech [4], inaccessible for may employees. Even if this is overcome there’s still the issue of teams being left in a lurch when a key employee is “out of pocket” at a crucial time.
The second challenge is showing the value returned by a sabbatical program. A developer getting to work on something they are interested in and passionate about is a clear win for them, but what’s the value prop for the employer and the business owners? What would it take to show them that this isn’t just another name for PTO?
Here’s what I’m thinking: imagine you don’t have a sabbatical program, or 20% Time program, but you’re considering starting one. I won’t make the blanket claim that that’s a good idea for all teams. However, if part of what you want from your developers is “innovation,” or you pride your business on being “cutting edge” it would seem good sense to offer some program to help facilitate this. The simplest reason being, given no other place to experiment and innovate, but the expectation to be experimental and innovative your team is likely start getting creative on your production application(s). This could work out great, but I’d advise more caution with your customer’s experience and your primary revenue stream.
Giving your team space to experiment can also be a good defense against burnout, lack of productivity, and churn. Problems are often solved faster if you stop looking at them for a period, and doing something different can make your return to your original task feel fresh. (Witness Minnesotans getting excited about the first snowfall…)
If you’re skeptical of the value of some sort of sabbatical – ask yourself what would change your mind? What would you want to see out of this sort of program? Surely you’d be pretty happy if you got Gmail out of the deal. Now build that into the expectations of the program.
Furthermore, that expectation isn’t the only lever you can adjust. What if the sabbatical was only for two weeks? How would that adjust your expectations? You won’t get Gmail in two weeks, but you might get an interesting API, an assessment and prototype of that Docker thing you’ve been hearing about, a blog post you can use to showcase your developer’s insights and willingness to share with the community, or a demo of a new feature your customers would love.
I claim that there exists a combination of duration and expectation for a sabbatical program in your company that you’d be on board with.
If your eyeballs are still with me I’m going to assume you’re interested in trying this out and are wondering what your sabbatical program could look like. Here are some ideas:
First off, making this program available only after a certain duration of employment seems reasonable. I would caution against expecting 5+ years. You want people to do it before they start considering other opportunities, and before they start to get burned out. Besides, if the program is structured well you should be eager to start seeing some benefits from it! How about once every 2 years?
Now how about duration? I think there’s a risk of being too long, or too short. Especially when you’re introducing this sort of program. If you’re doing sprints your sprint length is probably a good place to start. My preference would be 2 weeks, but for sure no less than 1 week.
I’m advising starting small, and the expectations need to be commensurate with duration. This piece will vary according to your values. So, rather than giving you an expectation to shoot for, I’m going to suggest that you ask the developer interested in doing a sabbatical what they are expecting to accomplish. Then you can work with them to arrive at an expectation that you are both excited about. This is also when you’ll want to decide how that result will be shared. Presentation? Demo? Blog post? Tutorial? There are a lot of ways to approach this. What matters is that you both agree to it.
Perhaps the most important piece of a successful sabbatical program is planning. A developer considering one should have a solid plan for what they’re trying to accomplish and how. You should have your balance of eligibility/duration/expectation worked out. Finally, getting the timing right is important. If a developer is going to have a successful sabbatical they can’t spend it working on their regular projects. From top to bottom that needs to be understood. Making sure it kicks off at good time will go a long way towards giving them the opportunity to succeed.
I’m a huge proponent of trying things, on small scale, evaluating and iterating. A sabbatical program is no different. I’d be interested to hear if you’ve tried this, if you’ve made it work, or if it crashed and burned. My advise is simply to give it a shot. [5]