This is a form of
tight coupling. Virtually all design tutorials advocate loose coupling. Putting yourself in the best position to reuse object types is one reason. Keeping the interface of each object functionally separate is another.
Knowing what Employees and Companies
do in your application will do make shed more light. Something as simple as a hashtable, where each Employee is a key and each Company a value. Something more sophisticated such as a Composite
pattern, where each Company represents its Employees by both membership and responsibilities over other Employees...it's a question of attributes you want to emphasize that I think will guide you along further.