In our company we tend to swing between "big important projects" and "tiny wins" quite a lot. The big important projects are the ones that unblock sales and that move the product forward a lot. The tiny wins are small things we can quickly fix, which came up from a concrete customer and would make their lives better immediately.
I have tried for years to find a rule to balance these types of projects. But in the end, I have just come to believe that both are essential, and that alternating between high-level and low-level somewhat randomly is the only solution.
It always amazes me to learn to what lengths end users of software will go without asking for simple fixes like these.
Some years ago, my team created a web-based portal for a local ad agency. Long-running actions that triggered ajax calls would display this hideous, too large, black spinning wheel. Probably there was a bug that caused the spinning wheel to sometimes remain on the screen until you refreshed.
At one point a user contacted us and asked how long the "black sun" as she called it was supposed to be there? We shrugged our shoulders and thought, "maybe a few seconds?". She said she had been working in the app, navigating and clicking right under the spinning wheel, for two whole days before contacting us!
I've heard doctors have it worse with people not asking about 'simple fixes' in a timely manner.
Also, consider what the default scenario might be for someone at a job like Olaf: How likely is he to be able to affect change when some part of a process is inefficient? When I was at my first job, the general mood was that one should keep their head down and just do as instructed, since going above and beyond was not encouraged.
That's an interesting perspective. When it comes to medicine, I usually have no idea whether there might be a "simple fix" for some problem. If I ask my doctor about something small, I expect he would just say "yeah, you're getting old" and then bill me $300. So I don't bother. Maybe end users think similarly.
This is America[0], healthcare is a privilege. Unless you're dying, you should never call an ambulance, and should keep an up-to-date list of what hospitals accept your insurance. And, if the doctor is going to prescribe you something, go on your insurance provider's site and see if it or the formulary are covered.
But seriously, how hard should I be expected to think when something seems medically 'off'? My left wrist has been a little 'off' for a few weeks, but WebMD says it shouldn't be carpal tunnel. Instead of seeing a doctor, I'll just google some more and see what I can do myself.
> My left wrist has been a little 'off' for a few weeks
The other side of this is that doctors in america lean heavy towards interventionism. If you go see a doctor, they will do something. Useful or not.
An american doctor will never, for example, say “Hey maybe your chair is too low compared to your desk and you’re putting too much pressure on your wrist” or suggest a series of stretching exercises to do 3x/day for a few weeks until the discomfort goes away. The best you can expect from a doctor is “eh it’s not bad enough for surgery yet, come back in a few years. Take advil or something idk”
I remember going in for a persistent cough. After 5 minutes the doctor decided “this is post nasal drip” (my nose drains into my throat instead of making me sniffly) and prescribed some medicine to take. And I’m like … yo this problem isn’t bad enough to need fixing, I just wanted to know what’s up. Too much intervention can easily make things worse.
When you have an acute problem that’s when american healthcare shines. Chronic and minor stuff, not so much.
> An american doctor will never, for example, say “Hey maybe your chair is too low compared to your desk and you’re putting too much pressure on your wrist” or suggest a series of stretching exercises to do 3x/day for a few weeks until the discomfort goes away.
A (good) chiropractor will do the first, and a physical therapist will do the second.
Yes, I saw a chiropractor for a while and their immediate advice was to get a better chair and a standing desk, plus some stretches, because I had "grad student syndrome".
> An american doctor will never, for example, say “Hey maybe your chair is too low compared to your desk and you’re putting too much pressure on your wrist” or suggest a series of stretching exercises to do 3x/day for a few weeks until the discomfort goes away. The best you can expect from a doctor is “eh it’s not bad enough for surgery yet, come back in a few years. Take advil or something idk”
Not my experience. I've had doctors that recommended I do stretch exercises for a certain condition I had.
The few times I've been to a doctor in America (I'm not from USA) I got excellent care. They explained the whole thing, told me about options I could take etc. I was very satisfied with the doctors.
Yes it's more expensive than it should be, but that's a different matter.
This is more or less the idea behind [Direct Primary Care](https://www.dpcare.org) – by turning primary care into a monthly subscription, you're encouraged to ask more simple questions to keep yourself in good health, and your doctor is encouraged to keep you healthy so you don't have to come in.
(Not affiliated with this movement and I don't even use it, just think it's a great idea.)
> It always amazes me to learn to what lengths end users of software will go without asking for simple fixes like these.
To be blunt, most users have been not been conditioned to expect anyone to listen to them. The software comes down from on high with a dictum that says "this is the way things work". Even if there is a way to provide feedback in the app, which often there isn't, it tends to goes straight into the void.
Users need to feel empowered to request changes by being involved in the development process. There are also often larger organizational issues that prevent users from feeling they have a say in how their workplace operates.
If that app had a "support" link on every page that would pop up a form, pre-filled with recognizably sane defaults that provide the context of the support request, I'd wonder about that user to.
If I had to hunt down "support" somewhere under "about" in the menu or if I was presented with a very generic form, I'd be that user because I'd dread the braindead support conversations I have learned to expect (Seriously, just today a hoster told me to send them a screenshot of the HTTP 504 response their customer UI receives for a javascript request to their ticketing system.... to support@....)
Google has this button for its products, say least for internal users.
Let me tell you, it has helped sometimes. It also regularly gets duped to threads with a few hundred complaints and product people saying it's intentional behavior.
My wife works as a school administrator, and has been spending the last few nights with her laptop updating the free school meals end dates for all the eligible kids, one by one via the web UI, because there is no automated option to do it in bulk.
This type of situation can be multiplied a millionfold across organisations and businesses, and I honestly don't know what the general solution is. Creators of software can't anticipate every need, and similarly you can't exactly publish a data model and give users a SQL prompt and expect that to end well. The best we can do is shrink the gap between developers and users so that the very low-hanging obvious fruit is implemented at least.
> Creators of software can't anticipate every need
This is one of the reasons why software development is so expensive. You really have to find those small little "business processes" and translate them into clear rules a computer can work with and keep a usable user interface. Without domain knowledge this is really hard.
This also is why the world runs in Excel. Somebody smart in the business unit starts with collecting all info in Excel and slowly builds more and more complex macros into it whenever they have a need. The larger the distance between the business and development the harder it is to capture all those small edges.
> Creators of software can't anticipate every need, and similarly you can't exactly publish a data model ... and expect that to end well.
People don’t want to expose a schema and API, especially for programs like that, because at that instant all their decisions become frozen and turn into technical debt. Any change to the schema would break all the unknown little hacks written by customers.
I always say that my most important piece of work was learning about “tel:”.
Someone had build this a operational report that listed people to contact—hundreds of them. Users would copy-paste the person ID and search for their phone number in another internal database. Then they would type that number. One of them had this hack where they typed it into a software phone that made the bulky physical phone attached ring. All that felt suboptimal to me.
That other database had standard URL structure so I knew that I could turn the id into a link by appending `https:\\admin.company.com\users?id=` That way, they could click and be in the right page without searching. But the reporting system had relevant personal information, so I could instead add a SQL JOIN and include the phone number right there. So I did, and I was showered with praises.
That’s when I thought: why not also have a link? There is this rarely used protocol `tel:`, the phone equivalent of `html:`. It never really made sense, until your phone turned into a computer… I had seen work a while ago. Lo-and-behold! It worked!
So I turned two painstainking ten-digit copying and look-ups into a single-click. I think that hack doubled that team’s productivity.
But the idea has gone way overboard. Everything that could be a phone number, address, or calendar date is now automatically made into a link in many web pages, apps, and instant messengers, such that you have to be very precise with your mouse or finger to be able to copy-paste without accidentally clicking the link. And in some apps they've made it literally impossible to copy-paste the data that they've turned into a link. You have to resort to using developer tools or copy the data by hand.
There needs to be some general UI convention that allows you the option to copy-paste as plain text. There are lots of situations where I don't want a link but just the data.
Pro tip: Hold down alt key before and during clicking to select a link to copy. This prevents the "link click" action from firing, and allows you e.g. place your mouse cursor in the middle of a link (don't forget to hold down alt!) and select the link's text.
I’ve had the experience of accidental power users — when you sit down with a user and they show you functionality which you as the developer didn’t realize existed.
In this case we were using a couple of third party GUI components, and importantly we were using them precisely as we should, and they interacted with other user customization code we had written in an unexpected but totally appropriate way.
> This is the kind of magic that sometimes happens when an engineer gets to talk directly to the users to find out what they are doing
This is why I love running a side project. It’s great to be able to talk to users and find out what they actually want. There’s no need to track their every move or measure clicks, just ask them directly.
"This is the kind of magic that sometimes happens when an engineer gets to talk directly to the users to find out what they are doing"
I think this is also the kind of magic that happens when a business is operating well and it's employees have empathy for each other.
If Engineering and Product are well aligned it should be a matter of habit to be looking for and executing on regular projects like Olaf's new menu item or the auto fill of a new account form mentioned here.
As engineers and engineering management we can make sure there is room in our schedules for these kinds of small projects.
And if we develop well our relationships with our product managers we can make those conversations like the one about the form auto filler easier to happen: "this is three hours of work tomorrow that will save this team 10s of hours each week until we get the new system built, it's worth an afternoon one sprint for a developer".
But also what I think is best displayed in this report is empathy :). Organizations that show empathy for their users are ones that tend to be the best to work for because they actually care about people who are using their products and the people who are making their products. And in general, over time, I think empathy builds better customer and employment relationships which then builds better businesses.
Mark seems awesome and thoughtful and deliberate. But it does seem that he implements some features without the approval of, or from the text, against the wishes of, the product people.
Maybe his product people were unreliable and unsympathetic to the users - he suggests so in the first anecdote. Maybe all product people are, I dunno. But I have been on projects where engineers were allowed (usually de facto rather than by policy) to unilaterally add features they thought were important. The results are not always as positive as they are in this article.
It sounds like these anecdotes are related to internal business systems. In over a decade I've only once seen a place that dedicated an actual FTE to internal product management, and that was because a whole team was dedicated to building those internal tools.
Much more likely, I'd guess, is that either nobody was responsible or the person ostensibly responsible had other things to focus on. The way these systems are usually supported is no official resourcing, but rather "grab Mark's time when he's in the office."
The writer of this is a great written communicator. That was some good technical writing that described the problem well and even gave a good business case for fixing it. If product wouldn’t make space for that fix, then they should rethink their career.
Olaf likely could export his 60 day report to excel, filter to last month and get a count, still not just a button click, but definitely better than a manual count. Just requires proficiency in excel, something I feel every business should train their employees in.
For the first one, I work in servicenow all day and it has an “insert and stay” menu option for basically any record, something I use incredibly often, so to whoever added that feature, I love you!
A while back I was working on a logistics follow-up system at a call center.
The system would fetch the logistics data from the different logistics partners and chew on it for a while, trying to determine which ones were "delayed", and burp out "events" that humans would see and act on. Usually by calling or e-mailing the customer to tell them there would be a slight delay, and giving a reason why. In the rare event the customer called the call center first, they could look up the logistics and tell the customer exactly what was going on with their repair or exchange or whatever.
All in all it was a fun little system to work on, and I enjoyed it a lot. What made it worth doing, even though it was a giant corporation's call center, was that my (shared) office was right next to the actual team actually working with the tool. I smoked cigarettes at the time, so it was not uncommon for me to take little smoke breaks with the actual users. At first they were hesitant to try and push "work questions" on me during my break, but I assured them that it was fine.
They'd bring up those tiny little things that never get fixed in systems like this. NDA prevents me from going into any kind of detail, but it was little stuff like Olaf's New Menu Item. Working that closely with the Actual Users was very liberating, and I think it alleviated a lot of their frustrations to have developer access, too.
That said, this team was maybe 50 people. When this "preemptive logistics issue team" model was rolled out world-wide, I had already left the organization for entirely unrelated reasons, and I don't think I would have given all those people direct access to me on my breaks like that.
> But the moral calculus was in everyone's favor. What is money, after all, compared with good and evil? If ZipRecruiter could stop trampling on Olaf's soul every month, and the only cost was a few hours of my time, that was time and money well-spent making the world a better place.
This speaks to my soul. I have never read such a clear description of how I choose what to work on.
If Olaf is more productive, engaged, and motivated because his job is not as soul-crushing, then there are second-order gains to add to the monetary cost-benefit analysis. (Though I totally agree that making your colleagues’ lives better is a worthy endeavour in itself).
I recently went on a "copy to clipboard" campaign, adding all sorts of places to click and copy information to the clipboard. Nobody asked for it but I've gotten lots of love from folks where it has saved them a ton of time / hassle.
Meanwhile I've got high priority requests to remove a thing that "they don't need" and I know the moment I remove it ... I'll get a request to add it back.
"From a purely business perspective, this project probably cost the company money."
This is only true in a narrow time context. If you broaden the context, then you can see where it falls down. The missing element is that people who can solve high-ROI problems are not willing to be cut off from work like this. If you don't let good people help their co-workers, then they'll leave and find a more hospitable environment. When that high-ROI problem comes along, that really would pay off quickly, then there won't be anybody like Olaf around to tackle it.
Think about a non-technical example. You probably have insurance of some kind, on your house, car, or life. In a narrow perspective, this just costs you money. A tree doesn't fall on your house, nobody rear ends your car, and you don't get hit by lightening. But in the long term, one of these sorts of things is bound to happen. The care and feeding of talented engineers who "lean in" is like an insurance policy for when a high-ROI opportunity presents itself.
You might believe that, but I don't think you know for sure, and I doubt you could prove it. I would not know what evidence of that claim would look like, or how to evaluate it.
What I would like, though, is to unask the question completely. Maybe Olaf's menu item saved the company money in the long term, or maybe it cost the company money in the long term. Why is that so important? Why should that be the primary consideration (or only consideration) when we judge whether the project was worth doing?
I would like a framework for evaluating these sorts of choices starting from a different place.
Something that has been on my mind a long time is the idea of persuading local merchants to pay someone to pick up trash on their street. In the USA, the argument would look like this: "If you chip in a small amount of money to pay for street sweeping, that cost will be more than offset by the revenues stemming from increased foot traffic to your business.”
This to me seems deeply insane. Everything is measured in dollars. To Americans, not living in a pile of filth has no intrinsic value apart from increased business returns. The argument “even if the cost isn't offset by increased revenues, at least you won't have to walk through piles of trash every day” does not carry any weight.
I would like to live in a world where Olaf's menu item was sufficiently justified by its obvious benefit to Olaf, and the presumption was that it was worth doing on that basis alone.
> To Americans, not living in a pile of filth has no intrinsic value apart from increased business returns.
I know it's fun to shit on Americans, but this is simply not true. You yourself begin the idea with "the idea of persuading local merchants to pay someone to pick up trash on their street". You have chosen to frame it economically, so it should come as no surprise that anyone you talk to about it evaluates it on economic grounds.
It's like asking someone if they want a 500 calorie cake and then complaining that no one focuses on the taste.
I agree wholeheartedly that Americans do end up thinking in economic terms and that's not great for society, but I strongly disagree that it's something intrinsic to being American.
We live in a society heavily dominated by corporations and where many people struggle to afford a dignified, stable life. I don't think people want to be in a hustle mindset all the time, but if you're forced to live in the desert, you're going to spend a lot of time thinking about water whether you like it or not.
> It was not doing its job, and to pick up the slack, Olaf, a sentient being, was having to pretend to be a machine.
I always used to joke that I got into computers because I was bad at math, and wanted to tell the computer to do the math for me. Eventually I realized it wasn't a joke, and it really does piss me off to see a person have to do a computer's job-- especially on a regular basis. Of course xkcd#1319[0] still applies, and it may not always be worth it to automate, but it can make a huge daily difference in the lives of users.
48 comments
[ 3.2 ms ] story [ 101 ms ] threadI have tried for years to find a rule to balance these types of projects. But in the end, I have just come to believe that both are essential, and that alternating between high-level and low-level somewhat randomly is the only solution.
Some years ago, my team created a web-based portal for a local ad agency. Long-running actions that triggered ajax calls would display this hideous, too large, black spinning wheel. Probably there was a bug that caused the spinning wheel to sometimes remain on the screen until you refreshed.
At one point a user contacted us and asked how long the "black sun" as she called it was supposed to be there? We shrugged our shoulders and thought, "maybe a few seconds?". She said she had been working in the app, navigating and clicking right under the spinning wheel, for two whole days before contacting us!
Also, consider what the default scenario might be for someone at a job like Olaf: How likely is he to be able to affect change when some part of a process is inefficient? When I was at my first job, the general mood was that one should keep their head down and just do as instructed, since going above and beyond was not encouraged.
But seriously, how hard should I be expected to think when something seems medically 'off'? My left wrist has been a little 'off' for a few weeks, but WebMD says it shouldn't be carpal tunnel. Instead of seeing a doctor, I'll just google some more and see what I can do myself.
[0] Where applicable
The other side of this is that doctors in america lean heavy towards interventionism. If you go see a doctor, they will do something. Useful or not.
An american doctor will never, for example, say “Hey maybe your chair is too low compared to your desk and you’re putting too much pressure on your wrist” or suggest a series of stretching exercises to do 3x/day for a few weeks until the discomfort goes away. The best you can expect from a doctor is “eh it’s not bad enough for surgery yet, come back in a few years. Take advil or something idk”
I remember going in for a persistent cough. After 5 minutes the doctor decided “this is post nasal drip” (my nose drains into my throat instead of making me sniffly) and prescribed some medicine to take. And I’m like … yo this problem isn’t bad enough to need fixing, I just wanted to know what’s up. Too much intervention can easily make things worse.
When you have an acute problem that’s when american healthcare shines. Chronic and minor stuff, not so much.
A (good) chiropractor will do the first, and a physical therapist will do the second.
You're right about regular MDs though.
Not my experience. I've had doctors that recommended I do stretch exercises for a certain condition I had.
The few times I've been to a doctor in America (I'm not from USA) I got excellent care. They explained the whole thing, told me about options I could take etc. I was very satisfied with the doctors.
Yes it's more expensive than it should be, but that's a different matter.
(Not affiliated with this movement and I don't even use it, just think it's a great idea.)
To be blunt, most users have been not been conditioned to expect anyone to listen to them. The software comes down from on high with a dictum that says "this is the way things work". Even if there is a way to provide feedback in the app, which often there isn't, it tends to goes straight into the void.
Users need to feel empowered to request changes by being involved in the development process. There are also often larger organizational issues that prevent users from feeling they have a say in how their workplace operates.
If I had to hunt down "support" somewhere under "about" in the menu or if I was presented with a very generic form, I'd be that user because I'd dread the braindead support conversations I have learned to expect (Seriously, just today a hoster told me to send them a screenshot of the HTTP 504 response their customer UI receives for a javascript request to their ticketing system.... to support@....)
Let me tell you, it has helped sometimes. It also regularly gets duped to threads with a few hundred complaints and product people saying it's intentional behavior.
Manual things can create mistakes.
This particular number from Olaf might not be critical if it is off by a few countsother workflows are.
This type of situation can be multiplied a millionfold across organisations and businesses, and I honestly don't know what the general solution is. Creators of software can't anticipate every need, and similarly you can't exactly publish a data model and give users a SQL prompt and expect that to end well. The best we can do is shrink the gap between developers and users so that the very low-hanging obvious fruit is implemented at least.
This is one of the reasons why software development is so expensive. You really have to find those small little "business processes" and translate them into clear rules a computer can work with and keep a usable user interface. Without domain knowledge this is really hard.
This also is why the world runs in Excel. Somebody smart in the business unit starts with collecting all info in Excel and slowly builds more and more complex macros into it whenever they have a need. The larger the distance between the business and development the harder it is to capture all those small edges.
People don’t want to expose a schema and API, especially for programs like that, because at that instant all their decisions become frozen and turn into technical debt. Any change to the schema would break all the unknown little hacks written by customers.
I don’t think there’s a good long term fix
Someone had build this a operational report that listed people to contact—hundreds of them. Users would copy-paste the person ID and search for their phone number in another internal database. Then they would type that number. One of them had this hack where they typed it into a software phone that made the bulky physical phone attached ring. All that felt suboptimal to me.
That other database had standard URL structure so I knew that I could turn the id into a link by appending `https:\\admin.company.com\users?id=` That way, they could click and be in the right page without searching. But the reporting system had relevant personal information, so I could instead add a SQL JOIN and include the phone number right there. So I did, and I was showered with praises.
That’s when I thought: why not also have a link? There is this rarely used protocol `tel:`, the phone equivalent of `html:`. It never really made sense, until your phone turned into a computer… I had seen work a while ago. Lo-and-behold! It worked!
So I turned two painstainking ten-digit copying and look-ups into a single-click. I think that hack doubled that team’s productivity.
But the idea has gone way overboard. Everything that could be a phone number, address, or calendar date is now automatically made into a link in many web pages, apps, and instant messengers, such that you have to be very precise with your mouse or finger to be able to copy-paste without accidentally clicking the link. And in some apps they've made it literally impossible to copy-paste the data that they've turned into a link. You have to resort to using developer tools or copy the data by hand.
There needs to be some general UI convention that allows you the option to copy-paste as plain text. There are lots of situations where I don't want a link but just the data.
Modern software is so hard to learn -- though browsers are old.
In this case we were using a couple of third party GUI components, and importantly we were using them precisely as we should, and they interacted with other user customization code we had written in an unexpected but totally appropriate way.
This is why I love running a side project. It’s great to be able to talk to users and find out what they actually want. There’s no need to track their every move or measure clicks, just ask them directly.
I think this is also the kind of magic that happens when a business is operating well and it's employees have empathy for each other.
If Engineering and Product are well aligned it should be a matter of habit to be looking for and executing on regular projects like Olaf's new menu item or the auto fill of a new account form mentioned here.
As engineers and engineering management we can make sure there is room in our schedules for these kinds of small projects.
And if we develop well our relationships with our product managers we can make those conversations like the one about the form auto filler easier to happen: "this is three hours of work tomorrow that will save this team 10s of hours each week until we get the new system built, it's worth an afternoon one sprint for a developer".
But also what I think is best displayed in this report is empathy :). Organizations that show empathy for their users are ones that tend to be the best to work for because they actually care about people who are using their products and the people who are making their products. And in general, over time, I think empathy builds better customer and employment relationships which then builds better businesses.
Maybe his product people were unreliable and unsympathetic to the users - he suggests so in the first anecdote. Maybe all product people are, I dunno. But I have been on projects where engineers were allowed (usually de facto rather than by policy) to unilaterally add features they thought were important. The results are not always as positive as they are in this article.
Much more likely, I'd guess, is that either nobody was responsible or the person ostensibly responsible had other things to focus on. The way these systems are usually supported is no official resourcing, but rather "grab Mark's time when he's in the office."
For the first one, I work in servicenow all day and it has an “insert and stay” menu option for basically any record, something I use incredibly often, so to whoever added that feature, I love you!
All in all it was a fun little system to work on, and I enjoyed it a lot. What made it worth doing, even though it was a giant corporation's call center, was that my (shared) office was right next to the actual team actually working with the tool. I smoked cigarettes at the time, so it was not uncommon for me to take little smoke breaks with the actual users. At first they were hesitant to try and push "work questions" on me during my break, but I assured them that it was fine.
They'd bring up those tiny little things that never get fixed in systems like this. NDA prevents me from going into any kind of detail, but it was little stuff like Olaf's New Menu Item. Working that closely with the Actual Users was very liberating, and I think it alleviated a lot of their frustrations to have developer access, too.
That said, this team was maybe 50 people. When this "preemptive logistics issue team" model was rolled out world-wide, I had already left the organization for entirely unrelated reasons, and I don't think I would have given all those people direct access to me on my breaks like that.
It works well, at certain scales, though!
This speaks to my soul. I have never read such a clear description of how I choose what to work on.
I recently went on a "copy to clipboard" campaign, adding all sorts of places to click and copy information to the clipboard. Nobody asked for it but I've gotten lots of love from folks where it has saved them a ton of time / hassle.
Meanwhile I've got high priority requests to remove a thing that "they don't need" and I know the moment I remove it ... I'll get a request to add it back.
This is only true in a narrow time context. If you broaden the context, then you can see where it falls down. The missing element is that people who can solve high-ROI problems are not willing to be cut off from work like this. If you don't let good people help their co-workers, then they'll leave and find a more hospitable environment. When that high-ROI problem comes along, that really would pay off quickly, then there won't be anybody like Olaf around to tackle it.
Think about a non-technical example. You probably have insurance of some kind, on your house, car, or life. In a narrow perspective, this just costs you money. A tree doesn't fall on your house, nobody rear ends your car, and you don't get hit by lightening. But in the long term, one of these sorts of things is bound to happen. The care and feeding of talented engineers who "lean in" is like an insurance policy for when a high-ROI opportunity presents itself.
You might believe that, but I don't think you know for sure, and I doubt you could prove it. I would not know what evidence of that claim would look like, or how to evaluate it.
What I would like, though, is to unask the question completely. Maybe Olaf's menu item saved the company money in the long term, or maybe it cost the company money in the long term. Why is that so important? Why should that be the primary consideration (or only consideration) when we judge whether the project was worth doing?
I would like a framework for evaluating these sorts of choices starting from a different place.
Something that has been on my mind a long time is the idea of persuading local merchants to pay someone to pick up trash on their street. In the USA, the argument would look like this: "If you chip in a small amount of money to pay for street sweeping, that cost will be more than offset by the revenues stemming from increased foot traffic to your business.”
This to me seems deeply insane. Everything is measured in dollars. To Americans, not living in a pile of filth has no intrinsic value apart from increased business returns. The argument “even if the cost isn't offset by increased revenues, at least you won't have to walk through piles of trash every day” does not carry any weight.
I would like to live in a world where Olaf's menu item was sufficiently justified by its obvious benefit to Olaf, and the presumption was that it was worth doing on that basis alone.
I know it's fun to shit on Americans, but this is simply not true. You yourself begin the idea with "the idea of persuading local merchants to pay someone to pick up trash on their street". You have chosen to frame it economically, so it should come as no surprise that anyone you talk to about it evaluates it on economic grounds.
It's like asking someone if they want a 500 calorie cake and then complaining that no one focuses on the taste.
We live in a society heavily dominated by corporations and where many people struggle to afford a dignified, stable life. I don't think people want to be in a hustle mindset all the time, but if you're forced to live in the desert, you're going to spend a lot of time thinking about water whether you like it or not.
[0] https://xkcd.com/1319/