Over the past year, we've focused on developing our product quickly, which has led to a significant amount of technical debt in our codebase. As a result, we've shipped applications without proper architecture and planning. However, when I suggest refactoring or re-architecting to my team, many of the senior developers and the engineering manager are skeptical. In my opinion, I am not just offering refactoring for just sake of refactoring; it's necessary because our current code base lacks abstraction and separation of concerns and has slow development times.
In those examples, how can I reduce skepticism in my team and bring more productivity, and more good code quality, and best practices to my team?
Do you need permission to get started with your ideas? e.g. could you run the integration tests as non-blocking on every build? So it doesn't slow anyone down.
Here's a good Q&A from a while ago about this: https://www.jointaro.com/question/wWlLItsSq4zSb6Trztv6/how-to-build-culture-of-owning-technical-debt/