Exceptional career in software engineering

What changes when an engineer moves beyond senior? You still need strong technical skills, but the problems become broader. You have to choose where to invest, help other teams move forward, and make decisions when ownership and requirements are unclear. Two conversations hosted by Ryan Peterman explore this transition from different angles. Adam Ernst discusses technical influence, infrastructure adoption, code reviews, and failure. Philip Su reflects on leadership, moving between engineering and management, and deciding what a successful career should actually look like. My takeaway is that career growth depends increasingly on the quality of your judgment and the impact you enable around you.

Adam Ernst: Making Technical Change Happen

Adam’s experience building mobile infrastructure at Meta offers a practical example of engineering leadership. Creating a better architecture was part of the work. Getting engineers with different priorities to adopt it required another set of skills.

During a migration away from Core Data, some teams saw immediate performance benefits. Others had less reason to prioritize the change. Adam describes combining technical evidence, direct conversations, empathy for other engineers’ concerns, and hands-on migration work to move adoption forward.

Watch Ryan Peterman’s conversation with Adam Ernst

Understand the Cost of Your Proposal

It is easy to see the benefits of a platform you built. The team adopting it sees the migration, testing, operational risk, and features they may have to postpone.

Before asking another team to change direction, ask yourself:

• What problem does this solve for them?

• What evidence would make the benefit convincing?

• How much work are we asking them to take on?

• What can we do to make adoption easier?

This applies to frameworks, APIs, infrastructure, and AI platforms. A benchmark can start the conversation. A working integration, clear documentation, and reliable support help turn interest into usage.

If adoption is slow, investigate the friction. Another presentation may be less useful than fixing the onboarding process.

Code Reviews Can Develop Engineering Judgment

Adam also describes code review as a way to influence how engineers approach future work. His emphasis is on explaining the reason behind feedback, remaining flexible, and being open to context he may have missed.

A useful review comment connects a proposed change to a consequence:

“This retry can repeat an operation that already succeeded. Can we make the request idempotent?”

That gives the author something they can apply beyond the current pull request. It also creates room for discussion. Perhaps the operation is already protected elsewhere, or the reviewer has misunderstood the execution path.

Review your own feedback occasionally. Does it teach a principle? Does it help the author make a decision? Are you spending attention on the risks that matter most?

Learn From Failed Projects

Adam’s conversation includes a major failed project and how to handle the experience. That matters because career stories often focus on successful launches and promotions, leaving out the decisions that did not work.

My practical lesson is to make learning visible while there is still time to change direction.

For an uncertain initiative, define the assumptions early. What must be true for the project to succeed? What evidence would cause you to narrow the scope, redesign it, or stop?

A prototype can be valuable even when it never reaches production. It may reveal a technical limit, an adoption problem, or a customer need that was misunderstood. The team should be able to explain what it learned and how that changes the next decision.

Philip Su: Choosing the Career You Want

Philip brings a broader perspective from a career spanning Microsoft, Meta, and OpenAI. His conversation covers reaching Distinguished Engineer at Meta, building its London engineering office, and moving between individual contributor and management roles.

Watch Ryan Peterman’s conversation with Philip Su

Choose Your Role by the Work It Requires

Philip’s discussion of IC and management transitions encourages a deliberate choice about the work you want to do. It also highlights how communication, coaching, vision, and business understanding become relevant to senior IC roles.

Think about your preferred working week.

Do you want to spend more time investigating technical problems, designing systems, and writing code? Do you enjoy hiring, coaching, giving feedback, and building the conditions for a team to succeed?

Both paths involve people. A senior IC needs to build agreement across teams. A manager needs enough technical understanding to make sound decisions and support engineers effectively.

The title gives you only part of the picture. Talk to people doing the job and understand where their time goes.

Writing Helps Teams Make Decisions

Writing and communication are recurring themes in Philip’s course.

For me, the practical value of writing is that it exposes gaps in thinking. If a proposal cannot explain the problem, the tradeoffs, and the expected result, the team probably needs more clarity before implementation.

A useful technical proposal should answer:

• What problem are we solving, and why now?

• What options did we consider?

• What are we recommending?

• What are the costs and risks?

• What decision or help do we need?

The same discipline improves status updates. Explain what changed, what it means, and what needs attention. Give readers enough context to act without asking them to reconstruct the project.

Decide What You Are Optimizing For

Philip’s advice to his younger self raises an uncomfortable question: will reaching the next career milestone actually produce the life you want? He reflects on the cost of pursuing advancement faster when relationships, health, and other priorities may suffer.

Ambition benefits from a clear direction.

Do you want greater technical depth? More influence over product strategy? The experience of building a team? More autonomy? More time for your family?

Those goals can lead to different choices. A larger title may bring work you enjoy, or responsibilities you would rather avoid. Understanding that tradeoff before accepting the role is part of good career judgment.

What I Would Apply

Together, these conversations suggest a practical way to think about growth beyond senior engineering:

1. Choose a meaningful problem. Understand the customer or business outcome before committing to the solution.

2. Make adoption part of delivery. Account for migration effort, documentation, support, and ownership.

3. Develop others through everyday work. Use reviews and design discussions to explain reasoning and invite better ideas.

4. Communicate decisions clearly. Make progress, risks, and requests easy to understand.

5. Review your direction regularly. Check whether the work is building the career and life you want.

One question I would keep returning to is: What becomes easier for the team because I am here?

Perhaps engineers can ship more safely. Perhaps a confusing decision becomes clear, a dependency gets resolved, or a colleague gains the confidence to own a difficult problem. Those improvements are meaningful evidence of leadership.

Credits: These reflections draw on Ryan Peterman’s interviews with Adam Ernst and Philip Su on The Peterman Pod, and the accompanying courses curated by Taro. The practical applications and commentary above are my interpretation.