Cypher-X

Kasia Trapszo's central claim is that the hardest problems senior engineers face are not systems problems. They are problems of communication, assumptions, alignment, and how you scale your own judgment so that good decisions keep happening when you are no longer the one writing the code. Her thesis is a chain: clarity earns trust, trust converts into alignment, alignment turns into forward motion, and scaling yourself is what makes that motion sustainable after you leave the room.

Trapszo is an IC leader at Netflix where she leads architecture for the commerce platform, and she has been doing a version of that work for roughly ten years. Her background spans startups, the banking sector, and building engineering teams from scratch. She frames her own pivot from systems to people work as coming out of a decade spent making systems more reliable, more scalable, and "maybe a little bit less surprising at 2:00 in the morning" when you are on call. She delivered this talk at QCon San Francisco 2025 in a 45-minute session that includes the Q&A; InfoQ published the recording, slides, and transcript, dated May 12, 2026. The audience Q&A, hosted by Kaye Mason, is folded into the relevant sections below rather than reproduced verbatim.

These notes report what Trapszo presented. Where I add background that an intermediate engineer needs but the talk did not state, the text says so explicitly. Her evidence is drawn from her own career rather than from studies, so treat the stories as reported experience and the conclusions as her considered opinion.

What You Will Learn

Why an individual contributor's leverage stops being measured in code output, and what replaces it.
How pattern recognition across payment systems saved weeks of engineering work, and why that specific kind of clarity is what earns trust.
Why two teams can each be internally clear, follow the same written spec, and still ship systems that disagree with each other.
How to reframe a looping "us versus them" debate into a shared problem, using a single question about a future state.
Why impostor syndrome sometimes signals over-engineered code rather than a gap in your own skill, and the four questions Trapszo uses to test an abstraction.
How to design a meeting so it produces a decision instead of another meeting.
How Trapszo used GenAI to turn meeting transcripts into lightweight architecture decision records, and why the practice spread without any process mandate.
What the Q&A surfaced about incentives, psychological safety, disagree-and-commit, and proving IC value against an engineering-manager peer.

The Opening Story: Why Psychological Safety Comes First

Early in her career at a startup, Trapszo was handed one of those safe tasks meant to teach responsibility without letting a junior engineer break anything important. The team used an ancient bug tracker, possibly Bugzilla, that was not configurable: you either got notifications for every bug event or you got none, so touching a bug produced a flood of email for everyone watching it. The fix was to build a concise daily digest of bug activity. She wrote the cron job, tested it locally, and pushed it to production with a typo in the cron expression. Instead of one daily report, it sent a report every minute to the entire engineering organization, including the CTO.

Her stated lessons are that you should test your cron expression and that "humility comes free with automation." The part she keeps returning to is how the team responded. Nobody yelled, nobody made her feel stupid, her manager messaged her frantically to just make it stop, and then they laughed, fixed it, and moved on. That safety is what let her learn from the mistake, and it is the basis for her claim that great teams are defined not only by technical skill but by how people communicate and help each other improve.

Background for readers unfamiliar with the term: a cron expression is a five-or-six-field schedule string used by Unix cron and most job schedulers. Fields for minute, hour, day-of-month, month, and day-of-week are matched independently, so * * * * * fires every minute while 0 9 * * * fires once a day at 09:00. A single misplaced field silently changes the frequency by orders of magnitude, which is exactly the failure Trapszo describes.

When Mason later asked how to build a culture that permits mistakes at a level where an incident might carry billions of dollars of impact, Trapszo was blunt that this cannot be manufactured from below. That culture has to be a top-down leadership message that mistakes and incidents are learning opportunities. Her framing: if something has already cost the company a billion dollars, the money is spent, so you might as well learn from it. She sees ICs as having far less leverage over this particular kind of culture change, and she recommends blameless retrospectives so the whole organization learns rather than one person being made miserable.

Clarity Builds Trust

The first arc of the talk is about clarity, illustrated with a payments project. Netflix was adding support for a payment method in Brazil that is ubiquitous there but had only ever been used for real-time payments. Netflix was the first large merchant to use it for subscription billing, and that difference is where the complexity came from. A real-time payment is one neat transaction, while subscription billing carries retries, grace periods, and renewals, which she describes as the invisible complexity of keeping a relationship alive rather than completing a single transfer.

