Reading · Data according to me...

The latest buzzword is “flow state”. Everybody is entering flow state now. With or without being fueled by caffeine, it’s beautiful to see?? Haha

Welcome to another of my whimsical thoughts.

We are so deep in creating now that no amount of talk can stop it. Webs of n8n nodes, agents, and so many API calls. We are racing to outsmart the system, and I spy with my little eyes an albatross.

In Coleridge’s Rime of the Ancient Mariner, the sailor shoots the albatross, which is considered a bird of good omen, and as punishment, he’s forced to wear its carcass around his neck.

So, what is Albatross management in tech or modern data and software management? It’s the art or curse of maintaining the “helpful” systems we built, only for these systems to become heavy, stale, and impossible to take off.

Where have you seen this before? In your systems.

It’s a feature that becomes a dependency; nobody trusts it, but still uses it because it feels easier to accommodate it than to remove or rebuild it.

And on that note, this article is about rebuilding.

What makes these things an issue is everything that has grown around it. Assumptions, queries, definitions, habits, and their meanings. It’s convenient.

You can’t just delete it because you could lose reference points, even if it’s not a solid one, but it makes you nervous thinking about it, and it’s still doing some work.

The albatross is not “the” bad decision, I think they are beautiful birds, but when we stop revisiting the weight on our necks and still make decisions with it, then bad things start to happen.

Oh! This can be applied to a number of cases outside of tech.

Albatross usually starts as a brilliant piece of work, never a mistake. AI agents, recoded scripts, automation nodes, anything that’s the best option at that time, etc. But tech seems to move fast, and soon, we start changing tokens, updating APIs, and start setting it and forgetting about it.

It works smoothly, we have a good time, and months later, we spend more hours debugging, managing, and prompting. At this point, you are not managing a workflow anymore, but taxidermying a dead bird.

How do you know you’re managing an albatross?

1. Jenga fear. When it has become too inconvenient to question. Once you start worrying about updating a library version because you know that this is going to wreck your custom code, then there’s a dead bird on your neck.

2. Debt of documentation. I think no matter how many times it’s said, this is never going away, but when you’re the only person who understands how the data flows, and every time something has to be updated, you’re the only one who can touch it, so it doesn’t implode, we have a dead bird on our necks.

3. Spending more time fixing the automation than even manual work? You guessed right.

So, systems you hesitate to ask questions about, when you start saying “it’s always been like that” very quickly, and when it can cause disruption if it’s removed.

Remember, it’s a bird of good omen. Just like vibe coding. But it shouldn’t come dread everytime you think about it. Some of the costs are low and isolated enough to tolerate, and when this is the case, the goal should be awareness, not perfection.

Know which parts of your system are carrying history, even though they no longer deserve to be there, and let others know. You want to recognize when you’re making decisions within technical or business constraints, and be deliberate about what you choose to keep.

Example, by quantifying hidden costs or running a parallel system that shows the discrepancies and how moving on is re-direction.

Or, hear me out, occasionally, just saying out loud what everyone suspects and no one has said: “This thing is weighing us down.”

What we can do is:

1. Build with an exit strategy: What happens if it breaks, or you have to start again?

2. Audit: as you build, make time to look at what your automations. If it’s not saving you, then let it go. It’s hard, but just like a dead albatross, it’s dragging you down.

3. Make the cost visible in a way that’s hard to ignore. Sometimes it’s not a better model, often times, it’s a simpler but competing one.

4. Prioritize human clarity. This needs no explanation.

And if you have to kill it, give people a reason to let go that feels safer than holding on.

There’s always that temptation to treat things as a technical problem. Retrain the model or do what data engineers do: fix a pipeline. And sometimes it works, but other times, the system is doing what it was optimized to do.

I think innovation shouldn’t always be about building things from scratch; sometimes it's knowing when to drop the bird.

For example, very techie people sometimes reject no-code or templated solutions because, I hate to say this, they feel it’s too simple, limited, or beneath their skill level or problem. (That felt heavy to say.)

BUT, there’s a specific brilliance in simplicity, and sometimes that’s what we worry about. Not that the old thing still works, but that we would rather build around it than choose a simpler way forward.

If you’re building a business, or an AI agent, you don’t need more clever problems, there are enough human problems, you can and should absolutely build from an existing solution, when it serves you.

A good intervention can be a narrative. Telling a better story than “this is how we’ve always done it” is part of the work.

It’s possible that the albatross was, at some point, you or/and your team’s best idea, and could still be, given the constraints at the time. But time moved on, and the system didn’t, and that gap between past intention and present reality lives the dead bird. Ironic. A dead bird living.

Managing them isn’t about blame. I believe it’s honesty and maturity that you are refusing to let past logic make current decisions. And that’s good work.

Not every albatross should be shot, you can have clearer labels for them or isolate them. Decide whether it’s still doing useful work, or whether it has become part of the work for no good reason. That is good work.

Aligning people around the cost of keeping something versus the cost of removing it is good work.

Don’t let your brilliance become a burden. Some things can be maintained, others questioned, and let go.

The ocean is big enough for new flights, and in that same flow state energy, pivot.

Why do you think we have new app updates every week?

Alright! Thanks for reading, and if you have a heavy bird in your tech stack or a jenga fear, share in the comments. We can laugh, learn, and fly.

Adios amigas x

Enjoyed this? I’m currently building a series of data tools using an entirely AI-orchestrated workflow.
Subscribe for the drafts, successes, failures, design choices, and finished product.

Up next on data according to me will be Intro to Git vs GitHub.

ICYMI

2026 Substack publishing system

Setting up shop for data science in 2026

January 9th or Quitter’s day?