Workflow strategies for mitigating merge conflicts from topic branches

Question

I'm right on the cusp of selling git to my higher-ups. They're listening to us talk about it, anyway. There's one thing I'm unsure of, and I'd like to see how people deal with this. Basically my question comes from the fundamental understanding that the further apart a pair of branches are allowed to get, the harder they are to merge.

I'm considering proposing this fairly simple workflow: Say I have a master (release) branch, a development branch, and topic branches off of that. Different developers are working on their separate topic branches, pulling and pushing those topic branches to a central repo as often as they feel they have working code. Periodically, when asked to do so by a developer, the maintainer (in our organization that person has the title "technical lead") merges from their feature branch into the development branch, that's put on a staging server and tested, and once the feature test complete, it's merged with master and pushed to production.

Here's my question. Should the devs merge their topic branches periodically? Doing so would ensure that they'll ALL merge back into dev fairly cleanly (or at least catches conflicts early before they can get out of hand). The only thing that I know my manager is going to dislike about that is, that's work they have to do to placate their tool, rather than work to deliver code to the project. Thoughts?