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

  • 3
    What have you tried so far? Have you explained the "why" as you see it to them?
    – Seth R
    Commented May 6, 2020 at 17:36
  • Whenever I start a new job, I like focusing on learning the "why's" behind the tasks we perform/ products we have / processes in place. Not every manager is able to realize some people (like myself) wants to find out the meaning so they can relate to the company's objectives, thus contributing to their accomplishment. I find your efforts commendable and can't congratulate you enough on that.
    – Arriel
    Commented May 6, 2020 at 17:40
  • what is the relationship between text in bold and the title? Answer to the title will not be the answer to bolded questions at the end Commented May 6, 2020 at 17:42
  • 4
    Have you started by just asking them "But why do we have these policies in place?" to probe beyond the obvious answers?
    – Erik
    Commented May 6, 2020 at 17:49
  • Make them watch a few of the Decfon talks on youtube. You could probably find a few which discuss the work you folks do. Listening to someone talk from the perspective of a "black hatter" might give them a greater appreciation for the importance of the work they do.
    – sam
    Commented May 6, 2020 at 18:25

2 Answers 2


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.


"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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .