Because the software we are paid to write has an external purpose. As scale increases, supply chains lengthen, and roles specialize, inevitably more and more people are missing the forest for the trees—this isn't an indictment, it's an inevitable result of the pursuit of efficiency and scale at all costs. Many engineers would be happy to polish the thing that exists, perhaps adding complexity the form of scalability, modularity or reusability that isn't actually needed, and in fact may make it harder to adapt to broader changes in the ecosystem that the company operates in. "Impact" is just a suitably hand-wavy management buzzword to be used in lots of different situations where they deem ICs to not sufficiently taking the big picture into account.
> Many engineers would be happy to polish the thing that exists, perhaps adding complexity the form of scalability, modularity or reusability that isn't actually needed, and in fact may make it harder to adapt to broader changes in the ecosystem that the company operates in
When done correctly it absolutely adds business value and should not make it harder to adapt or change, that's the point of good engineering. The problem is that you need years, if not decades, of technical experience to see this, and it's also a hard sell when there is no immediate "impact". It's basically something that happens because consumers don't know any better, so then it becomes low priority for making profit... at least until a competitor shows up that has better software and then it has a competitive edge, but that's a different matter.
Sure. I'm just explaining why the term exists. Of course it is often applied by clueless managers, there's nothing you can do about that except go find a better manager. Just don't make the mistake of thinking its all bullshit because you've only dealt with muppets on the leadership side—I see this often with journeyman engineers who have never had the privilege of a good management team and it's very sad.
