There's so much I wish I new earlier. I think in these sorts of things soft skills are of utter importance throughout the process. People, engineers especially, will have opinions - strong ones at that, and for any one project it's important to define and clarify and shared language early, and constantly update it.

These sorts of projects are ideal of Domain Driven Design as it allows you to talk about common concepts that might have the same name between departments, but mean something slightly different, and reflect this in the code.

It's important to identify the Domain Expert early and have open dialogue with them during the development.

In my first experiences we did not do DDD, and what I would now call the Domain Expert, ie the person with the most knowledge about their systems, had way too much influence on the architecture and development details, and so it became quite a mess where implicit knowledge was expected from the users.

When it came down to it the application did very simple things in very convoluted ways, but I never once felt like not having an engineering background hindered me. What would've helped me was more authority in regards to database design. Get very comfortable with APIs that handle data formats, at least know about the major O/RM, and get proof that you're the RDBMS expert if they don't already have one.