I don't work in IT, but it does sound like typical IT to me. The business people do not understand the time and effort necessary to keep IT running smoothly. The question is, what can an IT person do about it? It seems to me most IT jobs always become highly pressurised because the business teams become overly demanding without taking an interest in what is actually involved. I am not sure how to address this, but there must be a way.
It's certainly not uncommon.
What I see happening is over time people pick up 'baggage', they build more and more tacit knowledge and become more and more 'go-to' people for particular subjects (bit of a tangent, but it's one reason why I think traditional salary models are a bit broken, because I think a lot of IT workers are overpaid when they first join a company but never get properly rewarded for their increasing effectiveness / responsibilities over time and end up being underpaid... i.e. the salary curve is way too flat. After 2 years in a role people might earn say 10% more than when they started, but really they should earn 50% more starting from a lower base). This is particuarly a problem if there is also growth in demand / scale, the cognitive load ramps up and organisations are too slow to react in adding more bodies to effectively manage the workload (adding the wrong people at the wrong time can in some cases just make things worse). The only time I've ever quit a job without another one lined up yet was a situation like this where I was basically doing the jobs of at least 2 and arguably 6 people. My team size underneath me more than doubled but that still wasn't enough plus for me as the head of that team, it just meant more overheads, more meetings to attend etc.
In terms of addressing the business engagement, if I reflect on what I think has worked [relatively] well in the past, it has been where you get a business person that has some level of tech knowledge/interest moving into a dedicated (not side of desk) product owner role and commits to working daily with the technical teams where necessary. Effectively they bridge the 'us and them' gap - they see first hand why things take so long to deliver technically, but also they have their finger on the pulse of what the business needs, they have very good domain knowledge and stakeholder relationships (compared to say hiring in some random external 'career product owner'). So it becomes a much more fluid and less transactional relationship across business and IT. Probably wouldn't fit every scenario though.
At least you have proper steerco.
My steerco is of an update, than an actual steering committee!
Steercos seem to differ wildly between orgs (heck, even between programmes at the same org). I once worked on a very tightly run programme where steercos were highly structured, explicit structures to the decks, strong direction from the senior people. It still wasn't perfect however, the approach to risk management was effectively holding up a mirror (if a workstream lead/PM raised a risk, it would just be reflected back at them as an action to come up with a plan to mitigate it.... the whole point of people raising risks at a steerco is because it is something they need help with, if it was something they could easily mitigate, it wouldn't make the cut for top X risks as they'd already have a plan in place). And then of course I've seen some other steercos where there was barely a ToR, no concept of quorum, sporadic attendance, lack of structure, just used for information sharing etc
