[MartinCron]

I don’t think in my case that it was necessarily about me and my performance. Just like I don’t think that the OP’s story is necessarily about him and his performance. When teams grow, they change. There is an all-too-often unspoken assumption that roles will get more and more specialized as the team expands. You can go from being a dev/pm/architect/analyst to being “just a dev” or “just an architect” so slowly that you don’t even notice the de-facto demotion until it is too late.

A metaphor I use with management to prevent this from happening again is “I eat my broccoli so I get to eat my ice cream. Hiring someone to eat ice cream for me so I can focus on just broccoli might make intuitive sense to you, but will have a detrimental effect on me”

[goldcd]

That's a metaphor that I know is now stuck permanently. My only addition would be that this is your broccoli and ice-cream. I'm eternally mystified as to what some of my colleagues like. Maybe the greatest benefit of agile I found is I can just shove my needs/rankings into it - and can then just let people pull out whatever they fancy from it. Running the other way there seemed to be surprise when a dev found some major issue or came up with some great idea and I was more than happy for them to add it themselves - and I'd happily rank up it at the cost of one of my planned features. I get the distinct impression that previous occupiers of my role were less flexible. What I've done (I hope) is just to be as open as possible about what "I like" and be open, consistent and say the same thing to anybody who asks.

[Itaxpica]

One of my old managers used to say that time and time again he would fret about which of his people would wind up stuck having to work on the shitty, boring parts of a project, only to find that someone else on the team was really excited to work on what he had thought were the shitty, boring parts; and on the flip side they would have seen as shitty and boring the stuff he thought was most interesting. The lesson for him was that as tempting as it can be as a manager to try to puppeteer everything, you can often get better results by just stepping back and letting a team figure out how they want to divide the work.

[MartinCron]

As a dev manager (small team) I am trying to never “assign” work. I just prioritize and describe, and let fellow coders pull the items that are most appealing to them.

Sometimes it means that I wind up doing work I would rather delegate if I were being selfish, but for the most part, everyone benefits.