3 ms·
Also adding in this response. > In this instance I don't want to hire an alphabet soup programmer who will move on to the next company as fast as the next resum
by JamesBarney 7y ago
Also adding in this response.
> In this instance I don't want to hire an alphabet soup programmer who will move on to the next company as fast as the next resume update allows. If it's a side effect of kicking ass on a variety of projects, broad experience is a nice-to-have, but I need someone who will hang around long enough to internalize and take responsibility for business goals.
I'll start with dev incentives and why it explains their behavior. Now one thing that is fairly common is internal raises are relatively much smaller when compared to market for jr. devs than sr. ones. This incentivizes most young/jr devs to switch jobs fairly often to get market pay raises(which are very substantial for young devs and usually much larger than internal raises, I quadrupled my salary in my first 3 years of working). To do this they need to build up technical expertise as quickly as possible because this is what the next job is looking for. And there really isn't any incentive to build up domain knowledge that will become useless the first time they switch jobs.
Senior/older devs for instance are usually on the opposite end where the pay raise for switching jobs is relative lower compared to internal raises. They are usually at a point where job security is more important because they fear being a hard to hire greybeard. They're already close to maxing out as a single contributor(and a lot of time if they wanted to move to management/tech leadership they would have already). And for them to pursue their goals of job security and maxing out pay by being valuable to one company as opposed to many companies they'll pursue and acquire lots of domain knowledge.
So I think you have two options. Hire an expensive older/sr. dev and convince them that the company would be a great place to spend the next 5-10 years. Or hire a younger dev and explain how it would be very beneficial for them to make a career there, talk about how much your company values domain knowledge and internalizing business goals. And then explain that you are willing to pay very handsomely for that and match what are the absolutely nuts pay bumps that go to jr. devs when they switch jobs.
*Note I'm generalizing like crazy and I don't think this is true in every case. I've met plenty of older devs who were fascinated by new tech and had little interest in domain knowledge and vice versa. But I think as a general rule it holds, and it holds for myself. When I first started I always got really excited about new tech and building out things the "right" way. Now 10 years in meeting business deadlines/goals and learning deep domain knowledge so the application really shines excites me more than learning Yet Another Framework.
- catherd 7y agoNot sure I agree with the hire a younger dev and start persuading option. In my managerial experience, it's almost impossible to change someone's core personality or their value system, either through words or through money. And even a temporary change takes monumental effort on my part. Better to find someone who's natural mode of operation fits this type of role. I feel like the personal value system and personality are what drive long term performance. You can explain and cajole all you want, but inevitably a few months later the core personality starts coming back through. Establishing a culture around certain things will go a long way toward making those behaviors expected, but finding a person who has the appropriate temperament and skill level for a the types of activity needed for a role is so incredibly easier than doing everything the hard way. Maybe I've been spoiled... I have a few engineers in other roles who do naturally get things done and don't need constant hand-holding to get through anything boring, but so far the programmers mostly just want to work on whatever they think is cool and turn into procrastination machines if I push too hard or give them an uncool task. I do have one older guy who I can leave to his own devices and the result will mostly make sense and happen without lots of my time pushing to finish. The other engineering roles with 'finishers' are mostly young guys, though, so I'm still hopeful any age could be this type.
- JamesBarney 7y agoI think you're right that changing a person is hard. But I disagree that changing a person's behavior by changing their incentives is nearly as difficult.