11 min read1 day ago

–

A retrospective on strategy, systems, and impact that doesn’t show up in GitHub

At the beginning of every year, I find myself doing the same ritual most people in tech do: reflecting on the past twelve months and thinking about what I want to focus on next. Part of that is intrinsic motivation, part of it is, let’s be honest, required by our company’s performance cycle.

While writing my own review this year, I noticed that what I consider “obvious day-to-day work” as a Staff Engineer is not so clear to many in the industry. So I decided to share it, both for engineers who are curious about this path, and for those who interact with Staff Engineers without always seeing the full shape of the role.

First, some context: I work at a household name large tech company with thousands of engineers. Within that environment, my scope sits in what would be considered a relatively small slice of the organization: I influence work across five teams spanning three different orgs within a large department.

On a regular basis, that means working closely with around 30 engineers, four team leads, and six product leads, in addition to directors, heads of orgs, and various cross-functional partners. Roughly 50 people are part of my day-to-day orbit, with another 10–20 “temporary” which come and go as work goes beyond organizational boundaries.

This isn’t a guide, a framework, or a prescription for how a Staff Engineer should spend their time. It’s simply a retrospective: how my year actually unfolded, shaped by shifting priorities, unexpected incidents, and the constant tradeoff between strategy, execution, and growing others.

What is the role actually about?

The Staff Engineer role is typically seen as a progression on the Individual Contributor track. In practice, though, it isn’t a “natural” extension of being a Senior Engineer.

From entry level through senior, progress is largely about getting better at the craft: writing better code, operating with more autonomy, being more reliable, and delivering larger or more complex pieces of work. Moving into a Staff+ role is different. It’s more of a role change than a straightforward promotion, similar in many ways to moving into the management track.

That distinction matters. While Staff+ and management roles overlap significantly in the skills required to succeed, and often in day-to-day activities. Beyond Senior, the work is less about direct execution and more about shaping systems, teams, and decisions.

If a Product Manager is like a Mini-CEO without people managing responsibilities, a Staff+ is like a Mini-CTO without the people managing side.

Importantly, this isn’t a one-way door. Many, myself included, move between Staff+ and management successfully in both directions. Choosing one path over the other is about the kind of problems you want to spend your time solving and it isn’t definite.

The Staff role isn’t static. Depending on the organization, the problem space, and even the time of year, you’ll find yourself wearing different hats. In my experience, most of the work can be broken into three broad areas.

1. Strategy and direction

In this mode, I work closely with senior and executive leadership across engineering, product, and other functions to understand business goals and organizational priorities.

From there, the work is about translating those goals into concrete technical strategies: identifying leverage points, aligning teams around a shared direction, and making tradeoffs explicit. Strategy doesn’t stop at planning,it flows directly into execution, shaping what we build, what we defer, and how teams sequence their work.

2. Execution and getting my hands dirty

This is the part of the role that often surprises people who assume Staff Engineers don’t code anymore.

Execution at a Staff+ level means oscillating between multiple modes: driving complex initiatives forward, unblocking teams, and, when it creates leverage, contributing directly through code. That can include writing production code, reviewing and shaping designs, setting architectural direction, scoping work, and communicating progress and risks to stakeholders.

The key difference from earlier IC roles is that execution is evaluated less on volume and more on impact.

3. Growing people and the organization

As a senior individual contributor, I’m expected to be a role model, not just in technical decisions, but in how work gets done.

A significant part of the job is raising the bar for the engineers around me. That happens in many forms: onboarding new hires, day-to-day coaching, thoughtful code reviews, and more structured efforts like presentations, workshops, mentorship programs, and writing.

Over time, this compounds into organizational capacity, which is often more valuable than any single technical contribution.

How time tends to break down

My past year was somewhat distributed as:

• 30% on strategy and direction
• 50% on execution
• 20% on growing people and organizational capability

The exact mix shifts depending on context, but this has been a useful mental model for me.

With that, here’s what my 2025 actually looked like.

January: Setting direction

Once the holiday slowdown ended and people were back from vacation, I went fully into strategy mode.

I spent a significant part of the month reviewing company and org-level documents to understand the business’ goals for the year: what the company was optimising for, how my org and adjacent orgs interpreted those priorities, and, most importantly, where they overlapped. The guiding question for me was simple but non-trivial: what do we need to do to succeed this year?

