Searching for Cheap Tricks

The amount of AI content and conversations out there is getting exhausting. It’s almost as bad as the burbling font of platform engineering content that gets rewritten and published each week. The below RAND paper and commentary got me thinking though: a lot of the AI talk is just talk about applying new technologies in general.

We are still really bad at the basic task of communicating requirements to developers, checking in on their work and seeing if they’re solving the right problems in a helpful way…and even knowing what business problems to need attention in the first place.

Here’s an email I wrote to a friend on this:

Re: my prodding to figure out cheap tricks for getting organizations to improve how they use computers, this paper has a few theories of why AI projects fail. I feel like you could do a search and replace for "AI projects" to just "IT project" and the same could be said. The core, non technical problem is two sided:

(1) getting non-technical leadership to understand what AI can do, how much effort it takes to do the work, and most importantly how to properly set the requirements: making sure you solve the right problem in the right way. This last part is the mystic "understand what you're doing, the point of it, the why's of your business." Like we were talking about last night in the backstreets of Antwerp, my theory here is that if you asked most people in a business "how does the business operate and function each day?" they would have poor answers, let alone answers that an AI could do anything with, or that programmers could do anything with.

(2) the technical people are unable to "speak the language of business" and get the people in #1 to "speak the language of IT." I'm sure this is a lack of communication, facilitation, and interpersonal skills ("managing upwards"), but it probably results in the tech people not pushing back enough and drilling down to get the non-tech people to be helpful. This is the pesky thing of consultants always saying "before we talk solutions and projects, let's take a step back and examine what you really want." People are eager to fix/improve the problems, and don't often question if they're solving the right problem, nor understand the tools available to solve it. (Including the tool of continuous learning which would say "we have to use a tight-feedback loop to learn how to solve the problem).

It all amounts to introducing an ongoing "culture" of finding and understanding the problems you're solving, and a similar process of "leadership" frequently checking in to see if the tech people are getting closer to solving a useful problem, or if they're straying away from the original requirements.

One of original goal of agile software development was to address these problems: “business IT alignment” as we sometimes called in the 2000s.” On the one end, Extreme Programming had a concise, clear cookbook to follow. I like these prescriptive, “do this” approach to corporate improvement. They’re a collection of “cheap tricks” you can start applying.

However, the “fix” is to change the mindset of the company, from management to worker, to always be curious and on the hunt for how to do things better, “continuous improvement.” There isn’t always a way to do things better, and you also have to spend most of your time actually doing things.

But, there’s at least two things that most organizations could be better at:

1. Understanding what they do, the job to to be done, and how their organization does that - I have a feeling that if you asked most people, tops to bottom, at an organization “how do things really work around here?” you’d get mixed results, most of them only part of the overall picture. Can you draw out and end-to-end flow of all the activities it takes to deliver the product or service to the customer?

2. Spotting when to experiment with changes. This is applying Toyota kata and all that. The mystic version of “continuous learning” is that you’re always on the lookout for learning and improvement. But, you also have to actually do the work. You have to check out people at the grocery store, put the Fedex letter into a person’s hands, send out a plumber at the right time to the right place to unclog a sink (and then they need to unclog it), transfer money between two accounts, etc. When is it OK to stop “doing things” and work on improving things? That’s a very hard “stop the line” call to make.

I want to find a way to combine the mystic management mind-games of most corporate improvement and transformation talk with “cheap tricks” that get people to start improving and keep improving.1 This is something like “the habit of building habits.” It’s all well and good to talk about “habit stacking” and tell people that they need to establish new habits and routines. Yes, but how do I start the habit of starting habits?

Once the people in an organization have gone through the mystic experience of asking “why” or even discovering their customer’s milkshakes, what are the daily tasks and routines they do? What tools do they use? How do they actually do the work? What are the cheap tricks they can start using to be better?

Relative to your interests

• Moonbound Revisited - “Several decades ago, the semiotician A. J. Greimas claimed that all stories are comprised of six actants, in three pairs: Subject/Object; Sender/Receiver; Helper/Opponent.”

• The Forgotten Surrealist Painter Who ‘Didn’t Have Time to Be Anyone’s Muse’ - “In contrast to the tendency of Surrealism’s male artists to depict women as thin, young, fragmented, static, and perpetually naked muses, Carrington’s women fell across a spectrum: often very old, powerful and threatening, in a state of action and transformation.”

