[mooreds]

In addition to knowing which bucket your salary comes from, I think it is also useful to know how your organization values building software. Because this affects your career just as much.

* Is your company selling software development hours (consulting)? I'm this car you'll be valued for client relations skills and the ability to bang out acceptable software.

* Is your company selling a software product (product company)? In this case you'll be valued for your ability to build and run software.

* Is your company selling something else that has a software component or that software enables (pretty much every other company)? In this case, you'll be valued for your ability to deliver on or below budget and you'll never be the star of the show.

Funnily enough, these seem to map well to the three categories the author mentioned. Consulting to sales/marketing, product to research and development, everyone else to maintenance.

[hackernoteng]

My experiences: 1) programmer in IT department of major newspaper: disregarded as IT geek. very small salary. the worst office spaces. 2) senior engineer in software startup: rockstar treatment, stock options, all the things you would expect as office culture 3) senior consultant at IT consulting company: must basically be a sales guy who writes good PowerPoints. Maximize billable hours. What ever you do dont complete a project quickly or with minimum amount of code.

you can probably guess where I am now.

[jwineinger]

Agree with these. I was a dev at a retailer that did catalog/phone sales and was starting to use web. Small salary, small PTO, no benefits. Pay increased when the business had an existential crisis and came to rely much more heavily on tech. Next was software consulting company churning out sites designed by marketing agencies, billed to the 15 min. Small salary, small PTO, some benefits. Then I went into SaaS (startup, then a public company). Nice salary + stock, great PTO, great benefits.

Aside from the comp/PTO/benefits, I learned that consulting isn't for me. The client interactions felt... adversarial, where they were trying to get more work for less money, while we were doing the opposite. I did not like that constant tension in conversations.

[SOLAR_FIELDS]

The point you made about consulting interactions resonates with why I also ended up not liking consulting. It feels like incentives are not aligned when doing software consulting a lot of the time.

[jncfhnb]

Flat fees. Problem solved.

[A1kmm]

I think it is flat fees which create the problem in the first place. There are six commonly recognised general project variables: cost, time, scope, quality, benefit, risk.

So suppose you've fixed cost, have you fixed the other five project variables too? If yes, you've just reinvented waterfall - which is fine if you have a very well defined task you repeat often, and there is little chance of much scope variation being desirable. It still might be adversarial in that you, as a consultant, might do the same process for every client, but it might be your first time working with a client, who expected more than the scope, or disagrees with your interpretation of the scoping document supplied.

Now suppose it is a much more bespoke task, where both sides need to discover some things about what works. You are likely to learn that part of the plan you originally had won't work to capture the benefits. Now the actual scope required is bigger; perhaps that is a risk you take. But perhaps one client realises some big scope requirement early, and deliberately takes advantage of the fact your scope is variable to conceal this from you when you set your fixed price; maybe you put some language in to try to reduce this risk. And perhaps your boss encourages you to use some of that language on an honest client who did genuinely try to communicate the scope, to make the client pay. Everything is once again back to being adversarial.

I think time and materials contracts are actually the best for aligning incentives - the consultant gives their best attempt at an accurate estimate of the work, and the client can freely change things as they go along - but carry the risk of cost changes. If the consultant is poor at estimation, doesn't give frank advice, or does low quality or slow work, the client ends the contract with the consultant and gets a better consultant, and since it is time and materials, it is clear what is payable and who owns what - so ultimately everything is well aligned.

[tessierashpool]

flat fees fail for dev.

as soon as you encounter an unexpected problem, your margin suffers. since unexpected problems can radically alter dev time, your margin can be obliterated.

[mooreds]

I love this post about the topic: http://web.archive.org/web/20220507182508/https://rickmaneli...

(Lost on the current site, as far as I can tell.)

[jncfhnb]

Make bigger margins

[tamimio]

Curious to know every consultant flat fees and/or the metrics they use to determine it, since you will be charging for the “value” rather than the fixed hourly rate.

[hackernoteng]

The consulting company gig paid alright. and all the guys who stayed got really rich due to IPO. I left the second my options vested. Literally when the transaction went through... no regrets because it SUCKED

[granshaw]

How often do consulting companies ipo nowadays tho… heck ipos in general have dwindled to a tiny number

[antod]

> Maximize billable hours. What ever you do dont complete a project quickly or with minimum amount of code.

There's a real continuum of engagement budget here - at the other end of the scale you have the opposite problem where the fees are barely adequate, and your success is based on systemitizing shortcuts to crash out cookie cutter minimum viable products, and being able to get clients to actually cough up.

