Is it best to try to work at a company where your software directly makes the company money? [closed]

Question

I was told once that the best place to work as a developer is a company where the software you write is what makes the company money, whether it be software production or software services like consulting. This is opposed to a company where the software you write is just to support some other part of the business that makes the money, like manufacturing or finance. I know there are always exceptions, but in general, are employees treated better if they are on the front lines of profit generation, as opposed to being just another cost center?

cost center (n.) - A cost center is part of an organization that does not produce direct profit and adds to the cost of running a company. Examples of cost centers include research and development departments, marketing departments, help desks and customer service/contact centers.

Answer 1

Oh, hell yes. Otherwise, you're relying on the head of IT to do a fantastic job of justifing/selling everyone in the company on your profitability.

It can be done, but most don't have the skill, time, or absence of office politics to over come it.

[Edit] Everyone wants to do a cost/benefit analysis, but without calculating the benefit.

Which company do you think is more likely to put a former programmer in charge: a software company or an insurance company?

Answer 2

There's two factors that I see.

One is that, when the software is the product, there's a very great tendency for sales to overpromise, perhaps in epic scale, and for the developers to be pressured to deliver. In any case, software deadlines tend to be treated as harder by software vendors. Software for internal use tends to have softer deadlines (although there are sometimes legal constraints), and death marches are somewhat less likely.

Another is that, when the software is the product, most of the higher-level execs will at least try to get a clue as to how it's done, and will in any case try to keep money flowing to the developers. When software is developed for internal use, there's a tendency to try to spend as little as possible, without really paying attention to whether cuts and/or outsourcing is a good idea.

There are some companies that develop software for internal use that they use as a competitive advantage. That can be the best of both worlds.

Answer 3

Oh yeah, many things, generally speaking, are going to be better if you're a developer at a company whose business is to create and sell software, compared to being a developer in a company doing something else (at a more or less peripheral department). (This is of course a gross simplification, as software plays an important role in many kinds of products today, and as there's a huge variance in overall atmosphere and job satisfaction between different companies.)

Chances are, in the former case, that the work is more interesting (i.e. motivating) and your colleagues smarter (smart people prefer to work with interesting stuff). Of course your work is also less likely to be outsourced, and so on. Just the feeling that you're closer to the core of the company, and do things that really matter, can be pretty neat. (Perhaps e.g. the most senior guys in your team or department are some of the key people in the whole company.)

Oh, the wording of the question prompts me to add this: I guess it's somewhat rare that software directly makes the money. At least on the B2B/enterprisey side of software business, there's typically a considerable sales push needed to make money out of a software solution (the software product itself and, often, related services). Even if you're working on a core product at a software house R&D team, it's possible that your day-to-day work is quite detached from the money-making (customer-facing) side of it all. (In fact, from one particular point of view, salespeople make the money by closing deals; all other work merely supports sales...) So, if you want to completely escape the notion of cost center that you mentioned, either write software that markets and sells itself, or become a salesperson or technical presales consultant. :-)

The above rambling is based on working many years at a software product company's R&D dept., yet nowhere near the "front lines of profit generation" as you put it.

Answer 4

Here's an alternate perspective: If you provide internal services, you don't have to deal with the vagaries of marketing and product managers, focus groups, "us vs. our competitors feature matrices" and other technically baseless factors. E.g., QA contributes directly to product success, but its "customers" are the product developers. They're all rational technologists, right?

Answer 5

If it doesn't help make profit, so why a cost center is maintained?

Even the person cleaning the restrooms is contributing to company's profits.

Answer 6

Company´s profile is the measure for your choice, not kind of work at company.

In common world, even when software is the product that makes money, they don´t cares about your cost center (yeah, you always a cost center number). The goals are sales amount, sales count, revenue, profit, cost and a infinite indicators based on commercial process.

You realise that when you raise your goals and they offer you a kind of geek/tech cadget insted a real promotion.

Answer 7

Software vendors and IT service companies can scale-up to deliver the same service or app to many more customers, and they benefit from the economies of scale. The same thing could apply to software which runs the core services of a company, like banking software for a bank, or logistics software for a delivery company like UPS.

In my experience programming positions where the focus is on 'internal' or 'departmental' software the projects are perpetually under-maintained. After years working in these conditions all I could come up with for a reason was: simple economies of scale. There just isn't enough time/money being lost by the poor-quality or poor-fitting software to justify the cost of a test/release cycle. But for smaller user bases your manager's hands might be tied by the economic reality: he/she might not be able to justify the test cost to let you fix a bug you found over a year ago, even if that bug is causing occasional errors in a production system. Imagine yourself explaining a situation like that to an end user, now imagine that happening two dozen times over the course of a year. That might be the economic reality you're signing up to live with.

So my advice for anyone considering taking an 'internal programming' job is: beware. I believe most of the software industry requires a 1:100 or 1:1000 ratio of developers to users to really justify active development. If you can find that kind of ratio inside a company then maybe you'll be fine (developing an app for a 10,000-person department by a team of 3-5 programmers). But most don't.

Of course there are a ton of assumptions here and many exceptions. Highly profitable industries (like finance) would have much smaller ratios and still justify the higher development costs. I'm also assuming software projects that provide basic 'information worker labor savings' over human processes and workflows (which was my experience are the mainstay of internal programmers).

Answer 8

I would qualify the answer a bit. If you work for a company in IT and that company also makes software then yes, you are not in the best place.

However, if you are in IT and your company does something non-software related as a product and is heavily dependent on IT to deliver, then you are in a good spot.

I have worked in Engineering driven companies as a software engineer and we really looked down on the IT folks and people who couldn't cut it in engineering.

I have also worked in IT for a telecommunications company. In that case our software, while not a product, was essential to the operation of the company. We were the highest compensated employees and had a lot of empowerment. We still had to justify projects etc, which does go both ways (you can point out that bad decisions are costly). Even in engineering though, you have to justify your projects will make the company money.

Answer 9

I think it depends on the kind of company, i.e. the role software plays in the overall product.

Companies where the software is hidden deep inside, usually has a lot of layers of hardware and design on top, which means all of those contribute to the final product, and either of them can make or break the product. Less software visibility, less impact. They might consider developers as disposable, and the department may be neglected because the management doesn't have a software background. You might write fantastic code, but no one can see it.

Companies where software takes the front seat obviously has more impact, but then its also the critical factor in the overall reception of the product. If you write good code and it works well, it shows.

Personally, for me the real joy is in getting hardware and software to sing along, a balance between pure hardware and pure software.

So the answer is yes.

Answer 10

Personally, I fully agree with Zed Shaw on this matter:

People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.

-- Epilogue to Learn Python the Hard way

Thus, Instead of working at a company whose primary revenue source is software, I would recommend to work at a company that just does something inherently interesting, where you can use programming to help solving those interesting problems.