Hacker News new | past | comments | ask | show | jobs | submit login

I find it very sad that the top answer on stack exchange is a guide for how to have mature discussion, see the manager's point of view and collectively look for a solution -- while respecting his authority. But when you come to HN, 10-to-1 the comments are all about punishing the manager by leaving, teaching management a lesson, suggesting that maybe they only need mediocrity (in other words, developers as great as us would never bow to such demands) and generally espousing a naive us-versus-them attitude.

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.




I didn't personally find it very mature. It's just somebody parroting "How To Win Friends" with an authoritative spin. I found it manipulative and warped.

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.)


The top-voted answer is a great example of how much wording matters. It sounds very mature and reasonable, compared to the off-the-cuff and coarse answers given in the comments here.

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.


Hhat one of the problems with workplace I have seen 2000 odd words of wafflely answer that does not address the question asked - get voted up.

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).


>But when you actually look at what it says, it's basically "roll over"

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.


A diplomatic situation implies a meeting of equals. That comment suggests a meeting wherein you very very very gently raise the possibility that perhaps there can be a small change to what's been mandated.

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.


Once you get past the Dale Carnegie stuff though, the top response is actually dead on the mark.

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.


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.

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?


It appears you've learned the lesson, having developers that write working software results in a more profitable company than having developers who remain in their seats for 8 hours a day.

The key is to make the company culture fit those who write working software.


I would agree unless said culture is toxic or negative (such as racist, sexist, or any combination thereof).


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.


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.


"maybe they only need mediocrity"

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.


It's important to realize that the goals of the manager and the developer are not necessarily aligned. In many cases, managers rationally prefer mediocrity.

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.


Perhaps. But managers have budgets, and at most companies controlling those budgets is the path to success. If I can deliver a great product with smaller staff (and less overhead) I'm generally going to come out far ahead.

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.


> and keeping everything out of the way.

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!


> 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".


In reality, if he can get a 30% pay raise elsewhere, he should take it. It's not about punishing anyone, it's about compensation. Part of his compensation is flexible work hours. Another part is money/benefits. If his manager came in and said 'we're going to pay you 12-24% less for your time' it would be just as much of an issue.


It's not about punishing anyone, it's about compensation.

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 love my work. I do not believe it is a good reason to pay me less and pocket the difference. The chances are that I will love work in other company too.


I'm not suggesting that they pay you less and pocket the difference; if it was bad, that would be reason alone to leave. Instead I'm suggesting that there are reasons to stay at one job instead of automatically changing to another, better paying one, and that people are not being foolish by remaining at the lower-paying one. This happens all the time when people are working on a startup, for example.


I like what I do too, but I'm not some ephemeral being, I have material needs. Anyway, It's always about compensation, environment and camaraderie is part of compensation.

If it weren't about compensation I would work on my own stuff or open source.


Indeed, it's called 'compensation' for a reason: it compensates for the time spent doing what you'd prefer not to. If you do what you love, nothing to compensate for :)


Bluntly, that attitude is incredibly naive and, in the extreme, obsequious.

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.


It's a compensation for opportunity cost. Even if it may be really fun to build things that make others rich I'll still need food, a roof, and healthcare.


The top-level answer is all the fluff without the substance. It is just nicely written.

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


The top-level answer is focused on what you call steps 2-4. You have a wider, better frame of reference, but some of their focus is appropriate too.


>But when you come to HN, 10-to-1 the comments are all about punishing the manager by leaving

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.


I think the guide to having a mature discussion is a very good one. I also think it isn't going to work with this kind of manager. If the "mature discussion" is not handled properly it might end up with the manager looking to fire the employee before they find a new job.

The safe thing is surely to just start looking for a new job.


Perhaps the most respectful and truthful way to handle this particular conflict is to assume some symmetry between "good developer" prevalence and "good managers" - that is to say that while it isn't discussed as often, good managers are as valuable and rare as the "10x developer."

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.


I am not sure it is rational to spend a lot effort to teach your management.

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.


It's a matter of perspective and context. In large, established organizations managers tend to be creatures of corporate politics--their intent is to climb the corporate ladder. They play political games with their employees, with other managers' employees, and with each other. Their job isn't to be on the team they lead; it's to represent upper management. It isn't naive to have an "us-versus-them" view in these cases, because it is quite literally the case.


I think he should leave if he can, not to punish the manager, but in order to not punish himself.

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.


This is a smokescreen. The economic reality is that good managers are a dime a dozen.


The difference between the two perspectives is that, in a buyer's market (e.g. SV), managers have no authority--or rather, have merely the imaginary kind of authority a grown adult perceives in their parents.


Going through the comments older than yours, I think you're significantly misrepresenting them. Very few of them are about punishing the manager. Most of them are about 'prepare to leave' or 'just leave' - the focus is on bettering the individual, not leaving a vindictive mark.

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.


From siblings to my comment:

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"


None of what you have quoted particularly reads as 'punish the manager'. It's only your post-facto flavouring that gives it that emphasis. Pretty much all of it is "you have to look out for #1" - which I agree is not always the best advice, since it doesn't try for a win-win solution.

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".


That's a fair characterization and you're welcome to that interpretation. I think I've explained my interpretation well enough that, even if you don't agree with it, you understand it.


>> 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.

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.)


I read the top comment as an unfortunate guide for fellating the manager. It has been 9 years since I last worked somewhere where anybody cared about hours in the office. Until the day casual work environments disappear, I personally wouldn't have much reason to work anywhere else.


In software, tiny complaints that make it up to the leaf nodes of the corporate tree are usually signals of huge iceberg problems below you. People are not saying leave your job to punish management. They are saying leave because things were previously OK, but now some things are happening down below that you will never be allowed to know about until it's too late. You have to amplify your actions and move quickly because of how little information you get.


You're right. I think a lotvof developers don't even know they're born.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: