4 ms·
The "investigate options" one was one of the few situations that I could see a possible slight. I've seen managers who play this dumb game where they put peopl
by awinder 11y ago
The "investigate options" one was one of the few situations that I could see a possible slight. I've seen managers who play this dumb game where they put people on a research problem, and the job isn't for the engineer to do unbiased research & prototyping, but it's instead to reinforce whatever argument they were originally pushing for (but your "job" is to actually bring facts in). I've heard the "you're biased" line enough from those kinds of people to just shrug it off and move on, but I've also seen engineers who become paralyzed trying to figure out "what the boss really wants". For my biased point of view, these managers fit into a category called "the worst" anyways, so getting worked up about it is probably not worth it.
As an aside on the not understanding front, what was the deal with the team lead scenario? In my experience team leads aren't managerial positions so I don't quite understand why the guy was so concerned with other employees salaries. There was also a lot of missing details there, the author could have been making significantly more, and so the raises were treated differently? That was definitely a peculiar one.
- exelius 11y agoYeah, generally at any company large enough to have a dedicated HR function, dev leads usually don't get informed or consulted in salary decisions. I was confused by that one too; his expectations were out of line on that one IMO. The reason for this is that it's not at all uncommon for dev team members to make more than team leads if they have a specific skill set that the market values more.
- fredwu 11y agoHi, Author here. Unfortunately that one was from a small startup where I was responsible for evaluating my team members' performance and salary.
- exelius 11y agoYeah; unfortunately at startups where roles / expectations aren't clearly defined, this type of stuff happens. Honestly I doubt it was out of malice; it's simply easier at a small company for the CEO to make all the comp decisions themselves than have to consult half the company about information that's supposed to be confidential. He may have thought he was doing the right thing to do -- startup CEOs are usually just winging it.
- hyperpape 11y agoTo me, it seemed clear that he had nominal responsibility for salaries, but was being routed around and undermined. Whether a "team lead" should have responsibility for salaries seems beside the point--if you've told someone they have responsibility they should have it until you relieve them of it.
- phkahler 11y ago>> The "investigate options" one was one of the few situations that I could see a possible slight. I've seen managers who play this dumb game where they put people on a research problem, and the job isn't for the engineer to do unbiased research & prototyping, but it's instead to reinforce whatever argument they were originally pushing for My manager asked me to interview a guy for our embedded software team. The guy was working for our internal customer and was already well liked by the team, but he wasn't creating software. I asked if my input would matter or he already had his mind made up, and he said that yes, this was a real interview. So I asked the guy a few questions and then decided to just give him "FizzBuzz" in the language of his choice. He spent the rest of our time and more trying to solve it but no full success. Then I was in the awkward position of taking him to lunch since everyone else had gone already. So I go back to the boss and say "the guy can't code, don't hire him". Boss hires him anyway. Kid figures out FizzBuzz later that afternoon - he's got determination, and people were ultimately happy with him being on the team. Lessons: 1)Boss's mind was already made up. 2)FizzBuzz is not necessarily a good test. 3) No matter what people think of you, if you fuck up that test your nickname around the office will be "Fizz" from then on.