Hacker News Reader

Comment by codingdave | Hacker News Reader

For those younger folk who ask why older management feels that the younger generation is full of entitlement - this scenario is exactly why.

The young engineer feels that they are a gift to their employer, and should have the freedom to work as they want.

The older manager feels that the work environment has a structure inherent within it, to which people are expected to comply.

As the engineer, it is your right to quit if you don't want to play by the rules.

As the manager, it is your right to fire people who won't work within your guidelines.

Either way, it is not a privilege on either side, nor a punishment if one side or the other decides to end the relationship.

It is simply two incompatible perspectives. If neither side will change, best to move on.

View on HN

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

> As the engineer, it is your right to quit if you don't want to play by the rules.

I think you mean that it is okay to quit if the rules change by someone else's accord...

Reply on news.ycombinator.com