You are already going about it the right way, by doing two things: 1. you are specific 2. you are investing time to offer a better way. A good way to communica

You are already going about it the right way, by doing two things: 1. you are specific 2. you are investing time to offer a better way. A good way to communicate is to keep it informal and provide direct feedback, w/o involving anyone else, so you avoid making the developer feel inferior or feel that there is a political element involved. Ideally, you would share screen and code the suggested improvements together, and it will not only help you accomplish what you set out to do, it can also build a bond/trust/respect between you and your new colleague. During the conversation, I would try to understand the following: Is there any legacy, currently working code, that has been implemented in this monolithic approach? Maybe the developer realized it was ok, for the initial iteration. Is the developer under a tight deadline? To meet the deadline she prefers solving problems in this way, for the initial iteration. In both situations above, the developer is aware of a better way, and your help to get it there in time will be appreciated. If not, some coaching is required (hopefully you have coding standards to refer to): Is she interested to learn a better way? What are her reservations and counter arguments? For smaller teams, daily team code reviews are very helpful. Have fun!