Top 10 most important powers of your SharePoint team sites in Office 365

Ian Cunningham  The solution depends on what the information is and how you're using it.

If you have a list of values, you may want to look into using a managed metadata column. I do this frequently. The values are stored in the central Term store. You'll need to make sure that you are named as in individual as a site collection admin to create an entry in the term store. But theoretically, your site owners should be able to access the term store to pull in a column without being a named SCA. Whenever the central list is updated, all the instances of that list of values are also updated.

The tricky part to this is training. Making sure that your site owners KNOW they are supposed to pull in this column of information from the central term store rather than recreating their own columns in their own sites.

If this is a list with multiple columns of data about each office, another option to look at is using the highlighted content webpart to publish across site collections. You can post a page with offices and addresses on your top level site and have a link to that page appear on your team sites in a web part.

But if the 100% requirement - and no other options are acceptable - is to have a list on each team site so that a lookup column in one list can bring in multiple fields of data about each office, then you may need to post that table on each site. 

The modern sites have come a long way. I think there are a lot of use cases where they make a great deal of sense. But I also think there are other use cases where having subsites is acceptable as long as you understand all the best practices and repercussions of using subsites, like no nested subsites. Only have them in a single layer under the parent site. Only create subsites based on security needs. Just because it's a new project, doesn't mean it needs a separate site if the people are the same. Stuff like that.