| ▲ | OhMeadhbh 10 hours ago | |
in the military we had a saying "you don't go to war with the army you want, but with the army you have." consequently, there was a lot of effort given to training and planning. the nature of most combat arms roles is such that you need most of the team operating at a decent level. i think the idea behind so much training is that if you can raise the performance of the worst performers, you might be able to improve the overall unit performance dramatically. to put it in marketing manager speak, for many tasks in a combat arms unit, individual performance is a satisfier, not a a delighter. if one person in the unit does a bad job, the unit will fail. if everyone in a unit does an "okay" job, the unit will not fail. the outcome between the two cases is dramatic. but if you have a unit where everyone is "okay" and then expend effort to make everyone in the unit exceptional, you will not notice a concomitant increase in performance. flipping this over to software development... you have a lot more control over whom you hire to be in your unit. but everyone has a bad week or a skills gap, so training (which could be as simple as giving people time to read up on a subject or write a few test programs) will eventually be important. like line military units, everyone needs to be hitting on all cylinders for the dev team to work in accordance with plan. investing in upskilling existing developers who are competent but underperforming may be a better strategy than uber-skilling your best developers or firing them and hoping you can replace them with someone with better ability to figure out how to be productive on the team. as a humourous aside... at amazon my manager discovered i was prior-service, saying "Oh! You were a MARINE!? I want to manage my team like a military outfit." unfortunately, my response was "WHAT!? You want to spend 80% of your budget on training and logistics!?" that was probably not the best thing to say in that situation. also... if we're talking about applying military metaphors to product development, it's worth it to look up the various OODA talks by John Boyd. i don't know if i agree with all of it, and it's not directly applicable. but there's enough there to justify at least reading about it. Boyd was a friend of my dad's, so i remember thinking he was crazy when i met him as a child, but again, he may have been crazy, but he was definitely an intellectual outsider who hit more than he missed. | ||