What’s the Developer’s Incentive to Ship?

The company always has a substantial incentive to ship. Usually, it’s financial. If you don’t ship the software, you can’t sell it. If it’s an internally used tool or a line of business application, then the company’s incentive to ship is to increase user productivity (again a financial incentive). To the company, shipping the software affects the bottom line and the incentive to ship is clear.

But what’s the incentive to ship for the software developers? Those are the guys that control the real ship date. In nearly every company I have ever seen, there is virtually no incentive to ship for the developers. In fact, in most companies, developers have an incentive not to ship! Sure, you can argue all you want that if they don’t ship, they risk the chance of losing their jobs as the company might suffer layoffs. Theoretically, improving your company’s financial well-being so you can keep your job should be a big incentive.

But Windows Vista didn’t ship for 5 years, 3 years later than the original plan. How many developers lost their jobs? Zilch. Plenty of companies are financially secure enough to withstand slipping ship dates without resorting to layoffs. Whether the software is for internal use or if it’s the core product that the company sells, developers don’t feel much pain from slipping ship dates. As the ship date continues to slip more and more, the sense of urgency, importance and chaos continually increases, adding some spice to an otherwise boring job. So there could even be hidden incentive not to ship. That’s a flawed system.

If a developer does the identical work the day after the software ships as the day before the software ships, from the developer’s perspective, shipping software is a non-event. After all, what’s the big deal about shipping software if I’m going to continue to do the same thing I was doing yesterday? Some individual team members are independently goal driven to ship. Hopefully, that’s the makeup of your team. But if I had to guess, judging from the norm of slipping ship dates for software projects everywhere, I suspect the vast majority of teams are made up of developers who are not overly anxious to ship software. What can you do?

Building an Environment that Encourages Shipping

Google is famous for the “20% time” it gives its engineers to work on projects they like. The way this works is that engineers are allowed to spend 20% of their time on whatever project they want, not necessarily the one that the company is banking on. Ask any engineer what they think of Google’s 20% time and they’ll say something that resembles “awwweeeesome!” But ask a manager or an executive of any company about Google’s 20% time and they are filled with fear. Fear that something like that would cut their productivity by 20% – how could they possibly afford that? The typical executive might even think Google is leaving productivity room on the table and at some point they could eliminate the 20% time and improve productivity by 25% (going from 80% to 100% is a 25% increase for those of you keeping track).

That’s a short-sighted view. Here’s why:

Most engineers at Google “save up” their 20%-time until the appropriate time in their main projects when they can work on their fun projects. Take a wild guess as to when the appropriate time to work on their 20% fun project is. You guessed it. It’s immediately after their main project ships!

Now imagine you are an engineer who [thinks s/he] has a brilliant idea. Over the past 8 months, you have saved up 30 days of 20%-time to work on your brilliant idea, but the only way you can start working on it is if you ship your main product!

How driven are you going to be to ship your project as soon as possible when you know your fun project won’t start until your main project ships? Are you going to allow scope creep? Are you going to work on that cool new feature you thought of that nobody cares about or are you going to hammer out the features from your todo list? Now you understand why Google’s release cycles and continuous application improvements have been relentless and have far outpaced the industry average. They have a pool of engineers who are eager to get on with their own projects and the only way to do that is to ship. Now that’s motivation!

We do something very similar at Axosoft. We never called it 20% time. We just called it a “fun side project.” After major releases of OnTime, we generally brainstorm and come up with a number of side projects that developers want to work on. They can do whatever they want. Software, hardware, web apps, automatic tuna sandwich maker, whatever. Then we spend the next 30 days working on fun projects.

This is the equivalent of taking a vacation, but rather than being stressed by the typical airport security, hotel and other vacation-related nightmares, you actually get to do something you love! For most developers it’s even better than a vacation! Software engineers love to build stuff. Most of us get a tremendous amount of satisfaction from seeing ideas come to life. The more exciting the ideas, the more satisfaction we get and nothing is more exciting than our own ideas.

It’s easy to provide a good incentive for developers to ship. Just don’t think of it as a loss in productivity!