[teaearlgraycold]

> Maximize billable hours. What ever you do dont complete a project quickly or with minimum amount of code.

OOF

[throwaway2037]

Was #3 the highest pay and least amount of work? If yes, I select #3.

[kayodelycaon]

I chose to make a career out of #3, specifically logistics. I know how stuff gets from vendor to customer.

This isn’t something you can buy out of a box. It’s usually heavily customized and made out of multiple systems were never design to work together. Every company does this differently.

I enjoy this. I’m good at thinking through whole systems across a company’s many departments. This requires knowledge of internal politics to navigate through problems. This is were I’m valuable. As a programmer, I’m good, but can’t match the expertise of someone who makes a career out of programming.

[ptsneves]

I am in the same camp. I also don’t think it is bad in compensation terms because lots of this maintenance work is often called devops and devops is well paid from my point of view. I do the logistics for embedded or SaaS. It has been good and it is often cool to login to devices that are seen as a black box by any other person in the world. I also know that when something is on fire the maintenance guy is the one being begged by the sales guys and higher management. Maintenance people end up being debugging gods.

[ted6767]

Brother

[jimbokun]

To simplify, you always always always want to be working in bullet point 2, if at all possible.

In the other two, you are a cost to be minimized or eliminated. Only if you are working on one of the companies core products are you an asset bringing revenue into the company.

[Closi]

I disagree - It depends on your career aspirations, your skillset, the company, and the type of software you like making.

If you are a great communicator and have a great ability to just 'get stuff done', you might be a superstar in 1 & 3, and you might find working in bullet point two highly frustrating.

With number 2 you are more likely to be working on a tiny part of a larger application.

My brother went from bashing out big scrappy functional software with lots of client interaction (option 1 or 3) and moved to a bigger product organisation where he is suddenly working on a team building a microservice for a larger application, but doesn't feel like he is making the same direct impact (i.e. it can be more satisfying to make 10 people's jobs 10% easier compared to than making 1 million's peoples jobs 0.1% easier). He would rather build some scrappy tools that gets the job done than build highly refined software, just because the scrappy programming to meet an end is more satisfying to him (and is generally the bit where you can build fast value!).

[ted6767]

I would also add career longevity and security. I work at a number 3, I wrote and maintain all the logistics stuff. Every product they sell goes through my code to package parts, put it together and get it out the door. Average time working here is measured in decades not years. It would take a new person roughly a year to figure out what's going on. It's incredibly complicated cash cow that complies with a slew of national and international regulations related to health care. I know more than I ever want to about HIPAA, international equivalents and transportation of hazardous and infections goods.

I wouldn't mind switching to #1 and doubling my paycheck but for now I could float here until I die, and many do.

[granshaw]

How’s the workload?

[killjoywashere]

Labcorp?

[Supermancho]

