Thursday, March 16, 2006
Outsourcing Legacy Skillsets
One trend in corporate America is outsourcing of legacy skillsets to other countries. One story I hear a lot is how employers overly value technical skills at the expense of very experienced people who bring other attributes (such as domain knowledge) to the table. Figured I would share my own thoughts in this regard...
What I have figured out is the main problem is that testing for domain knowledge is difficult. Of course, modern management thinking has trained many to think of folks as programmer-pluggable units where you are no longer an individual but an FTE. Ignoring this for a moment, I think there are three things to consider.
1. Stigma: Younger managers may be afraid of the dinosaurs who know more than they do. Folks who know their stuff may be way too networked and could without effort point out flaws in a project/approach. Hopefully, you will be lucky to find a manager that is more interested in climbing the ladder and moving on before showtime as they will have less fear of project failure.
2. Laziness: I can figure out how deep someone's knowledge is in Java in about 15 minutes yet it would take me a lot longer to figure out if they knew say commodities trading. Even if I figured out what their knowledge of commodities trading was, it would take even longer for me to place a value on it. For Java, this would be easy. Of course, if a person has both, a superior set of abstractions arising from better business knowledge may end up finishing work far quicker or even changing the nature of the project, but I can't simply put a score to this approach.
3. Companies while predictably wandering off the path of agility, still are attempting to figure out lighter weight ways of developing valuable working software. Maybe if the dinosaurs read the Agile Manifesto they may have learned that there are these folks in the enterprise better known as customers and that domain knowledge may not be as important as they believe. After all, if we are developing software couldn't we simply just ask them?
| | View blog reactionsWhat I have figured out is the main problem is that testing for domain knowledge is difficult. Of course, modern management thinking has trained many to think of folks as programmer-pluggable units where you are no longer an individual but an FTE. Ignoring this for a moment, I think there are three things to consider.
1. Stigma: Younger managers may be afraid of the dinosaurs who know more than they do. Folks who know their stuff may be way too networked and could without effort point out flaws in a project/approach. Hopefully, you will be lucky to find a manager that is more interested in climbing the ladder and moving on before showtime as they will have less fear of project failure.
2. Laziness: I can figure out how deep someone's knowledge is in Java in about 15 minutes yet it would take me a lot longer to figure out if they knew say commodities trading. Even if I figured out what their knowledge of commodities trading was, it would take even longer for me to place a value on it. For Java, this would be easy. Of course, if a person has both, a superior set of abstractions arising from better business knowledge may end up finishing work far quicker or even changing the nature of the project, but I can't simply put a score to this approach.
3. Companies while predictably wandering off the path of agility, still are attempting to figure out lighter weight ways of developing valuable working software. Maybe if the dinosaurs read the Agile Manifesto they may have learned that there are these folks in the enterprise better known as customers and that domain knowledge may not be as important as they believe. After all, if we are developing software couldn't we simply just ask them?
