Why is it not true for them? Sales are not magic, it is a profession that can be learned. I have seen a lot of companies stating how important is sales, and how unique they are. It can't be true for all companies. It is like everyone thinking that they are above average, it is just not possible.

If your product is software, literally it is impossible that sales add more value than the engineering organization that builds the product. Without engineering organization, you don't have anything to sell. Without sales and marketing, you will also have a hard time. It is collaboration what brings success.

> There's too much focus by developers on shallow things, like fad-following the latest frameworks, on pseudo-intellectualism or technology-purism

This is usually a problem with recruiting. You get what you pay for. If your interviews are about technical expertise and you ignore basic persona-values evaluation and fit to build valuable features, you get that. And it jeopardizes the viability of a company. You need some really good experts, but you don't need everyone to be one.

The distinction is that product development, sales and marketing can act as multipliers in a way that engineering seldom does. A tech company's growth is rarely due to the technical excellence of their product. There are obvious exceptions at the extremes, but very few of us are working for a Pied Piper with some truly amazing competitive advantage in technology.

For example, what would happen if magically Twitter's tech became 50% better overnight? That would certainly reduce costs, but would it lead to any growth? Would the average person use the service more if the tech was better? Would companies buy more ads? Would revenue increase?

Now imagine their product development, sales and marketing teams became 50% better. They could have actual product improvements beyond doubling Tweet length. They could instantly sell more ads. They could increase external partnerships to bring more attention to the platform. They would have all sorts of opportunities for added revenue and growth.

(I cannot distinguish product development from engineering as cleanly as you do, but on sales and marketing...)

Can't disagree more. At least with the definitions I have in my head, this sentence is logically inconsistent with such definitions. Engineering is the way you get non-linear leverages. Sales and marketing, almost always give linear multiples at best.

I feel once you have the "golden goose" leverage delivered by engineering in hand, you start calling it sales because that's the final step in conversion to $$$. Also, that's when the linear multiple provided by sales and marketing is the biggest in absolute numbers.

[But yes, if you call everything you see as "marginal contribution" engineering, and everything valuable "product development", then you tautologically "prove" your conclusion.]

I also think that many people, especially in the tech industry, don't understand the scope of functions included in "sales and marketing". It isn't just sales people calling up customers trying to sell enough to reach their quota. It is nearly everything involved in revenue generation of a company.

Also, given sufficiently large numbers, better asymptotic growth always beats. So this is less wrong when talking about huge businesses.

> Sales and marketing, almost always give linear multiples at best.

Counterexample: Apple's famous 1984 ad.

But I actually disagree with your example. I was expecting something like Dollar Shave Club to be used as a counterexample, where the entire value is arguably produced by marketing.

While I don't have metrics (and it is hard to even define a good metric to distinguish the leverage produced by marketing vs. excellent product development when they exist since day 1), I seriously doubt even Apple's 1984 ad had superlinear boost relative to the $ invested on it the ad had the product engineering was not good enough to sell itself.

In fact, I am not sure if it is fair to say the original Mac is an astounding commercial success relative to other computers at its time, unlike Apple II. I feel the ad was famous for its artistic value and post-hoc success of Apple, not much because it actually sold the product.

But back to the primary discussion, think about it this way: had Mac not been a revolutionary product that carried its weight, would that ad even meant anything? As in could you even sensibly run that ad for any product and expect good performance? (This is especially relevant since the ad is pretty abstract and non-product specific, so it is not crazy to imagine this hypothetical scenario.)

It's really hard for me to imagine or come up with an anecdote where a sales process or marketing initiative has had more than a linear multiplier. It could be 10x, but even that is usually very big. Never exponential, or even quadratic (though in network effect businesses the quadratic amplification via marketing sometimes exists.)

Have you ever started a company that successfully exited? Or managed a product from cradle to grave?

There is another comment in here about perspectives gained from taking on multiple roles. If you can’t think of a single case of a great salesperson adding multiples to a product’s performance, I gently suggest broadening your scope.

more than a linear multiplier

Read more carefully.

BTW, ever heard of word of mouth advertising? That's by definition exponential.

I'm always in an engineering role.

