| There are other reasons. For example, when I started my current job about 10 years ago, the company had around 115 employees, and me and my three colleagues were THE software development team at the company. You need some kind of automation? You went to us. Oh, and we also built the internal CMDB and all the tooling Now, there are 450+ employees, my team has ~8 developers, and there are more development teams, with different purposes and scopes. Colleagues still come to us when they have development needs, and quite often we have to tell them "that's out of scope of what we do these days" (and hopefully point them somewhere else who can help them). Not because we don't want to be helpful, but because we're already overrun with work that's very clearly in scope for us, and that our department lead prioritized for us. What does that have to do with support? It creates incentives to say "not our job". Back in the days, if a customer had a tricky problem, support might involve us in the solution. Now, we have to decline unless it's likely a problem with our corner of the software. Which means support staff has to chase for other responsible engineers / experts. So the small company from 10 years probably had much better support experience, at least in cases where support cases couldn't be resolved by first-level support. There are more reasons: our whole software landscape was much smaller, so an average support person could be familiar with a larger part of it. You don't need intentional design for stability to create a maze that support has to traverse. |