As a software developer, I rather work at a company that sells billions of dollars in merchandise, with a huge amount of software to maintain doing that and endless middle management ideas to build on (most of which won't amount to anything). Job security. Lots of opportunities to move around and nobody needs to know how the reference was about all the s-shows, when you go somewhere else.

[chii]

> (i.e. it can be more satisfying to make 10 people's jobs 10% easier compared to than making 1 million's peoples jobs 0.1% easier)

i think in this case, it's got nothing to do with the impact, but to do with the intimacy with the users. This has more to do with the organization rather than the category outlined in the OP.

[sbrother]

Actually #1 is my favorite, as I'm better at technical sales and rapid prototyping than I am at slow, FAANG style politicking, planning, risk mitigation and eventual development. I've done both at various points in my career and consistently make about ~twice as much money running my own consultancy, not to mention I'm so much happier in that environment.

[granshaw]

Do you get much stress in terms of sometimes not being “rapid” enough, not having anyone to rely on apart from yourself (assuming you’re solo), and finding business?

[sbrother]

Not really, because I always maintain at least a few clients so I'm not too worried about losing one. Once you have a solid pipeline, losing a client becomes just part of the business, not the scary emotional experience of "getting fired".

And I have a network of other independents I can bring in to help out with things. They're a good source of leads for me as well.

[michaelsalim]

It depends on the person and the company as others have said. Personally, I found no 3 to be pretty nice in competent companies. On the other hand, I wouldn't want to work with companies like no 1 again. And no 2 can be quite a mixed bag.

[jonfw]

With #1- you are the product

[Closi]

All jobs are transactional, the transaction is just more clear-cut with #1.

[patmorgan23]

Nah there's still tons a variability. Some companies are great some are poor, and different people like working in different environments. #2 might be YOUR ideal workplace but it's not everyones.

[ravenstine]

Eh, I don't think it's that clear cut. I've worked in all three types, and there were positives and negatives to each, and none are necessarily better than the other. I will say that #2 tends to be the most reliable and tolerant of your faults.

[hgomersall]

Most companies should treat software as a core product. Not many do.

[vegetablepotpie]

As a third bullet point person, never ever attempt to solve interesting technical problems.

I’ve made that mistake, I’ve been asked into meetings and asked “how’s it going” then promptly told “don’t tell me the details.”

Working in bullet point three means working on boring, forgettable solutions. You may find yourself making valid technical solutions that are political suicide.

[Aeolun]

> You may find yourself making valid technical solutions that are political suicide.

If everyone else does the opposite, you can make a career out of making correct technical decisions.

Seems to work for me anyway.

[hinkley]

> you'll never be the star of the show.

This is far too kind. If you work eg for a hardware manufacturer, not only won’t you be the star, but good luck getting any respect. You are a cost. One they wish they didn’t have to pay. Delivering on time and under budget doesn’t put you on their radar, it takes you off.

[badpun]

Depends on the hardware manufacturer. From what I know, developers at Intel are treated pretty well. It all depends on how integral the software component is to the overall product's market success. In the case of Intel, a GPU with poor and buggy drivers is not gonna sell, so software is pretty important.

[hinkley]

Isn't Intel struggling now because their definition of 'pretty well' wasn't good enough and they lost key people to competitors?

[verinus]

this.

first company is good for starters to get to know others.

third should be avoided if you want to stay in software and not transition to management. You will always be seen as a necessary evil, your problems not understood while others working on core products will be perceived as an asset.

second one is the one to make a career in software dev.

[resonious]

I actually had a pretty good time at a third-category place. When you're writing software for a non-tech company, it means your customers are very close - often in the same building, working at the same time. You can watch them use the software, hear complaints in real time, and push solutions very fast.

In my case, I might've been lucky, though. One of the co-founders had a CS degree and deeply valued the productivity boost we got from custom software.

[rprospero]

Along those lines, one of the most toxic places I've ever encountered for developers was at a company that sold b2b software. You would think that developers would be valued for creating the product, but they were fully treated as a cost centre. The profit centre was the sales team who went out and got companies to send money. The developers merely existed because legal said that, for compliance reasons, the firm was required to provide the costumers with software after the client paid for said software (legal accounted for 24% of the company's budget while software development was 15%). If the sales team promised something that the software couldn't do (e.g. track the position of any cell phone in the country with just a phone number in the early 90's before smart phones), then any refund owed to the client would come out of the product team's budget. The salesman (they were all men) would not be required to return his commission, since he did his job and got someone to sign a cheque.

Surprisingly enough, the company was not Oracle.

[verinus]

interesting that this company could stay in business.

over the long term I would think that two things will happen: good devs will leave the company while the remaining fight an uphill battle maintaining code until the customers leave.

but ofc sales and incentives in general are a whole different area of problems.

[rprospero]

It's interesting that you mentioned the good devs leaving, because they never got the chance. The owner had a policy of only hiring average devs and 10x devs were fired with extreme prejudice. His hiring theory was similar to modern server management: Cattle, not pets. It should be possible to fire a dev on Monday and have their replacement closing tickets by Friday. Good devs were harder to replace than average devs, so every good dev was a liability.

This policy was also useful for retention. Other firms in the area knew that he fired all of the good devs, so they never tried to poach his employees. In fact, if you got tired of the toxic environment and quit, the firm's name on your resume meant that you probably weren't going to get another dev job without leaving town. When a dev sees their former colleagues making sandwiches at Subway, another weekend of unpaid overtime doesn't sound as bleak.

[makk]

> In my case, I might've been lucky, though. One of the co-founders had a CS degree and deeply valued the productivity boost we got from custom software.

This. A mentor told me, “[As a software developer], never work for a company with a CEO who has never pushed code to production.”

I think you miss some good places to work by following that advice, but you avoid a ton that are worth avoiding.

[verinus]

ofc individual experiences might differ! it certainly depends on the company and leadership. From my experience in a bigger one understanding ended when leadership was needed in software areas, but leadership was recruited only from the other domain...

