It's Always the Process, Stupid

What drives me nuts is how many people can’t separate those two tasks/projects.

We’re going to write down what Step 7 currently is/does. No, now is not the time to start discussing what it ought to do. Please let us just get through sorting out what Step 7 currently is. Yes, some people do it differently. That’s why we hit a snag. Let’s just pick one of those wrong ways, document it, and do it all wrong together. We’ll fix it as a separate step. Now isn’t the time to fix it, as much as it feels like a convenient time to.

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.

Your story and the article’s thesis that AI is for acceleration and automation (not other things like design/intelligence) remind me of one particular CEO’s five step product process:

1) design smart(er) requirements- I.e beat up the ask and rewrite the problem statement correctly. 1B is every requirement has a persons name attached who is traceable/responsible for its inclusion- not a department.

2) delete features you don’t need or which are hedges (if you aren’t adding back 10% of the time, then you aren’t deleting enough)

3) simplify or optimize. This step must come after 1 and 2 so you aren’t wasting effort optimizing the wrong thing

4) accelerate

5) automate

This way is very clear where AI plugs in- and more importantly, WHEN it plugs in.

Also, plenty of times people try to run this process backwards, with poor outcomes.

Writing is such a powerful and often underrated and underutilized tool; I don't think it's an overstatement to say that it's at par with fire and should be in the top 5 of all-time humanity inventions/discoveries.

Feynman's Algorithm:

Write down the problem. Think very hard. Write down the solution.

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 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 customer has a single customer number. Between mergers, acquisitions and shutdowns it was impossible to keep straight and keep tracking history. It impacted rates, contracts, sales commissions, division revenue-everything. In they end they gave everyone a new number while still using the old ones.

Almost every problem a modern corpo has can be solved with an appropriate head-count of appropriately trained/educated people, and that's why none of them get solved.

The processes suck because of decades of corner cutting and "fat" trimming while the executives congratulate themselves for only making the product a biiiit worse in exchange for a 0.0005% cost reduction, before then offsetting any gains by giving themselves all the money that would've gone to whatever is now dead.

Repeat this process for 30 years and you have companies like Microsoft that can barely ship anything that works anymore, and our 4 Big Websites frequently just fail to load pages for no explicable reason, Amazon goes down and takes 1/3 of the internet with it, and AI companies are now going to devour the carcass of our internet and shit it back to us in LLM waffle while charging us money for the privilege to eat it.

There is an ai strategy if you are selling hype instead of products.

Although I very much agree with the sentiment "here's the hard truth" is LinkedIn speak/ LLM-tell to me

I feel like this is an inside view from the BPO community and the only part of AI they see is the part that affects BPO. But for most businesses AI strategy is not about AI for internal use but AI to either improve customer funnels or launch new products. Most of the companies I've talked to in the past year wanted a strategy for customer facing AI not internal AI.

It can both be Business Process Optimization and an AI strategy.

In fact, if an AI strategy becomes business process optimization, I'd say that AI strategy for that company is successful.

There are too many AI strategy today that isn't even business process optimization and detached from bottom line, and just being pure FOMO from the C suite. Those probably won't end well.

The Agile Manifesto says "People over process", this can be interpreted in many ways. But ideally you follow the 80/20 rule and have clear cut processes for the most frequent cases and/or liability/law/SLA stuff you can't do without. But you should have fast escape hatches as well imo where a good engineer having admin access on a platform or deploying a hot-fix is also possible.

Providing the rockstars with a sandbox where they can do anything and work independently, while being shielded from all the processes and paperwork that slow them down (while also having people to pull that slack), is a fairly good method, but depending on the work that isn't viable. Their work has to come out of the sandbox at some point, and there will be some back-and-fourth which will probably put blocks on the team in that case.

I doubt there's much to do about the specific process that can be done to minimise the problems of the rockstars without also causing problems further down the ladder, without just starting to make exceptions like you said. It's probably just an emergent behaviour of processes like this intended to raise average quality. You pull up the bottom floor, but the roof gets lower as a result. You can find similar problems in schooling.

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

One thing process protects against is lazy people.

Like, we recently had an incident where someone just pasted "401 - URL" into the description and sent it off. We recently asked someone to open the incident through the correct channels. We got a service request "Fix" with the mail thread attached to it in a format we couldn't open. We get incidents "System is slow, infrastructure is problem" from random "DevOps" people.

