Management = Bullshit (LLM Edition)

I've seen this happen in emails too:

"Recent outage was due to a retry loop for the Foo API exceeding rate limits. We're implementing a backoff algo"

Sender, via ChatGPT:

Hi,

I wanted to provide more context regarding the recent outage.

The issue was triggered by a retry loop in the Foo API integration. When the API began returning errors, our system initiated repeated retry attempts without sufficient delay, which quickly exceeded the rate limits imposed by the API provider. As a result, requests were throttled, leading to degraded service availability.

To address this, we are implementing an exponential backoff algorithm with jitter. This approach will ensure that retries are spaced out appropriately and reduce the likelihood of breaching rate limits in the future. We are also reviewing our monitoring and alerting thresholds to detect similar patterns earlier.

We’ll continue to monitor the system closely and share further updates as improvements are rolled out.

Best regards,

Receiver, via ChatGPT:

"The outage was caused by excessive retry attempts to the Foo API, which triggered rate limiting and degraded service. To prevent recurrence, exponential backoff with jitter is being implemented"

Recycling a prediction from a year ago:

> Ultimately a lot of this generative tech stuff is just counterfeiting extra signals people were using to try to guess at interest, attentiveness, intelligence, etc.

> So yeah, as those indicators become debased, maybe we'll go back to sending something [...] all boiled down to bullet points.

This is how society collapses and OpenAI wins.

Funny how encoder-decoder architectures have led to decoder-encoder behaviors.

This is the kind of thing my manager and skip manager are up to. Most of our jira tickets now are written as a random jumble of ideas, fed into internal proprietary LLM and then turned into jira description and acceptance criteria. Totally pointless

Wow. Full circle

I would be interested to know more about the authors employment.

As a small business owner, my DR plan is oriented to reasonably preventing getting locked out or screwing things up for customers in the event of an emergency.

I learned a lot about what to do and what not to do leading SOC 2 Type 2 audits at a large firm.

Our auditors handed us a bunch of templates that they had purchased from an even larger firm. They said we could adopt them verbatim, but that we should at least read and probably modify them.

Management was… stressed… that we had paid close to $100,000 for that to be their policy “analysis”. I was tasked to read through all their templates and sort out what was and wasn’t necessary, compare to how we actually did business and what we gave two shits about, and produce work that closed the gap. (That’s another story; turns out it’s really hard writing policy for a business where both (active) founders and the CEO are looking for different things.)

It helps to plan for abstract scenarios, like “we lost the office but the people are alive”. Or “we lost all facilities and people in this state, but not the next one over”.

It also really helps to have management who understands the reality that not everything can be planned for, and that any DR strategy worth its salt has some kind of line in the sand beyond which you can’t do anything.

I’ve used LLMs to generate text for a soc2 audit about our processes. For one requirement, it took me 20 minutes to produce 8 pages that otherwise would have taken hours at least. This wasn’t misrepresentation or anything - more like here’s the requirement, here’s a summary of what we do, describe specifically how that meets the requirement. Outside of coding, it’s a perfect application for the tech.

They're like backups, in that they don't actually exist unless you've tested them.

A copy-pasted plan is actually fine, as long as whoever's responsible for following it actually can follow it and it works.

A plan that nobody's even looked at much less tried to follow isn't fine. Even if it's word-for-word identical to one that is fine.

The problem is, it's not necessarily the job of the person who is tasked with doing it.

These are the kind of things that fall between the gaps in smaller companies and there's no expert to build this disaster recovery plan because there is no risk or compliance department.

It falls into the lap of whomever is dealing with the audits or whoever has a reputation for getting things done and unblocking people.

People will down vote you, but when I worked for a mega corp and a hurricane knocked out our office, they had a plan, and it worked: they set up in a hotel, and continued operations, people stayed employed, people got the products (which were largely essentials) in their supermarkets, etc.

This is not like, super trivial. People needed to figure out power, hardware, networking, vpn, etc.. etc.. etc.. and staffing. A lot of that had absolutely nothing to do with IT, but some of it did.

The real management failure is taking a problem and assigning it to someone who has no interest in solving it. There's plenty of people interested in working on these kinds of things. Why waste this guy's time.

middle manager spotted ^

That’s a clever way to burst both the AI bubble and the startup bubble all in one fell swoop.

Theoretically the EM is building the department to do what the company needs, using departments or groups of engineers as the Lego pieces. Good ones are able to keep improving capabilities and keep good engineers at the company. But often they’re just surfing success they had little to do with, and it’s usually an inflated title at small companies.

It's really just monitoring you. A designated technical lead on your team can be very helpful, but once someone moves off the dev team but also isn't able to make any decisions from the product/business side they just become dead weight. I have the same issue with my EM trying to get coaching and visibility and have gone to LLMs just like you because manager is clueless.