I managed a high-functioning C++ image processing group for 25 years. I kept senior-level engineers on staff for decades.
We tended to write "engine code." Like pipelines and whatnot.
The company had a very (very) long tradition of engineering (Like, 100 years).
There were many downsides to the way they worked (over-structured, mostly), but they always gave my team and me a great deal of respect.
They didn't use contractors very often.
To this day, design quality, code quality, product quality, documentation, and focus on deliverable are the major cornerstones of my software work, but I am shocked at how little that matters to modern development shops. It's been a really disheartening experience.
I guess I was in a silo of quality-focus, all those years. They would treat very minor bugs like extinction-level emergencies (not fun).
> but I am shocked at how little that matters to modern development shops. It's been a really disheartening experience.
Modern development shops operate in a hyper competitive environment with razor thin margins. Unfortunately, great documentation is often the last thing that's prioritized for such shops.
Personally, I think this is a HUGE mistake; talented technical writers are in good supply and should be hired by any development shop to improve adoption of their product. HOWEVER, as a developer, the shop will prefer that you work on features rather than documentation.
Not NYC. Long Island, but headquartered in Tokyo. I’m avoiding directly naming them, so I don’t have to deal with any agita, but they make photographic equipment, and are a household name.
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.
Like someone on a team for a decade talking about why it works so well and discusses cultural and political issues and how the team overcame them.