Stock Unreal uses a binary file format for its assets; switching this would be prohibitively expensive and is thus effectively a no-go. That means you have to life with binary assets, and the problem with binary assets is that they don't merge well, if at all. This complicates collaboration.
Unreal has built-in support for most major source control systems, and where possible (e.g., with Perforce integration) will encourage you to use a system of exclusive checkout on asset files, so that only one developer can be making modifications to a file at a time (excluding some workarounds that are generally only good for temporary, scratch work one won't check in). There is some basic support for diffing certain binary assets within the Unreal editor, but it's not great, and merging support isn't really a thing.
So the best strategy is to partition your work: where feasible, break up data into different asset files so different people can modify individual files as they need. Use Unreal's sub-level support to partition your world in a fashion that works well for your design process. For example, you might put the terrain in one sub-level, major, broad-strokes environment art in another, set dressing and minor detail work in yet a third, and audio stuff in a fourth, et cetera. Such an organization would in theory let four different developers work on the same area concurrently so long as they only need to check out one of those levels.
Of course it is still possible for, say, an audio developer to be laying out a bunch of audio volumes around a building to get correct reverb settings while somebody else is busy moving that entire building somewhere else, thus creating a logical conflict. You can basically only avoid these through communication and coordination, and by paying attention to who has what other levels checked out. With a small team, this isn't that hard.
You could alternatively split the world up into several small chunks in a grid-based fashion and just dictate that everybody work in different regions of the world at once. This helps solve the major downside of the first approach (except maybe at the seams of the levels), but can also make more bottlenecks when people need to make changes to the same region of the world at the same time. This also requires communication to resolve.
The above mostly applies to developers who need to work on the binary assets (levels, art, Blueprints). It usually excludes programmers who work on the C++ side of things. Generally, so long as C++ programmers are not making destructive or other major file-format changes, they can work on anything concurrently with the asset-focused developers, and can use standard source control and collaboration techniques (merging, et cetera) to synchronize work with other programmers.
Where you can run into trouble with C++ changes is in scenarios where your non-programmers do not build the entire editor from scratch themselves -- that is, when they're using a pre-built binary of your editor version from a build server or whatever.
If a programmer makes certain changes, for example, if they change a file format, they generally have to be careful not to check in new assets in that format until a build is available to the non-programmers. If they check in assets in a new format before a new binary is available, and an artist syncs those new assets from source control, the artist may no longer be able to load the assets and end up blocked or even crashing, depending on the nature of the change.
This sometimes means programmers have to do this annoying dance of checking in changes with shim code supporting both old and new versions, letting that build go in, and then later removing the old shims. There are processes you can put into place to enforce these rules, and even tools you can build to help enforce it, but nothing really comes with Unreal itself.
