[rollcat]

> Has anyone found effective tools for maintaining this synchronization between documented architecture and implemented code?

Yes, it's called structure, discipline, and iterative improvement.

Keep the documentation alongside the code. Think in BSD terms: the OS is delivered as a whole; if I modify /bin/ls to support a new flag, then I update the ls.1 man page accordingly, preferably in the same commit/PR.

The man pages are a good reference if you already have familiarity with the employed concepts, so it's good to have an intro/overview document that walks you through those basics. This core design rarely sees radical changes, it tends to evolve - so adapt the overview as you make strategic decisions. The best benchmark is always a new hire. Find out what is it that they didn't understand, and task them with improving the document.

[worik]

> Has anyone found effective tools for...

Managing management?

Code comments and documentation make no money, only features make money.

Bitter experience...

[rollcat]

Try working as a manager.

Software development is just one piece of the bigger picture that your manager is concerned with, same way as adding features is just one among your many responsibilities.

Managers understand risk. Communicate the risk of disregarding bugfixes, documentation, technical debt, even if it takes a lot of handholding. Expect no less from your manger: if they can communicate client expectations, budget constraints, and most importantly: long-term strategy, together you may be able to devise a better plan to address your own concerns.

In other words, empathy can go both ways.

And yeah, there are bad managers, just like there are bad coders. Sometimes it's an interpersonal problem. It's called life.