I hear that one a lot but pretty frequently it's applied to "social problems" which were caused by technology. It seems to imply some kind of technology/society boundary which doesn't actually exist.

Mild disagree.

The saying "you can't solve social problems with technology" usually means - at least in the places I have heard / used it - "If your workforce fights a process - be it for the process being stupid, tools being slow, incentives do not align with policy, whatever - especially a control step, no amount of mandatory tech enforcement of that process step will yield better results." At best you get garbled data because someone hit the keyboard to fill in mandatory fields, sometimes, the process now works OUTSIDE of the system by informal methods because 'work still needs to be done', at worst, you get a mutiny.

You have to fix the people(s' problems) by actually talking to them and take the pain points away, you do not go to 'computer says no' territory first.

In my experience, no org problem is only social, and no tech problem is merely technical. Finding a sustainable solution in both fields is what distinguishes a staff engineer from a junior consultant.

Another point of view on that.

I work on SaaS platform as engineer. We can have some people from customer A asking for bunch of fields to be mandatory - just to get 6 months later people from that company nagging about the fields saying our platform sucks - well no their process and requirements suck - we didn’t come up which fields are mandatory.

I've been thinking a lot about that lately, and I agree. I used to be hard in the "You can't solve social problems with technical solutions", but that's not the whole truth. If people aren't using your thing, sure, you can brand that as social problem (lack of buy-in on the process, people not being heard during rollout, ...). However one way of getting people to use your thing/process is to make it easier to use. Integrate it well into the workflow they're already familiar with, bring the tooling close, reduce friction, provide some extra value to your users with features etc. That's technical solutions, but if you choose them based on knowledge of the "social problem" they can be quite effective.

This is what I was trying to express, perhaps poorly:

> no org problem is only social, and no tech problem is merely technical.

I was going for "the intersection is clearly nonempty" but maybe the better argument is "the intersection is pretty much everything."

There very much is that boundary. Jira by tech itself is a good product, but now try shoving it down people’s throats and see how that goes.

Or on a bigger scale look at FB/Social media and society. There definitely without a doubt is a boundary. They interact and overlap.

Jira by itself is a bunch of bits, it's only good or bad as judged by a community of users whose needs it does or does not meet.

Not to mention, technicial solutions are usually the only viable ones. It's not like, in practice, we solve social problems in other ways.

Oh, now I have a name for the epidemic pervasive through our company.

Almost all of the tech debt we have was introduced by leadership guidance to ignore. And all additional debt to manage it or ameliorate it (since problems don't just go away) is also guidance from leadership to fast track fixes.

What happened to the days where software engineers were the experts who decided tech priority?

> guidance from leadership to fast track fixes.

That is *IF* there ever is acknowledgment that things need to be fixed.

"These pesky issues, who knows where they come from, just quickly get it out of the way. We have the next shiny new to tackle for the next quarter, and we better finish it quickly".

> What happened to the days where software engineers were the experts who decided tech priority?

Outside of a very small number of firms that were called out as notable for being led in a way that enabled that, often by engineers that were themselves still hands on, they never existed, and even there it was “business leadership that happened to also be engineers, and made decisions based on business priorities informed by their understanding of software engineering”, not “software engineers in their walled-off citadels of pure engineering”, and it usually involves, in successful firms, considerable willingness to accept tech debt, just as business leadership can often not be shy about accepting funancial debt.

> business leadership can often not be shy about accepting financial debt

Business leadership is not shy about accepting financial debt when business leadership has decided it should accept financial debt. Technical leadership should ostensibly not be shy about accepting technical debt because business leadership has decided it should accept technical debt. The distribution of agency and responsibility in the two situations is different.

Pedantically, true "tech debt" does exist. Usually it had resulted from "org debt", which since then mostly ceased to exist in its original form, but the tech debt remains.

“tech is easy, people are hard”