Operating Principles That Guided Me to Staff Engineer (Part 1: Driving Impact)

Make more impact, get more done, and grow faster

📣 Ship faster with context-aware AI (Sponsor)

Augment Code is built for real engineering teams. It understands your codebase across 10M+ lines, 10k+ files, and every repo in your stack—so it can actually help: writing functions, fixing CI issues, triaging incidents, and reviewing PRs.

All from your IDE or terminal. No vibes. Just progress.

---

Hi fellow High Growth Engineer 👋

I’m happy to share that I was recently promoted to a Staff Engineer at Pinterest! There’s a lot I’m excited about in the new role, like starting a whole new growth journey and making sure I’m the best “Staff” I can be. I’ll be writing more content around Staff-level topics, as teaching has been a huge source of growth for me.

In that vein, the first article begins now! We’ll cover the operating principles that drive my actions every day and likely helped me reach the Staff level (I say likely because correlation != causation). They are not necessarily a requirement, only how I operate. Any advice or opinions are my own and not of my company.

The principles will be shared in two parts:

1. This article - Principles that expand your impact every day

2. The next article - Principles that expand your influence

Both tie together into helping you deliver Staff-level scope and results, which need to be large, complex, and across teams.

Let’s jump into the first principle!

Principle 1: Find Problems. Create Scope

Venturing into Staff engineer expectations requires you to not just be handed problems. You need to find them. And even if you are handed a problem, you won’t take that problem at face value. You’ll understand it deeply and find even more ways to improve past what you were given.

Why should you do this? Well, this is how you create your own impact and drive what’s most valuable to work on. To reach Staff level, you need to provide direction. Identifying problems that need to be fixed enables you to provide that direction.

So how do you find problems? Don’t be complacent. Continuously ask, “How can we do this better?”

A few examples from small to large are…

• Small: A question that keeps coming up in support channels → I ask myself, “What would need to happen for this to not keep coming up?”

  • …leads to a JIRA ticket that gets prioritized

• Medium: A time-consuming on-call handoff → I ask myself, “What could we do to make this take less time?”

  • …leads to a 1-Pager that documents the problem

• Large: Builds take 50 minutes longer than they should → I ask myself, “What aspects of it are the slowest and how can we speed those up?”

  • …leads to a strategy doc with cross-functional alignment

Each case illustrates how you can find your own impact without relying on your manager or tech lead to hand this off to you.

The process is simple:

1. Observe how a system works

2. Ask if it can be improved

It’s easier said than done, though. The way to do it consistently is this:

Do not accept the status quo. Do not become complacent.

Instead of viewing the way things are as “just the way it is,” you view it always as something that can be improved. This does not mean that the existing system is or needs to be “bad.” It’s only that everything can always be better. Keep looking for that, and you’ll find plenty of impact and scope.

It doesn’t end there, though. Once you find the scope, you need to drive the solution.

Principle 2: Extreme Ownership

The term “Extreme Ownership” comes from the book by Jocko Willink, a retired US Navy SEAL veteran.

Jocko describes extreme ownership as taking ownership of the problems and mistakes that happen, then seeing through that they’ll be fixed. If something goes wrong, you don’t blame anyone but yourself. He describes it through the lens of war and his experiences on the battlefield. You don’t need to know more than that for this article, but you can check his TED talk if you’re curious.

I agree with his definition, and in the tech world, I see ways to apply extreme ownership every day. Extending principle 1 further, what matters in ownership is not just identifying problems, but what you do next, and how. After identifying a problem, the next action often falls into one of three categories:

1. Say nothing. Let it remain a problem, and maybe it’ll get fixed eventually

2. State the problem. Make the problem known, but let it be someone else’s fix.

3. State the problem and drive a solution. This is where extreme ownership is. You don’t just call out the problem and make it someone else’s job to fix it. You ensure a fix happens, end-to-end.

Extreme Ownership goes past only identifying problems

In the tech world, some examples of driving solutions are:

• Putting up a quick code fix to the issue

• Drafting a 1-page proposal of a fix to the problem

• Making a bug ticket, reporting to the owning team, and following up with them

• Creating a proof of concept to demonstrate an idea, then enabling another engineer to ship the full fix, and following up with them as they implement it.

• Reporting it to the owner, but offering to help as much as you can

