I am a manager in the cybersecurity division where I work. I have been a manager for the past five years and am well respected in the division.

Our team is responsible for security engineering and second-line security incident response. Typical tasks can include reviewing (and acting upon if needed) SIEM alerts, deploying security tools, IAM administration, etc. Many tasks can only be done via live interaction with internal customers (i.e., other employees).

Several junior engineers in my team demonstrate good initiative and passion for the work but who sometimes over estimates their own technical competency. As a result, when they are troubleshooting with other employees outside of our division, they are often not able to fully own the ticket from beginning to end, with the end result of the ticket passing through several senior peers' hands before resolution. This is problematic in several ways:

  • Each hand-off creates an opportunity for previous information to be distorted such that subsequent senior team members may be acting on incorrect information / technical state. (Think of telephone game.)

  • Increases distrust among our internal customers. Customers most often prefer one person to own their ticket rather than be passed off in a chain with no one person responsible for ticket resolution.

  • Increases customer service times. When a junior colleague gets stuck in a ticket when live with a customer, a senior peer may not be available then and there. As a result, lengthy waiting times can develop, degrading customer service. Cutting off a customer just seems bad practice and unfair to the customer.

  • As a result of lack of senior peer supervision, junior engineers may make a critical error that results in a companywide security impact for which I may not be fully able to recover from. All security engineering team members have elevated administrator rights to include domain administrator / AD forest administrator.

True, documentation of processes can help to a certain extent, but not fully as unexpected behavior and / or newly discovered vulnerabilities / errors can arise. Researching, triaging, and analyzing these is not something I expect junior engineers to be able to do independently.

I am thinking of creating a rule that tickets in which live customer interaction is necessary, should only be worked when the junior engineer feels he / she can own the ticket from beginning to end and during a time when senior help is available. However, I fear junior engineers may feel coddled and resentful as if I am distrustful of them being able to work independently.

As a manager, I can certainly take a very prescriptive approach by assigning tickets to individuals, but I prefer not to spoon-feed folks or manage with an iron fist. I want a certain degree of engineer autonomy without them feeling micromanaged.

How can I implement such a rule and minimize the demoralizing effect on junior team members?

  • 16
    Question: Is this a Workplace problem or is this a Workflow problem? Because looking at the question - my first reaction is that the problem here isn't about Workplace interactions - it's that you have a technical problem with your training and ticket allocation. Commented Nov 7, 2023 at 5:21
  • 54
    Why would you expect a junior employee to be able to own work in the first place?
    – Aida Paul
    Commented Nov 7, 2023 at 6:06
  • 49
    Why does this result in "the ticket passing through several senior peers' hands before resolution"? It sounds like those senior peers have the same problem if they also need to pass it to someone else. Why isn't it handed over once to a single senior peer (a.k.a. escalated to second line), why is it handed over multiple times? Commented Nov 7, 2023 at 15:36
  • 11
    @Sharpenologist True, but I raised the question because the OP considers it a problem that the juniors can't handle it, but identifies the problem as this resulting in multiple handovers between multiple seniors. This suggests that the problem is broader than only the juniors, and might be a general (distribution of) skills problem, and then the focus on juniors is a bit of a red herring, as I would expect those same multiple handovers to occur if one of those (initial) seniors had taken the call instead of a junior (it would just eliminate the handover from junior to senior). Commented Nov 7, 2023 at 16:02
  • 15
    Without sometimes taking tickets that are at the edge of their ability, how will your juniors learn and move into seniors? I think the issue might be more with the escalation process (or lack therof) than with the juniors, who also may not always be able to accurately identify if they can actually complete a ticket themselves.
    – Meg
    Commented Nov 7, 2023 at 16:31

4 Answers 4


You are conflating two different things: being accountable for the resolution of a ticket with being able to resolve a ticket by themselves. The very fact that you mention the word "handoff" feels like the process equivalent of a code smell: why are they handing off the ticket to someone else? Because they can't complete it by themselves? That doesn't really sound like a reason to do that.

There are always going to be tickets that can't be resolved by one person working more-or-less independently and this will become more true as cybersecurity as a field (and IT in general really) matures and fragments into fractally ever more sub-specialties.

The demand for people who can own a ticket start-to-finish with little-to-no outside help currently far exceeds the supply (thanks for the spot bonuses!) and will continue to do so for a long time because the demand is increasing but it takes years (decades?) to reach the peak of your game in the field, plus the increasing complexity I mentioned before.

So if your junior folks are going to pick up tickets, then have them be responsible for the ticket: they should be the (only) point-of-contact for the internal customer, they should be the ones tracking resolution and communicating to the stakeholder, they should be reaching out for help as appropriate, they should be getting sign-offs (the admin equivalent of code review) on what they've done from their senior peers. No, they aren't going to be able to do that live. If that's not ok, then you can't use juniors at all and you will have to budget (for an appropriate definition of "budget") for the occasional mistakes the seniors will inevitably make while yolo-ing live changes to production systems (e.g. Active Directory).

Think about it from your perspective as a manager: you are responsible for the outcomes from your team yet there's probably no way on Earth you could personally deliver the outcomes yourself. Instead you take responsibility for making sure the work gets done even if you don't personally do it.

So have them be more like that. Have them be more like you. You may even find that you get some good EMs and TPMs out of it! Like good engineers, they are also a commodity in short supply!


Your assumption seems to be that junior employees can work unsupervised. It is the very essence of juniors that they need seniors to guide them. They cannot work unsupervised. They don't know what they don't know. It's only when they hit that spot, that they recognize they cannot do it alone.

