In Staff Engineer, Will Larson describes one category of high-leverage activities "Staff-plus engineers" perform that he calls "editing":

A surprising number of projects are one small change away from succeeding, one quick modification away from unlocking a new opportunity, or one conversation away from consensus. I think of making those small changes, quick modifications, and short conversations as editing your team's approach.

With your organizational privilege, relationships you've built across the company, and ability to see around corners derived from your experience, you can often shift a project's outcomes by investing the smallest ounce of effort, and this is some of the most valuable work you can do.

I was enlightened when I read this. It captures concisely something that I've been doing for some time but couldn't quite summarize on my own. I can think of multiple instances where I "edited" our team's technical direction since I became TL a little over one year ago:

• Alice writes a design proposal to build feature X, which requires three complex sub-systems to be built and integrate seamlessly with each other. Each sub-system takes about a quarter of engineering time. The proposal is deemed too risky by stakeholders. Knowing how to "short-circuit" our existing systems, I suggest first building a MVP which only requires building one sub-system plus some workaround paths elsewhere. With reduced ETA to a prototype, it's much less risky and easier to get buy-in.

• Bob sets out to build a non-trivial service for feature Y. Having had a conversation with someone from a partner team a few months ago, I know they are working on something very similar and are well ahead in schedule. I arranged for Bob to meet with the partner team to explore the possibility of joining forces. Such synergies avoid reinventing the wheel and strengthen the collaborative relationship between teams.

• Charlie has spent three quarters on project Z that for various reasons turned out to be much bigger in scope than originally planned. Having been in the same situation a few times, I understand too well how having too much work-in-progress is bad for morale and decreases the overall productivity of the team. I advised Charlie to be firm and "ruthless" when working with the PM to postpone TODO items into phase 2 and prioritizing shipping what has been built.

Another reason I find this framing useful is that, it rightfully acknowledges certain strengths of a software engineer that some might dismiss out of a belief that only designing and implementing complex systems count as "true" technical capabilities.

I fell victim to that belief too. I didn't go so far as despising "engineers without true technical capabilities or anything alike, but I was genuinely concerned about my own career growth. I thought I wouldn't be able to scale my impact any further once I've outgrown my organization's growth such that there wouldn't be technically challenging projects for me any more -- not unusual in well established teams whose businesses are past the periods of rapid growth.

In reality, I'd be well positioned to edit our team's approach by possessing a deeper understanding of the systems, building trusting connections with partner teams, or simply having made more mistakes than others to stay off pitfalls. All these don't require an increase in technical scope and difficulty of the projects, but are just as significant.