I am not sure there is a best way since this depends a lot on the internal tooling of your organisation. However the main thing to pay attention to IMO are release and development cycles. Ideally you want both teams to be able to release new features, functionalities without impacting the other. (for instance if other_team makes a change to their code for a third team you would like this to have no possible impact on your application. Similarly other_team should not need to know how and when you use their module to make changes to their application.

One way to do this would be to have other_team_work be packaged and installable (using a setup.py) and then pushed to a package registery (for instance gitlab's package registery or github packages). This way you can use other_team_work as though it were just another python package with pip (using the extra-package-url argument) and using specific versions in a requirements.txt.

The simplest way (but can be dangerous) is add other_team_work to your project in PYTHONPATH. You can add this to django settings.py file, after BASE_DIR definition. Example:

import sys

BASE_DIR = Path(__file__).resolve().parent.parent  # default Django base dir
OTHER_TEAM_WORK_PARENT_DIR = BASE_DIR.parent  # in accordance with your directories
sys.path.append(str(OTHER_TEAM_WORK_PARENT_DIR))

This code add your directory org_wide_django_code to PYTHONPATH and you can import other_team_work in your code:

from other_team_work import implemented_logic