Hacker News Reader

Comment by allochthon | Hacker News Reader

generally espousing a naive us-versus-them attitude.

It is nearly impossible to avoid this kind of attitude when managers see themselves in a shaping rather than supporting/facilitating role. I've seen good teams given a new, inexperienced manager who sees his job as turning certain knobs and "incenting" certain behaviors and outcomes, and it ends exactly like you think it would. The good devs leave, and the team is in for difficulties. We need to redefine what "management" means.

The critical point that such managers don't seem to get is that good devs must own what they're creating, and they're not instruments to blindly further someone else's purposes.

View on HN

I'm not sure what you mean. All managers are paid to ensure better outcomes, where "better" is defined by the company (not by the engineers, except insofar as this enables the company's goals). Some managers are more effective at this, and some less. As a manager, sometimes it's better to have a cohesive team with consistent rules, even if some engineers will opt to work elsewhere as a result.

Although I am sympathetic with OP's feelings that a strict 9-5 rule is most likely unhelpful for everyone, I do think if the engineer took a confrontational tone, the manager would have no choice but to call his bluff. Any other move, and no one would take that manager seriously again. Therefore, the top answer in the original post is correct: ask nicely, and if compromise is impossible, start interviewing elsewhere. If he can really get a 40% bump, it's probably worth taking that.

I suppose "manager" is industrial aged thinking for a company with that particular culture. Good developers are self managing and self actualised and self motivated I believe. Support/facilitate is an apt role for someone to massage the backlog and keep accountability with stakeholders.

the manager would have no choice but to call his bluff.

It's exactly the same for good devs confronting a confused manager. They must call the manager's bluff, and that often (usually?) means leaving. Less experienced devs will try to push back, but it's probably as hopeless as the dev imagines it to be, and they risk just prolonging a bad situation.

That was a really good post. I've never seen the distinction between supporting/facilitating and shaping pointed out in such a lucid way.

OTOH, when it's time to move from research into production, this 'shaping' rather works: those 'good devs' with poor respect for authority move out of the team (either from the company or deeper back into R&D), where people who stay / newly hired readily agree to fulfill well-defined roles.

What "authority"?

Different people have different roles. If I know tons about implementing caches, I probably end up making most of the decisions about that sort of thing. If you know a lot about scheduling projects, probably you'll end up doing a lot of that. A junior person probably won't get to make a lot of decisions, except in whatever rather small area they are contributing in. And so on. Management doesn't mean you are an authority, it just means you have different responsibilities (and I manage as well as develop, I don't write this solely as a developer).

We can all come up with counterexamples to the above. What if someone is not pulling their weight? What if a group decides to drink (heavily) at the job? And so on. Sure, at some point somebody needs to make decisions about hire/fire/probation, and so on, but the hope and desire is to build a team that self directs itself in as much as that is possible.

I don't know, the whole 'authority' thing comes off as weird to me.

Maybe there's some linguistic problem (English being not my native), but I wrote about the power of making decisions, of telling you what to do and what not to. It really isn't applicable to junior positions, but if you're one of the most senior developers on a project, you might well doubt the competence of the project manager to make tech-related decisions. Micromanagement aside, you and PM may have serious disagreements on what technology stack to move to or buy-vs-build decisions.

It's also a great lesson for software development as having the Manager class instruct the 'managed' classes is usually a worse design than having the managed classes inform the manager.

Reply on news.ycombinator.com