The Developer Who "Knows" (But You'll Be the One Typing)

Before anything else — this post isn't a callout. It isn't a rant. It isn't even really about that developer.

It's about a system. A pattern. A perfectly preventable spiral that I have watched play out — in different teams, different companies, different tech stacks — with almost identical beats every single time. And if we're being honest, every person in the story, including the tech lead, made choices that kept the spiral going.

So. With that said. Let me tell you about the spiral.

There's a specific kind of situation that exists in every team, in every company, in every timezone — and if you've been a tech lead long enough, you've lived it.

Sprint Planning. The ticket goes up. Estimation starts. And someone raises their hand and says the words — the exact words — that set the whole thing in motion:

"Oo, alam ko yan. Familiar na ko dyan. Madali lang yan." (Yes, I know that. I'm already familiar with it. That's easy.)

And you believe them. Of course you believe them. Why would someone overcommit about knowing how to implement a Service Bus consumer with retry policies and dead-letter handling? That's such a specific thing to overcommit about.

But here's the thing — and this is important — they probably believed themselves too.

That's where it starts. Not with a lie. With optimism. With "I've seen this before, I can figure it out" energy that every developer has felt at some point. The problem isn't the confidence. The problem is what happens next, when the confidence meets reality and nobody creates a safe space for that collision to happen out loud.

The Anatomy of How It Goes

Let me paint you a picture. It's Sprint Day 3. The ticket has been assigned. You've given them everything — the architecture docs, the sample repo, even a recorded Teams meeting of you explaining the pattern at 1.5x speed because you were feeling generous.

You check in.

"Kumusta na? Any blockers?" (How's it going? Any blockers?)

"Wala pa, sir. Nag-aasikaso ko pa lang ng environment setup." (Nothing yet, sir. I'm still taking care of the environment setup.)

Day 3. Environment setup.

You give them the benefit of the doubt. Environment issues happen. You've lived through a week of dotnet restore inexplicably failing because someone's NuGet cache decided to have feelings that day. You understand.

Day 5. You check in again.

"Kumusta? Nagsimula ka na?" (How are you? Have you started yet?)

"Sir, may tanong lang ako about the architecture..." (Sir, I just have a question about the architecture...)

The question they ask is about something you covered in the Teams recording. Minute 4. You remember because you sighed audibly when you recorded it and you could hear yourself sigh when you watched it back.

Day 7. Sprint Review is tomorrow. The ticket is still In Progress. Not "In Review." Not "Done." Just... In Progress, floating there in Jira like a message in a bottle that nobody sent.

You open the PR. There are 11 lines of code. Three of them are comments. One comment says // TODO: implement this.

You stare at the screen for a long time.

Here is the first place the system failed: nobody created a moment where it was safe to say "I'm lost." Not in planning. Not in standups. Not in the check-ins. The dev didn't say it. You didn't ask the right question to surface it. The team culture hadn't normalized it. So the silence filled in for honesty, and honesty is the only thing that could have stopped what comes next.

The Decision That Compounds Everything

This is where it happens. This is the moment. The fork in the road.

You could have a direct conversation. You could say, "Hey, I think we might be stuck — let's pair on this tomorrow morning, walk me through where you are." But you're Filipino. Ayaw nating mapahiya ang iba — we don't want to embarrass others. You're also mabait — kind. Too kind. Kindness deployed at the wrong moment, in the wrong direction.

So instead, you do what every well-meaning tech lead has done at least once in their career:

You open your laptop at 10 PM and you start typing.

You tell yourself it's faster this way. You tell yourself you'll teach them after. You tell yourself this is a one-time thing and next sprint they'll be more prepared.

Here's what's actually happening: you are solving the symptom and locking in the cause. The developer never gets the feedback that something went wrong. The team never sees that the estimate was off. The process never catches it. And next sprint, the exact same setup is in place — same confidence, same silence, same 10 PM.

You are not being kind. You are being comfortable. There is a difference.

The Screen Share Nobody Asked For

Here's the part nobody talks about in any leadership book I've ever read:

Sometimes, in trying to help, you end up doing a very expensive one-on-one tutorial that neither of you signed up for.

They're there in the Teams call, mic off, camera off, theoretically "pair programming" with you. You are sharing your screen. You are explaining every keystroke. You are essentially a one-man coding tutorial channel with zero engagement metrics.

At some point you say, "May tanong ka ba? Naiintindihan mo ba?" (Do you have questions? Do you understand?) and they say "Oo sir, clear na." (Yes sir, it's clear now.) Then you ask them to explain back the last thing you said and there is a silence so long that the Teams "your connection may be unstable" notification almost feels personal.

The hard truth here is: passive observation is not learning. Watching someone code is not the same as coding. The developer isn't growing in this session. They're being carried. And you — the lead — are burning time, burning energy, and burning the one resource you can't expense-report: your trust in the process.

Week Three: The Follow-Up You Regret

You check in again because you are, at your core, an optimist. Optimism, in software delivery, is a feature and a bug.

"Hey, kumusta na yung progress?" (Hey, how's the progress going?)

They send you a screenshot. You zoom in. It is a screenshot of the Microsoft Docs landing page.

Not a specific article. The landing page.

You close the Teams window. You open it again. You close it again. You go to the kitchen, drink water, and stare at the refrigerator for forty-five seconds. You are not angry. You are a person trying to locate yourself in space and time.

When you come back, there's a follow-up message:

"Sir, saan ba yung docs ng Service Bus?" (Sir, where are the docs for Service Bus?)

You sent them the link. Week one. It was the second item in your onboarding message. You pinned it in the Teams channel. You put it in the ticket description. The link is in the Teams recording at minute 2 — thirty seconds before the part they also didn't watch.

You send the link again. You add a smiley face.

The smiley face takes everything you have.

And here — right here — is the second place the system failed: there was no structure for accountability. Not punitive accountability. Just the simple kind: "Hey, here's what we agreed on, here's what I'm seeing, let's close that gap together." Without that structure, goodwill becomes a substitute for progress. And goodwill runs out.

Month One: The Escalation Arc (A Tragedy in Four Acts)

Act I: The Measured Escalation.

You write a very calm, very professional message to your manager. Ticket in progress for three weeks. Resources provided. Blockers not being surfaced. You're concerned about delivery. You use the word "velocity" and "knowledge gap" because the draft with more honest language felt unkind to send.

Your manager says: "Let's give it one more week. Baka may personal na nangyayare." — "Maybe something personal is going on."

You say: "Of course. Understood."

This is a reasonable response. Managers are supposed to consider context. People have lives. The instinct is right. What's missing is that nobody is having a real conversation with the developer about what's actually happening — everyone is speculating around them, not with them.

Act II: The Second Escalation.

One more week. Still In Progress. There is now a second // TODO comment in a different file.

You escalate again — this time with a timeline. Dates, check-ins, screenshots, the Teams recording link timestamped to Minute 4. Your manager forwards it to HR. HR schedules a meeting.

Act III: The Meeting.

Four people: you, your manager, HR, the developer.

HR asks how they're finding the project.

The developer says: "Medyo mahirap po yung requirements." — "The requirements are a bit difficult."

You smile. It is a smile that has traveled very far to get here.

Here's what nobody in that room names out loud: the developer is not wrong. The requirements were difficult — difficult enough that without proper support structure, daily clarity check-ins, and psychological safety to say "I don't understand this," a less experienced developer was always going to struggle. The gap between their skill level and the ticket complexity was real. It just wasn't surfaced in Week 1 when it was still cheap to fix.

Act IV: The PIP.

HR recommends a Performance Improvement Plan. Goals, timelines, milestones.

Your manager asks if you can support the developer through the PIP.

You say yes.

You say yes because you're a lead and this is what leads do. But also — and be honest here — you say yes because somewhere in the back of your mind you know that some of what landed here was the system failing this person, not just this person failing the system.

HR sends the PIP document. It needs to be acknowledged — signed, digitally, in the HR portal — within 48 hours.

Forty-eight hours pass.

Nothing.

HR follows up.

Still nothing.

Your manager pings the developer directly.

The developer replies, cheerfully, within seconds — which means they have been online this entire time — with:

"Sir, ano po ba yung PIP?" — "Sir, what exactly is a PIP?"

You stare at the message. You read it again. You close the app. You reopen it. The message is still there, asking the same question with the same cheerful energy, completely unbothered, like someone who just got a LinkedIn notification and not a formal HR document requiring their signature.

HR explains what a PIP is.

The developer reads it.

Then — and this is the part you will be telling people about for years — the developer replies:

"Sir, pero bakit naman po? Nag-deliver naman ako ng features." — "Sir, but why though? I did deliver features."

You put your phone face down on the table.

You pick it up again.

Nag-deliver naman ako ng features.

They are not wrong. Features were delivered. Every single sprint. On time, even. Reviewed, merged, demoed. The codebase has the receipts.

What the developer does not mention — what they perhaps genuinely do not register as relevant — is that you wrote most of those features. That you reviewed and rewrote their PRs in the comments until the code was unrecognizable from what was submitted. That you were their standup proxy, their rubber duck, their ghostwriter. That their "delivery" was, in a very meaningful sense, your delivery with their name on the envelope.

But here is the twist that makes this whole thing genuinely, painfully funny: from their point of view, they are completely correct.

Think about it. Every check-in ended with "clear na sir." Every feature got merged. Every sprint demo went fine. Nobody ever sat them down and said "hey, you are not actually doing this work, and that is a problem." The lead absorbed everything silently. The manager said "one more week" twice. The team's retro sticky note said "Good collaboration 🙌."

What exactly were they supposed to conclude?

That they were underperforming? Based on what signal? The merged PRs? The sprint demos they presented with full confidence? The fact that their tech lead was always available to help — which they reasonably interpreted as "this is just how this team works, sir"?

They didn't acknowledge the PIP because in the story they were living — assembled entirely from the feedback they actually received — they were a developer who delivered features, had a supportive lead, and worked on a very collaborative team.

The PIP was the first honest piece of information they received.

And it arrived in Month Two.

That is not funny. That is actually tragic. And the tragedy is, at least partially, on the system that let two months pass before saying anything true out loud.

Month Two: The Full-Stack Support Experience

The PIP is active. You schedule daily 30-minute check-ins. More Teams recordings. Step-by-step guides with screenshots. A private channel with pinned resources organized by topic. You are thorough. You are patient. You are trying.

The daily log goes something like this:

Day 1: "Sir, nag-crash yung VS Code ko." (Sir, my VS Code crashed.)
Day 2: "Sir, may error ako." The error is a missing semicolon.
Day 3: No response until 4:47 PM. "Sir, sorry busy ako kanina." (Sir, sorry I was busy earlier.)
Day 4: They paste 200 lines of code and ask if it's correct. You recognize the pattern immediately — it doesn't match anything you discussed, and it uses an approach you explicitly said not to use in the Teams recording at minute 7. They didn't paste bad code because they're careless. They pasted it because they're drowning and grabbing at anything that looks like a lifeline.
Day 5: Absent. No message. They reappear Monday: "Sir, hindi ako marunong mag-leave ng leave." (Sir, I don't know how to file a leave.)

By week two you realize you have quietly become their lead, mentor, pair programmer, rubber duck, knowledge base author, standup proxy, and ghostwriter — all at the same time, on top of your own deliverables.

This is not sustainable. It also isn't entirely their fault, and it isn't entirely yours. It is the result of a gap — skill gap, communication gap, expectation gap — that was never closed at the right time, and that everyone around it kept patching with workarounds instead of addressing directly.

Their name is on the PRs.
Yours is in the commit messages, buried, untagged.
Neither of you is fully served by this arrangement.

The Final Boss: The Retrospective

End of sprint. Retro time.

Scrum Master: "What went well?"

The developer types: "Natulungan ako ng team." — "The team helped me out."

The team. The team helped them.

And the board has a sticky note: "Good collaboration 🙌" — three upvotes.

Here is the uncomfortable thing about that sticky note: it isn't wrong. The team did help. You did show up. The collaboration did happen — it just happened in a way that was unsustainable, invisible, and unacknowledged in any official capacity.

The retro should have been the moment to name that. Not to embarrass anyone. Just to say: "Hey, we carried a lot this sprint. Let's talk about how we support each other and grow each other at the same time next time." That conversation never happened.

That's the lesson. Not "this developer is bad." The lesson is: teams need space to name what's actually happening, or the next sprint starts with the same silent setup.

Why Does This Happen?

I've thought about this a lot, usually at 11 PM, usually while the retro board is still open in another tab.

Part of it is culture. Sa atin — in our culture — we don't want to call someone out publicly. It feels cruel. It feels like we're making someone feel bobo — stupid — in front of the team. So we absorb. We cover. We fix in private. The instinct is human and it's kind. It just needs to be paired with honesty, or it becomes an indefinite subsidy.

Part of it is optimism. Maybe this sprint was an anomaly. Maybe next sprint they'll have a breakthrough. Maybe the domain was just harder than it looked. You give chances, and chances, and chances — the way Filipinos extend utang na loob — a debt of gratitude, a bond of obligation — until you've given so many that the accounting doesn't make sense anymore.

Part of it is that the work has to get done. The deadline is real. The client doesn't care. And so you do what you've always done, which is show up and deliver, even when delivering means carrying more than your share.

But part of it — the part worth sitting with — is that we never built the environment where honesty was easier than silence. And that's on the whole team. Including the lead.

What I'd Do Differently

Create safety for "I don't know" from Day 1. The opening standup of any new project should explicitly include: "If you're stuck for more than a day, that's a team blocker, not a personal failure. Say it out loud." Say it enough times and it becomes true.

The "you drive, I watch" early check-in. When someone claims a skill, schedule a 20-minute working session in the first week — not as a test, but as a natural "let's look at this together" touchpoint. Real understanding shows up fast when the IDE is open.

Name the gap, not the person. When something isn't moving, the conversation shouldn't be "you're not delivering." It should be "I'm seeing a gap between the ticket and where you are — let's figure out what's missing." One opens a person up. The other closes them down.

Document the support, not just the output. Keep a running log of check-ins, resources shared, questions asked. Not for a PIP. For clarity — so that at Month 2, everyone, including the developer, can see the shape of what happened and make an honest decision together.

Have the uncomfortable conversation at Day 5, not Month 2. "Mukhang nag-struggle ka dito, tara usap tayo privately" — "Looks like you're struggling here, let's talk privately" — said at Day 5 takes thirty minutes. Said at Month 2, post-PIP, it costs everyone — the developer's confidence, the team's velocity, and yes, the lead's evenings.

A Note to the Dev Who Sees Themselves in This

Uy. — Hey.

Huwag kang mahiya. — Don't be ashamed. Every developer — every single one, including the ones who look unbothered in code reviews — has raised their hand about something they only half understood. The difference between the ones who grew and the ones who got stuck isn't talent. It's the willingness to say "hindi ko alam" — "I don't know" — before the silence becomes the story.

Your lead doing your work isn't a kindness to you. It's a kindness to the sprint. You lose the chance to actually learn, to fail safely, to ask the dumb question before it becomes a PIP question. That window is small. Use it.

Sabihin mo agad. — Say it early. Nobody thinks less of a developer who asks. Everyone notices a developer who doesn't — eventually.

And watch the Teams recording. All of it. Minute 4 especially.

A Note to the Tech Lead Who Recognizes Their Own 11 PM

Pare — buddy — I see you.

You are not failing your team by setting honest expectations. You are failing them by not setting any. The most genuinely kind thing you can do is make people capable — and that means telling them the truth before the PIP does it for you.

You can be warm and be direct. You can care deeply about someone and hold them to a standard. In the Filipino context we sometimes treat these as opposites — mabait means soft, mahigpit — strict — means harsh. But the best leads I've seen are neither. They're honest, early, and human about it.

Stop absorbing the work at 11 PM. Start having the conversation at Day 5.

The team you build is the team you communicate with.

(Also: write the blog post at 11 PM instead. Cheaper. Slightly more therapeutic.)

If any of this hit home — whether you've been the developer, the lead, or the manager who said "give it one more week" — then you already know the lesson.

Tulad nga ng sabi nila — as they say — the first step is naming it.

The second step is making sure your next sprint doesn't start with the same silence.