Own the problem, not the solution

I don't understand what the author is trying to say with this post.

"Don't be a solution looking for a problem"?

Okay, but there's little insight beyond that pithy statement, no guidance of how to avoid that trap, just an anecdote that someone did that once?

Or is the point the middle about Kubernetes? The author brings up questions and says:

> What problem was Kubernetes trying to solve? How did the solution address the problem? What problem was Agile trying to solve? How did the solution address the problem? It’s only by examining these questions can an organization make the solution their own.

But then doesn't go onto to actually examine or explore these questions in the blogpost, just moves on and ignores those questions after bringing them up.

Overall, this post feels half-baked. The author seems to want the audience to do the work in fleshing out his thoughts.

What does it mean to "own the problem" and what advantage does that have over "[owning a] solution".

When I read the title, I immediately went to medical care. Many doctors, hospitals, practices, insurance companies, etc. all own the solution not the problem. I once went to an eye doctor with blurry vision in both eyes. The doctor examined me, had a solution, got paid by the insurance company. There was only one problem. My vision was still blurry in both eyes. He told me my eyes were fine. He owned the solution but not the problem. I later realized I had started a new med and stopped it. The blurry vision went away. I owned the problem.

My 2 cent biased view is that most medical care in the US - at least the kind available to us commoners - is now solution oriented. They own the solution but you still own the problem.

There are some very notable exceptions including individual doctors. One exception I have personal experience with is Mass General Hospital. It is a remarkable place. When you go in to the Emergency room, they own the problem. They basically won't let you leave the place until they have owned the problem. It is remarkable how different that experience is compared to others. You sort of have to see it to believe it. They may not be able to fix you, but the problem is no longer yours. In most cases (and I have several) they do fix it.

Once I went to the hospital, got a plan from the doctor to see someone who specialized in my condition and left. An hour later the doctor called telling me to go the ER immediately. She had called the other doctor to get his skill and

So what does this have to do with the article? I believe we, as a culture, have become to a very large extent "solution" oriented. Ozempic. We have a whole generation of obese people, including five year olds. Now we have a solution. Just put everyone on ozempic. Sure it will cost them their life savings. Sure common people will not be able to afford. Sure they can never get off it.

And that is the point of the article I believe. Don't go for solutions. Go for the problem. Why are so many people so obese now? We don't know and we don't care because we have a solution. Maybe so many people are obese because somewhere up the line people people chose to provide solutions and not fix the problem. <snark>Sugar, fat, industry owned food regulation anyone?</snark>

So maybe the point of the Cargo Cult Theory is not so much imitation, but solution fixation.

What rambling mess connects bands doing covers in various styles, cargo cults and implementing Kubernetes?

Reads like a bunch of ideas thrown together looking for a point

Sometimes Kubernetes is the answer.

I don’t need Google scale, I don’t need all the bells and whistles, but what I get is abstracting server infra, and pushing it onto a dedicated corporate wide team.

"I help private equity portfolio companies maximize growth during the holding period using their technology organization."

This sounds like a laser-focused specialization/niche, and yet no specific skill? That does explain the angle of the article.

This is how it should be and I think we should go back to this approaches. Too many buzzwords, too much agile ideology. Not that we should ignore Agile but the solution to a problem must bring in the expected value for the customer. On the other hand I feel the pressure with my clients that they go into a strategic direction with decisions for specific platforms and technologies. So sometimes you are forced to use platforms and tools which are not an ideal solution for a specific problem

Sometimes there's a perverse dynamic where you have to know a technology extremely well to use it simply, and if you can't invest time in understanding it at an expert level, you have to use it in a much more complicated way.

If you stay on the well-trodden path, using it exactly the way everybody else uses it, you get easy fixes to the problems you encounter. You google for a problem, and the conversations you find apply straightforwardly to your situation. You never have to ask your own questions, because somebody has asked them before, and the only time you have to consult the docs is to help you understand the answers on Stack Overflow. However, you have to take on the burden of implementing the same architecture as everybody else, even if it's more complex than you need. This is how my last company used Kubernetes. When I arrived, they had a functioning bog-standard Kubernetes deployment. None of the (very small) team of full-time employees understood it very well, but they were able to cargo-cult their way forward. It worked out okay. I lived in fear of the day I would have to do a deep dive into Kubernetes to solve a production outage, but it never came.

I think if we had had an expert in Kubernetes who understood the technology thoroughly, they might have been able to build a simpler solution that had fewer moving parts, fewer opportunities for failures and mistakes, while still meeting our needs. However, the downside of using a tool in a from-scratch expert way is that you have to take the same from-scratch approach to troubleshooting problems. The answers online won't apply to your setup. If you try to ask for help, people won't understand you. They might even tell you you're doing it wrong. If you tell them, "Module X is for Y, and we don't need Y. Our setup has been working fine without X for two years," they'll still say, "Your error must be because you're not using X." You'll be entirely on your own. That's how I imagine it would have been if somebody on our team invested the effort to become a Kubernetes expert and build exactly what we needed. If they left, we would have been left with a perfect bespoke solution, and we would have been screwed the first time something went wrong (or the first time our needs changed.) Again, that's not my expert opinion on Kubernetes, just what I imagine based on my experience with other complex technologies.

I think something similar to an "innovation token" is at work here. Gaining fundamental expertise with a technology and building a bespoke solution with it (making a cover song your own, in the article's analogy) is an investment of effort. Cargo-culting your way forward (playing the song just like someone else) allows you to spend that effort elsewhere, at least for a while.

TL;DR: using $thing for the sake of $thing is just elevated cargo culting.

    He didn’t worry about what the Agile Alliance said to do, he made the solution his own, and he excelled.

In other words, know what your problem is and solve that, instead of trying to force your problem into a favored solution.