Everyone is hired for a specific job. The details of that job are explicit to both parties. Where there is ambiguity we call that out and set that expectation (ex: that this duty may change).
This alone avoids a lot of the “not my job problem” or people trying to encroach on someone else’s job. In turn, this reduces chances of conflict and politics.
Additionally, we keep communication extremely focused on work. There are no slack channels for watercooling, there are no “get to meet each other” zoom calls.
We (including founders) log on, we do our work, we communicate (via text) about issues, wins, concerns, questions, and we log off. There’s no expectation of working hours (save for that weekly dev sync I mentioned).
We also don’t preset deadlines. I’m not going to sit here and say we don’t have target dates, because we do. But it’s an explicit function of engineering to determine the scope of a feature and to assign it an effort. Based on that effort I can then forecast when it might get done. But there’s no deadline. This is just good engineering practice and also helps us improve our code quality over time. We do not share forecast completion dates with users and customers. The most we will say is that we’re working on something. No etas.
We’ve also built in a culture of shipping constantly. Shipping a feature or a release isn’t some big event. I might log on in the morning and see that a feature was finished over night (including final QA, etc.) and I’ll just release it. This takes a lot of pressure off development. Because we’re so comfortable releasing, even if there was an issue, we could just roll back. I’ve had to do this twice now and it was a non issue. The release notes hadn’t even been emailed to users yet, so no harm.