- 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
- 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
- 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
- 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"
It just does not work like that. It’s a simple maximization problem. If your ideal is science and engineering and good code then your value will only be recognized by people who share the same ideal and these people are usually not the one distributing money.
If your ideal is making money then you will do everything in the book to make sure that the ones that distribute it mostly distribute it to you. That means taking credit, over promising, transferring blame, sabotaging careers, networking, shmoozing, etc...
Sounds familiar? That’s the ABC of the corporate world. That’s why most large companies end up being steered by incompetent people (Peters principle, IOW the last level you can reach before your incompetence really shows and shmoozing is not enough anymore).
If money is what you are after, either stay in a big Corp and forget about technical excellence or start your business and pray. Or, realize that there can be other form of rewards than money for your excellence.
OP's argument is not a "true or false" proposition. It's a model, and as such it has some degree of correspondence with reality. That correspondence may be low or it may be high.
I think it is a useful model. It has a high degree of correspondence to what I see at one of the big internet tech companies where I work. People similarly situated would be well advised to consider this model when deciding how to spend their time, at least if their goals involve getting paid more.
If this doesn't match your experience, consider that this may simply be that your firm does not work the same way as the author's. It doesn't make you or the author wrong; you're just looking at different things.
They're usually a main contributor and value good code as much as you. They're surrounded by a set of engineers who have worked together for 5+ years. And most of these engineers have followed the manager from one company to the next.
If a company starts treating the group unfairly, they move on to the next company as a group.
Delivering value to stakeholders is undoubtably an indicator for success in business. If your work environment isn't rewarding you for that in a way that satisfies you, then find one that will. If you are delivering value, then your company has to compete to keep you, just as much as you have to compete with your colleagues (and also the rest of the workforce in general) for what ever position it is that you want.
If you're not prepared to seek better opportunities, not only are you disadvantaging yourself, but by just putting up with whatever you're unhappy about, you're also disadvantaging every other person out there like you, by stifling competition, and setting the tone that you'll just put up with whatever bullshit comes down to you from management.
This is not you being generous or them being parasite. BSD type license is not "hint hint GPL type honor code". You need to communicate what you want from others trough the license.
If you use non-AGPL or non GPL open license that's a sign that others can exploit your work for commercial purposes without contributing back money or code.
If you use BSD type license and others exploit it like it was intended to, don't complain. If someone uses AGPL or GPL, but you need the code don't complain. Offer money or code.
If this isn't your jam, the MIT/BSD licenses aren't for you. Go GPL or something.
How about an L-AGPL that so that the source of a component must be published without extending to the whole work?
Or maybe one that requires any changes made (patches) must be made available to the public under CC0, even if you only use it internally?
It's a pity that modified licenses are basically treated like plague spots, nobody wants to touch them. This conservationism prevents exploration of alternative development models.
Uh. No. This is only valid if you interpret laws and ethics as one in the same. Maybe you do. That's fine. But not everyone does.
When I lucked out it was right time, right place, getting noticed, and I saw the opportunity for what it was.
When I struggled I’d busted my ass for a few years with no recognition.
In both instances I’d done the same thing with wildly different results.
- you look around for growth opportunities, and learn that your company hasn't promoted any engineers in the past year
It's completely reasonable to understand and be cautious of the these things happening, but coming to the belief that this encompasses the whole of reality is unfortunate. (maybe that's not what gp meant…)
It's important for engineers to understand that they have options. If you're being mistreated, move on — if people are claiming credit for your work* there are places that you can go where this doesn't happen. You have a skill that is in-demand and under supplied, take advantage of that fact while you can.
* This happens on a spectrum, some engineers have a skewed view about how much credit builders should receive. It takes a wide array of skills to market, build, and sell successful products. The best leaders that I've worked publicly credit "the team" for successes and themselves for failures but this can only happen when the leader in question has high trust in their board and investors.
If it haven’t worked at a terrible place, and you’ve worked more than four places, then congratulations, you won the lottery.
(If you haven’t worked more than, say, six places, you probably have no business telling anybody how the industry is).
I have personally seen this more than a couple of times. The worse I have seen is the CTO having worked for the company for a few years get fired and then his shares diluted away to nothing.
There is a correlation between these types of CEOs and hiring fresh grads. They are more susceptible to this type of brainwashing. Engineers with a few more years of experience having seen this are more wise.
Your company can't charge more than the perceived value delivered, and they can't pay you more money than they charge the customers.
People will continue to use Google to search for pages on the Internet despite all the products Google launches and retires. Millions will send parcels using FedEx no matter what software is used to run it. All manner of corporate games can take place at FedEx i.e. use Oracle or Posgresql. Remove Java, use PHP ... it doesn't matter people will still send their parcels. I know I am over generalizing but the shenanigans make it hard to tie your contribution to revenue.
As a barber, you can only cut one person's hair at a time. Regardless of your customer service, this will limit your impact and compensation. Own a chain of barbershop and you'll impact more people and be compensated accordingly.
This thread seems to dedicated to the annoying cap on individual contribution in a team game.
You have to both create value and proactively take the cut of the profit you deserve.
Giving away code is no big deal. Code is a rapidly depreciating asset and everything you create you will create something better tomorrow.
You give people code to demonstrate what they have the opportunity to buy if they want to make money. If they are stupid they don't pay and you find smarter people who want to make money.
Reality is more nuanced and what can be considered 'value' are harder to tell but overall I think one should always strive for excellence in making values for the society. My experience working in different jobs (most are non IT) is that as long as you can create values, there will be a suitable place for your ability.
He wasn't saying that the business doesn't create any value. He was saying that the people who created the value were not the ones rewarded for it.
"My experience working in different jobs (most are non IT) is that as long as you can create values, there will be a suitable place for your ability."
I think it's easier to fit in if you either don't create a lot of value or you create a lot of value and expect your reward to be commensurate with somebody who who doesn't.
I think developer jobs are a bit different to most because the effects are amplified and the value is hard to recognize. It's possible for somebody who is very good to create a huge amount of value and not have it perceived and somebody who is not good at all to actively destroy value (e.g. take a good code base and turn it into a buggy technical debt ridden shitshow) and also not have it perceived. I've personally seen the latter happen and everybody just chalked up the resultant lost business to inevitable bad luck.
Counter-point: firms exist.
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?
So no, in the context of a large firm, it's definitely NOT an engineer's job to figure out how their skills align with market demand. And that's the whole damn point of a firm.
Now, this may be reasonable advice if I want to maximize by income. But maybe my goal is to maximize income under the constraint 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.
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.
Profits by definition are calculated after labor costs are deducted, so employees get 0% of the profits in salary.
However, take a look at your company's accounts and see how much of the gross revenue is paid out as wages and salary. It'll be a big chunk. There's your share.
Highly compensated managers are taking a share of profit, often quite literally (look at how VP and above positions are compensated). But always indirectly -- you can't tell me a 7-8 figure salary "isn't a share of profit". That's obvious BS. And if my own compensation is a share of profit in the same sense (which, a port of it literally is), then my observation that non-engineers get 99% of that share is still accurate.
Anyways, and much more importantly, this is pretty tangential to my original point. The point is that if I'm an engineer at a large firm, it is NOT my job to do the MBA thing. The entire premise of a firm is that the author of this post is wrong.
Bonuses, profit sharing and raises are all things that exist. So while technically correct, you are actually completely wrong.
The point discussed in the article is very valid: you need to be perceived as "delivering value" - otherwise, your compensation will suffer. That's the whole reason why you earn well working in finance - not because "only the smartest make it there", but because you're very close to the money. The money a quant brings in can be connected to him with a very short line.
The author of that post does understand these trade-offs and is asking the best way to maximize wrt his constraints. So this article just misses the mark.
This is generally the approach for maximizing cash compensation, in lieu of being a highly sought after programmer by Google et al. That and jumping from jobs every 2 years for 20-40% pay increase.
By Value, I think OP is talking about value in the context of an engineers role.
For an engineering, you can create linear value with your amazing code, but as you contribute more broadly (architecture design, mentoring, code-reviews, etc), you multiply the value you provide.
> 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?
That sentiment reminds me of this scene from The Wire: https://www.youtube.com/watch?v=1e10ZPVafUA (NSFW - Language)
Ultimately, I want a profitable product to be a byproduct of my excellent engineering, not have my engineering be just a means to an end, of getting to a profitable product.
In other words, “I want to work for a company that values engineering excellence.” And the reply is something like, “you don’t understand how business works”? It’s true that an understanding of the concepts in the article will help you recognize a good business so that you don’t go to work for a company started by engineers with no understanding of business themselves, but you don’t want to work for someone that has a knee-jerk reaction to bringing up engineering quality as something important, either.
Because you're guaranteed compensation as an employee. You will get your salary even in the firm loses money - you're not taking any financial risks.
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.
But the other concept, on-off splits, is also something which I think managers 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.
Interesting. I started at Google as a SWE in 2009 and I did not see any of this. I left in 2011 so I don't know how the situation is today.
However when I worked there it was obvious that when promotion cycle came everyone was first to claim they "put feature X into Y", even if they were just the ones doing the wiring, not the ones implementing the actual thing.
The situation was aggravated by the fact that promotions were (probably still are) in the hands of "promotion committees" (which most often did not have a damn clue about your product or team and who contributed what in reality) and not in the hands of your boss. As a result I saw promotions biased towards the most shameless liars and self-promoters.
If people are glad you came back then you are correct and you need a raise or more power or both. If they just ask you about your trip then your perception of your value is out of whack.
Also found that 'on-off splits' metric so resounding.
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."
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.
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.
I say this as a programmer who likes writing beautiful code. Nevertheless, when we look around, we see no equivalent of charity hospitals for coders, where philanthropists donate wings and endow chairs to advance the state of the craft. (Not to disparage what we do have: CS Departments, GitHub, some open source foundations are awesome, but do not reflect similar public standing.) Our craft is not valued on its own terms because the broader society does not believe it is inherently beneficial to them. In a day when facebook and twitter throw our elections open to tampering, uber does... whatever uber does, and everyone's even more addicted to Netflix than they were to TV, can you blame them?
Lawyers are valued because they make society freer and fairer. Doctors enhance human dignity by caring for those made weak by sickness. Do you have an equivalently positive outcome for what our profession does when left to its own devices? If not, it's rightly difficult to appeal to the pieties of your profession with someone who does not share that profession.
This isn't meant to be a rebuke, rather, a reminder that good skills are unhelpful unless put to good use. If you don't like money as a means of keeping score on that, there's plenty of work in the public and nonprofit sectors.
That's ridiculous. Of course they think this way. How many doctors are working in a hospital doing the latest surgical technique, versus how many have opened their own office? Do you think opening a private practice means you concentrate more on medicine vs. administration?
They do it because it pays more.
Thinking programmers are unique in having to balance their profession and business is just plain wrong. It's true that most professionals might not think about it that often, but then again, most programmers don't think this way either.
You have to be insured to practice. There's a professional organization that licenses you to practice. These are the social structures we put in place to limit the damage done by the various forces of the world that would tempt a doctor to be anything but faithful to the practice including profit.
A hospital may ask a doctor it hired to "cut corners," but the doctor should refuse and if the hospital tries to fire them and get away with it anyway... the hospital should pay for that.
What I meant by the last line of my comment is that we have a vested interest in producing more software, not less, and I don't think cost is the problem. Although there are people with a vested interest in the status quo who would see the expense of insured, professional software engineers as being unbearable to their interests... not necessarily because such practices would harm the public good and their reliance on technology.
Simple economics are not the best representation of reality.
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.
Additionally, in reality but not in simple economics, there is a huge gap in value-generated for the company and perceived-value-generated for the company. In fact, there can be situations where the two are negatively correlated and the engineer knows best.
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 bosses who want higher headcounts to justify their position.
- We get our money from competitive poaching, so that if GOOG/MSFT/FB has us the other firms don't.
- 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 required.
- We get our money from VC firms playing pyramid games.
- We get our money from government grants that need to get spent or funding gets cut next year.
- We get our money from grants that have to be spent to show investment in "innovation" or "modernization".
- We get our money from selling out users to drive advertising clicks.
- We get our money because...BTC is stupidly volatile.
~
It's extremely naive, in the modern economy, to say "herp derp just deliver value to customers and you'll get paid what you're worth".
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.
> We get our money from selling out users to drive advertising clicks.
Advertisers are the real customer and users the product and all that. This perverse incentive is the driver of most garbage on the web. And not only is the user sold out, they are manipulated by the advertising, the products (e.g. search results, news pages) are manipulated, and now elections are manipulated (Because Facebook et al designed to put the user first would not have spread viral bullshit).
Engineers need to put morality and social good above making more money. Greed is not the god that people should be worshiping and designing economic systems around.
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.
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.
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.
Any disagreements on which part needs to be perfect is really a misalignment if understanding the business
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).
True, but you can make it easy for your boss to conclude that you do deliver a lot of value. For example, don't assume he knows what it is you're doing, or the value of it. Show it and tell it and remind him. It's what any good salesman does, and face it, we're all salesmen one way or another.
And get a pat on the head while he or she gets the cash.
It's worth noting how good we have it: when you examine career salaries against years of school required and unemployment/failure rates (i.e., insurance salesmen can make millions, but most don't/can't.) then software engineering is one of the highest paid professions in the US. Could this be true if a controlling majority of employers were so greedy?
To not share in the losses you need to make yourself essential and irreplaceable, which is more and more difficult since a lot of the popular frameworks and cloud services that make developer/devops jobs easier also make them an easily replaceable part.
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.
Work smart, work effectively, not hard.
The further you are from the owner of the business the more likely you are to be rewarded for non-productive proxies.
This is true, but the thing you're missing is that there's not many folks out there that can add value for customers. That's why engineers who create value get paid so well, which is the articles point.
I've noticed that engineers that get paid the most tend to understand the technical and business trade-offs that come from decisions they make.
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.
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.
- 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
- to understand one's value in $ terms, it needs to be measurable in some way.
Some possible ways to measure:
- 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".
- 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"
- 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"
Interestingly, for each of these, value in terms of $ gets more and more difficult to measure.
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.
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.
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.
How does building a stable, easy to maintain, extensible product not help the broader team execute?
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.
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 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.