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”.
The word impact has become a trigger to me. It is both sufficiently abstract and seemingly concrete, and allows managers to do pretty much what they want from it.
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.
I have previously worked at a place where some of the engineering teams would build incredibly poor products and features, which would be on fire all the time (because it would fall over if you looked at it wrong), and they got constant praise from management because they “put in the extra mile to fix an issue in prod”.
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.
A good counter to this is having a strong technical IC leadership roles(I.E. Staff IC or similar) that leadership regularly gets input on in terms what is impactful in areas like this. The key piece is the work is low-visibility when successful and high visibility when it goes all wrong. A strong technical organization will recognize that and leverage high-judgement individuals close to the technical work so that they it can be accounted for properly.
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.
It's often important to help management define what impact is rather than to let them define it for you. If you want quality and stability to be included in impact, define a way to measure it and then get management to sign off on it being impact worthy. Our infra team has dash boards for keeping CI times low, false positive and false negative rates low, etc. Simply not regressing on those metrics is a daunting task and they have managed to convince management of that fact. As a result, their impact is measured by those dashboards which they defined. You can do this on any team by defining quality KPI such as the rate of customer reported bugs, customer sentiment, number and length of outages over some time period, etc.
All those metrics can be gamed to death and none of them sound impressive to the C-suite. Even if they accept that those are your KPIs, they will not think of you as an "A" player if all you want to do is maintain a number.
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.