When to Solve Your Team’s Problems, and When to Let Them Sort It Out
After careful review of her harried work life, Charla, an IT manager, discovered that 20% of her time over the previous two months was spent managing escalations. It seemed that each interaction with her team ended with her feeling a need to exercise her authority to rescue them from a crisis. For example:
Sarah complains that Ken — a peer — repeatedly fails to include her on group emails.
Geri can’t get the data he needs from another department.
An internal customer is two months late with requirements but is pressing Pat not to push back his delivery date.
A VP is bypassing the approval process and directly cajoling Brittney to add functionality.
Sunil is distracted from his commitments by another team’s periodic informal requests for his help.
Charla routinely ended her day having accomplished almost none of what she intended to do in her attempt to be responsive to her team’s demands for rescue. As she inspected her calendar, she concluded her team’s motto had become, “When in doubt, escalate.”
Managers are more likely to get in a situation like Charla’s, where they allow their team to abdicate responsibility for solving their own problems, when they fail to understand their true role as managers. Prior to taking a management role, you can measure your contribution to the organization by counting the number of important problems you solve. But the day you become a manager, the arithmetic changes. Your success is no longer measured by how many problems you solve. Instead, your role is to build a team that solves problems.
Anytime you become the hero by solving the problem, you risk teaching your team that without you, the situation is helpless. Over time, and with repetition, you collude with your team in creating a situation that isn’t good for any of you. You surrender your bandwidth to low priority tasks and you reinforce weakness in your team.
If you’re an effective manager, escalations should be aberrations that you accept rarely and thoughtfully. Here are some questions to ask yourself and principles to follow to make sure you’re not stepping in when you shouldn’t.
Who should own this problem? When you transition from professional to manager, change the way you approach problems presented to you. Before asking, “How do we solve the problem?” pause and consider, “Who should own this problem?” Balance the need to solve the present issue with consideration for how the way it is solved will influence future behavior. For example, if a team member is getting inappropriate pressure from a powerful internal customer, it’s tempting to conclude that your authority is needed to solve the problem. Notice, however, that by stepping in and confronting the customer, you are teaching your team that they are incapable of holding boundaries without you.
Do it now or do it right? At times, it’s appropriate to allow a direct report to escalate a problem if urgency trumps process. For example, if customer requirements must be complete in order for a strategic product launch to come in on time, you might need to use your pulpit to get action. But even under these circumstances, you should engage those in your team in the process as much as you can so you are more a partner and less the hero.
What is the least I can do? In your desire to be useful and responsive, you might be tempted to do more than you should. If others are struggling to solve problems they should rightfully own, always ask, “What is the least I can do?” Find the lowest level of initiative for yourself while requiring your team member to act at the highest level they are capable of. Then, use it as a teaching moment to help your team learn to do it without you the next time. For example, if a boundary needs to be set with a senior manager in another division, you might ask your employee to craft and send the email and cc you. Coach her on how to write the email in a tactful but clear way. Once she sends it, you can reply and show your support for the employee. Over time, the goal should be to drop you from the cc line and build confidence in your employee that she can hold boundaries.
Content, pattern, or relationship? Think of the problems presented to you at three different levels: content, pattern, and relationship.
Content problems are those where the issue is the immediate concern. For example, if a nurse is supposed to fill out patient reports before the end of his shift, and failed to do so, you have a content problem. The problem is the missing report.
Pattern problems exist when the problem isn’t the single issue itself, but when the issue is a recurring one. For example, patient reports are routinely left incomplete.
Relationship problems happen when the issue has to do with fundamental concerns about competence, trust, or respect. Relationship problems generally call for a change in relationship, structure, or policy.
In general, employees should solve most content and pattern problems on their own. This should certainly be the case for problems within the team. For example, if a peer nurse isn’t getting reports done in a way that affects another peer, the accountability conversation should happen at the level where the consequence is most acutely felt. In healthy organizations, and with strong teams, content and pattern problems outside of the team should also be generally solved by whomever experiences them. They should not be escalated. For example, if colleagues in other departments bypass a prioritization process, those who experience the bypass are in the best position to both see and confront it. If others seem repentant, but then repeat the infraction, they should similarly hold the pattern conversation.
However, if they have candidly addressed the problem at those two levels and do not see appropriate change, then escalation is appropriate. Ideally, those escalating to you would stay involved. They should also notify the other person when they have the pattern conversation that if the solution does not work, they will need to escalate to find some other answer. That lets the other party understand all of the consequences of noncompliance — hopefully adding motivation to follow through — and avoids the accusation that they are simply pulling a power play when they later escalate the problem to you.
Going back to our nursing example: After addressing the first instance (content), and then the emerging pattern, the affected nurse could end the pattern conversation with, “Great, it sounds like I have your commitment to be 100% consistent with the patient records. If there are further problems, I’ll have exhausted my available options and recommend we talk about this with our managers.”
It takes two to escalate. Client and long-time IT veteran Tom O’Dea has a policy he calls “mutually agreed escalation.” A former executive at AT&T and Sprint, Tom is always willing to get involved, but only when all parties agree they need his help to solve the problem. This extra requirement encourages team members to make going to him a last rather than a first resort. He makes exceptions when there is a power differential between his employee and their counterpart. But with peer-level disputes he has learned that the cooperative escalation requirement discourages his people from using him as a cudgel to threaten others or a cop-out to avoid uncomfortable conflict. Instead, they feel more responsible to maintain a respectful dialogue and surface concerns honestly so that if they reach loggerheads they can agree to involve him.
As a manager, your primary contribution is creating a high-performance team and the primary driver of high performance in teams and organizations is a culture of peer accountability.
Escalations are sometimes appropriate, but if handled incorrectly, they eat away at this crucial norm. These five principles can help you judge if and how to allow escalations in a way that builds rather than weakens your team.