In addition to what <i>chadash</i> said, and the whole "Chesterton's Fence" avoidance... I'd say being helpful to the team goes a long way. Here's an index reply I wrote that I link to often[0]. The first link there is about understanding codebases, but if you look at the links, they're pretty much all about making the team's job easier, removing frictions.<p>You have a useful background in consulting. As any good consultant, you observe, you recognize problems and frustrations, you figure out the job to be done, you figure out the current state and the desired state, you represent that gap, and you solve that problem. You do that for the team. You're hopefully accustomed to communicating with stakeholders with different skillsets and doing impedance matching: this is valuable. Make engineering problems understandable by non-engineers, make non-engineering problems understandable by engineers. That transcoding is very useful.<p>If your team is having trouble deploying something, make deployment easier. If code is not documented, write better documentation. If issues lack clarity, write good issue templates to capture <i>problems</i> (and not implementations/solutions) and lower the barrier to writing clear issues. If you can bring your expertise in consulting being exposed to a variety of contexts, sectors, and industries; this is useful. These are examples that may not be applicable, but you get the idea: there are a lot of things to do that have not been done for a bunch of reasons, be a gift of a person and be helpful.<p>- [0]: <a href="https://news.ycombinator.com/item?id=25025253" rel="nofollow">https://news.ycombinator.com/item?id=25025253</a>