Yet at multiple companies I've implemented A/B testing, come up with ideas for features, implemented them, tested them, and have seen growth of the bottom line in the 10-40% range.

I've heard much from product and marketing at the same companies about the amazing things that they are coming up with and how they will grow the company. I've tested those. Most of the wins don't reach the same range.

Now don't get me wrong. I'm not saying you don't need product and marketing. You absolutely do. But if you listen to the engineers who know what you can do, rather than treat them as cogs in the wheel, you'd be amazed at what can happen.

There's no money in caring about the company long term. Increase in salary for an engineer comes in changing jobs, not internal promotion (which, for places where this is even a concept, is usually constrained by some arbitrary limit, where as job change depends on your negotiation skills and resume). We're optimising for what is successful.

>They're too busy arguing about whether Rust is our savior or how dumb blub programmers are, etc.

I know there are lame fan boys, but many of us are actually value focused and realize that a more powerful language is cheaper across the entire product life cycle. Having said that, I wouldn't feel too bad about using even Java these days because they've added enough stuff to lessen the impact of how awful the language is, that it probably doesn't make much of a difference. But you can't say that about every language, some languages are just too expensive time-wise to make sense in any setting.

I agree that there are limits internally, if your goal is to stay on the "tech ladder". Those limits carry over across companies once you get to a certain point, right around where you hit the "Lead/Principal Engineer" point. Once you get there, a switch to another company is more often going to be for technology and problem domain (e.g. to do something "more interesting") than for a promotion (pay increase). Promotion by job switching is less likely at this point simply because there are fewer positions of these types required.

It's different for a switch to the "non-tech ladder". Even "laterally" (e.g. "Lead/Principal Engineer" -> "(Senior) Engineering Manager") is effectively a promotion: the compensation is better and the leadership is more likely to listen. It also opens up more opportunities up the ladder internally.

> I know there are lame fan boys, but many of us are actually value focused and realize that a more powerful language is cheaper across the entire product life cycle.

This is by no means absolutely true. It depends strongly on the product and the duration of the life cycle, among many other things. Language choice sometimes has a significant impact which can be positive or negative. Most of the time it simply doesn't matter that much.

I am not sure that Facebook creating Instagram Stories to compete with Snapchat is a definitively better solution than Twitter buying Periscope to compete with Meerkat. Either way, you still need someone to think up those new features, communicate them to the public, and sell them to your customers.

But who communicates this to the customer? How decides what features are built (in a larger company)? Who pitches these new features to potential customers?

At a big enough company where the engineers aren't the ones doing this work, the benefits of any engineering achievement is moot if those other 3 groups don't do their jobs well.

Engineering is the key multiplier.

> For example, what would happen if magically Twitter's tech became 50% better overnight?

What if twitter only needed 50-100 engineers?

What if twitter had an ad platform that was as good as facebooks or googles?

If the world had 50% better tech we could automate tens of millions of jobs.

Their IPO will suck because every wannabe big company must have lots of employees to raise more money.

If you don't have a product, you can multiply zero as much as you want, it's still zero. Engineering provides base value, everything else is just build on top of it.

But your product does need some marketing, which is the point I was trying to make.

Marketing does not just "build on top of [Engineering]", they are codependent.

Like software engineering. And like writing software, some people are better at it / enjoy it more than others. Software engineers and good salespeople are very well compensated because they're hard to replace.

> I have seen a lot of companies stating how important is sales, and how unique they are. It can't be true for all companies. It is like everyone thinking that they are above average, it is just not possible.

Most companies, particularly most start-ups, suck at sales. "Great engineers, shit sales" is a more common failure mode in Silicon Valley than "sold something couldn't be built." Also, "good at sales" isn't a one dimensional metric. There are different sales processes, some of which some people (and consequently companies) are better at than others.

> If your product is software, literally it is impossible that sales add more value than the engineering organization that builds the product

You're conflating how essential a step is to a process with how valuable it is. Mediating those factors is how difficult it is to replace the parts in the step. Consider, for example, an automobile assembly line. It would be incorrect to assume that just because the vehicle is useless without an engine, it is impossible for anyone to be more valuable than the person who mounts the engine.

Bad, derivative products hocked by hopelessly deluded people playing startup accounts for most failures. Over promise and under deliver kills even more.

