Careers are made or broken on whether you get to be an idea person or an implementer.

If you're an idea person you get the lion's share of the credit for anything that goes right, and can always blame your failures on the implementor. Plus ideas are easier to come up with than implementations.

If you're an implementor you work hard, and then don't get much of the credit. But without implementors you simply don't have a product.

I've met FAR more competent implementers in my life than I have product owners. You seem (and others) seem to be arguing that there is some sort of market inefficiency here, but I don't see that.

And I say that as an implementer.

Well, bad ideas are easy and plentiful, and then execution is hard and everything.

But good ideas are hard, and then execution is routine.

By an "idea" Doerr meant just some short, off-hand statement, say, at a party or over the family Sunday dinner table, some summary might tell a neighbor over a back fence.

A good idea, however, may come with a stack of solid background research on the market, the problem to be solved, and a really good solution, say, the first good or a much better solution, with good barriers to entry, etc.

Here's an approach: Pick a problem that so far is solved at best poorly but where the first good solution will be close to a must have for enough people and revenue per person to make a successful business.

Then find a good solution. The solution might have secret sauce which was needed to solve the problem (why the problem wasn't solved 10 years ago) and that can also be a big barrier to entry.

It would help a lot to exploit current, comparatively dirt cheap, computing. If you write all your own code, then likely you don't need co-founders.

Venture capital won't much help because by the time you have enough for the VCs to write you a check, you will already have enough in traction that you can monetize to have enough revenue that you no longer need, want, or will accept their check, BoD, term sheet, vesting of what you already own 100% of, etc.

The checkbooks of the VCs were important when a Web site startup needed to spend big bucks with Sun Micro Systems, Oracle, Cisco, etc., but those days are over. Now the prices for such things are WAY down and the checkbooks of the VCs much less important.

But still, even among implementors there are frequently disagreements on the design that should be followed. And you see the same pattern. The person who wins the disagreement tends to get a lion's share of the credit for improvements, and often gets to skip blame if it fails.

If you win several of these in a row you may get offered a raise and title of architect.

At another level, I’ll admit that most founders I’ve worked for have excelled more at promoting their ideas, raising money, and hiring talent — top talent, no small feat! — than product ownership. In this case, the lieutenants who make the gears mesh and not jam are the heroes to me.

I can have five ideas before lunch with time to spate on blaming the people who will actually implement them for the past failures of my "great ideas with poor implementation"

But engineers/implementers who get into politics have a huge advantage: they can produce proofs, especially in tech. Nothing is more scary for an executive type than an engineer who refuses to be bullied into accepting the blame.

Be technically right, hunt the information that will make you correct business-wise. And you will be able to make a much stronger claim in the blame game that the guy who is just business-right.

That said, I've met quite a few implementers that seem to believe that because it's their hands on the keyboard, no other activity warrants credit, all the way down to the guy who thinks that he commands "respect" (in the gang-sense) because he can shut down the Exchange server.

It is one thing to take an idea to market when you are selling for companies like IBM, Accenture, Google, etc.

But when you have to sell the same idea on your own, that takes real skill and hard-work!

Mostly this is a self-inflicted problem. Especially in the Bay Area, where developers tend to value CS ability signaling rather than the ability to work well with product teams and the ability to engage in practical engineering.

There's too much focus by developers on shallow things, like fad-following the latest frameworks, on pseudo-intellectualism or technology-purism (e.g. "coding is doing math", code "elegance", whether/how FP is just so much better than anything else, etc.), and trivia like programming language choice.

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.

No. We all create value. Businesses, when running smoothly, are like a well oiled machine. Nothing is redundant. Garbage is collected. Businesses is cutthroat industries cannot afford to be redundant.

I always wondered why all cars had 4 wheels. Turns out, the 3 wheeled car is horrible (see Top Gear), a 5 wheeled car is pointless, and a 2 wheeled car is a motorcycle. But when you're a kid, compact jet propulsion or anti-gravity doesn't seem so difficult. But that's also why you're a kid.

I started a business thinking everyone can be their own executive, worker, and entrepreneur. They could handle their own responsibilities, manage their work, and do that work. Unfortunately, we had to go through a lot of them. Utopia wasn't working, but they were also miserable. It wasn't what they wanted, expected, or enjoyed. They all loved the idea though, including myself.

Fast forward five years, and my car has 4 wheels. I am the "founder". I decide where the business should go, lay out the work that needs to be done, and hand it over. The "executive" is then responsible for that work getting done. They hand it over to the "employees" in a way that is efficient and accountable. The third group just needs to accomplish the tasks they promised to do for the money they agreed on.

I'll see your scumbag executive and raise you my wrench throwing employee and delusional founder -- that would be me. I'd like to think 4 years ago, but who the hell knows.

If you wish to manage responsibilities, join the managers. If you wish to drive the ship, join the founders. And this is your correct career path.

An employee who believes they are better than the founder or executive is already holding a wrench.

I can also relate to the notion that the engineers do all the work, which was a sentiment I shared early in my career before I understood the kinds of problems executives and founders had to solve. I cringe when I hear an executive say "How hard can it be? Get some bright bulbs in here and have code up a solution that doesn't have these problems." or when an engineer says "The CEO just parties with 'investors' and blows sunshine up our ass while we actually build the thing he is gets credit for." or when a founder says "I wrote the foundation this company at a dam hackathon in 24 hours and you're going to take 6 months to have an alpha release?"

I have seen again and again that people who haven't been in the role they are criticizing have constructed an understanding of it that doesn't capture what the actual role entails. Or in the the crowd funding case completely under estimating to cost or effort to do some aspect of development they have never done before.

If the company is hitting its milestones, people know what they should be doing, and the problems that pop up all seem that they can be overcome. Then you know all three classes of people are doing their jobs well.

When things take forever to get done, nobody knows why or how the thing they are working on fits in, and every week there is a new problem that changes all the priorities and efforts, then you know you're on the way to being dead as a company.

This adds to a lot of the bad feelings. Some people are great at marketing, but if you work for someone mediocre then it's easy to see how you will think they are worthless.

It is easy to sit around as a dev and complain about what the suits are doing, when the devs do all the work. I don't think the same devs would be very happy if they switched jobs for a day (and in the same thought, I don't think the suite would do that well coding either).

