I think a lot of analog designers will struggle with gm/Id because programming isn't exactly their forte. You have to be able to develop tables to work with based on your process and tools that you are comfortable with, and then be able to set up the problems in a way that matches the tools and how well you understand the circuit and test benches already. If you can't design an opamp without using gm/Id already, you will likely struggle when using the method. Managers love the idea, because it gives them the illusion that design cycles can be much faster and easier.
On the other hand it can be very useful since 1) it uses the same process files that designers simulate around anyways. 2) can reduce the number of design variables to start iterating over (e.g. starting with a simple gm/Id target already eliminates one of the two variables once you know the other).
On the other hand, in my experience of designing for production over many years, I can't say that your managers will start by giving you all the nice specs and constraints up front (power, area, f3db, fu, etc.), that would be nice. But it's more like, we need a 6 or 7 bit ADC for the ethernet front end receiver, how long will it take you to design it? The big struggle is figuring out how to even translate that to specs (which includes learning how to ask others for help, and hopefully getting it).