Few truly good products fail because even a bad sales team can sell a good company to a bigger company that can capitalize on the deal.

there are many good engineers, but they are very difficult to replace. in addition, more engineers does not always translate to faster delivery, so there is a natural limit to how many should exist to build out a specific product.

there are also many good salespeople and they can be trained in much less time and there can be many more of them.

This is probably the most "I'm a technical founder and I have something to say!" thread I've seen here in a while.

These engineers tend to find themselves well compensated. They aren’t representative of most coders in the Valley. Similarly with salespeople, you have lots of meagrely-compensated glorified customer service people and then people with difficult-to-replace relationships.

Anecdote as counter-example: a previous employer was approached by a vendor which offered a solution developed by "former NASA specialists" (I think it was to manage inventory). The total cost of deploying it was around a million.

We tried hard to stop the executives from going ahead with it, but around $400k had been paid by the time we managed to kill the project when it became clear that a. the vendor did not actually have a product and was using us as the R&D guinea pig, taking advantage of the data from millions of our customers and b. the "NASA" part referred to one of their developers who had briefly interned with a NASA contractor.

So, the sales organisation managed to "create" $400k of "value" (in the sense of hard revenue in their bank account) without engineering being involved.

Yes, it's called "fraud".

Though IMO the mercenary freedom exists only in theory as the true freedom which makes it worth it is blocked by the inane interview processes that develepers impose on each other. There is a dissonance in the way technical skills are supposed to be some sort of objective measure and the moat digging this culture creates. (It specifically allows in only a certain class of "technical")

Though taking a few steps back these are all first world in first sorld problems. :/

For example, one team has spent several weeks and thousands of dollars to get another team's SOAP integration working correctly, when it would have taken five minutes in REST.

The codebase did not follow a "elegant" practice and is an absolute spaghetti mess. Things that should take 30 minutes take one week and this add tremendously to personnel cost.

I agree though that working together is tremendously undervalued. A decently smart person can be taught anything (which is part of the replacability problem you mentioned), but how to not be an entitled ass is nearly impossible to teach in a workplace environment.

This'll probably come across as depressing to most of the engineers in the audience, but I don't see this as an example of a company that did anything wrong. Rather, it's a company that did everything right but did it too early. They followed the fad of the early 2000s; there was no way to know then that a better fad would come out in the mid 2000s. And they're still around (and a "large corporation") now, which indicates that from a customer & business POV, they've actually been more successful than ~99% of other technology companies founded in that era.

If you're successful, you too can get to have the kindergartners of today complain about what an idiot you are. That's the best-case outcome, though: more likely, nobody will use your code or it will be thrown away a year later for the newer, shinier fad.

(The more positive spin on this is that our industry actually is making progress, and quite rapidly. What other industry can you look at the best practices of 15 years ago and say "What idiots we all were back then!"?)

Things taking a week when they could take 30m is your company paying interest on that debt. To determine if taking on that debt was a good idea you need a lot more context. e.g. the Cobol mainframes that run the financial system are difficult and expensive to maintain, but it's still cheaper than the alternative: rewriting those systems.

Most startups take on massive amounts of tech debt because it helps them move faster and the company not failing is way more important. Once a company is out of startup mode it should balance goals a bit more thoughtfully.

We should print this and hang it on every wall of every room in which a piece of code is written. It is the most misunderstood and misused concept of Software Engineering.

I think you mean undervalued.

If you have a sucky multiplier of course your product won't do well but if it isn't technically executed right you still have a zero.

It is a radical proposition that a farm day laborer adds more value than an elite tech worker because 'the system would stop without food'.

The value add is controlled by the person who decides what "value add" is. That is the executive, original product designers and customers (who may well be represented by marketing in some businesses, I dunno).

http://www.cornandsoybeandigest.com/are-1000-acres-part-time... “One of the most difficult factors for many 1,100-acre or less farmers to accept is that, unless they have livestock, they're probably underemployed. Thirty years ago, 1,000 acres was enough to support Dad, me and three hired men. ... As one industry sage puts it, “It's not the 1,000-acre farmer that needs to worry. They can still support themselves with off-farm income. The guy who needs to worry is the 3,000- to 5,000-acre farmer who knows he needs to reach 10,000 acres if he wants to stay in business.

