It's pretty fundamental to the personality of people in sales to be driven by getting the sale and getting compensated based on the deal size. If you remove that carrot, it just doesn't work. Some sales people will make millions, some will make nothing.
How come it works for basically every other job on this planet? Developers aren't paid per feature implemented/bug fixed, and we still do those things, how come sales people are unable to do things for a fixed monthly salary?
>, how come sales people are unable to do things for a fixed monthly salary?
You have to separate out 2 different ideas of the "theoretical idealized salesperson that works for fixed salary" -vs- "real-world salesperson that works for variable commissions".
The businesses that have attempted to pay fixed salaries for salespeople end up attracting incompetent salespeople who can't sell. They become a negative cost on the company's payroll because they can't bring in any revenue. In contrast, the high-performance salespeople (the "rainmakers") are attracted to the variable high-commission, because they know they have the hard-to-find skills to actually sell and bring in the money. If a salesperson has the skills to get a customer to sign a contract and pay money, they have the leverage to get a percentage of that.
Developers, db sysadmins, tech support staff, etc are not in situations to directly influence and shake the hand of a new potential customer and convince them to write a check.
I do know that (I myself also worked in sales for a short stint, unrelated to software though), what I don't understand how these magical "sales people" apparently can't work for a fixed salary when literally everyone else can. Apparently the rest of us can do high quality work without being paid for each feature/bug fixed, yet these individuals cannot?
> Many top salespeople have a zero base salary.
Hmm, probably true in some places, but here (Spain) that wouldn't even be legal. When I worked in sales we had minimum wage + commission, but I'm sure the salary would be 0 if they were allowed to set it up like that.
> Hmm, probably true in some places, but here (Spain) that wouldn't even be legal. When I worked in sales we had minimum wage + commission, but I'm sure the salary would be 0 if they were allowed to set it up like that.
In the United States having "zero base bay" is hypothetical. If a full-time employee had no commission payouts they'd be compensated minimum wage as necessary to comply with laws.
Sales jobs often come with a warm-up period with either a higher base salary or they get paid part of their commission target for a number of months regardless of how many sales they make.
> what I don't understand how these magical "sales people" apparently can't work for a fixed salary when literally everyone else can
It isn't that "sales people"[0] can't work for a fixed salary. The good ones just won't because they can find another employer that will pay commission, and they know they will make more with commission than without.
Employers will pay commission because that's how you attract the best sales people, and the best sales people are worth orders of magnitude more to their business than average sales people. Despite how much they earn, in general and compared to their average peers, the best sales people don't cost orders of magnitude more (5x is a more typical spread in tech sales.)
The advantage of 100% commission -- where it is legal -- is pretty obvious from the employer's view point. The company only pays for production. These sales people are commonly (but not always) independent contractors. The benefit for the sales person is a little less obvious, but, generally, they have more autonomy, a simpler comp plan without any caps, and earn more per dollar sold than they would on a base + commission plan.
> the rest of us can do high quality work without being paid for each feature/bug fixed, yet these individuals cannot
Yes they can not. It is not high quality work but high quality results for sales guy. Developer work is complete once service deployed. It wouldn't be developer failure if user volume doesn't reach x thousands per day on their web service. It would definitely be salesman failure sales does not reach x dollars in certain duration.
Developer equivalent of sales would be to say "I have distributed x sales brochures and call x number of clients this month. My job is done."
It's not that they're unable to; it's that the field attracts people who are financially motivated and other companies have compensation structures that reward personal performance.
Top salespeople generally won't work for a fixed salary because they want to make as much as they can, and the way they do that is by having as much of their compensation tied to personal performance as possible.
I personally think more engineers/developers should think the same way, but it's also much harder to directly tie job performance to compensation when contributing to a product.
But that's the same no matter if you work in sales, customer support or many other roles, a lot of people just care about the money with little regards to anything else, yet the sales department are the only ones who must have commission?
> But that's the same no matter if you work in sales, customer support or many other roles, a lot of people just care about the money with little regards to anything else,
It's actually not the same for many roles. See the comments from people in this thread alone who scoff at the notion of maximizing compensation. I don't get it personally, but it's not an uncommon thought.
> yet the sales department are the only ones who must have commission?
I think there's a very high likelihood that a salesperson is primarily driven by compensation, and good salespeople will already be working in a commission-driven compensation model elsewhere.
Why would a top salesperson at Dell, HPE, Oracle, or wherever else a hardware salesperson comes from move to Oxide to take less money and completely decouple their compensation from their performance?
Even if your intent is to maximize income in customer support, you often don’t have the market option to do that. I have seen (and even worked at) places where chat support, phone support, and support administrators have a quota of chats, calls, or ticket responses and make bonuses based on how much they exceed their numbers. Unfortunately sometimes that results in people updating tickets several times an hour saying things like “we’re still looking into this and haven’t forgotten you” without actually looking into anything.
One place I worked I tried to move the quota system more towards being the final response on a resolve issue, but upper management didn’t want to ever judge whether an issue was resolved even when the customer said they were happy. They did incorporate an NPS query for every interaction, though, and a multiplier against the volume-based quota. Unfortunately that favored people who were good BS artists when lying to the customer about looking into things.
The fallout from the above paragraph was that quality, caring staff would get punished for actually solving customer problems.
Almost every other role is at least one level removed from putting cash in the company's account, which is what leads to the shenanigans you described with metrics that are a poor proxy for revenue generation (and/or are too easy to game).
Sales is unique because the monetary benefit to the company is mostly objective: If someone closes a $10 million sales contract, that becomes $10 million in revenue.
If a team of developers work together to fix a bug, how would you calculate the revenue value of the bug and how would you distribute that to the team that solved it? Technically the value of a bug is negative because it costs the company, so do you subtract that from the pay of the engineers he worked on it? If 5 people implement a feature that uses a library developed by 5 other people, which was built on the platform team's infrastructure, how do you divide up the commission? It doesn't work.
A $10 million sales contract is objectively $10 million in revenue, sure, but it's silly to attribute that entirely to the sales person just like it would be silly to attribute it entirely to the engineers that built the product or the marketing team that bought billboards.
Because sales are quantifiable and directly mapped to performance.
To get that kind of proportional payback in engineering you'd need very clear financial objectives for a project. I could see that happening in optimization scenarios where consultants are brought in and get paid for whatever they can trim from operational costs.
In fact I’ve seen both tech and manufacturing efficiency consultants whose quotes include $x up front plus monitoring and reporting that shows the efficiency gains. Then rather than taking a closing fixed payment, they get a percentage of the savings to the client over the first six or twelve months.
Freelancers and consultants do absolutely have the option to get paid by the feature. It’s exceedingly rare for internal employees or contract employees though. That means there’s no market competition based on it yet. Some places do have bonuses or even profit sharing. Some senior ICs and many managers across the industry can get equity through either grants or options.
Sales professionals have a lot of different places they can sell things. The market-rate compensation for sales includes commissions. So to get the best sales people, you want something easy and exciting to sell with a good commission structure tied to the sales.
> How come it works for basically every other job on this planet?
In sales it is uniquely easy to identify your contribution since it's literally measured in dollars coming in.
There's no way to quantify that for feature implemented/bug fixed, it would devolve into endless politics.
> how come sales people are unable to do things for a fixed monthly salary?
Sure they are able, but no good sales person is interested. Presumably you'd want to hire the good ones. You can certainly staff a mediocre sales team on a fixed salary, they just won't do much selling.
> In sales it is uniquely easy to identify your contribution since it's literally measured in dollars coming in.
This logic about stops working as soon as you sell something that is not some immediately exchanged mass produced commoditized gadget. Sales people on commission have tons of incentive to saddle the company with demands and imaginary product features they can't actually deliver on and be long gone before the bill comes due.
"He was informed the flagging was for two reasons: first, he was told he had an incorrect visa, but he was also told that there was another reason that the agents would not disclose to him.
“I can’t help but wonder whether my frequent, and less than flattering, public comments regarding their president and his administration played a role – or perhaps I’m simply succumbing to paranoia,” he said."
This is most likely a very mundane event. Was his visa actually incorrect, because the second speculation is irrelevant if that is the case. I don't know, it would be nice if they clarified that point.
I am curious about that also, however it seems odd that one band member had the correct visa? If our assumption is they didn't get a visa that allowed them to perform, it means one did or there was a second reason that only applied to the other three.
"With 4 out of 5 people keeping their flats, “Housing First” is effective in the long run. In 20 percent of the cases, people move out because they prefer to stay with friends or relatives – or because they don’t manage to pay the rent. But even in this case they are not dropped. They can apply again for an apartment and are supported again if they wish."
There are no preconditions, but there are conditions to maintain. In this case, rent being required apparently. This is the recipe for success that I've seen. And if they don't maintain the conditions they get kicked out with the opportunity to come back and try again.
Since homelessness is mostly transient in general, I'm skeptical of the claim to effectiveness, since it's likely that a large portion of a sample would move on within a year anyway.
dist author here. since darren0 was so kind to reference my tool, I'll just add dist is written in go, is cross platform, can handle github, gitlab, homebrew packages (with caveats), and a few others and you can create custom aliases as well. there are a few additional features in the works right now. also supports signature and checksum verification if available.
It's great to see movement in this space. The main problem in my experience is github api and throttling. It's really hard to download 40 binaries while building an image for CI/CD. Binaries themselves are CDNed, but github apis to find them are easily throttled, especially behind NAT.
Need to have some caching mechanism avoid this. Eget seems currently abandoned, maybe gah can start looking stuff in a cache.
cool. please let me know when you post, I would like to read. I'm the author of dist if that wasn't clear. Also looking for feedback on the project should you find it useful.
eget duckdb/duckdb
2 candidates found (unsure architecture): please select manually
(1) duckdb_cli-osx-universal.zip
(2) libduckdb-osx-universal.zip
Enter selection number:
Afterwards it correctly unzips. Can use cmdline flag to match artifacts
`gah` fails:
gah install duckdb/duckdb
Fetching release info for: duckdb/duckdb [latest]
Found release: v1.1.3 Bugfix Release
Downloading:
Warning: output file name has no length
curl: option -o: is badly used here
(Using curl 8.4.0 on macOS)
`dist` also fails:
dist install duckdb/duckdb
• determining latest version
• version: 1.1.3
⨯ no matching asset found, score too low
⨯ closest matching: duckdb_cli-osx-universal.zip (34) (threshold: 40)
I thought that no one in right mind will use underscore in the binary name, but it seems that I had too much faith in humanity. Fixed:
gah install duckdb/duckdb
Fetching release info for: duckdb/duckdb [latest]
Found release: v1.1.3 Bugfix Release
Several download URLs were found which match your OS and arch. Please select one:
1) https://github.com/duckdb/duckdb/releases/download/v1.1.3/duckdb_cli-linux- amd64.zip
2) https://github.com/duckdb/duckdb/releases/download/v1.1.3/libduckdb-linux-amd64.zip
#? 1
Downloading: duckdb_cli-linux-amd64.zip
##################### 100,0%
Extracting: duckdb_cli-linux-amd64.zip
Installing: duckdb
Give a new name or keep 'duckdb'? (Leave empty to keep the same)
New name:
Installed: duckdb
Done!
--no-score-check didn't help, so i didn't include it.
Works with your fix.
I sent you an email to schedule a chat. Hope you don't mind. I'm very thankful for your work in this space. Will keep testing this in place of my eget workflows.
Some thoughts so far:
1. ability to pick my own dir or to default to .local/bin . Eg I love using eget from ansible to drop various useful binaries
2. Ability to override github url, so I could do my own token management/cache in a centralized way. This would fix the biggest downside of such tools in CI.
4. lazy mode. I have an ad-hoc script to lazily download various nice-to-have-but-heavy binaries into devcontainer on my team. Eg it's a bash script that checks if usql is in path, if it's not, it downloads a pinned version and runs it and passes args through. Given how fast most binaries are this is the only way to have all the binaries we need without wasting gigs of space of stuff that only 1 person on team may use.
Technically there's a config file and you can set the path, it's not been tested a lot on custom paths and I haven't documented it yet, but if you look at the source it'll show you how.
I'm working on a Distfile so be able to install multiple pinned versions at the same time, I'm also working on installing multiple binaries at the same time.
I think compiling go is something I'll stay away from. I think it would be better to encourage folks like mic92 to use goreleaser and publish static binaries.
The transition to Wayland also seems to correlate with the adoption of client side decorations (CSD). This "modern" approach destroys the traditional UX of XFCE as seen by recent changes in the settings manager. I fear for the future of XFCE. The advantage of XFCE for me has always been that it's a stable implementation of a traditional Win98/XP UX. I hope they don't adopt more Gnome3 patterns.
> The transition to Wayland also seems to correlate with the adoption of client side decorations (CSD)
Not really. The GNOME/GTK folks were already on the CSD bandwagon well before Wayland. Wayland compositors are free to draw their own decorations (and xfwm4 will indeed continue doing that once it's a Wayland compositor), and one of the actually neat things about Wayland is that there is a protocol that allows the compositor to tell applications not to draw their own decorations. (Whereas on X11 an app can tell the WM it will draw CSDs and the WM can't do a thing about it.)
Certainly GNOME has gone all the way to CSDs (IIRC if an app on GNOME doesn't draw CSDs, they get no decorations at all), but that has nothing to do with Wayland.
What has this to do with wayland or XFCE? The only major DE that is using client side decorations is gnome. This has been true since 2018:
> I heard that GNOME is currently trying to lobby for all applications implementing CSD. One of the arguments seems to be that CSD is a must on Wayland. That’s of course not the case. Nothing in Wayland enforces CSD. Wayland itself is as ignorant about this as X11. [...] In fact we created a protocol (supported by GTK) that allows to negotiate with the Wayland compositor whether to use CSD or SSD.
On Wayland, the compositor can either let windows draw their own borders, or it can disallow it. On X11, if a window want's to draw its own decorations... it will just do it, and you won't be able to do anything about it.
Pretty much every single Wayland compositor follows this except for GNOME, who refuse to do so. It causes problems with windows like Davinci Resolve who don't draw their own decos. This leaves some windows without any controls at all lol. But this is a tangent and purely a GNOME problem.
I mean yeah... But most people are going to have trouble with that, especially being unable to resize or move the window. I even saw a tech Youtuber try out gnome and they were baffled on why they couldn't move or resize davinci resolve whatsoever. Its almost shameful how negligent and hard-headed gnome is being.
Sure it does. Allowing windows to draw their own decorations, often in different ways and with different styles and themes, and not respecting the settings in xfwm4 as to what window-control buttons should be drawn (and where)... that's a huge UX issue.
The process drawing it's own decorations? Technical decision that both Windows (tad complicated) and macOS already do, nothing to do with UX. There's nothing stopping this model from having the uniformity of SSD (as like on macOS), but it does on Linux due to multiple toolkits which don't all agree with eachother.
A tax refund means you paid too much taxes and the government refunds the excess. The size of the refund means nothing except how good you are in predicting taxes.
Unfortunately, the distinction is sometimes (though rarely) useful and would be a far more disruptive change than this one. I think you would actually need a Go v2 to change it.
