🏎️💨 Fast and Furious: Misunderstood Impact in a Slow-Moving System 🚓

Let’s get right to it. In a recent 1:1, I received feedback that my upcoming annual review was trending toward a “partially meets expectations” rating.

That stung. Not just because of what it implies for bonuses and perception, but because the reasoning didn’t reflect the reality of my work—or the level at which I’ve been contributing.

The feedback painted a picture of someone careless, invisible, and disengaged. That’s not who I am. But it’s who I appeared to be through a narrow lens. So in the spirit of transparency, I want to share the exact feedback I received—and the context that was left out.

🪞 The Feedback I Got

Here’s what I was told:

🧪 Code Quality & Bugs

“There continue to be noticeable bugs in the frontend… breaking changes and missed edge cases… merge conflict led to deleted code that blocked the pipeline.”

“Frontend bugs were clearly visible during recent demos… concern around speed and a lack of thorough testing.”

📢 Communication & Visibility

“We’ve had to handle numerous help desk requests and demo issues stemming from surprise features or changes.”

“Even when others introduce them… approving PRs without proper evaluation has led to unintended side effects.”

🎯 Leadership & Initiative

“You’re not showing initiative on shared projects or stepping into leadership opportunities (e.g. AWS, Remix).”

📦 PR Scope & Tech Debt

“Still seeing large, unscoped PRs… heads-down tech debt work without alignment or communication… creates risk.”

“No new tech debt work unless aligned with me or the product manager.”

🧩 What the Feedback Got Wrong

🐞 “There continue to be noticeable bugs in the frontend…”

Expecting zero regressions is unrealistic—and bugs happen across the stack, not just in frontend. Neither of us have tracked regressions over time, so the claim that things have gotten worse is unfounded.

Also, for six months leading up to this, I was primarily focused on backend work. I wasn’t even active in the frontend codebase. Yet I was held accountable for bugs introduced by others—because I’m the most senior frontend engineer.

That’s not accountability. That’s scapegoating.

Let’s be clear:
I’m not responsible for the team. I’m not the manager.
I’m not responsible for the product roadmap. I’m not the PM.
I am responsible for writing code, improving product quality, and raising concerns when I see issues. But responsibility without authority is a setup.

If I’m going to be held responsible for failures, I should also be empowered to make decisions that prevent them.
And if we’re celebrating wins as a team, then we need to own losses the same way—consistently and collectively, not selectively.

🧨 “Merge conflict led to deleted code that blocked the pipeline…”

This might reference two separate incidents—neither of which match the claim.

First, one incident involved a requested change by other engineers. That change resulted in a blocked pipeline due to missing database permissions. I didn’t author that change—but I did fix it. I coordinated the upgrade of our database version to support the feature.

The second possibility: I intentionally disabled a job that was breaking deployments. Why? Because the job regenerated service links but had never been updated to handle legacy services. It began overwriting critical legacy link data, breaking monolith deployments.

No one on the team remembered that our now-director had manually updated those links years ago and left a silent logic gap to protect them. My “fix”? I added explicit logic to exclude legacy services—turning a hidden hack into real, intentional code.

So if that’s the incident being referenced, let’s call it what it was:
A fix to a hidden bug caused by forgotten tech debt and undocumented behavior—not a mistake.

When I received this feedback, I didn’t even ask for clarification—because I was blindsided. No explanation. Just vague blame.

🪄 “Surprise features caused demo issues…”

This referred to a contractor-led UX improvement. I told the contractor to:

• Get feedback from the team and users
• Get approval from our manager and PM before release
• I would only approve the technical implementation

I even helped by getting direct user feedback for him before the change was merged. Still, the feature was a surprise—and a bust.

Meanwhile, I’ve consistently received feedback that I move fast—but my accuracy is high, my developer experience thoughtful, and my bug fix turnaround fast. We give transparent updates in every standup and 1:1.

If people were surprised, they weren’t paying attention.

🧱 “You’re not showing initiative on AWS or Remix…”

• AWS is backend-led. The one frontend task involved? I proposed a cleaner implementation that saved time.
• Remix? I led the direction shift toward it a year and a half ago—long before it was formalized. I:
  • Refactored our frontend directory structure
  • Switched us to Vite and Vitest
  • Adopted loaders and actions from React Router

All without being asked.
I didn’t wait for a green light—I built the runway.

🧠 The Team Links Timeline They Ignored

The project I was most criticized for—Team Links—was a case study in broken perception.

• The first sprint was lost to "Big Day Planning" (a 2-full-day quarterly planning and sync session) prep.
• I completed Phase 1, but the team was too busy to review.
• The second sprint began with a live design doc/code walkthrough.
• I received two rounds of feedback—addressed both in one day each.
• The team asked to see Phase 2 before merging, which delayed things.
• Once Phase 2 was complete, reviewed, updated, and ready to merge, I couldn’t get approval.
• My manager requested I merge without further testing.
• I spent a week pairing with a backend principal engineer to review functionality.
• He was out for a week, so I broke up the work into 9 chained PRs.

If the team had bandwidth, I could’ve shipped this in a little over a week.
Instead, the delay was interpreted as a lack of initiative.

🚀 The Metadata Rewrite: What They Called “Unscoped Tech Debt”

This wasn't some slow-burn side project. This was work I did on my own initiative, outside sprint goals, and long before any recognition—only to be warned it was “risky” and “misaligned.”

Here’s the real story:

We had a feature called “metadata.” But if you looked closer, the main columns—name, url, source—made it clear:

It was actually a misnamed links table.

Some rows used url for literal URLs. Others used it for arbitrary values. The name field was sometimes a pseudo-key. There was no consistent distinction between links and metadata. Every feature that touched it duplicated logic—for parsing, validating, and displaying.

The only thing reused? A pile of fragile regexes.

I fixed that:

• Split metadata and links into distinct models
• Normalized link naming for consistency
• Centralized generation, parsing, and validation logic
• Made the system truly polymorphic
• Wrote safe migrations and updated backend logic
• Coordinated a DB upgrade for new permissions
• Updated designs and built new frontend interfaces
• Delivered everything solo, with minimal feedback

Why so fast?
Because months earlier, I had already refactored the frontend logic and part of the backend logic to be polymorphic—anticipating this shift. I also used AI tools to fill knowledge gaps and boost efficiency.

What others saw as “risky” tech debt cleanup was actually a long-overdue architectural correction.

Post-launch, incidents were minimal—and easy to debug thanks to centralized logic.

And the team’s feedback?

“You introduce too many great things too fast.”

I’m okay with that.
Because the work wasn’t wrong—they just weren’t ready to understand it.

🧠 Final Thought

I’m a frontend engineer doing backend migrations, data modeling, infrastructure coordination, architectural strategy, and delivering full-stack tested features across both platforms.

But instead of “exceeds expectations,” I was told I might not even meet them.

So next time, I’ll bring the spotlight with me.
And I’ll make sure what gets remembered is what actually happened.