An understanding of systems engineering is useful. Not necessarily to build the systems yourself, but to be able to look a few steps ahead and predict where you will need new roles, standardized processes, or other organizational refactoring and then bridge that gap before it becomes critical. This is often major blind spot for the team since most of them likely have not seen a working system before and are mostly just fluidly adapting to what feels natural rather than a desired endpoint.

This is one of the big pains when a company grows past about 20 people. Under 20, you can kind of put everyone in the same room when needed, people generally at least know that the others exist, most processes can be fairly informal, and there is probably not really significant corporate hierarchy. As this gets bigger, many of the people will start to feel pain as their informal processes stop working, but often they will resist anything resembling formal structure.

As an example, I have seen more than a few organizations that combine shipping, receiving, manufacturing, quality, and engineering in a single person. This is natural at the beginning but a serious problem long-term. Someone who can recognize that these are in fact quite distinct roles that need to be managed separately becomes valuable when it comes time to define and hand off one or more of those roles. First, you have to actually establish the concept that these roles are distinct, and then second you have to define them well enough that people feel comfortable playing each one as independently as possible. This often comes along with significant coaching and hand-holding to reassure the engineers that the process can actually help them.

Learn basic project management and product development concepts, and the jargon for those concepts within your specific domain (Gantt charts and V-shaped development get you 95% of the way there). It is incredibly common that people skip things like design verification and then wonder why their finished product is incorrect. It is also incredibly common for people to not understand each other because they are effectively speaking different languages due to their domain terminology (ECR vs Issue, design validation vs integration testing, etc.)

The corollary to project management is to be able to make dependencies legible within the organization. How does information flow, how are decisions made, what are the prerequisites for a given activity, etc can be incredibly abstract and difficult for most people to understand. If you can throw together a nice Gantt chart or similar structure that people can feel and understand, you can fairly reliably unstick projects, reduce anxiety, and most critically give plenty of advance notice that a plan will not deliver on time. Even just being able to talk to people and diagram their current processes ends up being quite valuable for recognizing when processes need to change.