But engineering and sales for a single product are inextricably linked. If engineering does not create a good product, that directly affects the success of the sales people; and vice versa if the sales team sucks then a great products potential value can go unrealized.

Are they under-represented and under-valued? Probably. Just like IT, they only get noticed when things screw up or go wrong.

Well yes, if we make completely baseless "normalizations" than that's true. Obviously, there is no reason to do that, but sure, if we do it that's the result.

Sales and marketing impact is immediate and falls off over time while engineering's impact is slow and can speed up over time.

The problem is trying to scale that product once marketing and sales do their job. I think the value of each of these 4 changes depending on the company size and tend to normalize to 1 as the company scales to the size of Google, Amazon, FB, etc.

This is possibly the most HN thing I've ever read. Bay Area developers are under-compensated?

Wages are (very purposely) not an efficient market so a group making more than most doing the same kind of work does not mean said group is overcompensated. It could be that the entire group is under-compensated, some of them just less so.

Seriously, discussions like this just show how out of touch sometimes this crowd is like.

That's also true of marketing, sales, and product development.

Takes sales for instance, sales is knowing your clients needs, and knowing how your product fits into those needs and then having a shit load of conversations about how your product fits clients needs. There isn't any magic. You can contact more people, and you can convince a few percent more people to buy your product.

This represents a fundamental misunderstanding of how sales works.

As others mentioned, product/sales/marketing/etc can all be replaced just as easily as developers.

