You may think that a software developer knows only to zoom in and that big picture is only for the architect, boss or customer.
The truth is that developers must constently Zoom in (focus), and Zoom out (see the big picture).
This take place first at the technical level : You know how to use high level package and framework to do your work, but at the same time you need to zoom in the details of the underlying protocol, and sometimes zoom in every bit sent on the network... Without loosing the big picture.
It takes also place at the business level : The responsibility of the developer is also to advice the customer about his decisions. Too often, not important features take most of the development time. It is his job to make development effort proportional to the importance of features.
It is also his job to advice on the prioritization of features : What can make money now and is fast to market ? What can be done later because technically challenging for now ?
For this, the developer needs to know the purpose of the product (big picture) as well as the economic impacts of decisions (focus). For example he needs to be aware of products licence, maintainability impact, ease to find human resources.
I think the best way to teach something is to train the audience to switch back and forth from details to big picture.
Without big picture : you loose sense of purpose, the audience will feel that the course is useless.
Without details : you loose sense of practicality, the audience will feel that in theory there is no difference between theory and practice, but in practice there is. And it will be suspicious.