One thing that many miss is that using "processes" takes potential personality clash out of the equation.

When you have a growing team of engineers there tends to not only be a number of them that like to be "individuals" but also that might not like be told "what to do".

Appreciating that this is a trait of a good engineer at one level is important.  We want them to be able to work independently and to know enough that they don't really need to be told what or how to do something - but of course that is not always the case.

Simple processes can be used to manage this including clear understanding of the responsibility of people they interact with.

Let us look at this example.  If you follow good process, the Help Desk is responsible for "ensuring" all tickets are acted on and closed, aiming to be within the SLA.  If the rule exists that they must escalate within a given time it is not seen by the engineer that they are "just hand balling".  Sure, some sensibility is needed to ensure they are not; that is a managers job.

Now that the engineer has the job, if you publish and announce that the Help Desk needs to follow the status of ALL un resolved tickets up; not only do they have permission to chase up the engineer but it is a requirement as part of their job.

The final piece is defining a time lapse against SLA's that if on a 3rd check the ticket is not resolved that they follow up with the engineer PLUS notify the management that an issue is not being resolved.  This becomes a requirement, not a "I'm telling the manager" situation - part of standar process and all in the aim of ensuring the user/customer has their problem resolved in suitable manner.