Things I've seen that seemed to contribute to team happiness and productivity:
1) Process-focus. It's not "stop doing that, Bob", it's "let's make sure that can't happen unless we really, really want it to". And not just for technical stuff.
2) But also a willingness to kill processes if they weren't useful. Always OK to ask "who needs this meeting?" or, understanding its purpose, "can this be a few 10-second Slacks with follow-up when necessary, instead of a 15-minute team meeting every day?"
3) Project managers who were "on the team's side", at least so far as the team could tell. You come in taking the whip to people, you end up with bullshit information. You can't manage a project effectively with bad info. You want your team to tell you when shit's going sideways, or just that it might, early. They won't do that if they think they're taking on personal risk by raising issues. And they'll be stressed out and their work will be worse.
4) Semi-relatedly, estimation based on past (team) performance, on the same project. No guess-timates becoming commitments. No "so, can you have that tomorrow? Two days?" This is one part of the "agile" thing that, when done right, I've not seen anything surpass in accuracy or in keeping panic and confusion away. It does mean your estimates at the start of a project can't usefully go very far into the future and will best be expressed as large ranges until at least a few weeks in, and that you can't swap people around all the time and keep estimating accurately—but that's true anyway, even if you pretend it's not. I have seen people care a lot that their estimates often suck but not be willing to give up the "so, one day? Two days?" ambushes or accept that there will be times in a project when responsible estimation is very imprecise. These folks tend to get bad info on top of the inherent flaws in their approaches, because they have trouble with #3.
5) No "I have five bosses" crap.
That all may be more "in the weeds" and/or obvious than what you wanted, though.
- Project managers who were "on the team's side", at least so far as the team could tell.
This. I've found this so imporant in my time. As far as I'm concerned, if a manager can't keep their own team on side, they might as well not bother. When the manager is popular and people unite around them in times of stress, then everything will work so much better. From there camaraderie and esprit de corps naturally starts to follow, especially if the product manager personally hired many of the members of the team and starts to build a tradition.
If I were to add something to your list it would be accountability, but not blame. If somebody does something wrong, both engineering wise but also in soft skills, its important that figures of authority take the time to both explain where the person went wrong with a view to trying to understand why the person made the mistake, but also visibly put into effect processes for the future to prevent this kind of thing, either by adding it to the onboarding training or with some kind of code review or even just make sure everyone in the team knows a key piece of information that person may have missed.
1) Process-focus. It's not "stop doing that, Bob", it's "let's make sure that can't happen unless we really, really want it to". And not just for technical stuff.
2) But also a willingness to kill processes if they weren't useful. Always OK to ask "who needs this meeting?" or, understanding its purpose, "can this be a few 10-second Slacks with follow-up when necessary, instead of a 15-minute team meeting every day?"
3) Project managers who were "on the team's side", at least so far as the team could tell. You come in taking the whip to people, you end up with bullshit information. You can't manage a project effectively with bad info. You want your team to tell you when shit's going sideways, or just that it might, early. They won't do that if they think they're taking on personal risk by raising issues. And they'll be stressed out and their work will be worse.
4) Semi-relatedly, estimation based on past (team) performance, on the same project. No guess-timates becoming commitments. No "so, can you have that tomorrow? Two days?" This is one part of the "agile" thing that, when done right, I've not seen anything surpass in accuracy or in keeping panic and confusion away. It does mean your estimates at the start of a project can't usefully go very far into the future and will best be expressed as large ranges until at least a few weeks in, and that you can't swap people around all the time and keep estimating accurately—but that's true anyway, even if you pretend it's not. I have seen people care a lot that their estimates often suck but not be willing to give up the "so, one day? Two days?" ambushes or accept that there will be times in a project when responsible estimation is very imprecise. These folks tend to get bad info on top of the inherent flaws in their approaches, because they have trouble with #3.
5) No "I have five bosses" crap.
That all may be more "in the weeds" and/or obvious than what you wanted, though.