3 ms·
> As an engineer (and manager) who owns infrastructure components, these “little” requests are death by a thousand cuts. They typically aren’t actually little,
by piva00 5y ago
> As an engineer (and manager) who owns infrastructure components, these “little” requests are death by a thousand cuts. They typically aren’t actually little, but even when they are, they forever add additional maintenance cost and complexity.
As a former SRE and tech lead for some OPS teams, I agree.
Sometimes they are actually little but will create divergent states for your code/infrastructure, increasing complexity and cognitive load on the team maintaining infra, slowly but surely.
In my experience with infrastructure on larger organisations it will require, at some point, to standardise practices and processes, and it will be painful for teams that don't fit squarely with the standard. You always aim to embrace 80-90% of the components in the organisation (or at least 80-90% of the most profitable/important ones) and take the hit that 20% will require modifications, as extensive and costly as they might be.
It's always a juggling act, engineers with the mindset of building whatever/however they want will feel less empowered when their favourite set of tools, tools that they might be using for a while, isn't supported by the standard. Some teams will take a lot of the load to adapt to whatever was agreed as a standard, churn will inevitably happen in those teams so it requires a long time deliberating what is acceptable or not. The job is always to strive making everyone as equally unhappy as possible because it's impossible to please everyone.
Those little requests might also have impacts and implications much larger than what the requester thinks about, when your infrastructure system is supporting 200+ teams any change is bound to cause ripple effects so you have to be deliberate.