Beyond Code: How Senior ICs Scale Their Impact Through Clarity, Alignment, and Documentation

As engineers progress in their careers, many senior individual contributors (ICs) face a common challenge: how to scale their impact beyond the code they write themselves. In her recent QCon San Francisco presentation, Netflix's Kasia Trapszo explored this transition, sharing practical strategies that have helped her move from hands-on coding to influencing entire organizations.

The Shift from Individual Contributor to Technical Leader

Trapszo began her presentation with a personal story from her early career as a junior engineer at a startup. Assigned to create a daily bug report system, she accidentally deployed a cron job with a typo that sent reports every minute to the entire engineering organization, including the CTO.

"That small moment stuck with me, because I realized how safe I felt learning from that mistake," Trapszo shared. "It was one of the first times that I understood that great teams are not defined just by their technical skills. They're defined by how they communicate and how they help each other get better."

This experience shaped her understanding that as engineers grow, their impact becomes less about the code they write and more about how they enable others to write better code.

Clarity Builds Trust

Trapszo's first key insight is that clarity builds trust. She illustrated this with a story about supporting a new payment method in Brazil at Netflix. The team initially believed they needed to rework parts of their invoicing system to handle the complexities of subscription billing with this payment method.

"As I was looking through the requirements, though, something started to feel familiar," Trapszo explained. "The rules, they were written differently, but the pattern was one that I have seen before. It reminded me of how we handle direct debit payments in Europe."

By recognizing the underlying pattern despite different terminology, she helped the team understand they only needed configuration changes, not a complete system overhaul. This saved weeks of engineering effort and prevented unnecessary complexity.

"That realization, it saved weeks of engineering effort, and it kept one of our most critical systems from getting more complex than it had to be," Trapszo noted. "More than that, it built trust. That's because the team saw that I wasn't just saying no to more complicated work. I was saying there's a simpler way."

This clarity-based approach earns influence not through authority, but through reasoning that helps others see more clearly. When engineers demonstrate this kind of pattern recognition, teams begin to trust their judgment and seek their input earlier in the process.

Alignment Creates Influence

The second key insight is that alignment creates influence. Trapszo shared an experience where two teams had implemented the same API field with different interpretations, leading to data mismatches during end-to-end testing.

"Both teams had implemented it exactly as they thought it was written," she explained. "They just interpreted the same spec in two very different ways. Same schema, same field name, same documentation, just two very reasonable and very different assumptions."

This "worst kind of correct" situation—where everyone is technically right but systems still disagree—is a common distributed systems problem. Trapszo realized that alignment isn't about having perfect documentation; it's about maintaining shared understanding underneath the documentation.

"Keeping that shared understanding alive, that takes real work," she emphasized. "That's not the kind of work that you will see on any roadmap."

Trapszo also addressed internal alignment—how to convince yourself that you belong in technical discussions. When she joined Netflix from a startup where she had been the first engineer, she initially felt impostor syndrome when confronted with the complex codebase.

"One day I was sitting at lunch with one of the other engineers on the team, and he was like, nobody actually gets that part of the code. It's a black box," Trapszo recalled. "Just like that, the fog lifted. It wasn't me. It really was just over-engineered."

This experience taught her that impostor syndrome isn't always a sign of personal inadequacy—it can be a valid reaction to unnecessary complexity. The antidote, she found, is to ask simple questions: "What problem is this abstraction solving? If it's not solving a problem, do we need it?"

Scaling Yourself Equals Lasting Impact

The third key insight is that scaling yourself creates lasting impact. Trapszo described reaching a point where her impact relied on meetings she couldn't even remember attending because decisions weren't being properly documented.

"I tried an experiment. I started using GenAI to summarize meeting transcripts into short architectural decision records," she shared. "Just a few paragraphs on what was decided, why, what tradeoffs did we make. Dropped that into a shared repo, no approvals, no ceremony, just a very simple record."

Within weeks, other engineers began adding their own notes, linking diagrams, and clarifying tradeoffs. The documentation system began maintaining itself.

"This is what scaling yourself really looks like," Trapszo explained. "It's not about doing more. There's only so many hours in the day. It's about creating enough clarity that other people can keep making good decisions without you."

Trapszo also emphasized the importance of structured decision-making. When a frustrated senior engineer came to her about stalled projects due to alignment issues, she helped her design more effective meetings by:

1. Naming the decision explicitly
2. Identifying who has input and who is the decision maker
3. Time-boxing the conversation
4. Writing down what was decided and assigning responsibilities

"The next week, she tried it. That meeting took 30 minutes instead of 60, and she walked away with clear next steps," Trapszo reported. "A while later, I saw her running a design review for somebody else's project. She was coaching them on how to structure the meeting."

Practical Implementation Strategies

Trapszo concluded with a challenge for the audience: "Pick one decision that you made this week that somebody else might need to know about in about six months. Write three sentences. Why? What else did you consider? What tradeoffs did you make? Put it somewhere where others can find it."

This simple act of documenting reasoning can be the first step toward scaling your impact. Over time, these small acts of clarity accumulate into a system that helps teams make consistent decisions without constant oversight.

During the Q&A session, Trapszo addressed several practical concerns:

Measuring the Impact of Non-Coding Work

When asked how to justify the value of IC work compared to managers with teams, Trapszo emphasized finding ways to measure the impact:

"I would assume that as that single individual IC, you're either doing a different level of work than that team of ICs, or it's not a fair comparison," she responded. "If you're doing that different kind of work, which is some of that leadership work that we talked about, where you're bringing clarity, creating alignment, bridging gaps, the engineer organization needs to value that work. If they don't value that work, then you need to figure out a way to measure it."

Using AI for Documentation

Trapszo sees AI as a valuable tool for managing documentation overload:

"I'm going to go back on the AI thing again, because I feel like that's where things actually are getting better now with that stuff because you can use GenAI to not just create those records but also keep them maintained and make sure that they make sense, that they're consistent within each other," she explained. "If you're creating a new architectural record, you can always ask your favorite GenAI tool to go and check it against all the other records that we have in there. Does it make sense? Does anything else need to be updated? Are we in alignment with each other? Are we creating nonsense?"

Building Psychological Safety

Regarding psychological safety, Trapszo emphasized that it should be part of team culture:

"Psychological safety is something that every team should just have as part of its culture," she stated. "It's particularly visible when something goes wrong. When it comes to incidents, when it comes to things going wrong, it's a lot better to allow people to learn from that without blaming, without finger pointing, using blameless retros, because everybody can learn, versus having one person be miserable."

The Path to Lasting Technical Influence

Trapszo's presentation offers a clear framework for senior ICs looking to expand their influence:

1. Build clarity through pattern recognition: Look for familiar patterns in new problems to avoid unnecessary complexity.
2. Create alignment through shared understanding: Ensure teams have consistent interpretations of requirements and specifications.
3. Scale yourself through documentation: Capture decision rationale so others can make good decisions without you.
4. Teach through example: Demonstrate the behaviors you want to see in others.

As Trapszo summarized: "Your code might scale a system, but your experience and clarity scales organizations. This is the kind of impact that lasts."

For senior ICs looking to grow their impact beyond individual contributions, these strategies provide a practical path to becoming technical leaders who multiply the effectiveness of entire teams.

Learn more about Kasia Trapszo's work and approach by watching the full presentation on InfoQ.