Forem: Nandish Dave

What Happened When I Stopped Delegating and Started Prompting

Nandish Dave — Mon, 23 Feb 2026 08:51:00 +0000

I had the vision. I had the architecture. I just didn't have the hands and time — until now.

The Lie We Tell Ourselves

As a lead — did you ever come across a situation where you spent your entire day playing around delegation and consolidation rather than really writing code, building prototypes, and solving the problems you were actually hired to solve?

Be honest.

Sprint planning. Backlog grooming. Stakeholder alignment. One-on-ones. Escalation calls. Architecture reviews. The calendar is a wall of colour-coded blocks with no white space.

By 6 PM, you've managed everything — and built nothing.

And then the real work begins.

Because the bugs don't fix themselves at 6 PM. The code doesn't write itself while you were explaining the same architecture to the third stakeholder today. The feature your team couldn't finish? It's still sitting there. Waiting for the one person who holds the full picture.

You.

So you open your laptop at 9 PM. Pour another coffee. And start doing the work that delegation was supposed to handle — but never quite did.

I did this for fifteen years.

Night after night. Sprint after sprint. I told myself it was leadership. It was ownership. It was "the price you pay for being senior."

But here's the truth nobody talks about: even when you do delegation right, it's still broken.

You write detailed Jira tickets. You add acceptance criteria. You attach architecture diagrams. You explain the context in a refinement session. You answer follow-up questions on Slack. You do a walkthrough call. You pair program the first module together.

And after all of that — you still don't get 100% of what you envisioned.

Not because the team is bad. They're talented. But the developer who picks up the ticket might not have the depth in that particular security pattern. Or the timeline is too tight to explore the edge cases you would have explored. Or they interpreted the requirement slightly differently — and by the time you catch it in code review, half the sprint is gone and rework isn't an option.

The gap between what a lead sees and what a team delivers is not a people problem. It's a physics problem. The full picture — functional, non-functional, security, scalability, coding standards, deployment nuances — lives in one brain. And no amount of Jira formatting, story pointing, or documentation can transfer it without loss.

So I became the safety net. The architect by day. The developer by night. The lead who led meetings until 6 PM and debugged until midnight.

I wore it like a badge of honour.

It was a chain.

And the root cause? Delegation is busted badly. Not because people can't follow instructions — but because information in transition tends to lose some of its part. Either while updating the Jira ticket or while interpreting the task. The full picture in a lead's head can never materialise fully, no matter how detailed you make it.

The Dream That Wouldn't Die

Here's the thing about being a lead who codes at midnight — it doesn't just steal your sleep. It steals your ambition.

Because somewhere behind the sprint boards and escalation calls and 11 PM debugging sessions, there was a dream. A side venture. A hustle. Something I wanted to build — not for a corporation, not for a client, not for a Jira ticket — but for myself.

VedicJivan. A digital platform for Vedic astrology and spiritual wellness. I had the complete vision in my head for years. A website. A blog engine. Astrological calculations. Consultation booking. Social media presence. Analytics. A brand that meant something to me beyond quarterly OKRs.

I knew the architecture. I knew the tech stack. I knew the content strategy. I could see it — fully formed, alive, running — every time I closed my eyes.

But when would I build it?

My days belonged to the company. Back-to-back meetings from 9 to 6. My evenings belonged to the code the team couldn't finish. My nights belonged to production incidents and deployment windows. And whatever was left — those thin, fragile hours between midnight and sleep — those belonged to my family. To my kids. To being present at birthday parties where I smiled for photos while mentally debugging a payment flow in the background.

I'd tell myself: "Next month. When the release is done. When the migration stabilises. When the team ramps up. Then I'll start."

Next month never came.

The release was always followed by another release. The migration was always followed by another migration. The team always needed one more sprint of hand-holding before they could run independently.

And VedicJivan sat in my head — perfectly designed, never built. A blueprint with no builder.

I tried once. Carved out a Saturday afternoon. Set up the project. Got halfway through the homepage. Then Monday happened. Then Tuesday's production incident. Then Wednesday's stakeholder escalation. By the following Saturday, I'd forgotten where I left off. The momentum was gone.

That's what nobody tells you about side hustles when you're an engineering lead. It's not about skill. It's not about money — though that was tight too, every euro accounted for, no budget for hiring freelancers to build your dream. It's about the one resource no delegation framework, no productivity hack, no time management course can manufacture:

Uninterrupted hours with a clear mind.

I didn't have them. I hadn't had them in years.

