|
|
|
|
|
by nthj
1350 days ago
|
|
There's an episode near the end of The West Wing where it's C. J. Cregg's first day as Chief of Staff. Of course, this same day, a national security emergency has arisen involving weapons-grade plutonium. The whole day goes by, with C. J. increasingly frustrated as the Secretaries of Defense, State, and Energy all pass the buck on the crisis. The President is able to nudge C. J. to put together a tiger team. With a few words, he has resolved the crisis. Until I saw this, I never understood corporate structures. Why are reporting lines structured so customers can languish until the CEO barks an order to address? But during a normal day-to-day, the top executive needs stability. Anyone incentivized and empowered to single-handedly address problems is also-by definition-someone who wields immense political power. So departments are set up. The implicit standing order is "maintain stability." And whenever process actually needs to change, the top executive routes around the communication chains he has established. |
|
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.