The project looked heavy. Documentation was long, requirements were strict, and the team was convinced it would need to rework parts of the invoicing system, which nobody wants to touch. They had started mapping new states, retry schedules, and conditional logic, the kind of work that begins simple and ends up touching most of the codebase and three adjacent services. Reading the requirements, Trapszo recognized the shape of European direct debit, which Netflix had been running for more than a decade. The vocabulary was different but the behavior matched: a limited retry window, delayed settlement, and a specific set of error conditions.

Once she walked the team through the comparison, the conclusion was that no new invoicing flow and no new states were required, only a few configuration changes. By her account this saved weeks of engineering effort and kept a critical system from accreting complexity it did not need. She is careful about what the episode demonstrates. It was not intelligence or seniority in the abstract; it was having seen enough payment methods to recognize which problems she had already solved. Her formulation is that senior engineering is less about knowing the answers and more about having "enough scar tissue to recognize which problems you have solved in the past."

The trust effect is the point she wants readers to take away. The team could see she was not refusing complicated work but pointing at a simpler path, and once people learn that your clarity makes their job easier, they start bringing problems to you earlier. That is influence earned through reasoning rather than granted by authority.

The Q&A sharpened this. Asked what to do when your influence hits a wall and people simply will not listen, Trapszo read that as a trust deficit rather than a communication problem: either they doubt the quality of your advice or they doubt your skills. Her method for building trust is deliberately unglamorous. She takes on the tasks nobody else wants, refactoring code nobody will touch and fixing bugs that would otherwise stay unfixed. Once the team sees that, they start believing the advice is good because the team moves faster with it. She repeated the same principle when asked how to teach junior engineers to adopt senior patterns: leading by example is the main lever, because people do not follow advice from someone who does not practice it. Her example was volunteering to take meeting notes, a task normally pushed onto the most junior person, which she notes is largely obsolete now that GenAI transcribes meetings.

Alignment Creates Influence

Personal clarity is necessary but not sufficient, because it does not always survive the handoff between teams.

When Everyone Is Right and the Systems Still Disagree

Trapszo describes a migration in which an older system was being moved to a new version while a production system depended on it. Both teams did the textbook work: reviewed the APIs, agreed on a schema, walked through the migration plan. Tests were green and the documentation was pristine. End-to-end testing then produced mismatches. Nothing crashed; transactions that should have lined up simply did not, and the data did not match.

The cause was a key identifier that both systems relied on, formatted slightly differently on each side. It was not a typo and not a missing field. Both teams had implemented the shared spec exactly as they understood it, and both readings were reasonable. Her summary is the line worth remembering: "We had clarity. We just didn't have the same clarity."

She frames this as a distributed systems problem in human form, with too many local truths and not enough consistency, and calls it "the worst kind of correct" because everyone is technically right while the systems still disagree. Her conclusion is that understanding rarely breaks down in the code. It breaks down in the conversations that never happen because everyone assumes agreement already exists. Alignment therefore does not live in the documentation; it lives in the shared understanding underneath it, and keeping that alive is real work that never appears on a roadmap.

Supplementary note, not from the talk: the concrete defenses against this class of bug are contract tests that both sides run against a shared example set, schemas that encode format constraints rather than only field names and types, and end-to-end tests exercised early rather than as a final gate. Trapszo diagnoses the failure but does not prescribe tooling for it.

Turning "Us Versus Them" into "Us Versus the Problem"

The second alignment story involves a machine learning model that routes payment transactions and had been in production for some time. Routing here means selecting which processor or path a transaction should take, a decision that affects authorization success rates and cost. The project team wanted to expand the model to new use cases, which from their side was the obvious next step because the model worked well. Engineering saw the integration around it as having decayed: multiple conditionals, old configuration paths, and historical quirks nobody wanted to approach. Building further on that felt to them like accumulating technical debt and tempting fate.

The conversation started looping. The project team wanted speed, engineering wanted stabilization first, product wanted results, and everyone had valid points and growing frustration. Trapszo's diagnosis is that a technical discussion had quietly turned into a debate about priorities, and that when everyone is right but nothing moves, it usually means the group is not solving the right problem.

