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.