However, and I think this -may- be your point, the work generated by those groups is understood by upper management as a key to success, whereas upper management likely does not understand that having the best tech is also a key to success (and, honestly, it's one that can many times be partially overcome by sufficient marketing, or overshadowed by bad product people, or...).

I think you could have left off the "as a key to success" part. Software engineering, as a discipline, is very hard to quantify and hard to understand. Every metric that anyone proposes for measuring the output and quality of work of a developer has largely been shown to be possible to game and not representative of good work. We wax poetically about an extremely productive day in which we got rid of 200 lines of code...no sales person would consider losing a customer to be a success, so you can see how that would sound confusing to a non-engineer. And the interview process is largely lampooned for asking questions that have very little applicability to the actual work being done and, yet, no one can agree on what questions a good candidate should be able to answer. Even engineers can have vastly different stances on what constitutes good work.

There's an old saying, "that which cannot be measured cannot be managed." A sales team can easily be stack ranked and their dollar value to the company measured to the penny. A marketing team can be judged by engagement numbers, inbound leads and other quantifiable results that are easy for an executive to understand. A product team's output is somewhat harder to quantify, but executives usually do take the time to understand their product and customers, so they can relate and have opinions on the work produced by the product team. Meanwhile, the engineers spend they day looking at text in another language, having conversations and arguments about bizarre made-up words like Hadoop, Riak and Mesos. They often have trouble communicating technical concerns to non-technical members of the team, including management. And seemingly simple changes in product direction are met with large time estimates and mutters of "redesigning the schema" or "scalability."

So executives decide to focus on optimizing and rewarding the departments that they can understand and engineering gets seen as a black box assigned to someone somewhat technical who's often only good at spin/messaging and not really a great technical leader. It's pretty undeniable that engineers create value. Even executives realize that. But the marginal value of one engineer over another is extremely difficult to know, even for people in engineering. So it's much easier to just assign them to tiers (SSE, Senior SSE, Staff SSE, Lead SSE, Architect, etc) and then treat them as fungible quantities.

Let's take a ridiculous example, but if someone were to offer me, say, $1m (a year) to work on a specific key niche project (i.e. something that fits within my skill set and where I could add tremendous value) then I would happily move wherever around the world.

Pay more -> you'll probably get a (significantly) higher amount of qualified applicants?

If you offer $1m per year (which is a ridiculous premise from the get go), you'll maybe get more good candidates (though a lot would assume there was something weird going on and would balk), but you'll certainly also get way more bad candidates, including many who are cunning and able to take up a lot of your recruiting bandwidth, and maybe cunning enough to actually talk their way in - making your problem worse.

It's just too simplistic to assume that throwing money at the problem will solve your talent problems.

Labor is a market exactly as any other: paying the highest price does not always get you the best quality but paying the lowest price always ensures you don't.

In any case, I think always is close enough to fit. Yes, sometimes someone gets something very cheaply but that's usually because of ignorance or urgency from the selling party, deception, etc., etc. In a natural market interaction, if you're paying bottom dollar you are not and cannot be getting the best quality (unless you are in a scenario where the offering is flat: the best offering is also the worst).

Yes: that is what he is saying.

> always is close enough to fit

No.

It is very unlikely to hire top talent at scale, but it is still possible to hire top talent occasionally even for below market rates.

Those who get kick out of these technical challenges are willing to do it for nearly free - we only gotta make sure, their other needs are taken care of.

https://www.theverge.com/2017/2/13/14599186/google-waymo-sel...

That said, the people Google was after probably didn't (really) want to work at Google, and needed convincing. Plenty of people prefer working on their own projects and couldn't care less about being employed by Google, but will forgo that for a "sure thing" payday (and there is nothing wrong with that). Business transaction like any other.

I'd wager that if developers renegotiated their contracts at the point where they were most irreplaceable on projects they would be able to extract a lot more money.

I'd wager that most executives would rather pay 5 people to do the job of 2 or even simply bury their head in the sand and not admit to themselves that replacing you is going to be more costly than let you have that kind of leverage.

This statement is laughable. In almost 99% of the companies out there 'product development' is simple a placeholder to describe people who look at the results of A/B testing and say which design to go with. You could supplant a child in their position and it would barely make a difference in any value created.

Product development is the place where MBAs go to retire and for all practical purposes add 0 value to anything real. Mostly its UI designers who suggest ideas. Engineers implement them, a data analysis team crunches data and finally presents it in a pie chart. All the so called product manager does is look at which parts occupy a bigger chunk and make a yes or no decision.

If have your own business and write your own code, then you get to pick what you want to learn and use and stay with just that. And maybe you already know enough. E.g., if some parts of Microsoft's .NET are enough for what you need to code and you know it, then why rush off to Linux?

E.g., for my startup, I typed in 100,000 lines of typing with 24,000 statements in Visual Basic .NET; it all runs. And I know a lot more in computing but is not popular now. From just what I know, I can't be hired as a programmer, but I have no trouble programming for my startup.

Okay, slash your engineering staff and double the sales people and lets see how you do.

How is any of that not done by thousands of other people as well? Especially sales.

I don't think it's possible to make general statements that one is harder than the other, because it depends very heavily on the person involved.

Rockstar salespeople are just as impressive in action as rockstar developers.

As an example, my company uses Django and the first 6-8 months I have spent hours debugging what would be a stupid issue like misconfigured Django or missing url. Eventually, that led me to optimizing the version of shell_plus that my company was using improving its bootup time by 200%(this was a rather large codebase). That's an instant 200% gain per developer/per django shell load and is probably the most impactful thing I've ever done. We estimated it would save around 6.67 hours of developer time per day(2 minutes saved - was originally 2.45 * 200 developers * 1 shell load every day)

In order to do this, it was maintaining a map of {appName: [list of imports]}.

When constructing this map, for some reason, it n^2 the imports - i.e., if an app "foo" had models "Bar", "Foo", "FooBar", then the import strings were, "from foo import Bar; from foo import Bar, Foo; from foo import Bar, Foo, FooBar" instead of "from foo import Bar, Foo, FooBar". Some apps had 50+ models, so instead of 1 import line for these 50 models, it was executing 2500 import lines. I fixed this so that it executed only one import line instead n^2 import lines.

Am reading "Deep Work" right now. In it he touches on this while explaining how hard it is to measure, and how no reliable attempts have turned up by those who try. This applies to C*O level on down, no one is sure how to measure this.

So when you write:

"The same just isn't true of product development, sales and marketing."

I call BS. There is no measure out there that can accurately gauge the specific contributions of an individual or a team within an org, in knowledge-centric work these days.

There are outliers. A team will luck into a bigger than expected sales deal. Or engineering stumble into a way to provide the same performance with less servers.