Number of logical reads in SQL server JOIN
There are cases where every single row from your larger table could be read, and cases where it is closer to the number from your smaller table.  SQL Server will pick the method it thinks is most efficient based upon the information it has.
For example, if you have an index on the larger table that includes the join column, there is likely going to be less reading, as it should be able to skip a bunch of records.  If you don't, then the only way it will know what rows to select is by reading each row.  Keep in mind that statistics will impact the choices made, and if they are out of date it could lead to a bad choice.
Note there are implications for adding indexes, and there are numerous cases where they hurt over all performance, versus increasing it, so don't go willy-nilly in creating them.  I'd say ask your DBA, but...
Personally, I would question if you want to retain your DBA.  An INNER JOIN (which is what you have, with the INNER omitted) is a filter and in many (but not all) cases you can move predicates between the WHERE clause and the ON clause with zero impact (SQL Server will optimize to the exact same query plan), so the &quot;because there is no WHERE clause&quot; is not only wrong, but in fundamentally misunderstand sort of way.
This is not to say your product team is correct. Looking at the screen shot, there are clearly more reads than 9K. If your products team is in Marketing, then I can understand their confusion (&lt;grin&gt;).
Lastly, the NOLOCK in there should be a big red flag.  There are cases where it won't cause a problem, but one should be able to clearly be able to articulate what the problems are, and why it won't be an issue before using it.