I've already talked about the things in here that were directly contradictory with what I personally want in a job (not interesting, low pay, etc), so I'll ignore those. Here's a huge, huge problem with his mindset:
> Secondly, we're working more closely with folks to determine their strengths and desires and align them to the right systems. Third, as new developers come in, we are teaming them with a business partner to help them understand the impact of their system on the business. We're trying to get them more invested in the strategy. We're trying to engage them in where the company is going.
This sort of reality distortion -- changing the developer's frame of reference as to what is interesting or not -- is one of the absolute key problems this company will have with retention. First year developer: Great, I'm working on this app with does X for the business, which causes us to save $Y on Z; I'm psyched. Second year developer: Wait, I don't see X or Z, and whether or not we save $Y or $Y * W, it's all the same to me; why am I doing this again?
You have to adapt to the developer, not adapt the developer to the business. There are simply too many great opportunities for a developer to expect them to put up with this.
Edit with one more thing: One of the huge underlying things that I saw in just about every part of the article was that developers weren't to be agents of their own destiny. They were to be told what to do, how to do it, and when to do it. Unless you give people some degree of power over the things they do, then 1) they're not connected or invested, and 2) they feel like a rat in a maze. Now, it seems that he has recognized this as a problem -- e.g. "They've got to take something that exists, but they don't have to live with it the way it exists." -- but it seems like a proper solution is a bit away.
Comments
I've already talked about the things in here that were directly contradictory with what I personally want in a job (not interesting, low pay, etc), so I'll ignore those. Here's a huge, huge problem with his mindset:
> Secondly, we're working more closely with folks to determine their strengths and desires and align them to the right systems. Third, as new developers come in, we are teaming them with a business partner to help them understand the impact of their system on the business. We're trying to get them more invested in the strategy. We're trying to engage them in where the company is going.
This sort of reality distortion -- changing the developer's frame of reference as to what is interesting or not -- is one of the absolute key problems this company will have with retention. First year developer: Great, I'm working on this app with does X for the business, which causes us to save $Y on Z; I'm psyched. Second year developer: Wait, I don't see X or Z, and whether or not we save $Y or $Y * W, it's all the same to me; why am I doing this again?
You have to adapt to the developer, not adapt the developer to the business. There are simply too many great opportunities for a developer to expect them to put up with this.
Edit with one more thing: One of the huge underlying things that I saw in just about every part of the article was that developers weren't to be agents of their own destiny. They were to be told what to do, how to do it, and when to do it. Unless you give people some degree of power over the things they do, then 1) they're not connected or invested, and 2) they feel like a rat in a maze. Now, it seems that he has recognized this as a problem -- e.g. "They've got to take something that exists, but they don't have to live with it the way it exists." -- but it seems like a proper solution is a bit away.