The topic of whether it is a good idea to have global pointers to each manager in your engine is an open one. I worked on a commercial game for PC, PS3 and Xbox that had a global static pointer to each subsystem manager, so g_pRenderer, g_pScene etc. I now currently work on a commercial engine that doesn't have subsystem managers but does have lots of static data and a few singletons dotted around for good measure. There are many ways to skin a cat.
In some regards I would say don't worry about. Don't lose sleep over unnecessary architecture that you don't require. When writing an engine its easy to fall into the trap trying to write it too perfectly but at the end of the day no engine, no matter how well written or otherwise, is any good if it isn't being used to make games.
Anyways, to give you an idea for what I do in my engine is have it broken down into to two areas and these are separate libraries. I have Kernel and Engine. Kernel contains a the main interface that Main() deals with and contains the Command, Task, Core (utilities for platform access) and threading. The kernel class allows access to each of its subsystems. The second library has the engine code in it so resource loading, gui, scene management, physics, rendering etc. The engine class provides access to those subsystems. Nothing in the kernel area depends on the engine area, only the other way around.
Circular dependancies do happen and these are more easily identifable if each subsystem requires a pointer to its subsystem dependancies upon construction, for example:
GuiManager* guiManager = new GuiManager(pSceneManager, pRenderManager, pInputManager, pDataManager);
Being forced to pass in pointers rather than just using globals makes you realise something might be wrong more easily.
In short, it sounds like you're on the right track but just focus on it meeting your needs and not some unattainable goal of perfection that noone ever really achieves.