Edit: I find it also frustrating, as I suspect that a lot of the bluster is from armchair cowboys, and in no way reflective of what those commenters would actually do in the given situation.
Edit: I find it also frustrating, as I suspect that a lot of the bluster is from armchair cowboys, and in no way reflective of what those commenters would actually do in the given situation.
This guy isn't happy with being told what to do. A conversation is very unlikely to sort this out.
I don't think leaving is about "punishing the manager." This job will be more appropriate for somebody else, and this company will probably be better off with somebody happy working in the new environment. It's not about mediocrity - it's about people sharing similar values and being happy with their working situation. That's very important and when people believe completely different things and don't have mutual respect for each other, it's very hard to find some kind of meaningful compromise.
Edit: I say what I've said not because I'm an armchair cowboy (thanks), but because I've tried the other approach before. It's better to find people elsewhere that share your philosophy, than to try to convert people. (Converting people feels egotistical to me. We all love our own opinions but who is to say that they are best for our neighbours? I certainly don't want to be the one arguing this - it is such a grey line and so easy to accidentally antagonise somebody.)
But when you actually look at what it says, it's basically "roll over". The best outcome envisioned in that response is, "If he compromises and lets you have a bit of flexibility". First, take a moment to appreciate that *lets you have" remark. As if we are grade schoolers and the manager is a teacher who gets to decide when we go to the bathroom.
Then notice how the best outcome imaginable is a compromise. A scenario where you simply get what you want is not even on the table, here, even though it's entirely possible that getting what you want in this case is the best outcome for everyone involved, and at the very least is probably achievable and reasonable.
Really, this is something that you can't properly advise on without knowing the personalities and the context. If management is full of dickheads, then this is your signal to search for the exits. Start looking for a new job, and jump ship when you can. Things will only get worse. On the other hand, if management is generally reasonable and this is an isolated problem, a reasonable discussion with this manager to find out what's going on is the thing to do. But this should be a discussion between equals, not the groveling and tiptoeing suggested.
I don't think we read the same comment. It most certainly doesn't say roll over. It says try to find a diplomatic solution before you fire shots. An ultimatum isn't going to change anyone's mind, and will only make things difficult. Try to come to an understanding so OP can keep his job and be happy, and the new manager can keep his developers and be happy. It also says that if there's no other way out but to leave, it costs OP nothing to be cordial and professional as he's exiting the company.
Cordial and professional doesn't mean being a doormat, and talking to management as an adult with autonomy over one's own life does not require an ultimatum.
A lot of the users also will jump in with completely pointless anecdotes about employment law as it applies in some country but the question is obviously about a different one (hint at will has no meaning outside of the UK).
If several senior developers leave because their attitude is not a good fit for new management, then the company may have to hire and then train new staff on loads of bespoke stuff without the people who wrote it being there. Who cares about getting people who fit the company culture if doing so kills your product?
The key is to make the company culture fit those who write working software.
Your compensation has effectively changed (free time is a form of compensation), so it's time to negotiate this change in compensation. Don't threaten to quit and don't assume you can "educate" the new manager on how the industry works. You can't. Try to come to an agreement on personal compensation. If you succeed, great. If you fail, smile, say "thank you" and start looking for another position.
Not only do I think that's excellent advice, I don't think it differs in any material way from what you're saying.
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.
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.
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.
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.
One thing I've learned on the employer/employee side of development (that was initially painful, but now just seems obvious) is that for most software projects as long as the goal is well defined and meets some need in some market as well as expected, all they do need is mediocrity. And I mean this is the sincerest way, not the "fuck them for thinking this" way, but the "they are right to think this" way.
You could be a 10X (or whatever shorthand you want to use for 'very good') developer compared to everyone else on the team and you might feel yourself being Harrison Bergeroned by process, tools and management designed to pull everyone toward the middle and when you quit you'll think "Now they'll see what they are missing", but then you find out they could in fact easily replace you with mediocrity and nobody would notice and the project could even go on to be financially successful if everything else falls into place.
I highly encourage all developers to maximize their talent and ability and always keep learning, but at the end of the day the results I see in the real world (on both ends -- mediocre developers becoming wildly successful and extremely talented developers who don't do nearly as well financially) are that the correlation between pure talent/skill and their financial/career success relative to other developers is fairly loose.
As a manager, you can either lead great devs on a 6-person-month project, or you can remove the good devs and turn that into a 36-person-month project. In the former, you're going to be seen by your peers and upper management and somebody who had an easy task but can't control your unruly employees who keep strange hours and don't follow the dress code. In the latter, you're going to be seen as somebody who successfully managed a very complex project with a large staff, impressively inspiring the employees to mass amounts of unpaid overtime.
The path to success for management lies in controlling larger staffs and larger budgets. Good development just gets in the way.
This is sick and this is exactly the problem with the manager mentioned in the SE question. The manager should not focus on controlling staff, but on controlling the workplace environment so that developers can focus on building the product, and not on in-office politics, dealing with angry customers, faulty equipment, etc. The role of manager should be one of a servant, not of a boss. Some other terms for that: "shit umbrella" and "developer abstraction layer".
I remember one of my first forays into management. It was a small team full of really good developers. We delivered ahead of schedule and way under budget. I remember thinking "this sucks, I'm not really DOING anything. I'm just letting these guys go out and kill it and keeping everything out of the way. This isn't going to end well for me".
It was the opposite. My boss was pleased as punch that we came in way under budget and ahead of schedule. The complexity (or lack of) didn't really seem to even show up on his radar.
Because this is supposed to be the job of a good manager. Not bossing people around, but abstracting away and isolating things irrelevant to their tasks.
Congratulations on your success!
Not so. Compensation is important if funding is available, but many devs love what they do and the service they're providing, beyond monetary compensation.
I have a passion for doing a great many things. I believe I should be compensated for expending time--literally quantums of my very life--if employed in the service of another. These two things aren't mutually exclusive.
If it weren't about compensation I would work on my own stuff or open source.
The real answer should basically say that you need to start negotiating.
Of course you need to be nice and civil (read Dale Carnegie's book) but also understand that you don't need to liked by some people. For negotiating there are many books. But the point is basically very simple: 1) figure out what you really care about, 2) learn what other side really cares about, 3) be nice, 4) every negotiation needs to end with both parties satisfied, 5) "no deal" is also possible outcome
It's not about punishing the manager, it's about getting the best job you can.
The problem, I think, was how the original question was phrased. It made it sound like a moral problem "You don't deserve good developers" which is a not very professional way of looking at it.
It's not your job to teach your boss how to do his or her job, and for cultural reasons, usually attempts to do so are met with hostility. The closest I have come without causing problems is buying my boss books. And even that... well, it was presumptuous, and it didn't change the boss' behavior, but it also didn't seem to blow back on me.
The question would have gone better if it were framed as an economic issue, a "what's best for me" issue, rather than as a "how can I change my boss" issue.
"I am getting paid less here than I think I could get paid elsewhere. That was okay before, because I am willing to take a pay cut to be treated a certain way, but management has changed now. What do I do?"
The problem here is that what the employee wants (and was sacrificing money to get) was a certain management style. If you want more money, you can negotiate that with your boss. If you want a new management style? you probably aren't going to be able to negotiate that. You could negotiate specific consequences of that management style, say, flex-time, but the root of it is still there. You probably aren't going to change your boss' management style.
In that case? A rational actor would leave the company. I mean, they would do so as gracefully as possible, of course, but you aren't going to change your boss' management style.
The safe thing is surely to just start looking for a new job.
The problem from the technical/developer perspective is a typical company - non-startup, non-technical core competency - lacks executive technical leadership. Therefore decisions about hiring management likely do not include technical understanding, and hence the managers aren't very likely to have any. So the best you can hope for (assuming you are a great developer) is benign neglect, where managers accept their ignorance and just keep the wheels turning.
But that's assuming extraordinary developers - most developers are by definition average, and therefore on average, the most probable situation just a mess of average developers with average managers not figuring anything out.
And while we can all be guilty here on HN of overstating our own abilities, I can say that people here seem to have a higher degree of understanding and wisdom overall (whether I agree with them or not) than I've seen on average in IT, so I have little doubt that frustrations with management can be heated, frequent and counterproductive to the business.
If you are their manager, sure. If you love the job, sure. If you work a industry where jobs are rare and it is hard finding a new one, sure.
But if you are software engineer, not working for a startup, and can very easily switch jobs. Why in the world would it be your responsibility to try and fix your management? It's a job, not a marriage.
I think managers should be wise this is their job, and developers don't need to make their job easy, they earn a lot of money anyway.
I see this trend lately where developers suddenly need to make everybody's job easier. Now developers need to make the HR people understand that... they need to make the stake holders understand that... etc etc Really?
Many programmers I know are very frugal and some single, and some are very resilient so they need to make a lot of people understand that there are limits and boundaries someone should not cross and that everybody should do their work.
Developers cannot do qualitative development in sweatshop environment.
In fact, on another review, there is one deleted comment whose content I don't know, and none of the other comments are about punishing the manager at all. It's less a '10-to-1' and more 'none-to-one' ratio.
You can't tell them: They can only learn this through experience. Alternately they may be the sort of shop where average developers are perfectly satisfactory.
read: The counter-party to your negotiation is not an honest/competent partner who may have reached a rational conclusion given their understanding of the situation. Also, exceptional talent doesn't need to be treated like this. Conclusion: only average talent negotiates, compromises, respects management's motives. Exceptional talent finds a different party.
You don't tell somebody such a thing. It would never work. The rules are the rules to most people... It's not always better to have "great" engineers - often companies just want somebody sitting at their desk ready to act on instructions. If that's the case then there is probably a lower-skilled engineer that would count themselves lucky to be sitting at a desk for 8 hours. He will be a lot easier to manage and probably a lot more appropriate for the new management.
read: Management is hidebound and petty. No possibility for compromise exists. Management placing burdensome demands on your time, therefore, is not an opportunity to negotiate but a cause to leave. Tolerance of such a situation is for low-skill employees only.
It's called an exit interview. Once you secure a new job, don't be shy with your managers about why you are leaving.
read: Don't try to constructively engage your management. Exercise your opportunity to leave, and then, once your exit is secure, air your displeasure with policy changes.
You don't need to tell them anything. If you're a good developer, you choose where and with whom to work. Feel your power and use your power.
read: Obviously management has no legitimate concern here, or interest in expressing how employee time is structured.
You quit.
By not continuing to work under managers that are shitty.
---
I could go on. I may have miscounted on the ratio, but it's hardly "none-to-one"
You are misconstruing what I said.
Negotiating often isn't the best option. You can cause a lot of harm attempting to negotiate. Rather than being a jerk about your opinions and trying to convert other people to them, it's better to go and find people that share them. (Additionally, I'm unsure that the OP was looking for a compromise, and disagree that compromise is possible between a rigid 8 hours a day and 6-7 hours a day. The numbers are very close; it's effectively one or the other here.)
I might be wrong to imply that tolerance is for low-skilled employees only, as there are high-skilled employees who tolerate or enjoy these circumstances, too. But somebody that can easily get another job is more likely to get another job - so there is something to this. I guess I said it more because of the OPs frame, which was cocky: "I'm a hotshot. I can go and get another job." (If you look at everything else I said however, I did say that the company can probably find somebody that is a better cultural/work-ethic fit. I think it's win-win.)
Yes, there may be some residual punishment or vindictive feelings underlying some of the commentary, but the main focus of pretty much all of it is 'look out for #1, that person is who your duty is to'. It's still a mischaracterisation of the commentary to call it out as suggesting punishment. The bulk of the commentary is not "fuck those guys, make them suffer", but "it's too much effort to change management culture from below - it's far easier to just move onto greener pastures if its available".