So the dream stayed a dream. Through promotions. Through company changes. Through moving countries. Through kids growing up. Through watching other people launch the things they talked about while I was still talking about mine.

The fire never died. But it was running out of oxygen.

And then — on a random evening when I expected nothing — everything changed.

The Evening Everything Changed

It was a regular weekday evening. Kids asleep. House quiet. I had maybe two hours before exhaustion would win.

I'd been hearing about AI tools changing the way developers work. I'd tried autocomplete assistants before — Copilot, code generators. Clever, sure. They could finish my sentences. But I didn't need someone to finish my sentences. I needed someone who could understand the whole picture alongside me and carry forward the thought process.

That evening, I opened Claude — an AI assistant I'd been curious about — and instead of asking for a code snippet, I did something I'd never done with a tool before.

I talked about VedicJivan.

Not the code. The dream. The brand. The audience. The content structure. The tech stack I wanted. The astrology calculations that needed specialized APIs. The SEO strategy. The analytics setup with Google Tag Manager and GA4. The Instagram presence. The Facebook cover that needed to match a spiritual aesthetic.

Everything that had lived in my head for years — I poured it into a conversation.

And then something happened that years of delegation, documentation, and Jira tickets never achieved.

The AI didn't just understand the pieces. It understood how they connected. It helped me architect the platform — not just the code, but the thinking. Content strategy for the blog. Node.js implementation for astrological calculations using specialised APIs. Brand voice options for Instagram. Analytics configuration to track which articles resonated.

I challenged it. "What about the mobile experience?" Addressed. "How do I structure the content for SEO?" Strategy outlined. "What's the best way to handle consultation booking without a backend team?" Solution designed.

I wasn't delegating. I wasn't waiting. I wasn't writing Jira tickets for someone else to interpret.

I was building.

For the first time in years — I was the architect AND the builder. With a thought partner who lost nothing in translation. Every requirement I described came back fully understood. Every nuance I mentioned was carried forward. The information didn't leak. The context didn't fade. The full picture in my head was finally materialising — exactly as I saw it.

In the span of a few weeks — working only in evenings, the same evenings that used to belong to corporate debugging — VedicJivan was alive. Website live. Blog publishing. Social media connected. Analytics tracking every visit. Astrological calculations running. A brand that looked like a small team of five built it.

One person built it. One person and one conversation.

I sat back and looked at what I'd created. The platform I'd dreamed about through years of birthday parties and production incidents and midnight deploys. The thing I'd told myself I'd build "next month" for half a decade.

It was real. It was running. It was mine.

And I hadn't lost a single night of sleep to build it.

Here's what actually changed — and it's not what you think.

AI didn't make me a better coder. I've been coding for fifteen years. It made me independent. The complete picture — functional, non-functional, security, maintainability, coding standards — finally had an execution partner that works at the speed of thought. No delegation. No information loss. No waiting.

I don't depend on a junior developer's availability to build what I can see. I don't sacrifice my evenings to finish what meetings stole from my days. I don't show up exhausted to morning standups because I was debugging at midnight.

And here's the beautiful irony: that independence made me a better leader.

Because I sleep. Because I have energy. Because when a junior developer asks me to explain an architecture decision, I actually want to teach — instead of thinking about the five other things I still need to code tonight. Because the dream that was suffocating under corporate exhaustion is now breathing — and that changes how you show up for everything.

The lead who codes at midnight is a tragic hero in our industry. We celebrate them. We promote them. We burn them out.

I was that hero for fifteen years.

I don't want to be anymore.

And thanks to AI — I don't have to be.

The cursor still blinks. The screen still glows. But the coffee is warm, the hour is reasonable, and for the first time in my career — the night shift is over.

But lately, something else has been keeping me awake — and it's not a production bug.

But What If the Cure Is Also the Poison?

I catch myself reaching for AI before I've finished thinking. I notice my patience for manual problem-solving shrinking. I wonder if my brain is learning new patterns — or forgetting how to form them on its own.

When a tool thinks alongside you at the speed of light, what happens to the parts of your mind that were built for slow, difficult, solitary thought? When the struggle disappears, does something else disappear with it?

The generation entering software engineering today will never know the 3 AM loneliness of a bug that doesn't Google well. They'll never build the mental calluses that come from hours of frustrated, unaided exploration. They'll be faster. They'll be more productive.

But will they be deeper?

I freed myself from the chain of delegation. But am I building a new chain — one made of prompts and convenience — that I can't yet see?