After developing clarity on how those goals translated into my domain, I shared my synthesis with the rest of the leadership group, team leads and product leads, and we used that as input for an off-site. There, we went deep on one of our top priorities and as part of it, I presented an initial draft of a strategy and delivery plan, which we aligned on and stress-tested together.

This work centered around a large initiative spanning multiple departments. At that stage, the most valuable output wasn’t detailed solutions, but a shared understanding of our current state, our target state, and the gap between the two.

February: Turning direction into a plan

With goals and priorities aligned, my focus shifted to a different question: what actually needs to happen for us to succeed?

This phase was largely exploratory. I worked across teams to identify dependencies, surface constraints, and negotiate roadmap changes. The goal was to sequence work in a way that respected each team’s local priorities while still converging on meaningful business outcomes.

A large part of the effort was breaking down broad initiatives into smaller, composable milestones: defining intermediate goals, clarifying ownership, and making tradeoffs explicit. By the end of the month, I was able to present a concrete plan and facilitate alignment on a shared path forward, one that worked for individual teams and added up to progress at the company level.

March: Executing and bringing people along

March was a blend of execution and people-focused work.

On the execution side, I worked with teams on the design of new features and contributed directly where it made sense, helping move a few critical pieces forward. In parallel, I shifted attention to ensuring that the broader group was aligned and equipped to execute.

With strategy and direction now clear, this was a good moment to run targeted sessions with cross-functional partners. I started with a session for non-engineers, walking through our current technical architecture, where we were headed, and how those changes connected back to business and product goals.

I then ran a more technical session with engineers, focused on drilling into details, identifying risk areas, and surfacing opportunities to simplify or improve our approach. These conversations helped turn abstract strategy into something teams could reason about, and act on, day to day.

April: Creating space and targeted intervention

By April, the direction and plans were stable enough that teams could make steady progress without heavy involvement from me. I intentionally shifted into a more supportive role, focusing on enabling execution rather than driving it directly.

That support took several forms: pairing with engineers on critical pieces of work, reviewing RFCs and pull requests, and acting as a sounding board for design and prioritization decisions. In parallel, I was pulled into a few emerging priorities in neighboring teams, helping them get unstuck on architectural questions and sequencing their work more effectively.

Alongside this, I participated in the company hackathon, using the opportunity to explore LLMs and build a few proof-of-concepts around how they could evolve parts of our product. While not all of this work shipped, it helped inform later discussions and de-risk future bets.

Toward the end of the month, I worked with my manager and other leaders to examine where our ways of working were slowing us down. That reflection led to a decision to start a new, focused workstream the following month.

May: Focused execution at scale

May was about translating intent into momentum.

To move forward on one of the key priorities we had identified in January, we formed a temporary, cross-team group by pulling engineers from several teams. The goal was to improve flow by concentrating effort and reducing coordination overhead.

This ended up being the most hands-on coding month of the year so far for me. We worked in pairs or mobs almost daily, rapidly iterating and integrating across domains. By the end of the month, we delivered a large, end-to-end feature spanning multiple systems, significantly faster than our usual pace.

More importantly, the month validated a different way of working that we could reuse later.

June: Amplifying impact

June started with me presenting to the broader organization on what we had accomplished so far: the context we started from, how we planned the work, and how we executed to reach our first milestone.

This squarely fell into the “growing people” bucket. The goal wasn’t just to share results, but to make the process visible, what good looked like, what we learned along the way, and how others could apply similar patterns in their own areas.

After that, my focus shifted back toward execution and planning, setting up the second half of the year with clearer paths and fewer unknowns.

July: Adapting to shifting priorities

July brought the first major curveball of the year. Company-level priorities shifted, and we had to reassess how those changes impacted the plans we had put in place earlier.

My focus during this period was on understanding the implications of those shifts, identifying what still mattered, and adapting our roadmap accordingly. Combined with the natural slowdown from summer vacations, this was a quieter month in terms of visible output, with my time split between recalibration, selective code contributions, and keeping momentum where possible.

August: Switching to a defensive posture

August introduced a more serious challenge. Some of the systems we depended on began failing under load, forcing us to pause parts of our planned feature work and move into a defensive stance focused on stability and reliability.

While some incidents were ultimately traced back to corner cases in an infrastructure provider, they exposed deeper fragility in our own systems. Treating this as a one-off would have been a mistake.

