This has just been from my experience but:<p>Prioritization: Most engineers find this difficult but identifying what needs to happen "now" and what can happen "then" is critical to being able to hit all of a company's targets. Being able to say "Yes, what you're talking about is important but we need to focus on XYZ to get to {Series A, Series B, Revenue Target, Milestone, etc}" and stick to it is very difficult to many people. I've heard "but this code is ugly" or "it's hard to support" but it's, most of the time, like complaining about the color we've decided to paint a boat while the boat is actively taking on water and sinking.<p>Business: Business is the language of managers, C-level, and the average non-technical employee. If you understand what your product is, why people pay for it, and how you can get people to pay more for it, you'll always have an understanding of what direction your company should be headed in. As an engineer you also have way more information about what is possible than everyone from the management team and if you can identify a quick win, hammer it out, and tell management about your idea and that it's already implemented they'll be blown away (most of the time).<p>Fostering Teamwork: The reality of the situation we find ourselves in is that pretty much anyone can code. Long gone are the days where an engineer needs to think about how much power/clocks/ram/disk an algorithm needs to take in business software settings. By and large even engineers at huge companies like Google just string together solutions by calling into functions/code written long before they started working there. This means that the real value to be delivered to a company is in making it so that these engineers can forever stay productive and that they never really need to understand the lower level tools to be effective. Program for your company for a day and you'll feed them for a day, teach everyone at your company how to program and you'll feed them for a lifetime. Find a way to position yourself as the guy people come to for help/tooling gaps/design questions and you will increase your value to the company. "X wants Y but they'll make our other investments worth (10*Y) so it's a no-brainier".<p>Make Failure Ok: No matter what you do you'll make a mistake at some point. What you need to do is add just the right amount of padding on everything so that no matter what mistake you make you land on soft ground. For instance, even if it's very over priced, I insist on backing up everything everywhere I work. Everyone thought it was a little much until recently one of our main QA DBs failed and we were able to recover. A few years ago that would have halted the dev process at the company for 3+ days which at a scale of more than 5 engineers is a massive loss. The moral is that if something CAN break or fail it WILL break or fail and plan for it to happen no matter how large or small your company/team is.<p>I've only recently started my career in SWE/SRE but these seem to be common patterns/practices that have worked for me.