The night shift is over. But the next conversation is just beginning.

That story — the one about what AI is quietly doing to the engineering mind — is one I'm still living. And I'll share it when I understand it better.

→ Follow me to read Part 2: nandishdave.world

Nandish Dave is an Engineering Lead with 15+ years of experience building enterprise-scale digital platforms. Currently at PostNL, previously at bpostgroup. He writes about engineering leadership, AI-augmented development, and the human side of technology.

LinkedIn | Website | Blog

The Pareto Principle in IT: How 80/20 Thinking Shapes Everything We Build

Nandish Dave — Mon, 16 Feb 2026 20:55:40 +0000

In 1896, Italian economist Vilfredo Pareto noticed something odd about his garden — 20% of his pea pods produced 80% of the peas. He then found the same pattern in land ownership: 80% of Italy's land was owned by 20% of the population.

Over a century later, this same ratio keeps showing up — not in gardens or land registries, but in our codebases, sprint boards, deployment pipelines, and enterprise roadmaps.

The Pareto Principle (the 80/20 rule) isn't just a management cliché. It's a pattern that, once you start seeing it in IT, you can't unsee. And more importantly, it changes how you make decisions at every level.

The Principle, Simply Put

Roughly 80% of outcomes come from 20% of causes.

It's not always exactly 80/20. Sometimes it's 90/10, sometimes 70/30. The point isn't the precision — it's the asymmetry. A small number of inputs disproportionately drive the results.

In IT, this asymmetry is everywhere. Let's walk through it — from your morning standup all the way up to company-wide programs.

Level 1: Agile Ceremonies

Standups

We've all been in standups that run 25 minutes when they should take 5. Here's the 80/20 reality:

80% of the value in a standup comes from surfacing blockers and dependencies — which takes about 20% of the time.
The other 80% of the time? Status updates that could have been a Slack message.

The fix: Focus standups ruthlessly on blockers, risks, and "I need help with..." moments. Save status for the board.

Sprint Retrospectives

Look at your last 10 retro action items. How many actually moved the needle? Typically:

2 out of 10 action items drive most of the improvement.
The rest are nice-to-haves that quietly die in the backlog.

The fix: Limit retro outcomes to 1-2 high-impact actions. Execute those well rather than listing 8 items nobody follows up on.

Sprint Planning & Backlog Refinement

In any product backlog:

20% of the stories deliver 80% of the user value.
The remaining 80% are edge cases, polish, and features that sound good in brainstorming but rarely get used.

The fix: Relentlessly prioritize. Ask: "If we could only ship 3 things this sprint, which 3 would matter most to users?" Start there.

Level 2: Story Development & Deployment

Writing Code

When you pick up a story, notice the pattern:

80% of the working solution comes together in the first 20% of your time — the core logic, the happy path, the main flow.
The remaining 80% of the time goes into edge cases, error handling, tests, and that one weird browser bug.

This isn't an argument to skip the second part. It's an argument to get the core right first. Spike the happy path. Validate the approach. Then invest in hardening.

Code Reviews

20% of review comments catch 80% of the real bugs — logic errors, security gaps, missing validations.
The other 80% of comments? Naming preferences, formatting, and "have you considered..." suggestions.

The fix: Automate the trivial stuff (linting, formatting). Focus human review time on logic, security, and design.

Deployments & Incidents

After years in the industry, one pattern is consistent:

80% of production incidents come from 20% of the codebase — usually the oldest, most coupled, least tested modules.
80% of deployment failures trace back to the same 20% of causes — config drift, untested migrations, dependency conflicts.

The fix: Identify your "hot zones." Invest in tests, monitoring, and refactoring for that critical 20% rather than spreading effort evenly across everything.

Level 3: Feature Development

Scope & Requirements

When building a full feature — say, a new payment system or a user dashboard:

20% of the feature set is what 80% of users will actually use daily.
The rest is edge cases for power users, admin overrides, or "the stakeholder asked for it once in a meeting."

I've seen teams spend months perfecting a reporting module that 3 people use, while the core workflow that 10,000 users hit daily has known friction points.

The fix: Ship the core 20% first. Measure. Then decide if the remaining 80% of scope is worth the investment. Often, it isn't.

Testing Strategy

You can't test everything with equal depth. The 80/20 lens helps:

80% of bugs cluster in 20% of the modules — the complex ones with lots of conditional logic, integrations, or state management.
80% of test value comes from 20% of your test suite — the integration tests that cover real user flows, not the unit tests for getters and setters.

