Real-world:<p>- you increase value; your bosses team up with each other and claim the credit; you might even get booed for some minor deficiencies whereas they will be boasting about their achievements<p>- you are generous and do non-AGPL based open-source; parasites are waiting in the open, incorporate your code to their commercial offering, never paying you anything; your bonus will be rude complaints about bugs in your code in your issue tracker<p>- you work for minimal salary and generous equity; when push comes to shovel, CEO will kick you out of the company due to "company problems" and claim your equity; bonus to the threat to your existence will be burnout from overworking and lack of credit<p>- your company creates a new opening for a lead position in your team for which you are the primary candidate; managers of other teams privately ask you if their friend can be pushed to your manager as the "one"
<i>> This is why I struggle with scenarios where people discuss pay and work without considering value.</i><p>Counter-point: firms exist.<p>If I'm the one figuring out how to create value, why the hell are the C suite, middle managers, and investors getting 99% of the profits?<p>So no, in the context of a large firm, it's definitely <i>NOT</i> an engineer's job to figure out how their skills align with market demand. And that's the <i>whole damn point</i> of a firm.<p>Now, this may be reasonable advice if I want to maximize by income. But maybe my goal is to maximize income <i>under the constraint</i> that "my excellent engineering" is the primary consideration in my performance evaluations. And there's nothing wrong with that; people trade income for all sorts of things. Telling someone not to make that trade-off is like chiding them for buying an expensive latte or sending their kids to an expensive private school. It's not your money, so it's none of your business.<p>edit: And, furthermore, the success of large firms and the high compensation available at those firms suggest that the author's advice might actually be actively harmful. As an engineer, you might actually be better off ignoring engineering-value alignment because you might be better off simply executing well within a well-oiled machine.
I completely endorse the suggestion that engineers should learn to understand this concept. If you learn one thing in your career, it should be this. One of the differences between working at BigCorp versus working at SmallCo or VentureCo is that in the smaller companies the relationship is much easier to trace out.<p>Dan Warmenhoven (when he was CEO of Network Appliance) had a wonderful way to very clearly explaining this in an accessible way. From gross margin to net margin to the fraction of the margin that was allocated to engineering.<p>But the other concept, on-off splits, is also something which I think <i>managers</i> need to understand a bit too. When I was at Google their compensation system tended to unfairly bias toward people delivering features and I and others argued for recognition of people that made delivering those features possible (which finally came about in 2009). As a manager you have to recognize when someone on your team or in your organization is helping the whole team work better or get more done. Whether that is an administrative person who is keeping things in the group calendar current or a tools engineer who is keeping the build running smoothly. If you're lucky they will be sick for a week and you'll see the entire organization hiccup as it adjusts. I say lucky because that will give you visibility into their contribution you might not otherwise have until it is too late.
I sometimes wonder if the vulgarity of capitalism forces us to think this way. You don't see lawyers, doctors, or capital-P engineers thinking this way. They have to think about the state of the art and practicing their craft with the utmost attention to detail. Anything less would be unprofessional.<p>And yet we programmers hear this story time and again: you don't matter, your craft doesn't matter: _all_ that matters is getting that money. If that's what your company values then that's what they'll make you do... and we don't have any profession to back us up when we say, "That's not good enough."<p>I suspect this is part of the story of how the Equifax's and the like happen: we prioritize profits over integrity and the consumer pays. If you, the professional software developer, refuse the company will simply find someone else who will. And they will probably hire them for less.<p>And yet if we were to raise the bar, stakeholders argue, then programmers would not be affordable: producing software would be too expensive and nobody would do it.
If you pretend simple economics is best representation of reality then this blog post is exactly on point, in a perfectly efficient market the value you earn for others is proportional to the profit you get in return and both are proportional to the good you do in the world.<p>Simple economics are not the best representation of reality.<p>For many pride in one's work can matter more than pay, the engineering profession attracts some of the most passionate do-gooders (Gates to name a famous example) who care about the world improving. They aren't usually recognized for it because they try to improve the world by fixing the systems rather than flying to a 3rd world country and building a house.<p>Additionally, in reality but not in simple economics, there is a huge gap in value-generated for the company and <i>perceived</i>-value-generated for the company. In fact, there can be situations where the two are negatively correlated and the engineer knows best.<p>Finally let's remember that short-term value to the company isn't the end-all-be-all. Did you know Zynga had some individual users who spent over 100 grand on virtual items? Great companies often arise by ignoring the short-term-profit and focusing on delivering a great product with a great experience, even if the market for it doesn't exist yet (i.e. what google did)
"We get our money from customers" doesn't actually cover many other very real use cases. Let's try:<p>- We get our money from bosses who want higher headcounts to justify their position.<p>- We get our money from competitive poaching, so that if GOOG/MSFT/FB has us the other firms don't.<p>- We get our money from salespeople tricking customers into buying our products. This deception is easier if the products actually meet a need, but that isn't <i>required</i>.<p>- We get our money from VC firms playing pyramid games.<p>- We get our money from government grants that need to get spent or funding gets cut next year.<p>- We get our money from grants that have to be spent to show investment in "innovation" or "modernization".<p>- We get our money from selling out users to drive advertising clicks.<p>- We get our money because...BTC is stupidly volatile.<p>~<p>It's extremely <i>naive</i>, in the modern economy, to say "herp derp just deliver value to customers and you'll get paid what you're worth".<p>EDIT: Nice downvotes. Again, consider that maybe the modern economy is so twisted and weird in software dev that maaaaybe this simple Protestant work-ethic narrative doesn't actually hold water. Sorry to burst your bubble.
This smells like a straw man argument. Most of us don't have pie in the sky ideals about perfect codebases. we have practical, hard won expectations of a work-person like codebase and we want to build to that standard - not some higher perfection ideal. And being prevented from having good engineering by "get it out the door no matter what" is frustrating because 99.9% of the time that leads to crap service, overruns, and more crap work on top.<p>the exceptions like say "move fast and break things" are ... exceptions not the rule. your company is not a facebook like special snowflake and using the snowflake argument to drive poor engineering decisions just makes you look silly.<p>one essay i remember from ages back on Joel On Software was him describing working at a Jewish / Israeli bakery. the bread oven was rusty and broken on the outside and looked like crap. but inside it was spotless stainless steel, because the bakers knew that the inside was what counted, and any money spent polishing up the outside of the oven was just waste.<p>that is an exeellent way to see the software / value argument - you have to know where the value comes from, and make that part fucking perfect. the rest can just be hung together with string.<p>Any disagreements on which part needs to be perfect is really a misalignment if understanding the business
"If you want to increase your compensation over time, continue to put yourself in a position where you can deliver the most value."<p>This assumes an efficient market. In the real world, however, value of a software engineer's output is really difficult to measure. Indirect value (like helping a team member) is even more difficult to measure than direct value (like implementing features or solving bugs and so on).
This is really dishonest and disrespectful to people. Most companies are dictatorships, where all of the profits that come from maximizing value to customers do not go to employees. Employees have absolutely no say in it whatsoever and in fact are paid for their time for the sole purpose of not sharing profits with them.
> If you want to increase your compensation over time, continue to put yourself in a position where you can deliver the most value.<p>Implied in the article but not stated: it's not about how hard you work. Working hard has nothing to do with it. Nobody cares how hard you work. It's about what value you provide to the company.<p>Work smart, work effectively, not hard.
The claim that "we get our money from our customers" is, on its face, wrong. Of course we're paid by the company, not the customer. The simple truth this article misses is that your wage is simply the price of your labor, and it is the firm that is paying it. The "value you add for customers" (however that might be measured) really doesn't come into the picture. The job market is competitive, and the amount your company pays you is primarily determined by how much they would have to pay someone else to do the same job.
The customer pays the company for some perceived value. It may not even be real. But given that it is, the Engineer may contribute to the process, or the testing, or the coding. Which are useless to the customer and not even perceptible. Consider: if the same product were delivered without testing, would testing be valueless?<p>No, its the whole enchilada that the customer pays for. The Engineer is a part of the product but so is the guy on the loading dock, and in the mail room, and sweeping the floors.<p>No we have to look elsewhere for compensation justification. This religion (born out of the Agile process?) that only work contributing to customer needs has 'value' has got to go. Its false on the face of it.
Fellow engineers: your (loose) money comes from overcapitalized companies fighting for talent that can multiply their investor's bets or, at least, their investor's hopes.
I'm pretty surprised to read this. I did not observe any statistically significant correlation between "creating value" and "compensation". The examples are so overwhelming I feel it's on the OP to exemplify his rather false assertion:<p><pre><code> - Big corps pay loads of cash to research centers that provide exactly zero value to customer.
- If you don't man up and negotiate no one will bump your compensation just because you're "creating value"
- Creation of value is so vague a term it's practically meaningless
</code></pre>
This goes on and on.
corollary to some of the points made in the post:<p>- to understand one's value in $ terms, it needs to be measurable in some way.<p>Some possible ways to measure:<p>- for a product already being sold to customers, my features are helping retain customers (bug fixes, performance improvements etc) as measure by A/B testing or sales guys saying "that fix landed the sale".<p>- for a product not yet being sold, my performance in building the product is helping time to market as measured by improvement in sales and marketing results : "we landed a field trial today with the features I helped implement" or "those demo videos have improved response to our marketing campaign"<p>- for work in a large company, my performance helps my organization achieve some stated goal by its general manager. As measure by : "we got that thing done the GM laid our last quarter, his meetings with upper management were very positive and landed additional funding to the project"<p>Interestingly, for each of these, value in terms of $ gets more and more difficult to measure.<p>in my experience, working in smaller companies, value is much easier to understand, but the work tends to be "everyone sweeps the floor".
In larger companies the work tends to be more specialized - and potentially more "cool" but driven by harder to pin down dynamics of the larger corporation organism. It also tends to be more "maddening" as the organization flip-flops around trying while seeking extremely difficult to attain growth.
The value I can deliver is strictly limited by the sales department these days. In the last four years, I have increased the value proposition of the business 100x-1000x (hard to know for sure, but not less than that) with my team's contributions (team of 2), yet I have not gotten a raise. No matter what I do, if we don't sell more, the value does not increase. So why should I care about the value I'm delivering when it does not affect my pay whatsoever?<p>Let's face, it almost all jobs are like this. Certainly all startups that are running on others' funds. Certainly all big corps. The author here is talking about a very small percentage of companies where individual contributors can actually contribute to the value of the company and the company reciprocates in value to the employee (pay). The one company that I worked in where this was the case, gave decent single digit raises. Hardly commensurate with value, but not bad.<p>In other words, there's no reason to focus on value provided for an employee at most companies because such focus is either unrewarded or almost unrewarded.
Tangent: had a similarly disappointing experience with Coinbase. Not worth going into details, but I walked away feeling like the application wasn't taken as seriously as I would have expected.
A question I have always asked. The answer can be scary because often it isn't "from customers buying the thing we're making", not even close.
> If you want to spend your life crafting beautiful code with headphones on, you can absolutely do that. You will get paid just fine for that. But if you’re not influencing others and helping the broader team execute, you’re setting a ceiling on the degree to which you can contribute to the company’s output.<p>How does building a stable, easy to maintain, extensible product not help the broader team execute?
"All you can contribute is what your own two hands can code."<p>The value of which has no obvious bound. The failure rate of software projects is huge and each failure can easily cost millions of dollars, or much more if it amounts to a product failure or business failure.<p>A single engineer's technical choices can easily make or break a project. It's hard to tell later which were the crucial choices, though.
> This is why engineering career ladders start to layer in responsibilities for things that a single individual can’t accomplish themselves. This doesn’t mean you need to become a manager, but it does mean you need to look beyond yourself to maximize the value you’re able to bring to the people who are ultimately paying you.<p>This is where I am right now. I've been a dev professionally for 2.5 years, and I'm looking ahead to what it will take to become a lead and eventually a senior engineer. I notice other senior engineers around me continuously providing value to those other than themselves: in the form of contributing more documentation, directing and organizing design meetings, and in general taking time to gather others to solve a recurring technical issue org-wide, once and for all.