The technology exoticness hierarchy

This is a draft in progress

How exotic can be the technology you use in the IT industry at large ? What programming language ? What database ? Is it safe or foolish to use a highly exotic or new programming language ? What if you think it's interesting enough so you should give it a a try ?

In my opinion, there are at least 3 levels you should consider.

Level 1: the IT service company

You supply brain and workforce for your customers, intervening into your customer's IT. For example, you're IBM (you may be a smaller company !). You have numerous customers, each with their culture and technological peculiarities. Certainly, the part of the IT you work on is not isolated into your customer's global architecture.

In this case, you have no other option than to play safe. You're in an environment with too many people from too many different horizons, and you don't control them. Use the same programming languages, operating systems, databases than everyone else, so people will have some common ground, at least for the basic technology.

Level 2: the internals of a company

You're not an IT company, but (as almost anyone today), IT is a part of your global strategy to build a competitive advantage. For example, you may be UPS, or an online reseller. You don't sell IT, but you need it.

Then you can climb one more steps on the ladder into the unknown. Actually, you can even climb two, but it depends on how you handle your IT technology in this matter, and you will manage it differently.

You're outsourcing

You've elected not to go into IT too deep, because, after all, this is not your core competency. You don't want to go after hiring programmers and an entire IT staff, manage a team that may be won't integrate well with the rest of your organization (in the sense of its structure), all you want is the result. Then you work on specification, may be with the help of a third party, elect an IT service company as your supplier, either a generalist or a more specialized one, sign a contract and go after the result.

Some of your people will need to speak to your supplier, so it's easier if the technology isn't too exotic.

Of course if it isn't exotic enough, you will have just the same software as everybody else and won't build any competitive advantage from this particular piece of software. In this case, you may even consider buying an existing software rather than building one.

You're doing it internally

(The right path in my opinion, since I'm not very fond of outsourcing).

Things are getting serious. You're doing it for the competitive advantage, otherwise you would have bought it. Further more, you're doing it on your internal ressources, either because you think it'll be less costly, or because you want to capitalize on people. This is to say that your own people will be the memory of the project, something difficult to get if you're outsourcing, and you want to be flexible and cumfortable on exploitation and future evolutions.

Level 3: the software editor

The computer gals and guys are on your payroll. You hire them, you choose them. You decide what kind you want.

Of course, the responsibility of finding adequate people now falls on you. You may have to pay them well. If you don't find enough of them, you may have to train them yourself. You are a software editor.

Needs a note on the economics of the service company vs the software editor.

NB: using an exotic technology doesn't mean you need to reinvent the wheel. If you're parrot, you don't need to invent a new operating system, programming language or whatever. Bring nicely together existing blocks, add a teaspoon of your magic sauce, and you may get a nice product.

On the economics of IT service and the software editor

In short, IT service is the simplest economical model of all: on one side, you buy time from engineers by putting them on your payroll. On the other side, you sell their time for a given hourly fee. The difference is your gross margin. Of course you have to take into account the dead time, that is the time during which the engineer isn't billed between two contracts, and the "dead body", for example the commercial representatives, who you pay but don't bill. But this can be very small, so in short, there's no fixed cost in this business, and you can start it with zero capital, and scale down rapidly through layoff when things go wrong.

In short, your revenue is roughly proportionnal to your head count, and your margin is the difference between what you pay your engineer and what your customer is willing to pay.

By the way, if you're the engineer, this is not very good for you: your salary makes most of the company expenditures, so it may not be willing to increase it too much.

At the software editor, by contrast, you have to develop the core product in advance, meaning burning cash to pay the engineers while you don't get any revenue. There is a fixed cost. But once the product hits the market and is a success (hopefully), the revenue depends on the number of times you can sell it, which don't depend on the number of engineers. If you sell your software through a website, the variable cost is close to zero, this is the model which has permit some open source software to distribute millions or hundred of millions of copies, while being run by foundations with very little money. Of course, this doesn't mean there are no other costs, such as marketing, and even variable costs, such as support, this last one being potentially proportionnal to the number of users. And by the way, a buy once gets maintenance forever is a dangerous proposition in this context.

If you're the engineer and want some money, this is the place to be. If you get your wages doubled, it will make no difference on the company bottom line, while it will be eager to retain you.