The fix: Focus test coverage where complexity lives. Use risk-based testing. Don't chase 100% coverage for the sake of a metric — chase 100% confidence in the flows that matter.

Performance Optimization

This is where Pareto is almost a law, not a principle:

80% of latency comes from 20% of the code paths — usually database queries, network calls, or that one O(n^2) loop nobody noticed.
80% of infrastructure cost comes from 20% of the services.

The fix: Profile first, optimize second. Don't guess — measure. The bottleneck is almost never where you think it is.

Level 4: Company-Wide Projects & Transformation

Digital Transformation Programs

Enterprise transformations are notorious for scope bloat. The 80/20 reality:

20% of the transformation initiatives drive 80% of the business impact — usually the ones closest to customer experience or revenue.
The other 80% of initiatives are internal tooling upgrades, process documentation, and governance frameworks that are important but not transformational.

The fix: Identify the 20% that moves business metrics. Fund those aggressively. Let the rest follow incrementally.

Migration Projects (Cloud, Platform, Monolith-to-Microservice)

Any large migration follows the pattern:

80% of the workloads migrate smoothly using 20% of the effort — the stateless apps, the containerized services, the ones that "just work."
The remaining 20% of workloads consume 80% of the effort — the legacy monoliths, the apps with hardcoded IPs, the ones nobody fully understands.

The fix: Migrate the easy 80% first. Build momentum, prove the pattern, free up resources. Then tackle the stubborn 20% with dedicated expertise.

Stakeholder Management

In any company-wide project:

20% of stakeholders generate 80% of the decisions (and the roadblocks).
20% of meetings produce 80% of the alignment.

The fix: Know who your critical 20% stakeholders are. Over-invest in those relationships. Keep the rest informed asynchronously.

The Meta-Pattern: 80/20 Applies to 80/20 Itself

Here's where it gets interesting. The Pareto Principle is fractal — it applies recursively.

Within that critical 20% of your backlog, 20% of those items drive 80% of the value. That means roughly 4% of your total backlog drives 64% of all outcomes.

Within the 20% of code causing 80% of bugs, 20% of that code causes the majority. A tiny fraction of your codebase is responsible for most of your pain.

This recursive nature means that finding the vital few isn't just useful — it's exponentially powerful.

How to Apply This Tomorrow

You don't need a framework or a consultant. Start with these questions:

In your next standup:
"What's the one thing blocking progress right now?"

In your next sprint planning:
"If we could only deliver 2 stories, which 2 would users notice most?"

In your next code review:
"Does this change touch our hot zones? If yes, let's review deeper."

In your next architecture discussion:
"Which 20% of this system handles 80% of the traffic?"

In your next project kickoff:
"What's the smallest scope that delivers the most value?"

The Trap to Avoid

The Pareto Principle is not permission to do 20% of the work and call it done. It's not about cutting corners.

It's about sequencing. Do the high-impact 20% first. Validate. Learn. Then decide how much of the remaining 80% is worth pursuing — armed with real data instead of assumptions.

The teams I've seen succeed aren't the ones who do the most work. They're the ones who do the right work first.

Conclusion

The Pareto Principle isn't a rule — it's a lens. And once you put it on, you start seeing the 80/20 split everywhere in IT:

Level	The 20% That Matters	The 80% Impact
Agile Ceremonies	Blockers & dependencies	Team velocity
Story Development	Core logic & happy path	Working software
Feature Scope	Key user workflows	User satisfaction
Testing	High-risk modules	Bug prevention
Performance	Critical code paths	System speed
Migrations	Easy-win workloads	Migration momentum
Transformation	Customer-facing initiatives	Business value

The best engineers and tech leaders I've worked with all share one trait: they have an instinct for what matters most. That instinct isn't magic — it's the Pareto Principle, internalized.

Start asking: "What's the 20% here?" — and watch how it changes the way you build, ship, and lead.

Why I Wrote This

I've spent years watching talented teams burn through energy on work that barely moves the needle — not because they lack skill, but because they lack focus on what actually matters. The Pareto Principle gave me a mental model to cut through the noise, and it's made me a better engineer, a better leader, and honestly, a better decision-maker in life.

I wrote this because I wish someone had framed it this way for me earlier in my career. If even one section made you pause and rethink how you're spending your time — it was worth writing.

I'd love to hear from you: Where have you seen the 80/20 pattern play out in your own work? Have you caught yourself spending 80% of your effort on something that didn't move the needle? Drop your questions or stories in the comments — let's learn from each other.

