Context, constraints and consequences
One of your reports has spent all week working on a new dashboard customisation launch. It's a long-awaited feature for some of your customers, and it's finally almost ready to ship.
Good news, right? Not really.
You see, on the team call on Monday you talked about an enterprise access controls launch that must go out by the end of next week, and unfortunately that work hasn't moved at all.
At this point, we don't know why they chose to work on dashboards over the new access controls capability. What we do know is that it's job to help people understand what to work on by providing context, setting constraints and explaining consequences.
Context
Unless your team knows what's most important, they can't be held accountable for working on the wrong things. It's not enough for them to be told what's important, they must also understand why it's important.
You may have said "we have to work on access control this week", but your report has been watching Slack for months where the account teams follow up to see when custom dashboards would be launched every week. A single statement can't erase the repeated exposure to a repeated, visible customer problem. There's a real business case that supports working on dashboards.
When setting context, you also have to explain why this is the case.
Rather than "we have to work on access control", give them all the context you have:
Custom dashboards are important, but they're not urgent. The customers asking for it are already customers, and if they have to wait four more weeks that's ok. We're actively losing new enterprise deals because customers can't manage access at the level they need.
Manager underestimate how much implicit context they have. They're the ones in the planning meetings, on the email chains, spoken to the customers and prospects. A decision that feels obvious to you may appear arbitrary to someone that's heard "work on X, not Y".
Understanding why you're focused on a specific item also gives them the ability to give you feedback. If they heard that the big deal that depends on access control is likely to be delayed to next quarter, they're more likely to share that if they know that you're optimising for closing deals.
Constraints
Context explains the decision. Constraints establish how people should act on it.
Saying "we have to work on access control this week" leaves significant room for ambiguity. Your report can spend an hour or two on it, then spend the rest of the week on dashboards and still feel like they did what you asked.
Constraints resolve those ambiguities:
The access control preview needs to be ready by this Friday, and shipped in production by next Friday. It needs to cover platform-owned access controls, identity provider integration and have examples for Okta, Entra ID and Keycloak. This work takes priority over anything else you're working on. If you need to switch to something else, talk to me first.
Now the team know the deadline, the standard expected and when to involve you.
They might still choose to work on dashboards on Monday and Tuesday before switching focus on Wednesday. You asked them to talk to you first, but they're confident that they can still hit the Friday date. That's ok. You've asked them to ship by Friday, and if they ship by Friday they met the constraint. Deciding what they work on each day of the week is overbearing, so long as they meet their commitments.
Constraints also create obligations for the manager. You can't hold someone accountable for something you introduced after the work was delivered. It's impossible to specify every constraint, but as a manager you need to be able to distinguish an expectation that needs to be explicitly established from one that is obvious.
The more important the expectation (be it timeline, quality or content), the less you should leave it to inference.
Consequences
Even clear context and constraints aren't enough to drive change in people sometimes.
People gravitate towards familiar work. It's easier to start, easier to estimate, and more likely to produce visible progress. Compare that to strategically important work, which is usually full of uncertainty, difficult coordination and usually comes with a "thanks, let's do the next part" when you've hit a milestone.
This creates a problem for managers: people can be busy, produce useful output and still consistently underinvest in the strategic priority (which the manager will then be held accountable for).
Instead of questioning aggressively ("Why didn't you work on access controls? I said it was the priority"), lead with curiosity:
I noticed you’ve been working on the dashboard launch. When we met as a team, I shared that access controls was the priority. What am I missing about the dashboard work that led you to focus there?
There might be a real reason there.
Joe from sales reached out to me and said that AcmeCorp are threatening to churn. They've been waiting for custom dashboards for a long time now. I chose to focus on getting enough shipped that we can run a demo for them and placate them.
But suppose the answer is familiarity:
I know the dashboard area well, so I could get straight into it. Access controls seems a bit messy and I wasn't sure where to start.
As a manager, you've learned two things about your report:
- They treated your stated priority as optional. You need to address that decision and make clear what you expect next time.
- They need help starting ambiguous work
This is useful, but you still need to address their decision to work on something that wasn't the priority:
That helps me understand. Access controls is still the priority. Let’s work out your first step and what support you need. Next time you’re unsure how to proceed, I need you to raise it rather than switch focus.
Together, you need to agree the next steps:
- Stop working on custom dashboards
- Your report drafts an outline of what they'll produce for access controls and lists any open questions
- You review it together in 24h time
When I've worked with new managers in the past, they've asked "but what if they don't change? I'm not going to fire them over working on something that's still useful".
That's never the first step, but it is the final step if they don't change their behaviour. If you clearly set expectations (first informally in a team call, then formally in a 1:1, and finally, documented through a performance improvement plan) and they don't meet those expectations, they're not meeting the needs of the role.
There's a difference between disregarding the priority, and attempting to work on it but struggling. Your role as a manager is to diagnose the capability, scope or support gaps in your team and help resolve them.
Short term pain, long term gain
Managers have their own incentives to avoid these hard priority conversations. Accepting their "I can work faster on dashboards" explanation provides immediate relief. You can praise the work they've done as useful, preserve a pleasant relationship and tell yourself that you're avoiding being a micromanager.
I'm here to tell you that's a lie.
There's a cost to every decision. Accepting an explanation to keep the peace results in several detrimental outcomes for the business (and yourself):
- The strategic work receives less focus
- People doing the harder work carry more of the burden
- Your stated priorities within the team become less credible. You say to work on one thing, then accept work done on something different.
Eventually you'll have to have the conversation anyway, and it will feel sudden to your report as you've spent months thanking them for the work they've done on other projects.
The next time you're tempted to say "thanks, let's focus on access controls next week", stay in the conversation a little longer. Make sure you both know what will change.