Interview with Marissa Chen on Technical Debt Management for Frontend Teams in Security-Software Developer Tools

Marissa Chen leads frontend engineering at CipherGuard, a mid-sized security-software company known for its developer tools tailored to API security. With over eight years in the industry, she’s keen on nurturing strong, diverse teams that tackle technical debt head-on. Recently, her team ran an International Women’s Day campaign focused on improving accessibility and code clarity—both key to managing technical debt. We sat down with Marissa to unpack practical steps for entry-level frontend developers aiming to support team-building while addressing technical debt.

What does technical debt mean from a frontend team-building perspective, especially in security-focused developer tools?

Marissa:
Technical debt isn’t just old or messy code; it’s also how your team manages that code and the shared knowledge around it. In security-software tools, the cost of unclear code or shortcuts can be huge—introducing vulnerabilities or slowing down fast response to threats. For a frontend team that’s mostly entry-level developers, this means you need to build habits and structures that prevent debt from piling up and that help everyone understand the trade-offs being made.

What practical first steps should entry-level frontend developers take when joining a security-software team, to avoid adding to technical debt?

Marissa:
First, get super comfortable with the existing codebase. Read the README, but also dig into the component tree, state management, and how security features tie into the UI. Don’t just skim—try running the app locally, inspect network calls, and look for test coverage gaps. This is crucial because undocumented security logic hidden in code can easily become technical debt.

Second, pair-program frequently, especially with senior devs. This helps you learn the coding standards and nuances of security-related UI components, which can be less forgiving than typical frontend elements. For example, an International Women’s Day accessibility campaign my team did involved creating custom components that met strict WCAG guidelines. Pairing prevented common pitfalls like missing aria-labels or improper keyboard navigation, which if left unchecked, become persistent debt.

How do you recommend structuring a new frontend team to handle ongoing technical debt, with entry-level developers in mind?

Marissa:
Divide responsibilities carefully but encourage cross-pollination. For entry-level devs, assign clear, manageable ownership areas—maybe the dashboard widgets or the onboarding flow. This gives them a sense of accountability without overwhelming them.

Create a “debt backlog” alongside your feature backlog. Make it visible during sprint planning. We use Jira for this, but tools like Clubhouse or Shortcut work well too. Entry-level devs can pick up smaller debt tickets (like refactoring a convoluted React hook or fixing flaky tests), which helps them learn the codebase and appreciate the importance of maintainability.

Also, designate technical debt champions—senior engineers who mentor juniors and oversee debt reduction initiatives. They should regularly review pull requests for complexity creep or shortcuts that might introduce debt, especially when security considerations are involved.

During your International Women’s Day campaign, what specific technical debt management practices did the team implement that might be instructive?

Marissa:
Great question! We launched an accessibility overhaul for some of our core UI components featured in the campaign. This required revisiting old code that hadn’t been maintained rigorously, creating significant technical debt.

We started by running an accessibility audit with tools like Axe and manual keyboard navigation tests. We then created small, focused tickets for fixes and improvements—not huge rewrite stories, because those can stall.

Entry-level devs were paired with UX designers and security engineers to ensure fixes didn’t break authentication flows or API calls. This multi-disciplinary interaction helped prevent the “fix one problem, create another” scenario, a common source of technical debt.

Moreover, we used Zigpoll to gather team feedback anonymously on the onboarding process related to accessibility work. We discovered some juniors felt hesitant to flag existing debt because they feared slowing down the sprint. Addressing this culture upfront prevented debt from hiding.

Can you share a concrete example where a well-managed technical debt initiative led by juniors improved team outcomes in a security developer tools context?

Marissa:
Sure. Last year, one of our entry-level devs noticed that a custom authentication banner component had inconsistent error handling and poor test coverage. Instead of ignoring it, she proposed a refactor as part of our technical debt backlog.

With guidance, she rewrote the component, improved error messaging, and added Jest tests. This reduced bugs by 35% in that area over the next quarter, according to our bug-tracking metrics. More importantly, it boosted team confidence in tackling technical debt without feeling like it was “just busy work.”

What are common pitfalls or gotchas entry-level devs face when trying to help with technical debt in security-focused frontend teams?

Marissa:
One big pitfall is confusing technical debt with feature work—sometimes juniors might think rewriting a UI widget from scratch is the best debt solution. But in security contexts, rewriting messy code can introduce new vulnerabilities if security checks aren’t carefully ported.

Another is underestimating the importance of documentation. A frontend developer might fix a complex component but forget to update README or Storybook stories, which leads to knowledge gaps.

Beware of “band-aid” fixes. For example, quickly patching a UI bug without addressing an underlying inconsistent state management logic can create more debt.

How should entry-level devs advocate for technical debt reduction without jeopardizing feature delivery or team morale?

Marissa:
Frame technical debt tickets as value-adds for the team and customers. For instance, say, “Improving this component’s code clarity will speed up security patch implementation by 20%” rather than just “Let’s clean up code.”

Use data. If you can show a correlation between debt and increased bugs or slower sprint velocity—like we did with that authentication banner—it’s easier to convince product owners to allocate time.

Also, suggest small, incremental improvements. A 2023 Stack Overflow survey found teams that dedicated 10-15% of each sprint to technical debt saw better overall delivery than teams trying to do big refactors intermittently.

What role does onboarding play in technical debt management, specifically for new frontend developers in security software companies?

Marissa:
Onboarding is critical. If new hires don’t understand the team’s debt policies or the unique security concerns baked into the frontend code, they might unwittingly add debt.

Our team runs a two-week onboarding that combines codebase walkthroughs, pair programming, and security training. For example, we highlight how UI feedback for authentication errors must not reveal sensitive info—a detail easily lost without thorough onboarding.

Also, encourage newbies to use feedback tools like Zigpoll or Officevibe to anonymously rate their onboarding experience. This feedback helps us tune the process and catch knowledge gaps early.

How do you balance the need for diverse skills and team stability when building a frontend team focused on reducing technical debt in developer tools?

Marissa:
Diverse skills bring fresh perspectives on debt—whether it’s a designer noticing accessibility debt or a junior dev suggesting simpler state logic. But stability matters more in security software, where rushed changes can open vulnerabilities.

We aim for a core stable team with 60% mid-to-senior devs and 40% entry-level. This balance lets juniors learn on the job without the team tipping into chaos.

Importantly, invest in soft skills. Entry-level devs who communicate well and ask questions tend to spot and flag debt early.

What final advice would you give entry-level frontend developers about managing technical debt as part of team-building in security software companies?

Marissa:
Start small. Don’t expect to rewrite everything. Pick manageable slices of the codebase and fix defects or improve tests.

Ask lots of questions. Pairing isn’t just about coding; it’s about understanding why certain choices were made, especially around security.

Take ownership. Even small debt tickets, like clarifying comments or fixing lint errors, build credibility and help the whole team.

Remember, technical debt isn’t just a problem—it’s an opportunity to learn, grow, and help your team build safer, cleaner tools.

Comparison Table: Common Technical Debt Management Practices vs. Team-Building Benefits for Entry-Level Frontend Devs in Security-Software Developer Tools

A Word of Caution

This approach requires patience—technical debt reduction is not glamorous and can slow feature output in the short term. Also, it won't work well if leadership prioritizes speed over quality without committing to a culture shift. In fast-scaling startups, teams may need stricter guardrails or automated security checks to keep debt in check.

Marissa’s experience shows that entry-level frontend developers, even early in their careers, can play a vital role in managing technical debt through team-building. With deliberate onboarding, shared ownership, and a culture that values clear, secure code, teams not only reduce debt—they build trust and expertise that pay off for years.