Sadly, that is the crap you need to deal with. This is the crap that grinds away cooperative culture by pure abuse. Before a certain dysfunctional project was dumped on us as "Make it Saas", people were happy to support ad-hoc, ambitious and strange things.

We are now forced by this project to enforce procedure and if this kills great ideas and adventures, so be it. The crappy, out-of-process things cost too much time.

“statistically, most people are going to be around average”

In big corporate environments, ‘around average’ process would be a radical improvement. We are stuck in the reality where standing up a Service Now form is considered great progress.

I think it is a managerial failure to have rockstar-type employees work the menial, process-managed stuff. Those should work on the unusual, the new, the moonshots. Stuff that has not yet been formalized in BPMN 2.0

Best lines in this article. But it doesn't get to IMO a very important point: why can't these processes easily be structured? Here are some good reasons:

- Your process interacts with an unstructured external world (physical reality, customer communication, etc.)

- Your process interacts with differently structured processes, and unstructured in the best agreed transfer protocol (could be external, like data sources, or even internal between teams with different taxonomies)

- Your process must support a wild kind of variability that is not worth categorizing (e.g. every kind of special delivery instruction a customer might provide)

Believing you can always solve these with the right taxonomy and process diagram is like believing there is always another manager to complain to. Experienced process design instead pushes semi-structured variability to the edges, acknowledges those edges, and watches them like a hawk for danger.

We should ABSOLUTELY be applying those principles more to AI... if anything, AI should help us decouple systems and overreach less on system scope. We should get more comfortable building smaller, well-structured processes that float in an unstructured soup, because it has gotten much cheaper for us to let every process have an unstructured edge.

This doesn’t ring true to me. Having processes which rely on communication between humans using natural language can of course be either structured or unstructured. Plenty of highly functioning companies existed well before structured data was even a thing.

That's why you need consultants to tell you that <buzzy-technique> has problems, but <rebadged-buzzy-technique> is really how you save money, and that's why working with a <rebadged-buzzy-technique> expert is how you can overhaul your business and manage operational costs.

I think this is what I’m running into. Other teams want my team to make tooling to simplify some data processing workflow. Nice UIs and such. But they can’t and generally won’t show me the written-down process for how it’s actually done today. Or how they’re going to do it manually as they develop their side of things.

Which leads us to turning into a different team: we have to go figure out what the process engineering even is, which means becoming a bigger expert than they are at the process they want us to make tooling for.

Question: could you use something like (example) Selenium to perform some or all of those pre-LLM tasks?

Well, that’s a pretty powerful capability.

I recently did a pilot project where we reduced the time for a high friction IT Request process from 4 day fulfillment to about 6 business hours. By “handing text and unstructured data”, the process was able to determine user intent, identify key areas of ambiguity that would delay the request, and eliminate the ambiguity based on data we have (90%) or by asking a yes/no question to someone.

All using GCP tools integrating with a service platform, our ERP and other data sources. Total time ~3 weeks, although we cheated because we understood both the problem and process.

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

In fairness, that is an extraordinary talent. The reality is that a huge amount of processes that exist have critical steps where humans have to make judgments because the information (was thought to be) not clear and structured enough for a machine.

For many processes that have just suddenly changed, somewhat subjective evaluations can be made reliably by an AI. At least as reliably as was being done before by relatively junior or outsourced staff.

Replacing low-level employees relying on a decision matrix playbook-type document with AI has a LOT of applications.

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?

It’s written in English by a German-speaking author. That could be the odd lilt you sense.

Yeah

If your answer requires clustering and assembling disparate facts strewn about on the internet or company data / documents and reasoning over them, then LLMs can help that. Atleast that's what I did when I used to answer questions on stackoverflow.

How is what you linked a business process? Cancer identification is a step in a larger process, specifically the "analyze unstructured data" part that the author alludes to.

AI won't take a shoddy process (say, your process for reviewing and accepting forms from patients) and magically make it better if you don't have an idea of what "better" actually entails.

"Improving a system requires knowing what you would do if you could do exactly what you wanted to. Because if you don't know what you would do if you could do exactly what you wanted to, how on earth are you going to know what you can do under constraints?"

- Russ Ackoff