3 ms·
One thing that maybe isn't captured in the "relationship transition" section is aside from "telling your former peers they have to do things they might not like
by dccoolgai 5y ago
One thing that maybe isn't captured in the "relationship transition" section is aside from "telling your former peers they have to do things they might not like" you have to also tell other people (your manager probably) that your former peers _won't_ do what's being asked or will do it on a later timeline. A lot of new team leads miss that part. In any sufficiently large effort, there is going to be N owners of N priorities, and all of them are going to see the single one they have as the most important and have no real incentive (in most places) against burning your team out to get their pet project done. That's where you come in.
- linuxftw 5y agoWhat this typically means is the team lead thinks they're entitled to do the interesting work, like designing new features, exploring new ideas, and everyone else gets to fix the bugs and implement their half baked ideas. Then the developers push back, because no, we're just as capable as the 'team lead' and don't care what you think.
- dccoolgai 5y agoIn my experience, that's more likely to happen if the team lead _doesn't_ take an active role in defending the team's ability to do "interesting" work. I think the "do it all yourself" fallacy was covered in the article (which I found to be very well-written on the whole).