Estimated reading time: 6 minutes

As a new staff+ engineer, it can be difficult to scale your impact. Here are some areas you can capitalize on. 

If you’ve recently become a staff+ engineer, you’ll find that the bar for your impact will have shot up – alongside the understanding that you’ll find your own ways to make that impact yourself. Where do you look for those impactful opportunities?

If you excelled in your previous role, you have most likely helped change the way your team works in order to be more effective. Maybe you identified abstractions that let the whole team deliver faster, or maybe you influenced the planning process to be more predictable and improved trust with stakeholders.

As a staff+ engineer, your scope of change increases. Now, you’ll be looking for ways to scale your impact beyond your team to a much larger section of the organization. These kinds of transformations are bigger bets. They are harder, riskier, and take longer.

So, how do you look for good bets?

Pinpointing areas to deliver impact 

Even if you have a good understanding of your company’s goals, it can be difficult to exactly pinpoint how you can transform a product, process, or system that truly delivers impact. Two places you can start are activities that are collectively time-consuming and activities that you don’t do often enough.

Find activities that are time-consuming 

Start by looking at where most engineering time is spent across your part of the organization. Talking to engineers on other teams, other staff+ engineers, or managers, or even embedding on a team can help you identify repetitive or laborious trends that may not be obvious without a broad view across teams.

Here are some signs to look out for: 

• Work that is largely similar across teams. For example, two or more teams may build similar functionality differently. Instead of repeating this work, a shared solution that covers 80% of needs can save time and effort. The teams are then free to focus on the 20% that sets their work apart. Another signal of dysfunction can be when sharing code across teams is difficult due to non-essential differences in functionally similar code.
• Routine, repetitive tasks for engineers. If engineers are following the same script or checklist each week, there may be an opportunity for automation or a product feature. This kind of task, sometimes described as toil, is often assigned on a rotating basis. Common examples include deployments with several manual steps; updating dependencies with manual testing; and frequent customer support tasks, like account modifications, that tier one support is unable to complete on their own.
• Frequent, low-complexity changes that require engineering effort. Product teams may run similar experiments frequently – adding feature flags, reordering steps, adjusting copy, or imagery. With the right tools and safeguards, these could be actioned by non-engineers. 

Pinpoint areas that should be done more often 

If you’re looking to compound your impact, invest time in finding activities, tasks, or processes that should be made more frequent. 

In doing so, you can reduce risks by finding tasks that benefit from the consistency and repeatability that automation can provide. Others can reduce churn, encourage architectural best practices, or even help to change mindsets.

How do you determine that an activity would benefit from increased frequency? There are a few places to start:

• Benchmark against other teams or organizations. Reading about how other engineering groups operate and talking with peers outside your organization can identify areas of underinvestment. Research in books like Accelerate has helped establish both key metrics to measure and thresholds for high performance. Companies’ engineering blogs are another source of successful transformations that can highlight questions to ask of your own team.
• Look at the vision for how the organization will operate in 12–18 months. Talk with senior managers and other senior technical leaders about the collective vision of the organization and what will be different in a year or so. There will be gaps to close in order to reach those goals which may include doing certain tasks or activities more frequently. For example, the org may wish to adopt continuous deployment, which means increasing deployment frequency. Likewise, a goal of creating an inner source program means creating libraries regularly. 
• Ask what activities make people the most nervous. If people on your team fear certain activities more than others, it might be time to encourage team members to do them more often. Releases and deployments are often nerve-wracking, and building the tools and practices to make them common non-events improves confidence. 
• Find common themes in retrospectives. (Or start doing retrospectives!) Are there common challenges in your organization? If projects frequently miss targets, listen for phrases like “I wish we had…” or “if only we’d…” If you hear the teams express an appetite for the same practices, tools, etc over and over, think about how to incorporate them. The team may just think that’s how things are, so they might not have solutions in mind. For example, late project churn is a common pain point that can seem normal when it can be avoided — or at least significantly reduced — with up-front design and modeling work. 

Change culture 

Whether you end up recommending new processes that streamline efficiency or ones that require repetition, facing a changing culture will become a reality at some point. For many, this can be difficult terrain. However, you must remember that it is easier to change behaviors than opinions. Clear actions, backed by strong messaging as to why they’re happening, are more likely to bring gradual change to viewpoints. If certain behaviors are rare, the goal is to understand why and fix those root causes.

Check in, prioritize, and build buy-in

Working in an engineering organization is a team effort. Check in with peers and leadership frequently to make sure the outcome justifies the time and that it is aligned with leadership’s goals. 

To lay the groundwork for buy-in to a change, start by aligning on the problem. In Good Strategy, Bad Strategy and Design in Practice, Richard Rumelt and Rich Hickey both recommend starting with a frank, blameless, and factual description of how things are now and a diagnosis of problems or opportunities. Creating a document that outlines this demonstrates to stakeholders — engineers, managers, leadership, cross-functional partners — that you’re hearing their concerns and gives them an opportunity to correct or align on the state of the world.

Preempt stakeholder doubts on the validity of your suggestion; be prepared to answer questions like “why this?” and “why now?” The easiest way to do this is to create an aligned diagnosis, which will make it easier to identify the most impactful areas to intervene.” Gathering input from a range of engineers and other stakeholders will also let you tie a proposed transformation into the work that they’re doing day-to-day. This could mean enhancing their current work streams or addressing pain points they’ve expressed. 

---

Berlin • November 3 & 4, 2025

Charity Majors, Sam Newman, and Humera Noor confirmed for LeadDev Berlin! 🙌

Find out more

Final thoughts

As a staff+ engineer, much of your work will be to develop a clear vision, define success, and create smaller, achievable milestones that move the org in the right direction. This is hard to do effectively and takes practice and feedback. Only some of the work will be technical, or solved by software; much of it will be interpersonal — building alignment on problems, validating and promoting solutions, modeling and coaching new behaviors. When you succeed, you’ll be creating leverage not only for yourself and your immediate team, but for teams across the org you may not even work with directly. That force multiplier is what drives the scale of your impact.