3 ms·

I suppose I should have phrased that slightly kinder, and that’s on me. What I mean is that you can’t take your average jogger and expect them to win the 100 me

I suppose I should have phrased that slightly kinder, and that’s on me. What I mean is that you can’t take your average jogger and expect them to win the 100 meter dash at the Olympics, no matter how much training and resources you provide them. Is that a real problem? No it certainly is not. Lots of people like rock climbing but you can’t expect an average climber to win a major competition or climb some of the toughest mountains. It doesn’t mean they shouldn’t enjoy climbing, but if they start training like they are about to free solo El Capitan they are very likely to get seriously hurt. Average developed, operators, sec. people can do plenty of good work. But put them in a position that will require them to be doing things way out of their area of expertise and no matter how you structure that role and what tools you give them you are setting them up for failure. Another thing I was thinking about was not individual people being average but rather organizations: an average mediocre organization cannot reliable expect excellence even out of its excellent employees. The environment just isn’t set up for success. I am sure most people here are familiar with having talented people working in an organization that decided to poorly adopt Agile because it’s the thing that will fix everything.

tway_GdBRwW 2y ago
The team and/or org may have more impact than you think. I've seen people who were stars in one company totally bomb in another.
1dom 2y ago
All fair points. (Although I'm not a fan of the climbing analogy, the joy of programming is that you can practice anything you want without risk of real harm, and I think that's what makes unicorn-like programmers: they've repeatedly done the equivalent of free solo El Capitan practice in their spare time and lived to to tell the tail.) I think it's help to consider excellence in the context of principals and practice. Everyone should be aiming for excellent principals for their domain and environment. But the practice that implements the principals needs to be specific to the capabilities. E.g. I think in principal, any company with any tech should have backups, and ideally the ability to rebuild after a disaster. If you have a team of unicorn engineers ("company A"), the principals might be put into practice by meticulously tight and efficient SDLC and accompanying pipelines, tooling and other scripts and automations. If you have only one very competent engineer ("company B"), but a huge bunch of traditional ops people, that principal might have to be put into practice with a more manual, basic process (Bob from accounting once a week makes a copy of the important spreadsheets on a CD and stores it in a fireproof safe at home.) Both businesses can deliver excellent and reliable service for their customers because they implement excellent principals in a way that their employees can deal with. Swap company A and company B's practice, and even though it's for the same excellent principal, everything falls apart. I think we're in agreement here. It's an uncomfortable truth that - on average - 50% of environments are company B. There's a problem that 90% of companies want their practices to look like company A. Nobody wants to feel mediocre.

tway_GdBRwW 2y ago

The team and/or org may have more impact than you think. I've seen people who were stars in one company totally bomb in another.

1dom 2y ago

All fair points. (Although I'm not a fan of the climbing analogy, the joy of programming is that you can practice anything you want without risk of real harm, and I think that's what makes unicorn-like programmers: they've repeatedly done the equivalent of free solo El Capitan practice in their spare time and lived to to tell the tail.) I think it's help to consider excellence in the context of principals and practice. Everyone should be aiming for excellent principals for their domain and environment. But the practice that implements the principals needs to be specific to the capabilities. E.g. I think in principal, any company with any tech should have backups, and ideally the ability to rebuild after a disaster. If you have a team of unicorn engineers ("company A"), the principals might be put into practice by meticulously tight and efficient SDLC and accompanying pipelines, tooling and other scripts and automations. If you have only one very competent engineer ("company B"), but a huge bunch of traditional ops people, that principal might have to be put into practice with a more manual, basic process (Bob from accounting once a week makes a copy of the important spreadsheets on a CD and stores it in a fireproof safe at home.) Both businesses can deliver excellent and reliable service for their customers because they implement excellent principals in a way that their employees can deal with. Swap company A and company B's practice, and even though it's for the same excellent principal, everything falls apart. I think we're in agreement here. It's an uncomfortable truth that - on average - 50% of environments are company B. There's a problem that 90% of companies want their practices to look like company A. Nobody wants to feel mediocre.