Unfortunately missing in the article is any plan for this to actually happen: for stability and quality to be valued by the CEMBI when their boss demands proof of “impact”.
I remember one telling me "I'm all about impact", and then praise people who built arguably impressive but totally useless and uncalled for shit, while others who sacrificed their souls preventing entire rotten stacks to fall got a "meh, they had a huge opportunity and didn't seize it".
An impact is what's happening when something hits something else. I prefer not to have impacts.
An issues they caused.
It’s not like they were operating at a velocity greater than other teams-they spent so much time and headcount putting out fires, that they instead spent 10 minutes thinking about how to build it better, they probably would have 1. Finished it sooner and 2. Ended up delivering more features and value as a result.
Mekka talks about this in terms of underrepresented groups[1] but the same principals apply as well to any low-vis when successful / high-vis when it goes wrong(I.E IT, Ops, etc) roles. It's really up to technical leadership in an organization to make sure that they're noting high-impact/low-viz work and surfacing that in a way that the "new shiny" doesn't drown it out. I've been in both domains(high-vis graphics/shiny!, low-vis tooling/devx that had huge impact) and you really do need to account for it properly otherwise you'll have exactly the situation described in the article. Your company/org will falter and stumble as those infrastructure pieces slow everything down if you don't retain/reward the people doing that work.
[1] https://mekka-tech.com/posts/2018-08-09-the-difficulty-ancho...