I would suggest the core issue was that you did not have the freedom to go get the important work down and be responsible for it. Too often work is subdivided so no one actually owns anything important -- because the bits are too small.
I've always been taught that breaking things down as small as possible is good - easier to estimate, easier to understand, easier to track.
You don't want to give a developer a week long task - that turns into two weeks, for instance. There just isn't the visibility.
I'd agree, there's a huge issue of none of the work feeling important, and an issue of Developers having no real power in the process (other than to unilaterally dictate how long we thought things would cost, strangely enough).
But is it a result of subdividing tasks too small? I'm not sure; it's an interesting concept to explore.
Each service gets assigned to one developer to build and own. Each developer then publishes a protocol/API for their service, and other developers--instead of needing to talk to them to consume their service--just consume its API.
This means each service can be developed, tested, mocked, gateway-ed, and made Highly Available in isolation from synchronous/blocking work by other developers.