I think it helps a lot when PMs decide on the lines of responsibility.<p>Like recently we had a project with a lot of mutual dependencies. The app scans a QR code for access and then access is denied. Who is at fault? The app developer? The API developer who gave them the code? The guy who integrated the code? The back end system handling roles?<p>Is this thing being worked on or is the responsible person waiting on someone else for a fix?<p>The lazy approach here would be to adopt scrum, which settles issues like this, at a great cost.<p>But I find a good PM makes it clear what the progress of the project is, without having to bother the engineers for it. They still do things similar to quick 5 minute meetings, but they slot it into the flow, like when the engineer gets back from lunch. Something like Trello helps a lot in this background monitoring, and the good PM encourages them to use it as it's what cuts down the meetings.<p>One thing I did as manager was to print out every page of the app, paste it on a wall, and then tick off whatever was done, whatever was high priority, or who needed to do it.<p>It's also important, but much harder, to make sure that the team gets along. When the team gets along, they communicate. When they communicate, they know what's going on. This might include posting memes on Slack as icebreakers or talking about their favorite football match. This might also mean allowing the team to head down and have a half hour tea break at 4 PM.