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.
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.
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.
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.
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.
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.
> 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
>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.
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.
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 don't tell somebody such a thing. It would never work. The rules are the rules to most people.
What you do is look for another job and resign when you've found it.
This is win-win for both of you: you can find something suitable for your lifestyle, and they can find somebody willing to play by their rules at whatever level of the market that is.
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.
Even when done with the best of intentions, second-guessing what upper management needs to do for a company to be its best is a gigantic waste of time and potential. Trust me, I've been there.
What a bunch of spoiled, whining brats! Sure, you can only code for 4-6 hours a day, but why not honor your contract by spending that other 2 hours mentoring less senior people, trying to understand your employer's business goals, and generally trying to do your best to move your company ahead. Sheesh. By the way, the sheer arrogance of the question "How do you tell managers that having good developers is a privilege?" beggars belief. I believe that as a programmer, it's your duty to spend some time doing stuff your manager didn't know he needed to ask you to do, rather than running personal errands.
The relationship between developer and manager is something that is continually evolving and being renegotiated. After all, most states are "at will".
Whether pay or conditions, there is nothing wrong with having a discussion and asking for changes (or in this case, retaining the status quo).
I do agree that "having good developers is a privilege" is a strange viewpoint. In fact, people often say I could get 30% more easily" when that isn't the case. So I take most of this question with a pinch of salt.
How do you know his whole contract terms. It's not that simple, there might be an informal clause to it, agreed on with previous management. Maybe in lawyer-centric US this is unthinkable, but I doubt that. The country is not specified, btw.
I bet you would have caused an uproar of sexism if your comment had said the same about a female shoulder. Is there any basis for the sexist nature of your comment?
> I believe that as a programmer, it's your duty to spend some time doing stuff your manager didn't know he needed to ask you to do, rather than running personal errands.
--------------
I believe in dealing in good faith with people who deal with me in good faith. But it has nothing special to do with being a programmer; it's something I'd do in any job, and it is reciprocal. There's an implied agreement that they're going to try to treat me decently and there's an implied agreement that I'll do the same for them. If either of us breach that, I strongly desire the other party to defect.
Work contract is an exchange of services between peers for the mutual benefit. If one of the peers wants something that is harmful to both of them, it is the responsibility of other peer to point that out.
There is no moral responsibility to "honor your contract". The contract is a mutual agreement, not a word of God.
He says he's in the office 6-7 hours a day, but that doesn't mean he's only working for that amount of time - he could also be working from home (and being much more productive during that time than he would be at the office).
I think explaining that "Most senors developers can leave and get another job with a 30-40% higher pay" and that "most current developers stay because of the flexible time and casual environment" is a very strong point. I would try to understand a bit more the concern about the forced 8 hours a day at the office.
But obviously, if the manager is just dumb, just go to higher authority and explain that this manager could create lots of problems (I.e. pissing off the lead developer who has most of the software knowledge isn't wise. . especially if he's already happy and doing a great job.)
If the higher authority doesn't give a @!$ well.. send me an e-mail I'm looking for great javascript developers ; )
> "Most senors developers can leave and get another job with a 30-40% higher pay" and that "most current developers stay because of the flexible time and casual environment" is a very strong point.
One of the worst things a developer can do is to underperform on purpose because of thoughts like the above ("I could get a better job elsewhere, so I don't need to put in any effort here"). It leads to the worst possible outcome for everyone: low pay, bad performance, dissatisfaction on both sides. If you think you deserve better pay, ask for it or go find it elsewhere. If you don't, you were just looking for excuses to slack off.
I didn't say "Work at 30-40% of their capacity". The job environment is obviously a very important factor when considering a position.. some developers preferred to have a smaller salary in exchange for a better work environment. This is what I think should be explained. Now, if a new manager comes in and remove that great environment, what in hell would you stay if you don't have the great environment AND you have lower salary than market standard?!
I completely disagree. Casual, unrushed work and lower hour weeks are absolutely a feature to hire qualified, but otherwise busy employees. Parents especially go for these sorts of roles.
When they say "casual atmosphere", you should think about people taking time off work to drive their kids to baseball practice. Not potheads arriving at 12PM at work.
Over the years, I've learned that often, "talking" does little or no good. Actions are what matter.
You demonstrate your value. They either respond in kind, or it's time to leave.
Not to omit all communication nor seeking some understanding. But this tends to be supplemental to the whole "actions" thing -- clarifying, perhaps, in some cases. I've rarely observed it to play a primary role in fixing a situation.
The new manager has no experience managing developers, and the old manager has moved into a development role to fill in gaps left by senior developers leaving the company and being unable to find replacements.
They have already failed. This is not your problem.
> As the engineer, it is your right to quit if you don't want to play by the rules.
Or, it's their right to say "no" (or just ignore the rule he's concluded is bad) and have a power struggle. Which is what I expect may happen at this company (not advising it, but what may happen). Or have an adult discussion about it
The new manager may not politically have a chance in hell of being able to fire the guy. Or he may replace him easily and fire him. Or realize he really is trying to cut everyone's pay approximately 15% and back off.
There are lots of ways this could happen.
That said, I do agree with you, moving on often has the smallest amount of conflict. Very possibly what the guy should do.
There is nothing about the poster that implies that the poster is particularly young. Simply that the developer isn't part of management.
Additionally, it is a fallacy to confuse entitlement with rationalism. The developer rationally knows that based on their skills they can go elsewhere easily. The question posed is an interesting one. The manager who has been brought on certainly has the right to make changes. But don't fall prey to the assumption that the manager is a good one. Companies fail all the time because they make human mistakes.
The tragedy here is that chances are this cultural shift will probably kill this company if it is too small. Most developers these days have the privilege of picking workplaces based on the culture and companies that don't account for this won't succeed.
There is a reason that google has a fleet of private busses that take their developers to and from work.
You are assuming that the developers are critical to the success of the company. This may be true in the startup world, but is not true in normal enterprise environments. In most cases, the core business is something else, and developers exist to improve the internal tools, not to drive the core business. Therefore, improving the dev staff is just a question of efficiency, not one of critical success or failure.
Actually, in many enterprise orgs, one of the key strategic questions of IT is whether or not to even have a dev staff. That is the whole "build vs. buy" discussion.
And frankly, the startup world should be jumping for joy over this - the lack of quality internal dev staffing is exactly what creates the need for larger enterprises to purchase outside products, and therefore create a market for startups.
There is a larger ecosystem at play here - if/when every enterprise-level company starts becoming a good place to be a dev, then their own internal capabilities will become greatly magnified, there will be a correlating decrease in their decision to purchase 3rd party products, and the market for startup-created products will decrease in turn.
You are absolutely right OP is unclear if he is just part of an IT division at a non engineering company. The vibe of his statement made it feel to me that he was working for a software company which is why I responded in that context.
..
Assuming the case you present:
If the OP is even a goodish engineer there are lots of opportunities out their and companies that have internal IT have to be conscientious of the fact that they are hiring from a pool of people in a high demand sector. Standard methods for managing other departments may not hold up in the IT department at a company that has decided decided to internalize dev. The decision to force this square peg through the round hole of the rest of your company culture may lead to the failure of the goal of internal dev at your company.
..
For a number of years I worked for a large org that had decided to internalize some dev. The engineering division functioned very differently than the rest of the company. Meetings were more flexible there was no way to predict when developers might actually be on site or working from home (something that was rigidly controlled in the rest of the organization). Friends in other sections would ooze with jealousy over our lifestyle... usually right up to the point where I started talking about the average number of hours engineers in our department billed to the organization. I was part of a team that regularly worked 15 to 18 hour days and was happy doing it. The fact of the matter was growing the development team was difficult, candidates with the appropriate skills were scarce. When I was hired the company had spent 2 years looking for someone to fill the position and it was another year of serious looking before we were able to hire another. Keeping in mind the company spent serious time and resources trying to grow this team which it wanted to be bigger. The company recognized the support provided by our scarce resource by affording developers with the leeway to live in a way were they might produce their best work.
...
the is a great story about Jeff Bezos telling an employee how to deal with a bad manager by voting with their feet:
http://lifehacker.com/5921729/jeff-bezos-taught-me-when-to-q...
The fact of the matter is there are a management success is dependent on cultural buy-in and a manager who was very successful at one company may fail at another because of a predetermining culture that they don't fit into. This is a risk companies in general have to manage and not figuring it out can cost money over time and potentially lead to failure.
..
Also I know this is Y combinator but I think that it is weird the way that people use the word startup to mean software company and talk about it like its an industry instead of a phase. sorry if this is lexically nit picky of me but i feel like the fact that you called me out for assuming that the poster works at a software company and not in the IT shop of a larger org puts you in a sort of glass houses and stones situation when it comes to word choices.
As the owner, it's in your interest for the structure to be challenged (sort of simulated annealing optimization), so you better create a way to question the very rules through these naturally stubborn goal-oriented managers. Probably by getting informally acquainted with developers.
I handed in my notice recently. My situation was somewhat similar to the one of the poster: project really not that interesting, unglamorous company, so-so salary, but casual atmosphere and not much to do, and I got to keep a lot of energy available to study and pursue my own coding projects. Then there was a change in management and pressure went up tenfolds, so I resigned.
First, I recognise now that it's potentially a bad idea to keep a job just because it does allow you to coast. There's a depressing quality in such choice; work representing the most part of our day, underperforming by choice, by remaining in an undemanding job, can even lower our self-esteem. I didn't do me much good, in any case.
Secondly, I am leaving because the market allows me to do it, because I know I am likely to find something better in a reasonable time. I could have handled the pressure, I could have remained and try to make that place a better place, but it's simply not in my best interest and it did more sense to just quit.
The position of the poster baffles me a bit: he recognises that conditions have changed and instead of adapting or refusing the new state of things, he dumps his responsibility to his own happiness to someone else: his manager. Indeed having good developers, in the current state of the market, is a privilege. In five years or ten years it might not be the case. Why making a case of us vs them? Isn't simpler to just take advantage of the bull dev market and leave?
It's naive, but widespread, from the part of managers to believe that by increasing the pressure they will get more bang for their buck. Let's them learn the hard way, until we can afford it. To moan and not budge is almost suspicious - maybe the poster is not so sure of himself after all? - and counterproductive for every party involved.
If where I was working began to micro-manage me then I'd leave. I left my last job because of this. It was so bad that they said I could only take breaks every 2 hours and had to wear a tie. I left for a company that matched my values and gladly took a pay cut doing so. Freedom is worth more than money. Kindly and professionally let them know why you left in your exit interview.
You can increase freedom/satisfaction by decreasing the things that you feel threaten it.
This is especially true in relationships, sometimes expressed as "don't sweat the small stuff—and it's all small stuff."
In evaluating a job or relationship, one technique is to make a pros and cons list, and put things that are easiest to adjust your attitudes on (like wearing a tie) in a third list to try to see the true value proposition.
Otherwise one risk is that you'll assume minor things may represent a "cultural/attitude problem" that doesn't really exist beyond a few easy-to-accept things, such as wearing a tie, taking out the garbage on a schedule, etc.
Of course, if the value proposition doesn't satisfy you, then you're in the wrong place. But if it does, keep your attention on the good things about the relationship as you practice "not sweating the small stuff."
Perhaps this is slightly off topic, but it seems to me that the 45 hour week is what employers really mean by a 40 hour week. For example, a very recent advertisement for a position at Gold Mansacks stated the job was full time, 40 hours per week,
from 9AM to 6PM. One can argue about lunch time, and whether the 40 hours are to occur somewhere within the hours of 9AM to 6PM. (Something tells me that 10AM to 6PM won't cut it.) In my experience, the mandatory lunch isn't mandatory, and the employer is getting closer to 45 hours than 40. At least to me, there is a significant difference between working 35 hours/week and 40 hours/week,especially if those 40 hours involve another 5 hours for "lunch."
Many years ago, an acquaintance of mine told me how incompetent I was running my business and managing people. She really let me have it, how could I be so stupid, anybody could do it better than me, etc.
A few years later, she started her own business, and lost everything, whereas I made money. (Note I'm not saying I was/am a great manager, I'm not.)
Anyhow, it's easy to dismiss your manager as being an incompetent fool. Until you try being one yourself.
I think the simple way would be to just ask for a raise to market levels or in lieu of more pay you would take additional privileges such as being able to set your own hours.
Or it could be rephrased - effectively he is only working a four day week spread over five days. If he is to work a full five day week he will 'need' 25% in more pay.
The chances are that if he does move to somewhere else he will have to do the full 8 hours a day but his pay will be commensurate with that. Again, this could be explained like that rather than 'you pay badly'.
So it may work if the manager 'sees' him as only hired for a four day week. He can then make the case for paying him for five days a week in order to achieve certain objectives, e.g. meet deadlines.
The developers there essentially take 30-40% pay cut in order to work 25% less hours?
I would find to cleaner to sign contract for 6 hours a day instead of 8 hours a day one and then slack away the difference. Is it possible that manager there is trying to change local culture?
Second thing that bothers me is the "any expectations of us, beyond that we produce quality software according to schedule" part. So, he works in a company that makes over-estimates work. That is unusual and something to be thankful for, but I do not find it "fair" to abuse the situation.
If we buy that argument, then manager is in perfect position to pack schedule much more in order to keep them there as long as he wants. My opinion is that management that leaves some room for unexpected problems in schedule someone to be treasured and not taken advantage of.
That manager is bad at their job, or has a different set of values than the developer who's asking the question. In either case, this is a recipe for a bad relationship.
As a manager, I consider my biggest responsibility to be creating and maintain an environment and structure where the developers that work in it (and report to me) are happy, productive, trusting, and engaged. Anything else I'm responsible for doing - like, say, delivering software - can't happen in a sustainable and predictable way without my being good at that first thing. Being a good software manager - or any manager really, but I've got less experience outside of of the software realm - is about people first and whatever-you-do second, and it sounds like this manager has forgotten and/or missed that.
What do you do in this situation? Make preparations to quit (which is distinct from actually quitting, but it can lead to that). If you have a decent network - and if you're good enough to get a 40% raise on moving jobs, you should - go talk to a few people at other companies you admire. If you've know any recruiters you trust, talk to them. Get a feeling for what the market will actually pay for your skills. Spend some time working though a good answer to "why do you want to leave your current job and come here," which force you to clearly work out what it is that you don't like in your current job (and if moving jobs will fix that).
Once you've done all that and still want to leave, go to your old manager (and their manager) with a job offer in hand, and tell them you want a 20% raise and the following four things to change in this specific way, pulling no punches. If they hesitate, put in your notice there and there. If they accept immediately, book another meeting for a month hence with both of them to re-evaluate how fixing those issues are going, and go back to your job.
If you're in this position, like Toronto, and can give a brief discourse off the top of your head about when it is and isn't appropriate to use a metaclass in Python, respond to this and let's talk.
I would be wary about being completely open and honest about such things at exit interviews. There is nothing to gain for the ex-employee personally at that point in time, and everything to lose by 'burning bridges'. You never know when a few criticisms (even if they are accurate and correct) will come back to haunt you.
At the exit interview, the main thing is to do what is best for yourself. If you really want to change how the company operates, stay on and apply gentle pressure or guidance. Criticism presented at an exit interview will 99% of the time come off sounding like sour grapes (unfortunately).
This is totally right, you absolutely want to sugar coat it. Don't say "I'm leaving because I hate bill". But for everyone else's benefit you can drop in that this new place you're working for gives you the flexible hours you require and is paying you more money.
The point was more, "if you're unhappy, find something new." You don't owe anyone anything, and if they can't figure out how to incentivize you into staying, you shouldn't. It sounds like old manager had a good grip on it and new manager does not, in this particular case.
Yup, important communication is often best when informal. For forms, official interviews and the like, carefully protect your goals. But be creative in considering how you can educate the other party.
Go over the manager's head. If that company is having trouble keeping senior staff, there are reasons for it and those reasons are probably not secret. I've done this, with mixed success, but have never had a problem with retaliation. You might be surprised how welcome your skip-level feedback is.
Oh, and if your skip-level manager doesn't know who you are (and ideally, his manager), then you either need to work on visibility, or you're not as senior or as pivotal as you might think.
Be polite. Tell them that you thought flexible hours were part of the deal.
And then walk. Moving to a new team in the same company is probably just as good, if you can swing it.
Beyond the straightforward good sense of this, it's a negotiation, and you should "talk to all the players on the opposing party's team" as you gather information.
A manager that does not understand the value of his or her employees, is a shity manager.
Basically you tell the manager straight up. But as we are talking about a shity manager. They would most likely become offended and hate you or fire you.
I find this situation to be less about good vs bad management or good vs bad developer.
This situation is simply about a mismatch in culture, expectation and personal value.
The company would be better off finding developers who are excited to be a hacker at the company and wants to contribute as much as they can.
The developer would be better off finding a job that allows the freedom he wants. It's clear to me the developer values freedom over pay and he should find a company with the same value.
Trying to get the developer and management to meet in the middle will simply prolong the agony.
I don't know about other devs but I sometimes worry about bad karma, which is why I try not to be an arrogant dickhead, even though I know I am important to the company. Just the pungent stink of both arrogance and professional ignorance coming from the OP kinda makes me embarrassed.
That being said, I don't consider it bad to speak up for yourself and it helps if you feel secure in your job. New management is changing things around. Instead of "dropping some knowledge" on this new manager about how developers must be given special treatment over other employees - maybe just explain that flex time is a major perk which you, personally, consider to be very important. If they insist you can't have it anymore then you can choose to adapt or find a new gig. You don't have to be the spokesperson for the entire industry.
Even in this market it's not impossible to find quality devs with a good attitude. I just find it better to conduct yourself professionally and not feel like you are better than everybody else. Conduct your business with integrity. Also keep in mind there's a 49% chance that you are a below-average developer.
IMHO a manager is to a good engineer what a tennis coach is to a tennis player.
The coach cannot play tennis any better than the player, but he can help him, keep him practicing, have him not miss any tournaments, manage his time, etc.
The coach trusts the player that he knows how to play tennis and player trusts his coach that he keep his back free of distractions.
I think the main task of a manager is to enable the engineer to do his/her work. Presence-obsession seems counter productive and this manager does not seems to understand how to manage smart people.
Lastly it has been shown, that the human brain can concentrate for about 6h on every sleep-wake cycle, everything else is subconscious drifting and distracting.
A 40h or more mandate is counter productive.
So a candid discussion with the manager making these points and explaining the mutual benefit would be in order.
If that does not work one has three choices: (1) accept it (2) escalate up (3) leave. Which of these is appropriate depends on the specific circumstances.
How can you make it a conversation about company objectives? Make it about the company, not the developers. There are probably companies that don't need the best developers. Others do. Talk about cost of bugs due to less experienced devs, lost productivity time if new hires are needed, etc.
The original asker of the question wrote exactly what he should say to the manager, right into his SO question. It's this bit:
> The reality is that any of our senior developers can walk out the door and have a new job with as much as 30-40% higher pay within a week. Most of us are only staying here for the casual environment, and being able to mix personal time into our work days.
He should just say that. If it's really true, then he should feel comfortable leveling with his boss like this.
Went to stackexchange, wanted to make comment, "must have 50 reputation points to comment", remembered why I don't use sites like stackexchange.com.
I'm a big fan of Dale Carnegie's book, and like many famous books, you can support many arguments using it. Also, it's strange that the top voted posts pulls several quotes for changing someone's opinion/winning an argument and uses that to support an argument of: "Respect his authority", which is nowhere in the Carnegie book.
I think of the story Dale Carnegie relates when a hotel he had long worked with decided to massively increase the rates for renting out that venue after the engagement had already been booked. (Analogous to changing workplace rules after you've already decided to work their in return for certain forms of monetary and non-monetary compensation).
The hotel certainly had every right to change their rental prices, it is, after all, their property. Dale had every right to either accept the new prices, complain about the new prices or leave. (I hope I don't have to spell out the analogies anymore).
So what did Dale do? He called up the hotel, not in an angry way, and laid out a list of pros and cons to the hotel changing their prices for speaking engagements.
Under pros, they would have an open schedule during a busy time of the year, and could book other engagements. Under cons, instead of getting value from Dale Carnegie, they would get none. The other Con was that having Dale Carnegie speak at the venue gave them tons of exposure to their target demographic.
The employee/employer relationship, especially for developers, isn't too dissimilar, and I think the SO OP gets that. While it's certainly the companies decision about whether or not they want to change workplace policies (including non-monetary forms of compensation like flexible hours), employees are under zero obligation to continue providing their services under the new plan.
However, A nice employee who has been treated respectfully may decide to warn the company, out of the good of his or her heart, that their new "compensation" program will cause them to lose one or more employees, which will result in a decrease in morale, productivity, the manager in question might end up being punished for his or her poor retention performance, and they will have become less competitive in the insanely competitive market for development talent.
You can call them ultimatums if you want, but at the end of the day employees agree to a compensation package in return for their services. Both sides can terminate that agreement at any time, and changes to either the service the employee provides or the compensation the employer provides are valid reasons to do so.
The word "authority" doesn't come into play.
In the software development industry, it's not like working for the town plant. It's extremely progressive, has great compensation benefits and flexibility. If a company isn't keeping up with the standard compensation package, you're doing them a service (though they may not realize it) by letting them know and possibly quitting. I've always understood 6-7 hours in the office to be quid pro quo for things like crunch time, servers going down in the middle of the night, etc.
Nothing's stopping the company from posting a job that pays 40k and requires 80 hours a week of in-office time, and nothing will force a competent developer to apply for that job.
How do you tell good developers that they are good hackers but bad developers?
How do you tell good developers that they will always have a manager whether it be a "manager" or a "client" or the demands of the problem they are trying to solve?
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.
If demands by an employer change or are no longer acceptable, find a new job and move on. If you are confident in your marketability, outright state your demands about flexible work et al, knowing that this may cause conflict and a departure may be expedited. None of us are fixed in our jobs.
One thing worth mentioning is that developers, as in other high variance skill pursuits (such as sports), have individual allowances and leeways. There is nothing "unfair" about a star performer essentially writing their own rules, and it is one of the great sadnesses of this profession that there are so many lobsters desperately trying to claw their peers down to the bottom of the pot.
So you're ignoring your managers, laughing at them, and deriding their actual time investment in the work output? Yeah, they sound just terrible. If you're not an engineer then you're not a contributor, right?
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.