Instead of asking whether to add the new use cases, she asked what it would take for everyone to feel confident with this model six months from now. She reports that the tone changed immediately, from defending positions to designing together, because the question moved the frame from "us versus them" to "us versus the problem." It surfaced that all three groups actually wanted the same end state: a simpler model with clearer boundaries that was easier to evolve and produced fewer surprises. The team agreed to pause the expansion, clean up the integration layer, and define cleaner input boundaries, and product came to see this as an investment in future resilience rather than a delay. The model was eventually expanded and the debt was cleaned up, though she adds the realistic caveat that it was probably never cleaned up completely.

Her generalization is that alignment is not about forcing agreement or being persuasive; it is about being connective, helping people see they are attacking the same problem from different angles.

The Q&A extended this to two harder cases. Asked how to deal with a loud, persuasive counterpart from the product organization, Trapszo's advice is to find the reason behind the volume, since everyone arrives with an angle and a story, and to use empathy to convert the conflict into a working relationship. Asked what to do when you have aligned horizontally but leadership above is not aligned, she was frank that it is a difficult situation: get the engineers aligned first, then escalate a level, because leadership misalignment has to be resolved by leadership.

She also endorsed disagree-and-commit, which is part of Netflix's culture, as a legitimate outcome rather than a symptom of an unfinished discussion. Her reading is that it usually indicates two viable solutions to the same problem that optimize for different things with different trade-offs. Committing means deferring to the designated decision maker, called the informed captain in Netflix parlance, and doing what is right for the project rather than making your approach win.

The Alignment Inside Your Own Head

The hardest alignment, in her account, is convincing yourself that you belong in the room. Trapszo joined Netflix as a senior engineer coming from a startup where she had been the first engineer, built the engineering team from the ground up, and knew the codebase intimately. Returning to an IC role at Netflix was something she wanted, until she opened the codebase and found what she describes as spaghetti rather than elegance.

Her first assumption was that the design must be brilliant and she simply was not qualified to see it. She spent days trying to reverse engineer the complexity, and it made less sense the deeper she went. The resolution came at lunch when another engineer on the team told her that nobody actually understands that part of the code, that it is a black box. It really was over-engineered.

The lesson she draws is that the feeling of not understanding something does not reliably mean you do not belong. Sometimes it means the thing genuinely is too complicated, because complexity can masquerade as sophistication and is often just a lack of clarity with good vocabulary. Rather than proving she understood everything, she started asking simpler questions:

What problem is this abstraction solving?
If it is not solving a problem, do we need it?
If it is not needed, can we remove it?
What would this look like as a very simple design?

She reports that these questions improved both the system and her own footing. Her framing is that clarity is not only something you produce for other people; it is something you have to rebuild inside yourself each time you enter a new space, because impostor syndrome never goes away, it only changes shape. The antidote she offers is curiosity, humility, and being willing to be the person who asks the question everyone else in the room is also wondering about.

Notably, when an audience member asked how to distinguish impostor syndrome from the Dunning-Kruger effect, framing the latter as fatal because overestimating your capabilities would limit your coworkers, Trapszo did not claim a method. She said the feeling persists even when giving a conference talk, and answered plainly, "I don't have an answer." That honesty is worth preserving rather than smoothing over: the talk offers no reliable self-test for the difference.

Scaling Yourself Equals Lasting Impact

Every senior engineer eventually hits a wall, and Trapszo argues it is not because the work gets harder but because there is more of it: more design reviews, more meetings, more memos, and more Slack conversations than anyone should reasonably survive. The specific failure she noticed was that her impact depended on meetings other people remembered and she did not. Her team would have a thoughtful discussion reaching good decisions, and a few weeks later would have the same thoughtful discussion on the same topic, because nobody had written it down. She is explicit that this was nobody's fault. There was no simple way to capture the why behind technical choices, and that reasoning does not fit neatly into a Jira ticket or a design doc.

The Experiment: Transcripts to Decision Records

Her experiment was to use GenAI to summarize meeting transcripts into short architecture decision records: a few paragraphs covering what was decided, why, and what trade-offs were made. She dropped them into a shared repository with no approvals and no ceremony, and she was not confident anyone would read them.

Within a few weeks other engineers began adding their own notes, linking diagrams, and clarifying trade-offs, including records from meetings she had not attended. People started joining meetings and saying the conversation had already happened, with a link. The practice had scaled beyond her, which is her working definition of scaling yourself: not doing more, since there are only so many hours in a day, but creating enough clarity that other people keep making good decisions without you. Her wry summary is that it started because she was tired of repeating herself, and "sometimes laziness is just efficiency waiting to be formalized."

The durable effect she highlights is that decisions moved out of people's heads and into the repository, so a new engineer wondering why a system works the way it does can find out. Her phrasing is that growth at this level is about reproducibility: making your reasoning visible so others can reuse it, challenge it, and build on it.

Background for readers new to the format: an architecture decision record (ADR) is a short, dated, immutable document capturing one decision, its context, the alternatives considered, and the consequences. The value comes from recording the reasoning at the moment it is fresh, so future engineers can tell whether a constraint still holds. Trapszo's version is deliberately lighter than the canonical template, which is part of why it spread.

She also flagged a risk from her own experience: doubt returns when you are no longer writing the code, and it is easy to wonder whether you are still adding value. Her reinterpretation is that the doubt usually means you are stretching into a contribution that multiplies other people's work rather than your own.

An audience member pushed back with a real operational problem. Their organization adopted ADRs, found them immensely helpful for shaping knowledge, and then hit cognitive overload: too many decisions and too many documents floating around, especially in a large domain. Trapszo said she had been in the same position and agreed that records nobody reads are pointless. Her proposed remedy is again GenAI, used not only to create records but to maintain them: before adding a new record, ask a model to check it against the existing corpus for consistency, whether other records need updating, and whether the set still makes sense together. She believes documentation practice is on the verge of changing because of this. Treat that as her forecast rather than a demonstrated result; the talk presents no measurement of whether the maintenance approach resolves the overload problem.

Designing Meetings That Produce Decisions

The second half of scaling yourself is helping others make good technical decisions rather than making them yourself. About a year before the talk, a senior engineer Trapszo calls Mary came to her frustrated. Mary's work on a gnarly data migration was technically solid, but the project kept stalling because she could not get alignment across teams that all had opinions. Her question was whether spending more time in meetings than doing engineering is simply what being a senior engineer is.

Trapszo asked her to walk through the meeting she felt was the biggest waste. It was a standard design review that went in circles, with everyone agreeing on the goal while debating implementation details that did not matter at that stage of the project. Two questions exposed the cause. Was there an agenda? Sort of; there was a design document. Did everyone know what decisions had to be made by the end of the meeting? No. Trapszo is careful to say this is not a criticism, because she has made the same mistake many times: you assume that putting smart people in a room with good context will make alignment emerge on its own. It does not. Alignment requires structure.

The structure they worked out has four parts:

Name the decision explicitly. People need to know what they are there to decide.
Identify who has input and who is the decision maker, the informed captain in Netflix terms.
Time box the conversation. She calls this the most important step, because engineers love to talk, herself included.
End by writing down what was decided and who is doing what. If you leave a meeting with a task list and no names attached, those tasks will not get done.

Trapszo calls this basic stuff that is nonetheless rarely taught, asking the audience whether anyone had a college class on structuring meetings. Mary tried it the following week and came away with clear next steps; Trapszo first says the meeting took 30 minutes instead of 60 and then immediately retracts the number, joking that it probably still took the full hour and that the real difference was the next steps. Some time later she saw Mary running a design review for someone else's project and coaching them on the same structure.

Asked in the Q&A how to frame the decision when the subject is large, Trapszo said it does not have to be a yes/no question. It can be "which database do we use for this system" or "do we go forward with this migration." The requirement is only that the group knows which decision is on the table, so the discussion does not devolve into implementation details.

Her conclusion about coaching is the strongest statement of leverage in the talk. Scaling yourself is not only documentation; it is recognizing what you learned through trial and error and compressing it into patterns others can use immediately. Helping one engineer skip a mistake you made three years ago is leverage; that engineer teaching it onward is exponential. She insists this work is not less technical, just a different class of technical problem: how do you transfer judgment, scale pattern recognition, and make tacit knowledge explicit? "These are engineering problems. They just don't show up in GitHub."

Getting Credit for Work That Has No Commit History

Two audience questions pressed on the uncomfortable consequence of that last line. The first noted that people who teach and transfer best practices are often not incentivized for it, and can even feel that giving away their knowledge threatens their own position. Trapszo treated this as a leadership problem: if leadership does not believe the IC leadership model works, you have to prove it, and the way to prove it is to find a way to measure it. The measure she names is team delivery efficiency, whether the team ships more effectively with someone helping them scale and teaching them how to do things well. If leadership will not buy in, her remaining options are blunt: do it quietly because you value it, or find another team.