(Edit: I have only done the dev and founder role here. But I just had about 10 executives tell me what kind of treats I was in for. I believed them, just from what I had learned in two of the roles).

The point is, what works works, and if you're forced to make things work, before you know it, you'll find yourself looking awfully similar to those in a similar situation.

There is a reason why these business structures are so common.

They work.

You can tell because when confronted with an alternative that works and is viable you get the age ol' "Yeah well anything is possible"

Of course, what is current was also possible, you're ignoring the fact you're buying into the current dogma and repeating it.

Maybe, had I bought something.

I did not buy my corporate structure. I built it.

It sounds like you're saying all cars have four wheels because everyone is buying into the current dogma and repeating it.

I'm saying, if you're building a car from scratch, there is a high likelihood you'll arrive at four wheels.

As a matter of engineering, certain structures are common for their physical and functional nature. The more specific the parameters of behavior, the more specific the implementation.

Also, not all cars have four wheels, not all cars are gasoline powered, mechanic evolution is quite infantile whereas static business operations are not.

I would argue that also the industrial business ops are still infantile as well.

Just more sales.

unabst did try "other things". Did you read the thread?

Enough people have left because of it that the bloom is well off the rose.

But if you just need something that works, copying a wheel is easier than reinventing one. Better yet, just buy one.

Furthermore, understanding the reasons why the most common wheel is what it is will provide invaluable insight into making a better wheel if it comes to that. It will also tell you the market forces or anything else at play. The reasons why anything works will exist and be real, if that thing that works exists and is working already.

You may like Eric Dietrich's book Developer Hegemony[1]. He talks about both why the third group is less successful and how people within that group can potentially improve their situation within the current system.

> I have found that the executive path is actually the one that most of the scumbags take, it is the one that attracts the most people, and those people are usually not likable, they're salespeople that sell themselves all day.

I've seen the sliminess as well, but regardless of how ethical you are, in order to be successful in any domain you must be prepared to defend your interests (which people might perceive as "scumbag" behavior) and convince others that you have something of value to offer them (i.e. "selling").

I think it is possible (though difficult) to be both successful and moral, but success isn't everything. I think certainly possible to have a fulfilling life and not be successful. But (and I'm not claiming this applies to you) I would caution people in general against getting stuck in the rut of telling themselves that they value things other than success and at the same time resenting those who are successful.