[ttymck]

> second one is the one to make a career in software dev.

Your comment and a dozen others make this out to be so black and white. If this is true then why am I finding it so difficult to make a career out of these situations. I find it impossible to identify companies in this category that are good to work for. Does anyone have any heuristics, or should I keep bouncing from one to the next until I get lucky?

[granshaw]

Just look for “good WLB” in the Glassdoor/blind reviews, AND that the company is healthy (doesn’t need to be a rocket ship) business wise

[ipaddr]

Honestly the second is most likely to find you outside of the field in 10 years with burnout. Third option allows you to take over part of a company and run things your way but you are being judged on different things. But great experience if you want to do a startup. The first option is great to get experience but teaches you speed over quality and will burn you out in time.

[zerr]

> * Is your company selling a software product (product company)

In the B2B world it is common to have a complex enough product that needs training services and tech support as well. Some vendors also add exams/certifications on top of it.

[mooreds]

That's fair, I was painting with a broad brush.

Once you get to a certain size of consulting company, you may also have an r&d department or someone responsible for building common libraries or knowledge repositories, for example.

[Scarblac]

Or a combination. I'm in a pretty small company (about 80 people total, 15 devs) and worked on all three of those last year.

[mooreds]

I'm a bit confused. You worked as a consultant selling hours, one a software product sold for a price and also on an internal enablement tool for the same company?

[jaymzcampbell]

Not the OP but I can believe it - where I work the main business is consultancy style work but to support that work there's custom generic software developed to sell/license to clients as part of a value add and there's dozens of internal tooling to support delivery teams. We have developers that will move between all 3 of those areas depending on their current allocation to client work.

[mooreds]

Sounds awesome! Thanks for illuminating me. How are these different work streams prioritized?

At first glance seems like the last category would suffer unless someone was "on the bench".

[IggleSniggle]

In a smaller company it's not hard for "invisible" (like CI) contributions to be actually seen and noticed by both leadership and by the people you work with every day. And on the other hand, if you're a dev working on product and getting work done is a lot harder than it should be, you've got a strong incentive to pause product work and focus on "maintenance" work.

When almost a quarter of the company (15 devs) can both see and feel your contribution to make their lives easier and more productive, you've got a pretty strong political position even if you aren't directly producing product. This is true even if you produce, say, an internal dashboard: you're known as the one dev who took time out to help the 20 sales people sell better (or whatever); you know their names, and they know yours.

[jaymzcampbell]

We have a process whereby people can request a change after a certain period (and team permitting) to allow people to rotate amongst different clients and different work streams. I think it's usually after 6 months on one particular thing you are eligible to request reassignment. Won't always be approved ofc.

[michaelt]

Scarblac's mentions a company that only has 15 developers. That means time spent on internal tooling like, say, improving the CI system has direct benefits for the other 14 developers, all of whom probably report to the same boss.

[9dev]

I’ve done this myself, too. We were building a WhatsApp-based support ticket system, that was the product; for large customers, we’d build chat bots (glorified decision trees) on hourly billing; and internally, we’d have an integrated CRM system and messaging API that other systems would rely on. Over the course of two years, I worked on all three.

[Scarblac]

Yes. About 40 of us are water managent consultants, I write tools for them to use in their projects (based on our products). Also sometimes we do projects where we write custom (water management related) software for customers, as consultants. And we have a few products of our own, mulyi tenant web apps, that similar customers buy licenses for, that I also work on.

[sumtechguy]

Some consulting companies also have software they sell as well as internal things that need to be done. They can have a 'boxed software' that gets 90% of their customers. Then consulting on top for the customers that do not want to do anything themselves or something the boxed software doesn't do. Plus you have internal r&d projects or other things.

[electrondood]

> Is your company selling software development hours (consulting)?

From working with contractors, this bucket also motivates you to strongly optimize for number of sprint points delivered, not quality/reusability/maintainability.

[irrational]

> Is your company selling something else that has a software component or that software enables (pretty much every other company)?

I'm not sure this is true? If my company sells food or clothing or shoes, they don't have a software component. I'm not sure what the breakdown is, but my gut feeling is "pretty much every other company" is wrong.

I work for a company that makes clothing and shoes. We have an enormous tech organization, but we aren't a consulting company, don't sell software, and don't put software into our products.

[toast0]

Your shoes and clothes don't have a software component (well, most don't), but in most producers, software enables their production.

