> Doesn't really mean he's clueless though. He's probably telling you that he is getting shit for bugs, and there's a company perception that the product is bug

> Doesn't really mean he's clueless though. He's probably telling you that he is getting shit for bugs, and there's a company perception that the product is buggy. Ask questions and find out. And if that's the perception, help him with a pragmatic way to share the real story. I think this means he is clueless in the way that a developer asking "what is a for loop" would be considered clueless. Managing company perception of what your team is working on, and advocating for their work both in terms of features and fixing bugs is like Engineering Management 101. Doing all this "asking questions to find out" stuff is what the manager should be doing. > My experience is that if the team isn't translating what they are doing, why, etc...upwards, then the boss eventually makes up something to measure. Again, managers doing this are clueless in the same way that a developer "making up" syntax would be. They should be replaced by better, more clueful managers. I have absolutely no idea why we as an industry tolerate arduous coding tests and take-home projects for "individual contributors", but have a propensity to give people managers a free pass on obvious stuff like this.