The second question came from a senior IC whose peer was an engineering manager with a whole team delivering under them, and who could not see how to demonstrate comparable value alone. Trapszo challenged the premise before answering. Either you are doing a different level of work than that team of ICs, or the comparison is not fair because it is one person against many. If it is the different kind of work, bringing clarity, creating alignment, and bridging gaps, then the organization has to value that work; and if it does not, you again have to find a way to measure and show that it is additive, that it makes the team faster or the product better.

A related question asked how an IC builds enough trust in themselves to start delegating. Her answer is that self-trust comes from external feedback rather than introspection. Teams bringing you problems is a signal. Colleagues reviewing your pull requests quickly, when reviews normally linger, is a signal. How people respond to your documentation and your explanations is a signal.

Architecture And Data Flow

The talk describes a repeatable process rather than a system. The diagram below traces the loop, including what happens at the point where a decision either gets captured or gets re-litigated a few weeks later.

flowchart TD
    A["Pattern recognition
and simplification"] --> B[Clarity]
    B --> C[Trust]
    C --> D["Alignment across teams
us vs the problem"]
    D --> E[Forward motion]
    E --> F["Decisions made in
meetings and reviews"]
    F --> G{"Captured?"}
    G -- No --> H["Same discussion
repeats weeks later"]
    H --> F
    G -- Yes --> I["Short decision record:
what, why, trade-offs"]
    I --> J[(Shared repository)]
    J --> K["Others extend, link,
and challenge the records"]
    K --> B
    J --> L["New engineers answer
why without you"]

The decision-record pipeline she actually ran is deliberately minimal, which is what made it survive without process enforcement. The dashed step is the corpus-consistency check she proposed in the Q&A as a remedy for record overload, not part of the workflow she described running:

flowchart LR
    M[Meeting transcript] --> N["GenAI summarization"]
    N --> O["Draft record:
decision, why, trade-offs"]
    O --> Q[(Shared repo, no approvals)]
    Q --> R["Linked in future meetings
instead of re-litigated"]
    O -.proposed.-> P["Consistency check against
existing records"]
    P -.-> Q

Trade-offs And Limitations

The evidence is experiential, not measured. Every claim in the talk rests on Trapszo's own projects at Netflix and earlier employers. She reports saved weeks on the Brazil payments work and a meeting Mary shortened, by a figure Trapszo immediately walked back, but provides no controlled comparison, and even qualifies the meeting result herself as probably still taking the full hour.
Pattern recognition can misfire. The direct debit analogy worked because the underlying behavior genuinely matched once terminology was stripped away. The same instinct applied to a payment method that only superficially resembles a known one would push a team toward configuration changes when new states were in fact required. Trapszo does not discuss how she validated the match beyond walking the team through the comparison.
Impostor syndrome is not a reliable complexity detector. Her spaghetti-code story resolved because a colleague independently confirmed the code was a black box. She explicitly declined to offer a way to distinguish impostor syndrome from overestimating your own competence, so a reader who concludes "this code is just bad" without corroboration may simply be wrong.
Decision records create their own load. The audience question about cognitive overload is a real limit on the practice. Her answer, using GenAI to maintain and cross-check the corpus, is offered as a promising direction and not as a validated fix.
GenAI-generated records inherit model failure modes. Not raised in the talk, but summarizing a transcript into a decision record can drop the losing argument, overstate consensus, or fabricate a rationale. Because these records become the organization's memory of why, an unreviewed summary can encode a wrong reason durably. A human check on each record is cheap relative to that risk.
Recording internal meetings has privacy and confidentiality implications. Also not addressed in the talk. Sending transcripts of architecture discussions to an external model provider may expose unreleased plans, security details, or personal data, and consent to recording is regulated in some jurisdictions. Confirm your organization's policy before replicating the workflow.
Culture change is bounded by leadership. Trapszo says directly that blameless, learning-oriented culture must come top-down and that ICs have far less leverage over it. Her incentive advice is similarly constrained: if leadership does not believe IC leadership works, either prove it with measurement, do it quietly because you value it, or find another team.
The one metric she names is not operationalized. Team delivery efficiency is a reasonable target for showing that influence work is additive, but she does not say how to measure it, over what period, or how to attribute a change in it to one person's clarity work rather than to staffing, scope, or luck. That gap matters most for the engineers who need the argument, since it is exactly the ones without organizational buy-in who must construct the evidence.
Time-boxing trades depth for closure. Naming a decision and cutting off discussion at a fixed point can force a call before the group has surfaced a real objection. The structure is designed to prevent circular debate, not to guarantee the decision is correct.

Practical Takeaways

Look for the pattern before designing the new system. When requirements look unfamiliar, strip the terminology and ask which previously solved problem has the same behavior. In the payments case the matching signals were a limited retry window, delayed settlement, and a specific error set.
Frame simplification as a cheaper path, not a refusal. Trust came from the team seeing an alternative rather than an objection.
Assume shared documents are read differently. Where two teams integrate on a shared identifier or schema, verify the concrete format with examples both sides execute against, and start end-to-end testing before the plan is finalized.
When a debate loops, change the question. Ask what it would take for everyone to feel confident about this system six months from now. It converts position defense into joint design.
Test abstractions with four questions. What problem is this solving; if none, do we need it; if not, can we remove it; what would the simple design look like?
Design meetings for a decision. Name the decision, identify input-givers versus the decision maker, time box, and record the outcome with owners' names attached.
Write the reasoning down where others can find it. A few paragraphs on what was decided, why, and the trade-offs, in a shared repository with no approval ceremony, is enough to start.
Build trust by taking the unwanted work. Refactoring the code nobody will touch and fixing the bugs nobody fixes is Trapszo's primary mechanism for earning the right to be heard.
Use blameless retrospectives after incidents, and if you are in leadership, say explicitly that incidents are for learning.
Read the signals that your influence is working. Teams bringing you problems, and colleagues reviewing your pull requests quickly instead of letting them linger, are the feedback she uses to judge whether she is doing the right things.
Do the challenge she set the audience. Pick one decision you made this week that someone may need to understand in six months. Write three sentences: why, what else you considered, and what trade-offs you made. Put it somewhere others can find it.

Key Terms

Individual contributor (IC) leadership — Leading through technical clarity, alignment, and mentorship without managing people; the career track Trapszo describes.
Informed captain — Netflix's term for the person designated to make a given decision after gathering input; the role you defer to when you disagree and commit.
Disagree and commit — Voicing a different view, then fully supporting the decision maker's choice; Trapszo treats it as a normal consequence of multiple valid solutions with different trade-offs.
Architecture decision record (ADR) — A short document capturing one decision, its context, alternatives, and consequences, kept in a shared repository so the reasoning survives the meeting.
Blameless retrospective — A post-incident review focused on the conditions that made the failure possible rather than on who caused it.
Psychological safety — A team environment where people can admit mistakes and ask questions without fear of humiliation; Trapszo says it is most visible when something goes wrong.
Direct debit — A pull-based payment arrangement in which a merchant is authorized to collect recurring amounts from a customer's bank account, with a defined retry window and delayed settlement.
Real-time payment — A payment that settles immediately as a single transaction, without the retry, grace period, and renewal machinery that subscription billing requires.
Grace period — In subscription billing, the window after a failed payment during which service continues while retries are attempted.
Scar tissue — Trapszo's term for accumulated experience with failure modes that lets a senior engineer recognize a familiar problem behind unfamiliar terminology.

Closing Assessment

The strongest material in this talk is the diagnostic language rather than the advice. "We had clarity, we just didn't have the same clarity" names a failure mode most engineers have lived through without a term for it, and "the worst kind of correct" captures why those situations resist normal debugging: every local view is defensible, so nobody has an obvious bug to fix. The reframing question about a six-month future state is similarly portable, and costs nothing to try the next time a design discussion starts repeating itself.

The weakest part is measurement, as the trade-offs section above sets out: team delivery efficiency is the right kind of answer but is left unoperationalized, which makes the talk more useful to engineers who already have organizational support for IC leadership than to those trying to establish it.

Trapszo's own designated takeaway is the sentence she asked the audience to keep if they kept nothing else: "Your code might scale a system, but your experience and clarity scales organizations." It sits on top of her account of the career arc, where you start by proving what you can do, move on to shaping how things are done, and eventually find that your largest contribution is shaping how other people think, work for which there is no commit history. Her closing instruction was to go scale people, not just systems, "because one of those actually listens."

Reference: Kasia Trapszo, Beyond Coding: How Senior ICs Grow Influence and Drive Impact, QCon San Francisco 2025, published by InfoQ on May 12, 2026.