I worked closely with my peer team leads and organizational leadership to define a focused response: identifying the highest-risk areas, agreeing on what “good” reliability looked like, and forming a small task force to address the most critical issues. Thi group consisted of core engineers and two other Staff Engineers, with a mandate to make meaningful progress quickly rather than produce long-term plans.

September: Deep execution and recovery

September was one of the most execution-heavy months of the year.

I led one of the task force tracks, working hands-on with engineers to diagnose issues, improve performance, and close gaps in reliability. This involved a lot of debugging, system analysis, and iteration under real-world constraints.

By the end of the month, we had made tangible improvements to monitoring and observability, gained much better visibility into system weak points, and addressed several of the highest-impact failure modes. More importantly, we left the organization in a stronger position to prevent and respond to similar incidents going forward.

October: From recovery to learning

October was about turning recovery work into lasting improvement.

Still operating within the task force, I used the new monitoring and observability tooling we had put in place to identify a few critical performance gaps that hadn’t been visible before. Addressing those issues, alongside progress made by the other tracks, brought the system back to a healthy and stable state.

As the task force wound down, we deliberately shifted focus from fixing to learning. I helped organize and lead a knowledge-sharing session with the broader engineering organization, a large-scale post-mortem and retrospective. We walked through how the problems emerged, how we detected and diagnosed them, and what ultimately worked to resolve them.

The goal wasn’t blame or completeness, but increasing organizational understanding of how complex systems fail, and how to respond when they do.

November: Re-entering execution and absorbing a surprise priority

With platform stability restored, we returned to our planned work and a more predictable execution rhythm. I spent time supporting engineers as momentum rebuilt, while also starting to look ahead to the priorities likely to shape the following year.

Midway through the month, a new and unexpected priority emerged, and I redirected most of my focus to delivering that functionality. The problem was non-trivial: it spanned multiple systems, several codebases, and teams operating across time zones.

I onboarded myself onto the relevant systems, worked closely with their maintainers, and helped define a cross-system approach that balanced local constraints with global correctness. From there, I moved into execution, contributing code and helping coordinate progress across boundaries.

December: Closing loops and setting up next year

December brought the natural slowdown that comes with year-end code freezes and the approach of the holidays. My focus shifted to closing loops: finishing the remaining pieces of the November initiative and ensuring the work landed cleanly.

With help from many others, we were able to get the effort across the line and remove one of the largest blockers teams would have otherwise carried into the new year. That, more than any single commit, was the real outcome, setting teams up to start the following year with fewer constraints and clearer paths forward.

From there, I intentionally wound down, using the break to reset before returning to the cycle again in the new year.

Wait, there’s more.

Of course, this isn’t everything. A large part of the job doesn’t fit neatly into a monthly timeline: building and maintaining relationships, regular 1:1s, mentoring conversations, learning new domains, experimenting with ideas that don’t always ship, and investing time in trust and context. Those moments rarely show up as milestones, but they’re what make the rest of the work possible. What I’ve described here are the highlights, the inflection points where that ongoing, often invisible work translated into tangible impact over the course of the year.

Finishing it up

Looking back, what strikes me most is how uneven,and intentionally so, the year was.

Some months were dominated by strategy and alignment, others by deep execution, and a few by stabilizing systems under pressure. Very little of it looked like a neat, repeatable routine. And that’s probably the clearest signal of operating at a Staff+ scope: the work follows the problems, not the calendar.

Sadly, GitHub doesn’t do a great job of capturing pair programming, whiteboards, or the hours spent in docs, Miro boards, and meetings. But if you mentally fill the gaps between commits with those artifacts, the contribution graph below becomes a pretty accurate visualization of my year. This is an actual screenshot of my Github at work:

Press enter or click to view image in full size

This is how my year went. Based on conversations with peers, the overall distribution is fairly common at this level, though the exact mix varies depending on archetype and context. Personally, I tend to sit somewhere between a Team Lead, an Architect, and a Solver, which maps pretty closely to how my time ended up being spent.

If there’s one takeaway I’d leave you with, it’s this: Staff+ work is less about doing more, and more about doing the right thing at the right time,sometimes by writing code, sometimes by getting out of the way, and often by making the invisible visible.

Then you take a short break, reset, and do it all over again next year.