Being a Staff engineer requires you to expand your impact outside your team. Taking extreme ownership gives you that, as ownership often expands outside your team, which builds Staff-level scope, influence, and results.

Now, will you always be able to “state the problem and drive a solution”? Yes and no. At the very least, you should be able to state the problem, and the “drive a solution” part varies based on the time available and how important the problem is.

In one instance, I reprioritized my work for 2 weeks to dedicate my time to high-impact cross-team fixes I identified. But if I did that every time, I’d never get what I originally set out to do done. So like most things, it’s a balance. If I have less time and the problems are less impactful, I may only make a bug ticket and follow up with the owners later. But for those high-impact finds, don’t be afraid to get permission to drive fixes for them and make a huge cross-functional impact.

Principle 3: Bias for Action

There’s a simple productivity idea from David Allen’s Getting Things Done called the “two-minute rule”: if something takes less than two minutes, just do it now. Don’t schedule it, don’t plan it, don’t put it in a system. Just finish it and move on.

I’ve found this applies to engineering too. Small, fast wins matter. They remove friction for you and others, and they build a reputation that you’re someone who gets things done.

But what I see instead is this:

1. Someone reports an issue, like incorrect copy text

2. A JIRA ticket is made to fix the issue

3. That JIRA ticket sits for weeks or months before being addressed, even though it would have taken a few minutes to fix.

Instead of earning a reputation for getting things done, you get the opposite—someone who adds to the backlog but rarely removes from it.

By the time it’s finally prioritized, you’ve spent more time creating and tracking the ticket than it would’ve taken to just fix it right away. That’s the opposite of bias for action.

Bias for action is about breaking that cycle. When something takes less than 15 minutes, fix it now. Don’t let problems linger.

Some examples I’ve seen or done myself:

• Someone calls out an outdated documentation link. Just fix it now.

• Fixing a flaky test after it fails, instead of filing it away for later.

• An alert is being overly noisy, so we update the thresholds now.

When I work with engineers who operate like this, it’s a breath of fresh air. I report an issue, and before I even check back in Slack, a fix is already up. Or if I’m blocked by another team’s API, they reply: “It’ll be fixed in the next deploy.” That kind of responsiveness instantly builds trust and goodwill.

And that goodwill compounds. I’ve gone out of my way to highlight these engineers in peer feedback and to their managers because it’s such a rare but valuable behavior. Not everyone will notice in the moment, but over time, it shapes your reputation.

Now, does this mean you should always drop everything for every little issue? No. If the fix really is small (<15 minutes), usually yes. If these small items are taking longer than that, you may need to invest in better systems to improve speed; more on that in principle 5.

Principle 4: Pragmatic Iteration

Make it work. Make it right. Make it fast. - Kent Beck

This is the principle I follow in pragmatic iteration.

Since I work in developer productivity, I’ve had lots of opportunities to spin up tools for engineers to get things done faster. A lot of my work is for internal use cases, so it’s not the end of the world if alpha versions of a tool are shipped, because engineers would rather have some productivity boost than no boost.

How this works in reality is a bit of an extension to “bias for action.” Let’s say an engineer reports an issue with something just as I’m heading into a meeting. What do you do?

• The anti-pattern response: Create a JIRA ticket and let it rot in the backlog.

• The decent response: Add it to the backlog and fix it weeks later.

• (What I do) The pragmatic response: Spin up my AI coding workflow, paste the request and a solution idea, then let the AI scaffold a solution while I’m in the meeting. When I’m done, I check the code, fix obvious flaws, and push it for review.

Is it the exact code I would have written by hand? No. But it solves the problem. And in my context of internal tools where speed matters more than elegance, that’s the right tradeoff.

I weigh the tradeoffs of…

1. Solving the engineer’s problem.

2. The risk of imperfect code.

3. The time cost of making it 100% perfect.

For me, solving the problem usually wins. If I were working on a financial, legal, or medical system, the weighting would flip. There, perfection matters more. Pragmatism means recognizing your environment and adjusting the factors you optimize for.

Too many teams get stuck in dogma like, “We must achieve 100% test coverage on every line of code.” Sometimes that’s right, but applied blindly, it slows progress for little benefit. Pragmatic iteration is about avoiding that trap: shipping code that solves the problem, cleaning it up later if it’s worth it.

Principle 5: Invest in Yourself

One of the highest ROI moves you can make as an engineer is to invest in your own productivity and knowledge, which makes all the other principles we discussed easier to accomplish.

