I've spent a good amount of time studying software architecture as well as implementing things in practice. I know how to work with things like microservices, event-driven architecture, event sourcing, DDD and so on. I also know how to structure a codebase with nice abstractions such as using the hexagonal architecture. Nice skills to have for building complex systems!
People always remember to point out on how you should avoid complexity and strive for simple solutions. I definitely agree with this. But what if a more complex architecture would actually be technically justified? When people usually talk about those sorts of systems and architectures they mean "complex" as exactly that - complex. This assumes that things are more difficult to work with but not something that would be impossible to work with. But I feel like a hidden danger can also exist:
Engineers don't actually see or understand the mistakes they are making
This could mean a lot of things, such as relying on network calls to always work, assuming consistent and fresh data when doing updates and so on. Nowadays things are even more wild with AI assisted coding and having your agent hit you with tons of code that you don't understand. But that's a topic for another day.
I'm not saying that everyone in the team should be proficient from day one when starting to build more complex systems. What I do think though is that people should get to that point eventually. If engineers aren't invested on this, bad results can occur.
So really my point is this: even though a more sophisticated architecture would technically be justified, a sure way to ruin it is to approach it without clear goals and commitments from everyone involved. If those are lacking, it's better to suffer with your existing issues until these fundamentals are worked out.