Beyond the Sprint: The Art of Creating Lasting Impact as a Staff+ Engineer

“Try not to become a person of success, but rather try to become a person of value.” Albert Einstein’s words might seem far removed from our world of pull requests and deployment pipelines, yet they perfectly capture the evolution every engineer faces as they progress beyond senior levels.

Last week, a colleague asked me a question that’s been bouncing around in my head: “How do you create impact significantly, measurably, and consistently for the long term?” It’s a deceptively simple question that gets to the heart of what separates good engineers from truly exceptional ones.

The Impact Paradox

Here’s the thing that trips up many engineers climbing the IC ladder: the higher you go, the less your individual code contributions matter, and the more your influence on others becomes your true measure of success. It’s counterintuitive, especially when you’ve spent years honing your technical skills.

At Agoda, we see this transition clearly across our IC levels:

IC1-IC2 (Associate/Software Engineer): Your impact is measured by your ability to execute within the teamIC3 (Senior Software Engineer): You’re expected to own features and mentor junior engineers, and start to extend beyond your teamIC4+ (Staff and beyond): Your impact extends beyond your immediate team to influence the broader technical organization, growing with teams impacted as you get higherMaya Angelou once said, “I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.” This wisdom applies surprisingly well to senior engineering roles — your code will be refactored, your architectures will evolve, but the engineers you’ve influenced will carry forward the principles and practices you’ve instilled.

The 70–30 Rule (And Why It Matters)

Here’s where things get interesting. As a Staff engineer, I expect you to spend roughly 30% of your time off sprint work. Lead engineers and more? That jumps to 50%. Before you panic about “not pulling your weight,” remember — you’re still expected to bring the same value as other engineers, just not the same code output.

This isn’t about working less; it’s about working differently. That extra time should be invested in projects with wide organizational impact — the kind of work that doesn’t fit neatly into a two-week sprint but transforms how we build software.

The Time Management Challenge

The biggest challenge? Actually managing this dual responsibility without losing your mind. We’ve all been there — torn between sprint commitments and that architectural refactor that could save the organization months of technical debt. Here are the strategies that actually work:

Time Boxing: Block out dedicated days or weeks for impact work. Yes, this means telling your team you’re unavailable for sprint work during those periods. It feels uncomfortable at first, but it’s essential for maintaining focus.

Sprint Integration: Sometimes you can bring your broader impact work into the sprint. Get your team involved — transparency helps, and you might discover allies who share your vision. Just be cautious not to let it interfere with sprint goals, and if the sprint goals are getting your work deprioritized, then maybe this isn’t the best way for you to work, take care with this one.

Data-Driven Advocacy: Start with metrics. When you can demonstrate the potential impact with hard numbers, you’ll find it much easier to get organizational support. Backing your vision with solid data transforms abstract ideas into tangible opportunities people can rally behind.

Manager Partnership: Your manager is there to support and advocate for you — they’re your ally in creating space for impact work. They can help you navigate organizational priorities, remove blockers, and ensure your broader contributions are visible to leadership. Don’t try to navigate this alone.

Cross-Team Collaboration: Find like-minded engineers across the organization, but don’t just collect contacts — build genuine relationships. Attend tech talks and networking events to actually connect, not just “grab and go.” on the pizza or bonchon. Have real conversations about the challenges teams are facing. This network becomes your foundation for identifying opportunities and finding collaborators who share your vision for improvement.

The Ownership Mindset

Here’s a mindset shift that separates good engineers from transformational ones: stop thinking “I work for this company” and start thinking “I am this company, and this company is me.” It sounds subtle, but the difference is profound.

When you truly adopt an ownership mindset, you stop seeing problems as someone else’s responsibility. That flaky test suite that everyone complains about in standup? You don’t just add your voice to the chorus of complaints — you take ownership and fix it. The deployment process that wastes 30 minutes of every engineer’s day? You don’t just tolerate it — you architect something better.

This becomes particularly challenging in larger organizations where the Bystander Effect kicks in. With hundreds or thousands of engineers around you, it’s easy to assume someone else will tackle that system-wide problem. “Surely the platform team is working on this,” or “The architecture group must have this on their roadmap.” But here’s the reality: everyone is making the same assumption. Problems persist not because they’re unsolvable, but because everyone thinks someone else should solve them.

People with an ownership mindset see a problem and ask “How do I solve this?” instead of “Why doesn’t someone fix this?” They understand that waiting for someone else to take action is exactly how problems persist indefinitely. They recognize that in a large organization, the very abundance of smart people can paradoxically lead to important problems being orphaned. They have a bias to action.

The difference between engineers who create impact and those who don’t often comes down to this: when faced with a problem, do you complain about it, let it slide, or take ownership of fixing it? Most engineers see the same inefficiencies you do — they just accept them as “the way things are.” Your opportunity lies in refusing to accept that status quo.

Measuring What Matters

Here’s where many engineers stumble: they focus on vanity metrics instead of meaningful impact. Lines of code written? Irrelevant. Number of tickets closed? Missing the point.

Real impact is measured through the metrics that actually matter to our engineering organization. At Agoda, we track several key indicators that reveal whether your work is truly moving the needle:

Velocity and Flow Efficiency: Your architectural decisions should improve how quickly code moves from commit to production. At Agoda, we track our own version of DORA metrics that measure the entire development flow. When you streamline our development process or eliminate bottlenecks, we see it reflected in faster code review cycles, reduced time from commit to merge, and shorter feedback loops. If your infrastructure work cuts down CI/CD queue times, that’s measurable impact across every team — engineers spend less time waiting and more time building.

