However, once inside I find that each product is kept together by a skeleton crew or sometimes by people who can only work on it part time since they're handling multiple projects.
It feels like the bus factor for most projects is one (or very close to one).
I don't know how I feel about the situation, and management response to my question/concerns "it is what it is".
Do you think this is a huge red flag?
Companies make all these technical blogs and conference talks about how to develop software in a sustainable and disciplined way, but it's all a bunch of lies to lure stupid devs to join in on their death march projects. And the scam is perfectly self-perpetuating, if all you're doing all day is fighting fires on these half baked systems you're not learning anything that's transferable to the next job.
If you want to effect change you will need to understand what the board consider “business value” - things like return for investors (roi to private equity, share holders, etc.), executive salaries, topline/bottomline ratios, etc. etc.. it’s unlikely to be customer satisfaction, especially if they’ve hit status quo/plateaued Once you understand management’s incentives you can work out how to motivate them to change, focused on those incentives, working backwards from them and pairing them up to your own goals.
‘The First 90 Days’ is a great book that provides tools on how to do the information gathering effectively.
The question you should ask is: Is this really that different from what I should expect if I went somewhere else?
This is common, adding people to a project typically makes things less efficient, which is counterintuitive. It's mainly due to communications overhead and developers, "stepping on each other's toes." It also requires exceptional project management of clearly defining tasks, timing of tasks, proper resource allocation, etc.
>It feels like the bus factor for most projects is one (or very close to one).
The bus factor always exists. If the most important person leaves and there are other redundant people on the project, they will still take time to get up to par, and there are a lot of factors, some that you can't mitigate (like raw ability), that go into full redundancy.
>I don't know how I feel about the situation, and management response to my question/concerns "it is what it is".
It's hard to tell from just a blurb. I would stick it out and see how it goes. It might be that they have a bunch of top notch people who can handle it and like their work. If the turnover is really low, this is a good sign. The best teams are always a small group of really quality people. If that is the case, you get to be a part of something pretty rare. It'll take time to figure that out though.
If not, then the evidence says that what they’re doing is working, and you should learn how it’s so efficient!
A sceleton crew might be good for mature projects that require very little support of any kind. If there aren't a lot (and that is subjective) of incidents and tickets from customers things might actually be good.
If you are not "top management" (executive, VP, C-level etc.) in that company there is very little you can do to change things.
What you can do is evaluate what you can expect as work and if you are going to find it rewarding.
Who cares, it's not your concern to worry about that.
I’m assuming you work at this company now?
What questions will you ask in your next set of job interviews that you didn’t ask this time? What questions did you ask during the interview this time where you felt like you got misleading answers?