[1] https://www.daedtech.com/developer-hegemony-the-crazy-idea-t...

Are you able to provide a cliff note or two about why they are less successful and how to improve their situations?

"Sociopaths, in their own best interests, knowingly promote over-performing losers into middle-management, groom under-performing losers into sociopaths, and leave the average bare-minimum-effort losers to fend for themselves."

What to do about it? These things:

* recognize that as software professionals we own the means of production

* learn the business side of software

* form partnerships with other developers such that the distinctions between worker and owner, suit and techie, no longer exists

* shift focus away from developing software according to a spec, and towards being a provider of overall business efficiency (often achieved through software).

Note that this is focused primarily towards developers working in the IT cost-centers of (generally non-technology) businesses.

[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

There isn't actually a way out, on a systemic level. On a personal level, though, you should be very honest with yourself about which of the three categories you want to be, and go after it. People who refuse to accept the trade-offs or deny that there is one are by definition Clueless.

Which is actually what Dietrich is advocating, with a careful caveat: these developer partnerships only hire other Sociopaths (or Opportunists, as Dietrich calls them) insofar as it is possible, and generally avoid growing large enough to need a gooey Clueless middle.

The MacLeod system describes organizations of all sizes, but only reaches its full flowering in large enterprises.

It breaks down the archetypes within companies, talks about what it takes to succeed as an employee or an executive, and then discusses an alternative route that we software engineers might be able to take.

Here's a blog about the book [0] and the book itself [1].

[0]: https://www.daedtech.com/developer-hegemony-the-crazy-idea-t...

[1]: https://leanpub.com/developerhegemony

But organizations today and perhaps in the past have always rewarded those who attain the power. Perversely, if you want a place where achievement (ie doing the work, building things) is rewarded properly, you need someone with that mindset to suck it up and win the power game.

p.s. That was rather negative response. May be it's the ecosystem and how things are.

p.p.s. Good post and stuffs like this should be taught in CS schools.

VCs have limited attention and those who are best at being loudest are likely to capture that available attention - similarly some people try to win arguments by being louder and making more noise than others.

But let's leave that aside for the moment. On a practical level, if engineers are to achieve money and prestige, then they'll have to (and here come several different ways of saying the same thing):

- sell themselves

- play a power game

- play politics

- ask for money & prestige, in all the different ways including dressing and speaking in a way that signals to money-and-prestige-bestowing people that you should get money and prestige

And they will have to concentrate on this and get good at it, apply the tactics & techniques, and succeed. That's how executive scumbags do it. This takes a fair amount of time and effort, so you'll have to spend a lot of your time on it. Nobody is giving away money for free without even being asked. And nobody cares about raising engineers' salaries as much as engineers do, so it's unlikely you'll find anyone to do it on your behalf. You either ask for it until it happens (selling something, selling yourself) or you say "well heck I wanted to be an ENGINEER" and spend your time doing engineering, and don't worry what's in the other guy's pocket. Screw him, he probably has an ulcer and his wife's a harpy!

Given that ten thousand years of human history have utterly failed to produce any system at any point in time where the value-makers are rewarded over the salespeople, I don't think any such system can be made. At least executive positions aren't quite at the level of a winner-takes-all competition and you have a plausible chance of making it to that level.

A lot of technical folks seem to have very little understanding or even interest in what for instance marketing and sales do. There are generalizations and often anecdotal knowledge that passes for understanding.

Developing software is just one small part of the process of creating value. Software does does sell itself. Creating demand and getting customers is incredibly difficult, expensive and unpredictable. If your target is advertisers based on users then acquiring users and advertisers is equally challenging.

As a thought experiment, get the best technical team and develop a product. Now after it is done, then what, how to do make money, how do you sell it or get users?

Next would be Employees. Jeez, those guys are the worst. Always thinking the ship will sink without them. If only the executives would listen to them the company would be on the right path.

Get off your high horse. You look foolish to all of us executives.

Founder is an employee, whose executives wouldn't listen to them.

I can see how it could be easier for you to "tune out", but from the Wozniak's mouse to Nokia smartphone presentations, your smirk is actually exactly correct: Employees make or break the firm. The ship will sink without them. Executives do not sufficiently listen to their employees.

I would though not agree fully about where you assume value is created. Usually, developers / middle managers do not create value. Mostly they are implementing ideas of others and in these ideas is most of value concentrated. I would say they deliver value but don't create most of it.

Perhaps I have a pessimistic view of the industry, but I've worked at 4-5 startups now (4-5 because one I'm on the fence about calling a startup) and I've come to find that the most value was always "created" when the devs and middle management (product) worked closely together to deliver and hustled/bustled without being blocked by some upper management bullshit. As soon as these companies grew, and these 250k-300k a year "executives" joined, everything slowly went up in flames. This is anecdotal, but it's an issue I've come to notice through personal experience in our industry.