• How Platform Engineering Enables the 10,000-Dev Workforce - Vendor survey overview.

• How the buildings you occupy might be affecting your brain - “Could bad architecture also be contributing to the development of neurodegenerative and psychiatric disorders?”

• Is AI a Silver Bullet? - “This is the trade off we have seen before: eliminating the accidental complexity of authoring code has less value than we think because code spends most of its time in maintenance, so the maintainability of the code is more important than the speed to author it.”

• The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI, RAND paper - As ever, communicating the requirements and the problem to be solved to IT is difficult and often results in solving the wrong problem, at least in the right way: “In failed projects, either the business leadership does not make them- selves available to discuss whether the choices made by the technical team align with their intent, or they do not realize that the metrics measuring the success of the AI model do not truly represent the metrics of success for its intended purpose. For example, business leaders may say that they need an ML algorithm that tells them the price to set for a product–but what they actually need is the price that gives them the greatest profit margin instead of the price that sells the most items. The data science team lacks this business context and therefore might make the wrong assumptions. These kinds of errors often become obvious only after the data science team delivers a completed AI model and attempts to integrate it into day-to-day business operations.”

• Why “AI” projects fail - “And we’ve been doing this for decades now, with every new technology we spend a lot of money to get a lot of bloody noses for way too little outcome. Because we keep not looking at actual, real problems in front of us – that the people affected by them probably can tell you at least a significant part of the solution to. No we want a magic tool to make the problem disappear. Which is a significantly different thing than solving it. Because actually solving a problem includes first fully understanding the reasons for the existence of the problem, reasons that often come back to an organizations’ structure, their – sometimes inconsistent – goals and their social structure in addition to actual technical issues.” And: “AI is so good at writing summaries of all the meetings I can then have summarized afterwards to understand what was going on” says that your organization has probably too many meetings that are not structured well and that you don’t think that understanding why people say a thing, how they present their case is important (which makes you a bad manager).”

Per Request

Wastebook

• “Progressive doomerism.” Here, but, interestingly it was my perplexity.ai summarizer that came up with that phrase which did not exist in the article.

• “I want to stay little like this. I don’t want to get bigger.” My four year old.

• “Dystopian hod-rod races.” Apple Music summary of Liquor in the Front.

• Similar to “resume-driven development”: “Given the demand for new AI projects, interviewees reported prioritizing projects that grab headlines, improve reputation, and increase institutional prestige. We refer to this as activity prestige, which is the amount of positive attention given to some projects based on the public demand for those projects' outcomes.” Here.

Logoff

I’m in Antwerp for DevOpsDays Antwerp. This is the 15th year anniversary of DevOpsDays, so I wanted to attend. I’m lucky that they accepted a five minute talk from me as well. In the talk, I’m trying to answer the question “has DevOps made things better?” I do that by looking at changes in the DORA clusters, but more importantly, changes in how those clusters are made (thanks to some help from Steve Fenton and Nathen Harvey understanding how that is all done and, thus, a more accurate y/y analysis).

And, then, of course, I give some advice on what the DevOps community should focus on now. These are just two points I talk about a lot here: (1) make sure you actually have build automation in place, because it seems like many people don’t, and, (2) stop building new platforms and just use pre-built ones. If there was a third common theme for me, it’d probably be something like “start the practice of product management” this despite how difficult, even impossible, that seems.

//

There are two Brueghels in Antwerp, at the Museum Mayer van den Bergh. First, it’s a great museum if you’re into Flemish and Dutch golden age paintings. The building itself is a nice Netherlands canal house style building. The two paintings are Mad Meg and Twelve Proverbs.2 Here is Mad Meg:

Seeing pictures like these is much different in real life than online or even in books. It’s not that much different so as to be divine or anything: you just see some new things like textures and your field of vision either gets bigger or smaller. For example, with Mad Meg, you can really get in there and study the countless micro-scenes. In contrast, with Twelve Proverbs, you can see how basic and simple the pictures are; unlike the Brueghels most everyone knows, these pictures are not chaotic and “alive.”

Anyhow.

If you like that kind of thing, you should check out on of my favorite books, Short Life in a Strange World. If that book is a good fit for you, while it’s a bit mystic, it’ll help you enjoy “art” in new ways. If you just want the cheap tricks, check out the equally good Art as Therapy.