Originally published on my blog: blog.nandishdave.world

Why I Spent 5 Hours Finding a 20-Minute Fix: A Case for Structured Logging

Nandish Dave — Tue, 10 Feb 2026 07:40:33 +0000

This article is based on a real production incident I worked on recently. Names and specifics are changed, but the lessons are real.

The Incident

A production incident. Customers unable to complete payments in certain edge cases. Priority 1. All hands on deck.

The fix, once we found the root cause, took about 20 minutes. But getting there? That took hours. Not because the bug was complex — but because our observability was broken.

This post is about what went wrong and what I'd do differently.

Problem 1: Cost-Driven Logging Decisions

AWS CloudWatch is powerful, but querying logs at scale gets expensive fast. To manage costs, all application logs were being shipped to Splunk.

Splunk is a great tool — but it comes with its own query language (SPL), its own learning curve, and its own quirks. During a P1 incident, the last thing you want is engineers Googling "how to filter Splunk logs by timestamp."

The trade-off nobody talks about: You save money on log queries but pay with engineer time during incidents. That cost is invisible until it isn't.

Problem 2: No Structured Logging

This was the bigger issue. Developers were logging raw stack traces — unstructured, inconsistent, and scattered across services.

No centralized error-handling middleware. Every service handled errors differently. Some logged full traces, some logged one-liners, some didn't log errors at all.

What unstructured logs look like during an incident:

ERROR: NullReferenceException at PaymentService.Process()
   at PaymentService.cs:line 142
   at OrderHandler.cs:line 89
INFO: Request received for user 48291
ERROR: Connection timeout to payment gateway
INFO: Request received for user 50123
INFO: Health check OK
ERROR: NullReferenceException at PaymentService.Process()
   at PaymentService.cs:line 142

Which error belongs to which customer? Which request triggered which failure? Impossible to tell.

What structured logs should look like:

{
  "timestamp": "2026-02-09T14:23:01Z",
  "level": "ERROR",
  "correlationId": "req-abc-123",
  "service": "payment-service",
  "userId": "48291",
  "message": "Payment processing failed",
  "error": "NullReferenceException",
  "stackTrace": "PaymentService.Process() at line 142",
  "context": {
    "orderId": "ORD-9981",
    "amount": 149.99,
    "gateway": "stripe"
  }
}

One log entry. Everything you need. Searchable, filterable, traceable.

Problem 3: No Correlation IDs

Without a unique correlation ID attached to each incoming request and passed through every downstream service call, there was no way to trace a single customer's journey end-to-end.

Thousands of requests per second. Logs interleaved. One customer's payment attempt scattered across 5 services with nothing connecting them.

A simple middleware that generates a UUID and attaches it to every log entry would have saved hours:

// Express middleware example
app.use((req, res, next) => {
  req.correlationId = req.headers['x-correlation-id'] || uuid();
  res.setHeader('x-correlation-id', req.correlationId);
  next();
});

Then in Splunk or any log tool: correlationId="req-abc-123" — and you see the entire request lifecycle.

What I'd Do Differently

Structured JSON logging from day one — not raw console.log or stack trace dumps
Correlation ID middleware — generated at the API gateway, passed to every service
Centralized error handling — one middleware that catches, formats, and logs all errors consistently
Evaluate observability costs holistically — factor in engineer time during incidents, not just storage costs
Log levels that mean something — ERROR for actual failures, WARN for degraded states, INFO for business events

The Takeaway

The cheapest log storage means nothing if your team burns hours reading unreadable logs during a P1.

Observability isn't overhead. It's the difference between a 20-minute fix and a 5-hour firefight.

Why I Wrote This

I've spent 15+ years building and debugging enterprise systems. This incident reminded me that we often over-invest in features and under-invest in observability. The tools and patterns I described above aren't complex — correlation IDs, structured logging, error middleware — but they're skipped more often than you'd think.

I wrote this so the next engineer stuck in a P1 at 2 AM has one less problem to deal with.

I'd love to hear from you:

What does your observability stack look like?
Have you faced a similar situation where finding the bug took longer than fixing it?
What logging practices does your team follow?

Drop your questions or experiences in the comments — I'll reply to every one.

I'm Nandish Dave — Cloud Architect & Full Stack Engineer with 15+ years building enterprise solutions. I write about cloud architecture, DevOps, and lessons from production. Find me at nandishdave.world.