Rajanand Ilangovan
@rajanand.org
Lead Data Engineer ==> Data Architect
https://rajanand.org/substack
https://rajanand.org/substack
Pinned
Hello,
I’m using this space to share how I think about work.
Not tools.
Not hacks.
Frameworks, mental models, and ways to turn execution into real impact.
If you’re good at what you do but feel stuck in task mode, this will be for you.
I’m using this space to share how I think about work.
Not tools.
Not hacks.
Frameworks, mental models, and ways to turn execution into real impact.
If you’re good at what you do but feel stuck in task mode, this will be for you.
The illusion of “we should have known”
“We should have known” feels insightful.
It isn’t.
It assumes today’s knowledge was available yesterday.
It flattens uncertainty retroactively.
Every decision is made inside a container:
Available information
Active constraints
“We should have known” feels insightful.
It isn’t.
It assumes today’s knowledge was available yesterday.
It flattens uncertainty retroactively.
Every decision is made inside a container:
Available information
Active constraints
January 13, 2026 at 10:30 PM
The illusion of “we should have known”
“We should have known” feels insightful.
It isn’t.
It assumes today’s knowledge was available yesterday.
It flattens uncertainty retroactively.
Every decision is made inside a container:
Available information
Active constraints
“We should have known” feels insightful.
It isn’t.
It assumes today’s knowledge was available yesterday.
It flattens uncertainty retroactively.
Every decision is made inside a container:
Available information
Active constraints
“This should’ve been obvious” is almost always hindsight talking.
Before failure:
- incomplete information
- real constraints
- explicit trade-offs
After failure:
- certainty
- rewritten history
- invisible constraints
Same decision. Different story.
Before failure:
- incomplete information
- real constraints
- explicit trade-offs
After failure:
- certainty
- rewritten history
- invisible constraints
Same decision. Different story.
January 13, 2026 at 9:22 PM
“This should’ve been obvious” is almost always hindsight talking.
Before failure:
- incomplete information
- real constraints
- explicit trade-offs
After failure:
- certainty
- rewritten history
- invisible constraints
Same decision. Different story.
Before failure:
- incomplete information
- real constraints
- explicit trade-offs
After failure:
- certainty
- rewritten history
- invisible constraints
Same decision. Different story.
Decisions don’t fail. Context expires.
Most post-mortems ask the wrong question.
They ask whether a decision was right or wrong.
But decisions aren’t timeless objects.
They are commitments made under a specific set of constraints, risks, and unknowns.
Most post-mortems ask the wrong question.
They ask whether a decision was right or wrong.
But decisions aren’t timeless objects.
They are commitments made under a specific set of constraints, risks, and unknowns.
January 13, 2026 at 8:33 PM
Decisions don’t fail. Context expires.
Most post-mortems ask the wrong question.
They ask whether a decision was right or wrong.
But decisions aren’t timeless objects.
They are commitments made under a specific set of constraints, risks, and unknowns.
Most post-mortems ask the wrong question.
They ask whether a decision was right or wrong.
But decisions aren’t timeless objects.
They are commitments made under a specific set of constraints, risks, and unknowns.
You built a pipeline that hit 97% uptime.
Six months later, during one miss, someone asks: "Why didn't we build this more reliably?"
You're not being judged on your decision. You're being judged as if you had hindsight at design time.
Six months later, during one miss, someone asks: "Why didn't we build this more reliably?"
You're not being judged on your decision. You're being judged as if you had hindsight at design time.
January 11, 2026 at 10:30 PM
You built a pipeline that hit 97% uptime.
Six months later, during one miss, someone asks: "Why didn't we build this more reliably?"
You're not being judged on your decision. You're being judged as if you had hindsight at design time.
Six months later, during one miss, someone asks: "Why didn't we build this more reliably?"
You're not being judged on your decision. You're being judged as if you had hindsight at design time.
The Hindsight Evaluation Trap:
You chose 95% uptime to save cost.
Leadership agreed.
One visible miss happens.
Suddenly: "Why isn't this 100%?"
The evaluation ignores the constraint.
The trade-off becomes invisible.
You absorb blame for uncertainty.
You chose 95% uptime to save cost.
Leadership agreed.
One visible miss happens.
Suddenly: "Why isn't this 100%?"
The evaluation ignores the constraint.
The trade-off becomes invisible.
You absorb blame for uncertainty.
January 11, 2026 at 7:30 AM
The Hindsight Evaluation Trap:
You chose 95% uptime to save cost.
Leadership agreed.
One visible miss happens.
Suddenly: "Why isn't this 100%?"
The evaluation ignores the constraint.
The trade-off becomes invisible.
You absorb blame for uncertainty.
You chose 95% uptime to save cost.
Leadership agreed.
One visible miss happens.
Suddenly: "Why isn't this 100%?"
The evaluation ignores the constraint.
The trade-off becomes invisible.
You absorb blame for uncertainty.
Data work is built forward under uncertainty, but evaluated backward under certainty.
That mismatch is the real source of frustration, not the incident.
Full breakdown → zurl.co/w4tHh
That mismatch is the real source of frustration, not the incident.
Full breakdown → zurl.co/w4tHh
Your Data Work Is Judged After the Fact.
(And That’s Why You’re Always Surprised)
zurl.co
January 8, 2026 at 8:30 PM
Data work is built forward under uncertainty, but evaluated backward under certainty.
That mismatch is the real source of frustration, not the incident.
Full breakdown → zurl.co/w4tHh
That mismatch is the real source of frustration, not the incident.
Full breakdown → zurl.co/w4tHh
Good data work is a series of bets.
Some pay off. Some don’t.
That doesn’t make them bad decisions.
If evaluation ignores the constraints and assumptions at decision time,
it’s not feedback. It’s hindsight dressed up as insight.
Some pay off. Some don’t.
That doesn’t make them bad decisions.
If evaluation ignores the constraints and assumptions at decision time,
it’s not feedback. It’s hindsight dressed up as insight.
January 7, 2026 at 8:34 PM
Good data work is a series of bets.
Some pay off. Some don’t.
That doesn’t make them bad decisions.
If evaluation ignores the constraints and assumptions at decision time,
it’s not feedback. It’s hindsight dressed up as insight.
Some pay off. Some don’t.
That doesn’t make them bad decisions.
If evaluation ignores the constraints and assumptions at decision time,
it’s not feedback. It’s hindsight dressed up as insight.
🎃 What’s scarier?
Owning the data or owning the outcome?
Owning the data or owning the outcome?
January 7, 2026 at 7:20 PM
🎃 What’s scarier?
Owning the data or owning the outcome?
Owning the data or owning the outcome?
You didn’t fail because your pipeline broke.
You failed because your work was judged after the outcome was known.
Data work is built forward under uncertainty.
It’s evaluated backward under certainty.
That gap is where most frustration lives.
You failed because your work was judged after the outcome was known.
Data work is built forward under uncertainty.
It’s evaluated backward under certainty.
That gap is where most frustration lives.
January 6, 2026 at 10:43 PM
You didn’t fail because your pipeline broke.
You failed because your work was judged after the outcome was known.
Data work is built forward under uncertainty.
It’s evaluated backward under certainty.
That gap is where most frustration lives.
You failed because your work was judged after the outcome was known.
Data work is built forward under uncertainty.
It’s evaluated backward under certainty.
That gap is where most frustration lives.
If you look inside a .git/objects folder, it looks like a mess of random numbers and letters. But Git actually only has three main "building blocks" that make up everything in your project.
They are: Blobs, Trees, and Commits.
They are: Blobs, Trees, and Commits.
January 6, 2026 at 6:54 PM
If you look inside a .git/objects folder, it looks like a mess of random numbers and letters. But Git actually only has three main "building blocks" that make up everything in your project.
They are: Blobs, Trees, and Commits.
They are: Blobs, Trees, and Commits.
I spent years using Git on "autopilot" before I realized I had no clue how it actually worked. I knew the commands the add, the push, the commit. but, the "why" was a total black box.
The biggest surprise? Git isn't actually a "code" tool. It’s a content tracker.
The biggest surprise? Git isn't actually a "code" tool. It’s a content tracker.
January 6, 2026 at 6:28 PM
I spent years using Git on "autopilot" before I realized I had no clue how it actually worked. I knew the commands the add, the push, the commit. but, the "why" was a total black box.
The biggest surprise? Git isn't actually a "code" tool. It’s a content tracker.
The biggest surprise? Git isn't actually a "code" tool. It’s a content tracker.
Mid-career stagnation has a specific smell: Being "Too Busy."
If your calendar is a wall of execution, you aren’t a Lead—you’re a high-capacity component.
The untaught skill of growth isn't doing more work; it’s creating the space to think about the right work.
If your calendar is a wall of execution, you aren’t a Lead—you’re a high-capacity component.
The untaught skill of growth isn't doing more work; it’s creating the space to think about the right work.
January 5, 2026 at 11:02 PM
Mid-career stagnation has a specific smell: Being "Too Busy."
If your calendar is a wall of execution, you aren’t a Lead—you’re a high-capacity component.
The untaught skill of growth isn't doing more work; it’s creating the space to think about the right work.
If your calendar is a wall of execution, you aren’t a Lead—you’re a high-capacity component.
The untaught skill of growth isn't doing more work; it’s creating the space to think about the right work.
I asked the Google Gemini app for a simple diagram of how Git reuses data to save space, and it gave me...
cows?
🐄
cows?
🐄
January 5, 2026 at 10:13 PM
I asked the Google Gemini app for a simple diagram of how Git reuses data to save space, and it gave me...
cows?
🐄
cows?
🐄
The most dangerous place for a Senior Engineer is the "Execution Echo Chamber."
You’re fast. You’re reliable. You close tickets.
But because you’re so good at the "How," leadership never invites you to discuss the "Why."
Here’s how to break out:
You’re fast. You’re reliable. You close tickets.
But because you’re so good at the "How," leadership never invites you to discuss the "Why."
Here’s how to break out:
January 5, 2026 at 6:05 PM
The most dangerous place for a Senior Engineer is the "Execution Echo Chamber."
You’re fast. You’re reliable. You close tickets.
But because you’re so good at the "How," leadership never invites you to discuss the "Why."
Here’s how to break out:
You’re fast. You’re reliable. You close tickets.
But because you’re so good at the "How," leadership never invites you to discuss the "Why."
Here’s how to break out:
The difference between a senior engineer and an architect
isn’t more tools — it’s different questions.
Doer mindset:
“How do I get this data to the dashboard?”
Owner mindset:
“If this source breaks or lies, how does the system react?”
Same pipeline. Same stack.
One optimizes for delivery speed.
isn’t more tools — it’s different questions.
Doer mindset:
“How do I get this data to the dashboard?”
Owner mindset:
“If this source breaks or lies, how does the system react?”
Same pipeline. Same stack.
One optimizes for delivery speed.
January 5, 2026 at 4:26 AM
The difference between a senior engineer and an architect
isn’t more tools — it’s different questions.
Doer mindset:
“How do I get this data to the dashboard?”
Owner mindset:
“If this source breaks or lies, how does the system react?”
Same pipeline. Same stack.
One optimizes for delivery speed.
isn’t more tools — it’s different questions.
Doer mindset:
“How do I get this data to the dashboard?”
Owner mindset:
“If this source breaks or lies, how does the system react?”
Same pipeline. Same stack.
One optimizes for delivery speed.
The mark of a Lead Engineer isn't how fast they start typing; it's how long they spend thinking before they touch the keyboard.
Next time a ticket hits your desk, stay out of your IDE for 20 min.
Draw the failure map. Find the bottleneck.
Code is cheap. Architecture is forever.
Next time a ticket hits your desk, stay out of your IDE for 20 min.
Draw the failure map. Find the bottleneck.
Code is cheap. Architecture is forever.
January 4, 2026 at 11:06 AM
The mark of a Lead Engineer isn't how fast they start typing; it's how long they spend thinking before they touch the keyboard.
Next time a ticket hits your desk, stay out of your IDE for 20 min.
Draw the failure map. Find the bottleneck.
Code is cheap. Architecture is forever.
Next time a ticket hits your desk, stay out of your IDE for 20 min.
Draw the failure map. Find the bottleneck.
Code is cheap. Architecture is forever.
Every data pipeline is a bet.
Not a bet about tools, a bet about how the system will fail.
Most engineers build for the happy path:
API up. Schema stable. Volume reasonable.
That’s not where production systems live.
Not a bet about tools, a bet about how the system will fail.
Most engineers build for the happy path:
API up. Schema stable. Volume reasonable.
That’s not where production systems live.
January 1, 2026 at 7:40 PM
Every data pipeline is a bet.
Not a bet about tools, a bet about how the system will fail.
Most engineers build for the happy path:
API up. Schema stable. Volume reasonable.
That’s not where production systems live.
Not a bet about tools, a bet about how the system will fail.
Most engineers build for the happy path:
API up. Schema stable. Volume reasonable.
That’s not where production systems live.
Your pipeline is not broken; your assumptions are.
rajanand.substack.com/p/your-pipe...
rajanand.substack.com/p/your-pipe...
January 1, 2026 at 7:25 PM
Your pipeline is not broken; your assumptions are.
rajanand.substack.com/p/your-pipe...
rajanand.substack.com/p/your-pipe...
A common mistake mid-level professionals make:
They think decisions are about being right.
Senior decisions are rarely about correctness.
They’re about constraints.
They think decisions are about being right.
Senior decisions are rarely about correctness.
They’re about constraints.
January 1, 2026 at 2:56 PM
A common mistake mid-level professionals make:
They think decisions are about being right.
Senior decisions are rarely about correctness.
They’re about constraints.
They think decisions are about being right.
Senior decisions are rarely about correctness.
They’re about constraints.
Hello,
I’m using this space to share how I think about work.
Not tools.
Not hacks.
Frameworks, mental models, and ways to turn execution into real impact.
If you’re good at what you do but feel stuck in task mode, this will be for you.
I’m using this space to share how I think about work.
Not tools.
Not hacks.
Frameworks, mental models, and ways to turn execution into real impact.
If you’re good at what you do but feel stuck in task mode, this will be for you.
January 1, 2026 at 8:54 AM
Hello,
I’m using this space to share how I think about work.
Not tools.
Not hacks.
Frameworks, mental models, and ways to turn execution into real impact.
If you’re good at what you do but feel stuck in task mode, this will be for you.
I’m using this space to share how I think about work.
Not tools.
Not hacks.
Frameworks, mental models, and ways to turn execution into real impact.
If you’re good at what you do but feel stuck in task mode, this will be for you.