The startup I work for is pretty flat. There's the chief product officer who is actually pretty technical, the chief technical officer, and engineers basically.
We use UMLs and flow charts in miro to diagram things from both a high level (for product to understand) to intricate details.
(but seriously, I'm interested it's just everything I've seen before had the strong scent of "we're doing this nonsense because we believe we're supposed to but don't understand why")
It's useful to have a common language for diagrams (actors, storage, etc)
It's not useful for more than very abstract concepts though. If you're UMLing your entire Java app before you add another class/method/function, you're doing it wrong.
Yeah we don't go that overkill, we really just diagram surface area (how does the backend communicate with the frontend and through which apis and when, and when should the front end expect a socket message, etc)
As a method of communication between projects, it works wonderfully
Fortunately I've never worked for an org that did "stuff" for the sake of doing stuff, or at least I never lasted long with those orgs. In order to be lean and efficient we need to cut out all the stuff that doesn't serve the purpose of building product.
We use UMLs and flow charts in miro to diagram things from both a high level (for product to understand) to intricate details.
It works great!