Versatile programmers

I work as a programmer for a small consultingware ISV. Since we're small, everyone has to be flexible and take on roles outside their primary area from time to time.

Programmers tend to be higher up the skills chain than some others in an ISV. As a result we have the ability to be reassigned to a number of non-programming roles at the same skill level or lower. These tasks could include in no particular order

QA testing
creating product documentation
creating online help files
sales engineering
professional services
producing training materials
delivering live training sessions
level 1 and 2 tech support
consulting
providing a reassuring presence on a customer site
creating content to demonstrate at trade shows
attending trade shows


In general there is little to no transferrance the other way into the core programming team. This is because it is generally difficult to impossible to quickly reposition someone up the skills chain instead of down it. For example it would not be realistic to try to cold reassign a tech writer or level 1 tech support rep from their usual role into the programming group for a couple of weeks to help the product team meet an end of month deadline. They don't have the required skills and experience to function effectively as programmers. So the standing programming team can only lose resources, and never gains them.

In larger companies, it should be possible to properly separate the programmers from the other roles. The other teams are big enough to be properly staffed and are expected to fill in their own shortfalls using their own means. In a smaller company we have to be more flexible and cannot just isolate the programmers from having to occasionally do non-programming tasks. Especially in consultingware, which is about smaller numbers of big sales, we have to be responsive to sales opportunities. When you're close to a big sale you do what you have to to make that sale. The success of the products and the company depends on it. Sometimes the distinction between the core product and a customization can be somewhat blurry. If the programmers can help make the difference in a short term big opportunity then that's worth doing.

In general it's not economical to reassign programmers to other roles since programmers tend to cost more than the roles they are taking on. So assigning a programmer who averages a loaded $100K a year to do tech writing or level 1 tech support than can be adequately staffed at a loaded $50K a year isn't cost effective in the long term.

There is a hidden cost to reassigning programmers. The cost is that the programmers cannot advance the core products when they are doing other tasks. At Microsoft there is a really good saying among the programmers: "If you're not writing code then what are you doing?" That really focuses the mind on what the programmers are there for. What's more important that a programmer should be doing than creating source code. Every day a programmer spends not writing code is a loss for the products he would otherwise be advancing. This cost is not immediately apparent, and may seem negligible in the short term. However over time it can be extremely costly if the core product becomes uncompetitive in the marketplace.

So the programmers immediate manager, product management and the company in general must be educated to understand the potential costs of reassigning programmers. In general requests for programmer reassignment should be carefully reviewed and challenged, and rejected if a compelling business case cannot be made for it.

In a dysfunctional environment, the programming team would be like a buffet table where any other group can help themselves at any time to a warm body or two to cover over a local shortfall. If you have a small programming team to begin with and you've got one person doing phone/email tech support, another one out of town at a trade show, another on another continent holding hands on a customer site, another helping set up a sales demo, two others over helping out with a QA cycle, and someone else conducting training sessions then you basically have nobody working on the actual products which will then be at risk of becoming uncompetitive. That's an extreme example but you have to be vigilant to keep the programmers writing code.