Forem: luk-f-a

Good reasons and bad reasons for Risk Management (RM series #1)

luk-f-a — Sun, 05 Nov 2023 17:25:19 +0000

I recently left a job in Risk Management. Mostly because the name was misleading, but that's a story for another day.
Having just left, I want to write —first of all for myself— what I learned. Just in case I need it one day in the future. Hopefully it will also be useful to others.

Everyone does risk management every day. If we have had a great sandwich for over a week in the fridge, we wonder: should I eat it? Pros: it was delicious. Cons: it might make me sick.

We weigh what can go wrong and what can go right and then make a decision. Companies do that too. Some companies establish a special department called "Risk Management". Ironically, sometimes they do manage risk, and sometimes they do not.

Note
Before I continue I must clarify that the rest of the post is partly serious and partly tongue-in-cheek. Which part is which is left as an exercise for the reader. Risk Management is a very important activity, and it is REALLY hard to do well. I will write about the latter in another post.

From my own experience and from talking to others, I have learned that companies have a whole bunch of reasons for setting up a Risk Management department. Some reasons are better than others.

What are the good reasons?

A company is a complex web of relationships that, hopefully, delivers some valuable product. If one part of the company fails so spectacularly such that it brings down the whole company, that would be bad for shareholders and bad for society. Society would lose a provider of whatever it was the company was making. Shareholders would have to re-organize the company, which is expensive and quite distracting from the core purpose of making whatever-it-was-that-it-was-making -for-society. Spending some effort up-front in not blowing up is worth it, on a net present value basis.
Most employees would also prefer that the company does not blow up tomorrow. However, many employees would not affected by the company blowing up in 20 years. There are some jobs that are able to create problems decades in the future. Those employees have an incentive to maximize their income today, whatever the cost for the company might be in 20 years. If you can increase sales of cancer-inducing powder or destructively additive medication and get a fat bonus for your efforts, maybe you will choose to do it, whether the company will be sued into oblivion or not. Spending some effort in stopping these guys before they harm the company is worth it.
Some employees do not even care if the company blows up tomorrow. They will get a job elsewhere. Ironically, they might get a better job afterwards, as Matt Levine argues sometimes. Spending some effort in stopping these guys before they harm the company is definitely worth it.

These are all great reasons for having a Risk Management team. There are more, but I don't intend to make this a book on risk management.

After almost 20 years in the financial industry, I can also enumerate some bad reasons to have a Risk Management team.

Bad reason #1: "Something might go slightly wrong somewhere". Most humans are risk-averse, which means they will rather have certainty over uncertainty. We also enjoy the feeling of improving something, large or small. When faced with the news that something somewhere has gone wrong, many people think "how could we make sure that this never goes wrong again?". That's a noble thought but sometimes misguided, especially in large companies. When we do risk management in our daily lives, we are impacted by the good and the bad. We might enjoy the sandwich, or get food poisoning. We have skin in the game. It is not the same in a company. If we hire a bunch of people and tell them it's their job to stop bad things from happening, it might play out in this way:
- first they try to stop really bad things from happening, which mostly means illegal behavior and bets that would bankrupt the company.
- without any real means of proving the counterfactual "if we weren't here, this company would be broke by now", they slowly develop a mentality that risk management is "always and everywhere a desirable phenomenon". Over time, they get used to being valued by what they do, not what they achieve.
- lastly, either out of the genuine desire to stop bad things from happening or a genuine desire to get a promotion, the scope of "bad things that should be stopped" starts to grow. And with that the size of the team. And with that the procedures they impose on the rest of the company. And with that the cost for the company, both in direct compliance cost and in lost business opportunities. Left unchecked, after a few years it's likely that your well-intentioned Risk Management team has written endless documents and cost millions of dollars in procedures to avoid pens from being misplaced (don't laugh, that's a real risk with real financial consequences!).

How could this happen? It's quite simple, the Risk Management team is only looking at the downside of things. And it's only being rewarded for doing something about it. Not for effectively tackling the worthwhile problems but for doing something about anything that could be argued it might be a problem.
The cost-benefit trade off does not work for a centralized Risk Management team to take care of minor loses and inconveniences. It is a bad reason for having an RM team. In statistics lingo, RM should take care of the tail, not the body of the loss distribution.

Bad reason #2: to shield top management in case something bad happens somewhere. Top management is made of humans. No matter how clever they are, how much they love the company, or how hard they work, they cannot be everywhere. Some tasks have to be delegated to less clever, less company-loving or less hard-working people. Something will go wrong eventually. What it is really important in that in case, is that everyone can say that they followed proper procedure. That is the only chance at saving their jobs after some embarrassing incident. Governance was followed is the line that will allow the C-suite level to save face (it does not always work but it usually does). I rank this as another type of principal-agent problem. It's not worth for the shareholder to spend millions to prevent the C-suite from being embarrassed. The shareholder would be better off saving the cost of the burdensome internal compliance with endless and ill-conceived governance, and absorbing the occasional loss. If the C-suite is occasionally embarrassed by something outside of their control, then so be it. The shareholder is already paying them millions, they should learn to live with it.

Bard vs ChatGPT: round 1

luk-f-a — Thu, 11 May 2023 20:22:49 +0000

Last night I ran a very quick, unrigorous, unscientific, and maybe even unfair comparison between Bard and ChatGPT.

LLMs do particularly well in those cases when we need something quick and simple in a tool we know little about. And I happened to have such a case: a simple website using htmx and fastAPI.

This is not going to be a long post, so I'm jumping directly to the two things that caught my attention:

Bard missed the prompt, and ChatGPT did much better.
ChatGPT asked me relevant questions to confirm understanding, Bard did not.

Bard missed the prompt

I asked Bard to use htmx. It kind of complied, but not really: it linked to htmx but did not use it.

    <h1>Function analyzer</h1>
    <input type="text" id="contract" placeholder="Enter a contract">
    <button id="analyze">Analyze</button>
    <div id="tree"></div>

    <script src="https://cdnjs.cloudflare.com/ajax/libs/htmx/1.8.0/htmx.min.js"></script>

Where are my htmx attributes Bard? All the logic is done in JS, which I wanted to avoid.

full body

<body>
    <h1>Function analyzer</h1>
    <input type="text" id="contract" placeholder="Enter a contract">
    <button id="analyze">Analyze</button>
    <div id="tree"></div>

    <script src="https://cdnjs.cloudflare.com/ajax/libs/htmx/1.8.0/htmx.min.js"></script>
    <script>
        const contractInput = document.getElementById("contract");
        const analyzeButton = document.getElementById("analyze");
        const treeDiv = document.getElementById("tree");

        analyzeButton.addEventListener("click", () => {
            // Get the contract from the input box.
            const contract = contractInput.value;

            // Make a request to the backend to get the tree view of the contract.
            fetch("/function-tree", {
                method: "GET",
                body: JSON.stringify({
                    contract: contract
                })
            })
            .then(response => response.json())
            .then(tree => {
                // Render the tree to HTML.
                const html = render_tree(tree);

                // Insert the HTML into the tree div.
                treeDiv.innerHTML = html;
            });
        });

        function render_tree(tree) {
            // Create a new ul element.
            const ul = document.createElement("ul");

            // Iterate over the tree.
            for (const key in tree) {
                // Create a new li element.
                const li = document.createElement("li");

                // Set the text of the li element to the key.
                li.textContent = key;

                // If the key is a dictionary, recursively render its children.
                if (typeof tree[key] === "object") {
                    li.appendChild(render_tree(tree[key]));
                }

                // Append the li element to the ul element.
                ul.appendChild(li);
            }

            // Return the ul element.
            return ul;
        }
    </script>

How did ChatGPT do? It did a good job, even if I had to edit the code to fix some bugs.

    <h1>Function Analyzer</h1>
    <label for="contract">Contract:</label>
    <input type="text" id="contract">
    <button hx-post="/function-tree" hx-trigger="click" hx-target="#treeview" hx-swap="outerHTML">Analyze</button>
    <label for="search">Search:</label>
    <input type="text" id="search" hx-post="/function-tree" hx-trigger="keyup changed delay:500ms" hx-target="#treeview" hx-swap="outerHTML">
    <div id="treeview"></div>

Note the hx-post (which I changed to hx-get), hx-target and hx-swap which are some of the basic elements of htmx.

ChatGPT asked good questions

My prompt included the following request in the last paragraph:

Your first task is to confirm your understanding of the task, by asking any questions that might be necessary, and then providing a design document. Once the document is confirmed by me, you will write the code.

ChatGPT asked good, relevant questions:

To confirm my understanding of the task and provide a design document, I have a few questions and a proposed design.

Questions:

1. Are there any specific design requirements for the website (e.g., colors, fonts, layout)?
2. Should the search functionality filter the tree view in real-time as the user types in the search text box, or should it only filter after pressing a "Search" button?
3. Is it required to use any specific front-end libraries or frameworks, other than htmx?

Bard was kind of pedantic about it:

I understand the task as follows:
[...]
Do you have any questions about my understanding of the task?

I'm giving round 1 to ChatGPT for following the prompt in terms of asking questions and using htmx as requested.