Bingo! I have seen the smartest engineers (Princeton PhD in one case) rot in bad environments and mediocre engineers provide solid contributions in strong, engineering focused environments. I have rarely come across an engineer that doesn't want to build great products. If you want to suck the energy and enthusiasm out of team, add in weekly 120min planning meetings, required daily progress reports, and 4-5 product pivots.
I wouldn't be able to make a definitive judgement on that. But what I can say is that at my previous place of employment, we had a number of projects that never saw the light of day because the other organization couldn't meet their milestones. We were in direct contact with their dev team.
Oh, for sure - worked in capital markets and getting any integration between the different teams was an unpleasant affair. However, it usually wasn't due to a lack of talent, but due to politics or personality - somebody who likes to say "no" a bunch, or refuses to allow some other approach. Most of the devs were grumpy, but liked the steady pay and stuck around. Probably the root of the problem - if retention became an issue, perhaps things would change?
I can't speak for management, but our team would inform their team on what was broken, and it would not get resolved in a timely fashion.
We would get contacted by the client to resolve an issue on our end, and after some debugging we would consistently discover it was broken because of the other company. They couldn't produce code that worked.
This could have been a management problem. For example maybe they simply did not care enough about the project to allocate the necessary dev resources. But it also could have been resolved on the dev side if they did a better job of testing their code that they claimed was complete.
Edit:
I guess the most direct answer would be, since it was a problem that I could have resolved with tech, I didn't see a reason why they couldn't resolve it with tech.
"I guess the most direct answer would be, since it was a problem that I could have resolved with tech, I didn't see a reason why they couldn't resolve it with tech."
That really captures how engineers think. I think I often think the same way but my gut feeling is that there might be a fallacy in that way of thinking. I can't think of it right now but your statement does give me a bit to think about. I'm not saying you're wrong. In fact, I think the same way and that worries me :-)
- They are under-resourced and/or over-committed: they know how to fix your problem, they just don't have time to do it.
- Your not paying them enough to make it worth fixing: similar to the above, but in this case you simply don't represent enough revenue to make the doing the fix cost effective. Especially if it's a problem only you have.
- They have architecture constraints that make it hard to fix the problem: a bad/simple/incorrect design may make fixing the problem very hard
- They have legacy code which was poorly written or simply coded very fast and is now brittle and difficult to fix.
- They have internal political problems which are preventing them from fixing the problem.
I'm sure there are more that others here on HN have seen.
The worse case I saw of this was with a contractor who underestimated how hard the problem was, under-resourced the project and the resources that where on the project where not very good engineers. That project crashed and burned so hard there were lawsuits.