Inventory management, production automation, order management is software at pretty much every company now, because doing it with paper or in people's head is error prone. I imagine your tech organization is in an enabling role.

[OJFord]

> If my company sells food or clothing or shoes, they don't have a software component.

E-commerce? I can't think of any chains without a website, or any large enough that 'company' seems apt that don't sell via it.

> I work for a company that makes clothing and shoes. We have an enormous tech organization, but we aren't a consulting company, don't sell software, and don't put software into our products.

Ok that's the 'or that software enables' isn't it?

[irrational]

I guess we are interpreting the third bullet point differently. I interpreted "Is your company selling something else that has a software component" as something like a car that has software built into it. And, I interpreted "or that software enables" as something like a board game that requires the use of a mobile app (like The Search for Planet X). In other words, the products are not useable without the software. Whereas, a t-shirt doesn't have a software component and isn't enabled by software (though, I could imagine a t-shirt with a QR code that is enabled by software, but that isn't the norm).

[mooreds]

Ah, sorry, when I wrote "that software enables" I meant you use some kind of software tool to help ship your product or service. That could be excel macros, SAP, custom POS systems or anything else. If it is customized or built in-house, you'll need developers.

Sorry I wasn't clearer.

[jeremyjh]

This is an article about software engineering - for software engineers. In this context it should not be hard to reason that companies that do not employ any software people are out of scope. Of course they exist.

[irrational]

But, my company does employ thousands of software people. We just don't sell consulting, sell software to other people, or sell products that use software.

[digging]

You misunderstand. The third group is not only companies that sell software-based products, the third group includes companies that use software to sell their products or manage other aspects of the business. Having an in-house online store is an example.

That presumably puts your company in that group, just like mine (or else I have no clue what thousands of software people would be doing on the payroll).

I bet our two companies have very different reliances on technology, but we're both in the same group, because all of our software supports our sales of our actual goods and services.

[alephnerd]

I'm guessing GAP.

[CRConrad]

Zara, Zalando...?

[alephnerd]

Logistics and e-commerce is a component of commerce (aka selling)

That said, you will absolutely be a cost center.

[patmorgan23]

Not every company hires software developers of course. But every type of business will when they get big enough. They may not call them developers but I bet you have some people doing business process automation that are basically developers.

[OkayPhysicist]

Pepsi's hiring Elixir developers for their backend and logistics systems. Pretty much every company of significant scale realizes they can either save money or gain some advantage from using custom software.

[dver]

Very much this.

What ever is being manufactured, the real product is data for process improvements, improve product quality.

[golergka]

Retailers of all kinds employ enormous amount of data analytics, data engineers and software engineers.

[deadbabe]

#2 is the best because if you can do your job quickly and efficiently you can minimize the amount of actual time you spend working as long as you are delivering the software.

[mastersummoner]

Well I agree with you, there are definitely developers out there who are completely happy with a 9 to 5 punch card type job.

[DayDollar]

Missing the hackernews part of product to research and development,: Is your company planning to use the exponential growth nature of software to enter into a overlooked niche or rapidly take over a existing industry? In that case, product development does not really catch the situation. Cause using the situation, closing time window till competition appears or funds run out, is way more important than the product or its quality

[shermantanktop]

Seems like a variation of #1 where the rewards are probabilistic and lumpy. I agree that the motivations and resulting behaviors end up pretty different.

[golergka]

> Is your company selling something else that has a software component or that software enables (pretty much every other company)? In this case, you'll be valued for your ability to deliver on or below budget and you'll never be the star of the show.

Trading companies are one of the very innovative in IT and offer software engineers salaries that are higher that FAANG.

[michael_leachim]

What category is Amazon? (the marketplace). It looks like a third category (company sells something else, but it has a software component supporting it).

I am asking because I am working in a company with similar business model and I am trying to figure out what category does my work belong to.

thank you.

EDIT: fix msg

[strikelaserclaw]

I think there is nuance here, even within a product company, not all software is equal. There's software to support core business (think ads in Google) and there's probably software to support internal dashboards (also in Google), I'm sure engineers working in ads in Google have much more leverage than those working in making dashboards for ops or some internal ticketing system. Conversely, I'm sure the companies we traditionally think software is just needed to support the core business also have software lines which generate income or is critical to their core business.

[michael_leachim]

thank you, maybe it is easier to understand

when you ask whether business will halt and die if the system you are responsible for is down or suddenly absent

or

it is going to be a mild inconvenience.

I think, defined like this makes it less ambiguous

edit: fix msg

[mooreds]

> when you ask whether business will halt and die if the system you are responsible for is down or suddenly absent

This is a great way to put it.

I also ask myself the question: "who are the rockstars" at a company. The folks that are celebrated.

If it isn't a developer/engineer, you aren't at a category 2 company.

[michael_leachim]

thank you, I've got something to think about.

[strikelaserclaw]

this is a good way of putting it, thanks, it is also a good way of assessing ones one value to a company (if i disappear tomorrow, will it mostly be a minor inconvenience or will there be a DEFCON 1 response raised)

[nonameiguess]

These categories are nowhere as cut and dry as HN seems to often think. Netflix is an even better example than Amazon. Infrastructure and delivery is certainly somewhat of a competitive advantage, but their product is not software at all. They're a media company, a production studio, a distributor. People like Shonda Rhimes are the true superstars and they get $500 million contracts that reflect that. It doesn't mean you can't have an extremely rewarding, well-compensated career as an engineer there, but you're still not Chris Hemsworth. You're not what their users really care about. Without content, there is nothing to sell, no matter how strong the software is.

Then you have something like a Raytheon. They're a far purer "technology" company than any FAANG other than Apple. Hardware and software is literally all they sell. No ads, no media, no communities. But very few of the products made there are owned by the company. They're made on behalf of third-party buyers, usually the US military, which puts you in category 3 according to this kind of breakdown, but that is extremely misleading. You're not a cost center. The pay tends to be lower compared to silicon valley standards because of government acquisition laws and the huge number of hiring constraints that have nothing to do with technical excellence, but you're still the primary value creator and the military program you're working for will treat you that way. This one is arguably even weirder because the actual "product" of the military is war and the superstars are the soldiers, pilots, line officers. Technology developers are always in a support role, but that isn't any different from working for Apple or Microsoft. Whoever is actually using those products isn't deriving value simply from using a computer. They're doing real world work with it and that work is what they really care about. Technology is always an enabler. Nonetheless, technology developers for the military make a lot more money and have far easier jobs than even a four-star general, so which role do you really want?

[michael_leachim]

100% second this, thank you

it is hard to say almost 99% product is not engineering but what it enables company to do. In a sense this division is psychological: either company cares about engineering and makes it a priority or it doesn't.

I think good proxy would be tooling which company uses, niche languages like Clojure/Erlang, open source activity, well known people in decision making positions rather than specific business type.

[chadash]

Amazon is unique. If you look at their revenue, the vast majority comes from E-Commerce. But if you look at their profits, the majority comes from AWS.

AWS is indisputably a software org, so it's clear that their senior leaders value software engineering. But I think that even Amazon's marketplace sees itself as a software org. From the early days, they always saw software as being a competitive advantage.

[ted6767]

Amazon is a partial monopoly so it depends on where you're working. Your team could be any of the 3 areas mentioned under the same umbrella.

Honestly a good manager will do more for your job than anything else.

[michael_leachim]

I agree that AWS is a software org, I am interested in E-Commerce in this particular case. Thank you for response

[hooverd]

You can definitely tell the difference in priorities for end users between Amazon.com and AWS too.

[jimbokun]

Over the years, Amazon has gone more and more in the direction of the software being the product.

As an immense e-commerce site, the software enabling all the sales was the key differentiator to the competition.

Then they brought in external sellers, making the e-commerce platform more directly a product.

Then of course they started selling the infrastructure directly as a product, as AWS. Which of course relies on software to automate the provisioning, operation, and monitoring of those computing resources.

[michael_leachim]

thank you, so it more dependent not on a type of company but on how the company runs itself.

It can have its main product not in software, but it can bet on R&D in order to outrun their competition.

And the other way around is true too, that is how you get bad software products which somehow always stays afloat because of exclusive focus on sales.

I agree that AWS is indeed a software product, this one is obvious.

[WWLink]

ooOoo I work at the 3rd kind... the thing is, our products have several different major engineering components, luckily we're all treated equally! That can also be a little bit of a downside sometimes, because the software industry definitely pays better at the top lol.

But I'm still getting paid damn well for a job that isn't at a software company. Woo!

[golemiprague]

Many companies has the last two intermixed, some devision create support software for the business and some create value generating software. Think about a bank, creating the system for the back office is not the same as creating the HFT system. Sometimes consulting and in house product is also intermixed. In short, the distinctions are correct but it is not about the organisation, more about the division in this organisation.