Don't Ever Forget to Challenge the Status Quo
Some timeless and cliché advice.
A senior engineer on my team wanted to attend a conference. It was in their area of expertise, the kind where they’d actually learn things that would benefit the team.
They’d been with us for two years. Solid performer. Never asked for a professional development budget before. The conference was well-regarded in the industry, not some vendor junket.
But we had a policy: conference attendance was capped at one per person per year. Budget constraints. Fair distribution of opportunities. The usual reasons.
This would be their second conference of the year. The first one had been in Q1—a mandatory vendor training that the team needed someone to attend. This new conference was the one they actually wanted to go to for their own development.
I looked at the policy. Saw they’d already been to one conference. Told them we couldn’t make it work. He understood. The conversation ended there.
Then I found out our sibling organization – same division, same budget constraints – regularly sent people to multiple conferences per year. They counted mandatory vendor trainings separately from conferences for professional development. Same policy our organization supposedly had to follow strictly.
This meant the engineer in question had an option: miss the conference and the learning opportunity, or transfer to the sibling org where they could go to the conference, but would have to leave the team they’d built a 2-year relationships with.
The engineer spent three weeks getting mixed messages while this played out. Finance said maybe. Their skip-level said probably. I said the policy was clear. The sibling org said they’d approve it if he would join their organization.
Frustrating for everyone involved.
What I Got Wrong
I treated the policy like it was absolute. But worse, I didn’t push back on the fact that it was being applied unevenly.
Policies exist for good reasons. When we approve conference attendance, we need to manage budget and ensure fair distribution of opportunities across the team. The one-per-person cap makes sense for that.
But our sibling organization was interpreting it differently. They didn’t count mandatory vendor trainings or required certifications against the cap. Only elective professional development conferences counted. For an outsider this seems like a petty problem that we’re being pedantic about. But in a organization with multiple-hundreds of people you want policies to be standardized and applied evenly.
This request wasn’t a random one, that would break the budget. This was a proven engineer who’d used their one “real” conference slot on a mandatory training, asking to attend an actual professional development conference.
The policy’s intent (fair distribution of development opportunities) wasn’t being violated. And the uneven application meant we were forcing good people to choose between professional growth and staying with their team.
I should have asked: why are we counting mandatory trainings against the conference cap when our sibling org doesn’t? Does this case deserve an exception? Instead, I saw the rule and stopped thinking. Not great.
How My Manager Handled It
My skip-level didn’t argue the policy was wrong. She acknowledged why it existed and that it generally made sense.
But she pushed on the inconsistency. Why was our sibling org interpreting “one conference per year” to exclude mandatory trainings, but we weren’t?
She built the case for why this situation was different:
This was a conference in the engineer’s core area of expertise
The first “conference” was mandatory vendor training, not elective professional development
The engineer had never actually used professional development budget for their own growth
The sibling org was explicitly not counting mandatory trainings against the cap
The policy’s intent was fair distribution of development opportunities
This interpretation wouldn’t violate that intent. In fact, it would actually serve it better
She showed leadership that we were applying the policy unevenly across the organization. Either the sibling org shouldn’t be making that distinction, or we should interpret the policy the same way.
She gave them a framework for making an exception without undermining the policy itself, that would lead to applying it consistently with how other parts of the org were already operating.
That’s what I should have done from the start.
When Policies Need Exceptions
Good policies create consistency. They prevent chaos. They encode organizational learning so we don’t have to re-litigate the same decisions repeatedly.
But policies are general rules designed for typical situations. Not every situation is typical.
I’ve seen this pattern repeat across different contexts:
A hiring timeline works for most roles but loses you a stellar candidate in a competitive market. The policy says three rounds over four weeks. The candidate has another offer in two.
A code review policy makes sense generally but blocks a critical security patch. The policy says two reviewers and 24-hour review window. The vulnerability is being actively exploited.
A promotion cycle is reasonable for most situations but fails to account for someone who took on a leadership role mid-cycle and crushed it. The policy says reviews happen twice a year. This person deserves recognition now.
The policy isn’t wrong in these cases. But rigid application without judgment creates bad outcomes.
The Framework I Use Now
When I hit a policy that’s creating a problem, I don’t assume it needs to change. I ask four questions:
First: Why does this policy exist?
Not just the stated reason. The actual problem it was designed to solve. Often you’ll find the policy made perfect sense when it was created, and still makes sense for most cases.
Second: Is the policy being applied consistently?
Are other teams, orgs, or divisions getting exceptions you’re not? If so, why? Inconsistent application often signals that the context has changed or that someone else has already solved the problems the policy was meant to prevent.
Third: Is this situation different?
Not “is it inconvenient” or “would I prefer a different outcome.” Actually different. Does the reasoning behind the policy apply here? Is the risk profile the same?
Fourth: What would an exception look like?
Can you grant an exception without setting a bad precedent? Can you document why this case is unique in a way that doesn’t open the floodgates?
If the answers are “the policy is sound,” “it’s being applied unevenly” or “this case is genuinely different,” and “we can make an exception without undermining the rule,” then you build your case.
Building the Case for an Exception
Document why this situation differs from the norm. Be specific.
Don’t say “this conference is really good” or “this person really deserves it.” That’s true for lots of situations that don’t warrant exceptions.
Say: “This conference is directly relevant to the engineer’s core responsibilities. The policy exists to ensure fair distribution of professional development opportunities. The first conference was mandatory vendor training required for the team. Our sibling org doesn’t count mandatory trainings against the cap. The policy’s intent isn’t being violated—they haven’t actually used their professional development allocation yet.”
Or: “Our sibling organization explicitly separates mandatory trainings from elective professional development in how they count conferences. If they can make that distinction, we should be able to as well. Either we need to apply the policy consistently, or we need to document why our org has different constraints.”
Show what makes the risk profile different. Point out inconsistent application. Give leadership a clear framework for granting the exception without setting a bad precedent.
Make it easy for them to say yes.
What I Should Have Done
I should have gone to my manager and laid out the situation. Here’s the policy. Here’s why it exists. Here’s how our sibling org interprets it. Here’s why this case is different. Here’s what an exception would look like. Can we make this work?
Instead, I saw the policy and stopped thinking. I didn’t push back on how we were interpreting it differently than other parts of the org. I didn’t advocate for consistency.
That’s on me.
The engineer eventually got to go to the conference. They spent three weeks uncertainty about it, leaving a bad aftertaste in their mouth. All that just to access standard professional development.
That uncertainty was unnecessary. I could have advocated for them from the start.
The Broader Lesson
Policies provide structure. They’re necessary. Most of the time, you should follow them.
But leadership means knowing when the structure needs to bend. When the specific context is different enough that the general rule doesn’t apply. Or when the policy is being applied inconsistently across the organization.
Inconsistent application is often the clearest signal that something’s wrong. If one team can do something and another can’t, there’s either a good reason for the difference or the policy isn’t being managed properly.
As a leader, you need to push back on that inconsistency. Not because you want to undermine the policy, but because uneven application creates confusion and forces people into unnecessary choices.
You can’t do this for every inconvenient policy. If you’re constantly pushing for exceptions, you’re probably the problem.
But when the situation genuinely differs from what the policy was designed to handle, or when you discover the policy is already being applied differently elsewhere, you owe it to your team to make the case.
I didn’t do that when it mattered. I won’t make that mistake again.
If you’re navigating the transition from IC to tech lead or engineering manager, I write about these leadership challenges every week. Subscribe at Stratechgist.com or connect with me on LinkedIn.