Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Always the Process, Stupid

its.promp.td

Post reply on HN
Print view View original

61–70 of 123 posts

Re: It's Always the Process, Stupid

#61

Post by ozim »

DocTomoe wrote: post #54
__MatrixMan__ wrote: post #31

Earlier quoted context omitted.

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…

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.

Re: It's Always the Process, Stupid

#62

Post by Telaneo »

alexpotato wrote: post #35

One of my favorite stories about processes and documentation: - Work at a hedge fund - Every evening, the whole firm "cycles" to start the next trading day - Step 7 of 18 fails - I document Step 7 and then show it to a bunch of folks - I end up having a meeting where I say: "Two things are true: 1. You all agree that Step 7 is incorrectly documented. 2. You all DISAGREE on what Step 7 should be doing" I love this sto…

I've been in discussions about Step 7, and my god, the experience was soul crushing. Even more soul crushing was that the result of that discussion was to not document Step 7, because doing that might enforce the idea of what it should be for and why it should be done.

Writing stuff down is great since it provides a baseline to agree upon, and later additions to the team will take it as given and not start to discuss minutiae and bog down discussions into nothingness. And if some point really is worth discussing, it shouldn't be hard to find support to change it. I've heard some wild misunderstandings of how things were based on how they were being done, and now I never want to do anything of any significant size without there being a clear and obvious process to it.

Re: It's Always the Process, Stupid

#63

Post by rootnod3 »

__MatrixMan__ wrote: post #31
wavemode wrote: post #10

Earlier quoted context omitted.

A similar observation commonly comes up related to software development - "it's not tech debt, it's org debt" (or to put a different way, "trying to use a technical solution to solve a social problem").

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.

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.

Re: It's Always the Process, Stupid

#64

Post by jjk166 »

crims0n wrote: post #38

I have complicated feelings towards process, especially in large enterprises. In one hand, I know process is how you get good work out of average people - and that has a lot of value in big businesses because statistically, most people are going to be around average. On the other hand, I have seen process stifle above average people or so called “rockstars”. The thing is, the bigger your reliance on process, the more…

> On the other hand, I have seen process stifle above average people or so called “rockstars”. The thing is, the bigger your reliance on process, the more you need these people to swoop in and fill in the cracks, save the day when things go horribly wrong, and otherwise be the glue that keeps things running (or perhaps oil for the machine is more apt).

This is a case of bad process. No process is perfect, but the whole point of process is so when things go wrong they don't go horribly wrong, and that you don't need rockstars to fill in the cracks. It should be making your rockstars faster because the stuff they need others to take care of gets done well. Unnecessary friction that slows people down is generally a sign of management mistaking paperwork for process.

Re: It's Always the Process, Stupid

#65

Post by ronbenton »

I have done general process automation work (usually designing new web-based tools) for 20 years now. The underlying idea has always applied, even before AI: if your process is ill-defined and/or nonsensical, trying to "automate" it isn't going to work out.

I have seen a smattering of instances along the way where the act of defining requirements forced companies to define processes better. Usually, though, companies are unwilling to do this and instead will insist on adding flexibility to the automation tooling, to the point where the tool is of no help.

Re: It's Always the Process, Stupid

#66

Post by DenisM »

> There is no such thing as an AI strategy. There is only Business Process Optimization (BPO).

Here’s your Ai strategy: every few months re-evaluate agent fitness and start switching over. Remember backstops and canaries.

Details:

Businesses usually assign responsibilities to somewhat flaky employees, with understanding there will be a percentage of errors. This works ok so long as errors don’t fluctuate wildly and don’t amplify through the system. Most business processes are a mess and that works ok.

Once agents become less flaky and there are enough backstops to contain occasional damage business will start switching.

Re: It's Always the Process, Stupid

#67

Post by dclowd9901 »

wavemode wrote: post #10
chrisweekly wrote: post #5

> Let’s rip the Band-Aid off immediately: If your underlying business process is a mess, sprinkling "AI dust" on it won’t turn it into gold. It will just speed up the rate at which you generate garbage. In the world of Business IT, we get seduced by the shiny new toy. Right now, that toy is Artificial Intelligence. Boardrooms are buzzing with buzzwords like LLMs, agentic workflows, and generative reasoning. Executive…

A similar observation commonly comes up related to software development - "it's not tech debt, it's org debt" (or to put a different way, "trying to use a technical solution to solve a social problem").

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?

Re: It's Always the Process, Stupid

#68

Post by zkmon »

watermelon0 wrote: post #15
zkmon wrote: post #7

This should go to all CEOs. They should realize that the real problem AI solves is handling of text and unstructured data. That is the core ability. But I don't blame them. Process optimization is hard. If a new tool promises more speed, without changing the process, they are ready to pour money at that.

Text and unstructured data is mainly related to NLP/LLM, not to the AI as a whole.

If you take out LLM (text/img/voice processing) from all the models, I'm curious to know, what else is left that can be called as AI today?

Re: It's Always the Process, Stupid

#70

Post by dragonwriter »

dclowd9901 wrote: post #67
wavemode wrote: post #10

Earlier quoted context omitted.

A similar observation commonly comes up related to software development - "it's not tech debt, it's org debt" (or to put a different way, "trying to use a technical solution to solve a social problem").

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?

> 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.

Post reply on HN