How can I help junior colleagues understand the why of tasks our team does

Question

I work in IT Security as the team lead of the team. I really enjoy mentoring younger, more junior colleagues of team and in the past, my manager has complimented me on how teaching and leadership are strengths of mine.

The quality of the team's work is superb and I get along very well with them. We communicate well and they are satisfied with my leadership. However, there is one issue I noticed - helping junior team members see the WHY behind the tasks our team does / security control implemented. These members have about ~ 1.5 - 2 years of work experience and come from a mix of technical and non technical backgrounds such as EE, CS, accountancy / audit and law.

For example, this week I was signing off on some code security reviews / new security implementation plans, and asked my team members why they thought these tasks being done and how the new security controls will be beneficial to our mission of continuous security monitoring . The team members' response was compliance with company security policy requirements which is true and good. However, I was expecting a response more in line with security risk mitigation and active management, and because these controls are best practice and proactive / future looking. In other words, I am more interested in the underlying spirit of the law perspective rather than simply to check off the boxes merely for compliance purposes.

How can mentor the team to move away from a compliance - focused perspective, and understand the deeper reason for our work?

Is my expectation reasonable or unrealistic, given these are junior team members although they come from somewhat technical backgrounds

Answer 1

Give them goals, not tasks

In (good) product organizations, engineers are given requirements in the form of user stories and/or goals. Instead of “Add an integer text box on screen 4 that’s saved in the database as resellerPerks,” these are worded as “Allow a salesperson to declare what percentage of the sale is due the reseller, to allow incentivization of exceptional efforts from that reseller.”

Do this yourself. Instead of saying “run project X’s code through the static analyzer,” say “Help developers identify security flaws in their code.” Specific things you regularly do, or that are required by compliance regimes, can be mentioned in the “How”, but by presenting the work as a goal in the first place, you avoid the need to “show people the goal under the task.” Instead you show the goals, and have some runbooks as to typical tasks that might help accomplish that goal. This allows people to use their minds and initiative to look for other/additional/better ways of achieving that goal.

This is how innovations like peer reviews in the development pipeline instead of Change Advisory Boards with people who have no context deliberating over the change, which still meet compliance requirements but suck a lot less, get made.

Answer 2

"What does the team need from you, today right now, in order to do their jobs better?"

Undoubtedly, there is a wealth of things that you could teach them. Yes, there are things that [you think ...] they really need to know. But – honestly – do they need to? (Yet?)

"In time," they might come to your level of understanding – just as you did – "because they need to." But, in the meantime, I suggest, "don't push it." If anyone comes to you on the side, expressing an elevated awareness and curiosity about such matters ... as you very likely did ... by all means enlighten them, as you were enlightened.