If you want people who work unsupervised and can solve problems alone to present a single, very professional point of contact for other teams, you need to hire seniors exclusively. It is not cheap and not cost effective, but there is no law forcing you to hire juniors. You get what you pay for.

Now, if you want to have juniors on the team, there need to be ground rules:

One of them might be that they do not change things in production without a review from a senior. That is perfectly normal in computers: none of our code sees production without senior reviews, not even that of other seniors.

As far as leaving a bad impression on the "clients", why do you even transport that information? If Jacob the junior has the ticket and Sanchez the senior needs to step in and help, that should be an absolutely normal and daily routine. That is what it means to have juniors and seniors on a team. But there is no need to communicate to the outside that Sanchez had needed to step in or that "we need to wait for Sanchez". Those are team internals and don't need to be communicated. Jacob has the ticket, Jacob will solve it, Jacob will communicate the success. It's none of your clients' business how much help Jacob got behind the scenes or who or what they had to wait for. If Jacob's ticket gets yanked away from them the second they cannot continue, they will not really learn anything from it. They only learn how to do it by getting guidance from Sanchez and then doing it themselves.

And yes, if you impose rules on juniors and single them out, that might be weird. It would be weird for them inside the team and even more humiliating if they had to communicate that to their clients. "Sorry, I cannot do that, I was not yet trusted with those privileges, I am a junior" is humiliating to say, and leaves the impression the client was serviced by a "less than optimal" team member.

So set the same rules for everyone. Every ticket that is actually something "new" (i.e. doesn't have a documented script that a trained monkey could follow) needs review from a senior. Even if a senior did it. Seniors, too, are only human and four eyes might spot a mistake that two eyes did not.

This way, nobody is singled out or told they aren't good enough. And who knows, your senior's quality might improve, too.

  • 3
    When the customer is present in a zoom call with you ( we do have remote employees) , how do you hide the fact though that there are multiple people present? Attendees is a number that can be seen by all on screen
    – Anthony
    Commented Nov 7, 2023 at 12:27
  • 57
    @Anthony: I don't think there is need to hide it. Adding an expert for a certain area to the zoom call after the initial problem assessment is a perfectly normal thing, and it's something that seniors do as well (after all, not every senior is an expert for everything). The expert helps, and, after the expert is no longer needed, the expert leaves and the junior finishes up the ticket. The junior is present the whole time, because (a) he/she is the contact point for the customer and (b) you want them to learn from the senior, which won't happen if you take the ticket away from them.
    – Heinzi
    Commented Nov 7, 2023 at 13:08
  • 8
    @T.Sar If you have that kind of business, then a four-eyes principle should always be applied, not just for juniors. Commented Nov 7, 2023 at 16:56
  • 34
    @Anthony From the customer's side, I'll say that having an engineer call in assistance is perfectly normal. When the problem goes somewhere unexpected, you call in the subject matter expert that can best solve it. Heck, I've had seniors call in junior team members when they were the SME for the task at hand. Junior/senior really has nothing to do with it. You use the best tool for the job. Don't be shy about that. You can even spin it so the customer feels like they're getting the VIP treatment.
    – bta
    Commented Nov 7, 2023 at 22:10
  • 8
    As a customer I don't expect my requests to be immediately handled by the experts. What I expect is my issue to be escalated to an expert the second the normal help desk person can't do it. Having an expert in a call along side my contact person will actually make me feel more valued and taken serious as a customer. I suspect the same is true for your customers.
    – seg
    Commented Nov 8, 2023 at 10:43

If you have a ticketing system, you should be doing some team meetings to triage the tickets by severity and priority and effort. You can at that time make some decisions about who to assign the mist urgent tasks to, and/or tell the juniors "until you know the codebase better, stick with the ones that are marked easy, or that aren't time critical, or work the problem with one of the lead engineers and let them show you how to manage impatient customers. And if you get stuck, please ask for help!" Or, work the problem but let the senior handle communicating with the customer, which seems to be the largest concern here.

Though frankly, most of us by now have no problem with the idea that a relatively low-level tech will handle the initial information gathering and standard solutions, a midrange tech will attempt to solve it or find a workaround, and the"big guns" get called in only if the ess skilled people can't handle it or the issue is time critical (losing an obscene amount of income per day the problem persist, serious security issues, that sort of thing).

Of course the customers are going to try to argue that their problem is the one that should be fixed yesterday. It is, for them. A certain amount of "I understand and we're getting to it as fast as we can" is needed, unless the customer is paying for priority service. One of a manager's jobs is to be a buffer between their staff and customers, internal and external, when necessary.

If you're already doing all this and customers are still irate, take a long hard look at whether you have enough staff, well enough trained, on the job. And at whether the customer is being unreasonable. And at whether you can rush out a temporary patch or workaround that will hold them until a proper fix is available.

As I've told many people, "Please be patient. I'm making mistakes as efficiently as I can."


Junior people need challenging problems to grow.

The problems you described are due to bad process. Why is there a lengthy delay when your junior people escalate a ticket? Why are there communication gaps? Aren't the junior people documenting everything in the ticketing system?

How about having a senior person "on call" so when the junior person needs help, they can bring that person on in real time and work together on the ticket? That will eliminate your delay and the junior person can brief the senior person while all the info is fresh. With both of them on the ticket, the opportunity for miscommunication is reduced as well.

  • 1
    The customer is live with the engineer in the moment on Zoom call, and if the wait for senior assistance is lengthy, I hate to keep other employees seeking assistance waiting. Cutting them off abruptly is also bad service
    – Anthony
    Commented Nov 8, 2023 at 23:27

You must log in to answer this question.

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