Live data from Hacker News

It's Always the Process, Stupid

its.promp.td

71–80 of 123 posts

Re: It's Always the Process, Stupid

#71
post #64
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 who…

Very often paperwork is the necessary process. I’ve seen multiple engineering teams who used to accept essentially any customer escalation, for example, until they found themselves essentially being DDoSed by poorly explained tickets filed at much too high of a priority. Now they have forms that customer-facing folks have to fill out explaining in detail what’s going wrong, why an escalation is required, and naming the senior person who’s accountable for the accuracy of that form.

Is it slow and annoying to jump through these hoops? Without a doubt! I’ve also seen people on the other side of the process who are very frustrated that they can’t just escalate when they know devs would want to hear about it. But it’s not acceptable for people to get woken up every week because the new support engineer filed a customer error as a global outage, and smart people tried and failed to put a stop through it through training. I don’t know what the alternative could be.

Re: It's Always the Process, Stupid

#72

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…

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.

Re: It's Always the Process, Stupid

#73
post #46

Earlier quoted context omitted.

I'm going to argue that, at scale, process beats the quality of the people you're using -- and also that there are toxic cultures, around Google and C++, where very smart people get seduced into spending all their time and effort fighting complexity, battling 45 minute builds, etc.

> and also that there are toxic cultures, around Google and C++, where very smart people get seduced into spending all their time and effort fighting complexity, battling 45 minute builds, etc. Not sure what you mean here. "Fighting" as in "seeking to prevent", or "putting up with", or what exactly? Is this supposed to be bad because it's exploitative, or because it's a poor use of the smart person's time, or what ex…

Essentially that the idea that people can hold 7 + 2 things in their head simultaneously is basically true such that when your tools make a demand on your attention it subtracts from the attention you can put on other things.

There are many sorts of struggle. There is struggle managing essential complexity and also the struggle, especially in the pre-product phase, of getting consensus over what is "essential" [1] When it comes to accidental complexity you can just struggle following the process or struggle to struggle less in the future by some combination of technical and social innovations which themselves can backfire into increased complexity.

Google can afford to use management techniques that would be impossible elsewhere because of the scale and profitability of their operations. Many a young person goes there thinking they'll learn something transferable but the market monopolies are the one thing that they can't walk out with.

[1] Ashby's law https://www.edge.org/response-detail/27150 best exemplified by the Wright flyer which could fly without tumbling because it controlled roll, pitch and yaw.

Re: It's Always the Process, Stupid

#74

Earlier quoted context omitted.

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 inform…

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

Re: It's Always the Process, Stupid

#75

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…

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

Re: It's Always the Process, Stupid

#76
post #66

> 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 d…

Bold presumption that businesses have any useful way to evaluate agent fitness. Hell, they struggle to evaluate human fitness and do basic things like plan and execute OKRs. What makes you think they’d be any good at continuous quality improvement on entities that can’t correctly explain their own reasoning?

Re: It's Always the Process, Stupid

#78

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.

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

Re: It's Always the Process, Stupid

#79

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

I worked for a fortune 300 company that engaged in a Business Process Redesign initiative. After spending 90 million on the project they pulled the plug. My takeaway was that the project was doomed because it was named wrong. Should have been called Business Process Design. They are now owned by Private Equity. I can only wonder what madness the would have wrought with AI. They tried to implement a system whereby a c…

Relevant in so many contexts: https://xkcd.com/927/
Post reply on HN