Quality and Reliability: The work that matters most often shows up in our Change Failure Rates and Escaping Bug metrics. When you invest time in improving our deployment pipeline, testing frameworks, or development practices, we see fewer failed Buckbeak deployments and lower Bug Density (our bugs per 100 MRs metric). These aren’t just numbers — they represent real customer impact and developer experience improvements.

System Health: Your platform work should drive improvements in our Uptime metrics. When you architect more resilient systems or improve our monitoring and alerting, the impact shows up in our uptime buffer calculations and reduced incidents.

Developer Experience: Some of the most valuable impact work doesn’t fit neatly into product metrics. When you reduce Failed CI Pipeline Percentage across the organization or improve our Build Time, you’re giving every engineer back hours of their week. When you establish patterns that reduce the Number of Reviews required for typical changes, you’re accelerating everyone. Or even impacts on local development looking at Time to Dev Feedback, compile times, local test runs, etc.

The beauty of focusing on these metrics is that they’re leading indicators of broader organizational health. Improve MLTC organization-wide, and you’re not just making deploys faster — you’re enabling more experimentation, faster feedback loops, and ultimately better products for our customers.

What separates good Staff+ engineers from great ones is their ability to identify which of these metrics their work will impact and by how much. Before you start that next architecture project, ask yourself: “Which of these numbers will improve, and how will I measure the change?”

The “Everything-is-Garbage” Opportunity

One of the most common refrains I hear from engineers seeking impact is “there’s nothing broken here to fix.” This couldn’t be further from the truth. In fact, I’d argue that this mindset is exactly what separates engineers who create lasting impact from those who wait for opportunities to be handed to them.

The reality is simpler than we make it: there’s always room for improvement, even in your immediate environment. Is your CI/CD pipeline perfect? Do bugs never escape to production? Are your systems optimally efficient in cost and performance? Of course not.

Tiger Woods once said, “No matter how good you get, you can always get better, and that’s the exciting part.” Apply this lens to your engineering environment. That “good enough” deployment process that everyone tolerates? That’s an opportunity. The manual testing step that slows down releases? Another opportunity. The 10 things you have to do to make your system work on your laptop, make it 1 or none, so its easier for people to get onboarded.

Start by challenging the status quo with a better vision. Look at your organization’s technical objectives and you’ll easily identify areas where meaningful work awaits. The key is developing an eye for inefficiency and a drive to imagine something better.

When Going Deep Beats Going Wide

Not all impact requires broad organizational influence. Sometimes the most valuable contribution you can make is diving into areas where “few would venture.” I’ve seen Staff engineers create tremendous value by tackling deep performance issues, exploring JVM internals, or optimizing database configurations that no one else wanted to touch.

These “extreme technical challenges” might not immediately impact teams beyond your own, but they provide unprecedented value in ways that aren’t always obvious. When you become the organization’s expert on memory optimization or database indexing strategies, you’re not just solving today’s problems — you’re building institutional knowledge that will benefit every team that encounters similar challenges. But make sure you document it, and/or communicate it outwards some way.

Ernest Hemingway wrote, “The way to make people trust-worthy is to trust them.” The same principle applies to technical leadership: when you demonstrate deep expertise in areas others avoid, you earn the trust that enables broader influence later. Your willingness to tackle the unglamorous but critical work establishes you as someone who can be counted on for the really challenging problems.

The Passion Investment

Here’s something that might be uncomfortable to hear: while you shouldn’t regularly sacrifice your personal time for work, the engineers who truly shine are often those willing to go above and beyond when it matters. This isn’t about unhealthy work-life balance — it’s about recognizing that breakthrough impact sometimes requires initial investment.

Think back to why you got into this field. If you’re passionate about solving complex problems, if you find genuine enjoyment in architecting elegant solutions, then that initial time investment to build a compelling case for your ideas isn’t sacrifice — it’s pursuing what you love.

I’m not suggesting you work nights and weekends indefinitely. But when you discover a problem that genuinely excites you, when you see a technical challenge that keeps you thinking even after you close your laptop, that’s often where your most impactful work will emerge. The key is being selective about what deserves that extra energy and ensuring it leads to organizational support, not just more unpaid overtime.

The Long Game

Creating lasting impact isn’t about heroic individual contributions — it’s about building systems, processes, and cultures that outlast your direct involvement. When you move teams or take on new challenges, the real test is whether the improvements you made continue to benefit the organization.

Think of yourself as a force multiplier. Your job isn’t to be the smartest person in the room; it’s to make everyone else in the room smarter. It’s to identify the systemic issues that slow down entire teams and architect solutions that create lasting change.

The transition from individual contributor to impact creator is one of the most challenging aspects of senior engineering roles. You’ll question whether you’re adding value, especially when you’re deep in planning mode while your teammates are shipping features. Trust the process. The organization needs engineers who can see beyond the next sprint, who can identify the architectural decisions that will pay dividends for years to come.

Your code will be refactored. Your services will be replaced. But the engineering practices you establish, the standards you set, and the engineers you mentor? That’s the legacy that defines true impact.

What impact work is calling to you? What systemic challenge in your organization needs someone willing to step up and drive change? The sprint will always be there — but the opportunity to shape your engineering culture won’t wait forever.