It would be awesome if we could get statistically significant numbers of people to report on this effect, although how to avoid selection bias etc. is beyond me atm.

Although we had a CTO that grew up with the company (used to be a programmer there) that reported direct to the CEO at the smaller, now we have no CTO and at least 5 layers in between us and the new CEO.

I was developer, and I was middle manager and I understand the sentiment fully. There are many aspects of reality that higher level management has to deal with which are not usually what they want reality to be but in practice you can not change it.

The issue I see here is that there are plenty of companies that are very successful and have a small hierarchy and very little hoops to jump through.

Yes, it is true that developers writing the software for Google's search engine and Gmail and other products, particularly the early developers who were writing core functionality before it even existed yet, are creating value. But are/were they capturing the full value created? In general, no. To the extent they "captured value" only came in the form of salary/benefits/etc. So they captured some, to be sure.

In highly successful companies who create hugely successful products that create tons of value, the actual capture of that value is absolutely not shared equally. This is in part because the risk was not shared equally.

Just as in successful companies, unsuccessful companies that ship a product that does not do well or fails completely, the developers who created it still captured a salary along the way. The investors and others who put in money or time and energy for little or not pay (in exchange for equity) were the ones with the most risk.

Bottom line... everyone involved in company-building and product-building create value along the way but value capture is generally concentrated for very good reasons.

We all take risk. I could find myself working for a company that doesn't make it, or just decides to fire me at a moment's notice. Losing my job and not being able to find another one means I might not be able to feed and house my family. That's real risk. On the other hand, most investors are pretty well off, and can weather a few startups failing. They're likely not going to get to the point where they don't know if they can continue to house their family for the next few months.

Developer joining a startup risks almost as much as a founder. He leaves his existing job for a promise of a salary, and if this startup fails - is left without a job, and possibly, without a salary either. This happened to me, and I was paid for first 2 months out of 6 I worked there.

> The investors and others who put in money or time and energy for little or not pay

Investors still have most of their money, I am left without a job, unable to pay my mortgage and possibly buy food.

Imagine this: I put $X, you put $Y into an investment. If investment is successful, I get a 100$, you get $Y+$X-$100. If it is not, we both get nothing. Would you consider this investment fair? No sane person would put a money into an investment fund, expecting a fixed value in return, but employer-employee relations are exactly that.

It all comes down to which group the people signing the checks value. I often say "pay is a social construct" and this is what I mean -- there's no objective basis for any of it. I think devs are paid better in the Bay Area than elsewhere just because we're assumed to be more important here relative to other parts of the US/world.

There is no objective reality here, just a bunch of beliefs.

My last gig was terribly silo'd as far as responsibilities go. But people go to lunch and happy hour together. Product dev would call out anyone that contributed, even though their team got the kudos because of process (despite the teams being cool, I left because management was shite).

These things bleed into each other constantly.

It's worth noting that this is simply in the "Tech Industry" which is much different than a "Good Life", "Adventure Quest", "[religion] walk", or any other form of purpose/success-based ranking.

Having operated in all three roles, all are incredibly valuable. Great leaders enable their teams to be more than the sum of their individual members (employees). But I would opine that the leadership roles come with significantly more risk, which is at least partially responsible for the money / prestige.

You could also say that humankind is still stuck in an evolutionary stage where in most places, being dominant is the best signal of "value". In a Tim Ferriss podcast, Ray Dalio actually mentions that disagreements at Bridgewater can take on different forms, because some people are less suitable for verbal, thinking-on-their-feet sort of debates, and might be better suited for long form (like Hacker News threads) debates.