• It means you can embody extreme ownership by following through on cross-functional problems while still getting done your original work.

• It means you can embody bias for action by turning what was a “I’ll add it to the backlog item” into a 1-minute task that you get done immediately, building trust with the other person.

• It means you can embody pragmatic iteration by having multiple solutions moving forward in parallel.

To achieve these through investing in yourself, there are two key focus areas:

1. Use high ROI tools. And yes, sometimes, they cost money.

2. Set up systems that make your daily work smoother.

Use high ROI tools

Some of the biggest wins can come from adopting a few tools that make the most common things you do more efficient and of a higher quality.

Cleanshot has been a great example of this for me. I use it 10-30 times per day for stronger communication with visuals. I use it to highlight problems and solutions in threads, document my code changes, and for video demos.

At the same time, it costs $29. I know, right, $29. What the heck!? A tool that can save you hundreds of hours every year and level up your communication, but I have to pay $29 one time or get it expensed? How dare they!!?? Ok, I’m being a little sarcastic here 😅 but I’ve seen this sentiment before, and it really makes no sense to me. As an engineer, we’re paid pretty comfortably. But there’s also a bias toward expecting everything to be free and open source. At the same time, most of us don’t work for free, so why expect others to?

One of the best lessons my dad taught me was to convert the value of my time into money. Time is the one thing you can’t get back, so pay for more of it. The average software engineer salary in the US is $150,000, which converts to $72 per hour. The question I ask myself when investing in myself through money is, “Is the time I get from it worth more than the price I pay?” If it is, I get it.

It works the same way with books. They’re one of the most affordable, high-quality forms of education available. Someone took thousands of hours to distill lessons from over 20 years of experience into a condensed format, all for just $10. It’s an amazing deal!

…Anyways, I’ll leave it up to you, but that’s just my strong opinion!

P.S. I’m not saying CleanShot is a must for everyone. It’s just an example for me because I use it a lot, and the $29 pays itself back plenty. The main takeaway is not to close yourself off to tools just because they cost anything. It should be a tradeoff between the cost and the benefit it gets you, not a strict “no pay for anything” rule.

</steps off soapbox>

If you’re curious about more tools for engineers, I share my recommendations here and in the top 7 engineering workflow tips article.

Set up systems

It’s not just about software either. Sometimes the best investment is taking a full day to properly set up your environment. A simple example: terminal autocompletion. You probably have your terminal open all day. Without autocomplete, you waste brain cycles remembering commands. With it, you free up attention for higher-level work — not “what was that command again?”, but “what problem am I actually solving?”

The ROI is huge. A few hours upfront can save you dozens of hours across months, which compounds over years.

If you’re curious where to start, here are two external articles I recommend: New Mac Setup by swyx and Mac Setup for Web Development by Robin Wieruch.

There are also these two High Growth Engineer articles: How I Setup My Terminal for Max Productivity, How I Got 27 Hours in a Week. Finally, if you become a subscriber, you can access the productivity learning track.

📖 TL;DR

• Find Problems. Create Scope.

  • Don’t wait for tasks to be handed to you. Observe how the current systems work and constantly ask “how can this be better?” to find problems to solve.

• Extreme Ownership

  • Don't just identify problems. Drive solutions end-to-end, as long as it makes a large impact.

  • Take ownership of issues spanning teams to build Staff-level impact.

• Bias for Action

  • Fix small issues (<15 minutes) immediately instead of creating tickets and delaying for weeks. Build trust by fixing problems quickly.

• Pragmatic Iteration

  • Ship working solutions first that provide value, then improve them based on what’s actually needed.

  • Balance velocity vs quality based on context. Recognize when it’s ok to break the rules and be pragmatic (e.g., 100% test coverage is not always necessary).

• Invest in Yourself

  • Use high-ROI tools that save time, especially if the time saved justifies cost.

  • Spend a day setting up productivity systems that compound over time.

These principles helped me consistently deliver results and build credibility. But to sustain that impact and scale it, you need something more: influence. Influence is how you get bigger, faster results by shaping priorities, aligning people, and earning trust. That’s what we’ll cover in Part 2. See you there in the next issue!

---

Thank you for reading and being a supporter in growing the newsletter 🙏

You can also hit the like ❤️ button at the bottom of this email to support me or share it with a friend to earn referral rewards. It helps me a ton!