What value is value if it can't be sold? Yes, there's intrinsic value in doing things because they need to be done but most of the work done in offices around the world derives its meaning from its worth to a buyer.

This being so(?), is the employee necessarily worth more, as you seem to imply, just because they are mashing away on tools rather than engaging with buyers or regulators, strategizing, and scheming?

the premise underlying your lament is that we should distribute compensation based on direct contribution to the product. but we simply don't distribute value that way. first of all, how would we accurately, objectively and differentially assign contribution for the success of a business to the contributing members? i'd guesstimate that an average US company might distribute value this way: owners 45%, executives 20%, employees 35%. you seem to be alluding to a distribution close to executives & owners 0%, employees 100%. are either of those correct? what would be the fair way to do it? you'd have to answer that before you can figure out how to get there.

and as distasteful as it may be, the way we seem to assign value _is_ political. we assign it based on an ability to take credit and argue for a larger share. we assign it for cultural values, like bravado and charisma. we don't really assign it for economic contribution, like commission for direct sales or compensation for risk, no matter how much that appeals to our rational economic minds. the distribution of value is exactly based on the political skill which you lament.

how do we change that? well, that's like asking how do we upend the currently accepted social hierarchy. and that's a big question.

Hmm.

Personally, I have tried to take all three paths. I find it creates the largest amount of potential.

Employee Hat: Develop stuff for the day job.

Founder Hat: Bootstrap by night and learn what it's like to be an owner.

Executive Hat: Work up the ladder by wearing the employee hat and bring what you learn as an owner/bootstrapper back to the day job.

Most sales people in IT are employees.

But i'd guess i'd say as a member of the likely scumbag group, i feel like you aren't really trying to see the multiple perspectives here. As someone else said, we all create value. It's rare successful companies can afford to keep people around who don't. It's much more likely "they don't create value in ways that you value", or value that you see. I think one of the things definitely holding you back here is the inability to see it from these other perspectives. You are telling yourself you understand people's motivations and goals (you think they are ambitious and trying to sell themselves to get ahead), but i don't think you really understand the perspective, just your story of it. And you definitely, even in these few sentences, have a clear bias and story about a ton of people.

" i wish it layed out a path of how to build an industry that doesn't attract all those ambitious selfish (executives) people"

I think you need to question your assumptions a lot here. You are assuming that such an industry could exist, or that it would be successful. You are assuming (as mentioned above) that your group is the only one that creates value. If that was really true, do you really believe the other groups would still exist?

Why wouldn't someone, in each industry, already have made a successful company that doesn't have those roles, and because they produce much more value, taken over?

I could believe you don't value what they do, but like the author, i don't believe that deserves the judgement you seem to. Assuming your definition of value is the right one, or better than others, is not a good place to start a real discussion from.

I think you would do well to rely less on personality stereotyping and more on understanding if you want to get to the place you desire (where the ambitious, selfish people you see, aren't causing you the annoyance they apparently do)

For at least a million year, you would have improved your chances of survival by sticking with a physically stronger mate than you are. This guy can beat the wolf when you cant, and maybe more importantly here, he may be able to beat the other tribal chiefs when you cant.

Guess how bad people stick to this habit even today. They literally have a brain forged to command them to do that. In practice what happen is that people will confirmation-biased you, they either gonna find out everything you do well, or everything you do badly depending on how badass you are. They will fill forms and say: "look, here are the reasons why we promoted him".

From what I've seen, even at Amazon which is a big geniuses recruiter - and therefore should be able to crack this problem - (amazon also have a form "reasons not to promote" which, if you're following, is kinda smart but mostly wishful thinking), people get promoted mostly based on the following leadership principle: the guy who's most likely to beat the wolf is gonna be promoted. I've experienced it first hand.

There is a light in the tunnel though. From my observations, I can tell that Amazon, for example, is able to recruit based on skills. Note that at this point, the social bonds aren't made yet which is why it works. This might also explains why you go up the ladder more easily by getting recruited - aka move diagonally. So the best thoughts I've been able to come up with is that, somehow, promotion should try to be like recruitment. Both intuitively and counter-intuitively, I think people should get promoted by people who don't know them, by some sort of recruitment process because we know we can fix that one. In any ways, I guess there is a fantastic startup to be made here.

unfortunately, it is a _whole_ lot more work and a _whole_ lot more stress, and is thus the road less traveled.