Empowerment vs. Entitlement
“Autonomy without accountability results in entitlement, not empowerment.”
Someone shared this quote in last week’s Tech Leader Chat where I spoke about empowering engineering teams, so I thought I’d unpack it here.
What does empowerment mean?
If you ask this question to a group of engineering leaders, you will probably get answers that are different, but aligned. Popular definitions are all some flavour of this: “Teams have the ability to choose their work, how it gets done, and they have resources they need to do it.” Some leaders will talk about speaking up with dissenting opinions, and some will emphasise control over roadmaps or technical choices.
In practice, your business constraints may only allow for empowerment to be visible in certain corners.
Your teams can’t define the roadmap, but you want them to be empowered to control how they execute on each project.
Your teams are required to use tools provided by a shared services team, but you want them to be empowered to adjust any workflows in order to fit their use cases or preference.
Your teams need to deliver projects by non-negotiable deadlines, but you want them to be empowered to push back on scope.
These scenarios might fit neatly into your own definition of empowerment.
But if you ask a team of individual contributors, their definition of empowerment might be wildly different.
For some ICs, being able to determine what they work on, now just how it gets done, is critical for empowerment.
But what’s missing from all of the definitions above is any note about what happens after the work is delivered. Autonomy and empowerment need to be balanced with responsibility. Otherwise, you end up with entitlement.
What’s entitlement?
I don’t love this word and the connotations that come with it (“get off my lawn, you entitled brat!”) but it is a great way to express the opposite of empowerment.
Where empowered teams feel they have the space and support to advocate for what they believe is right, entitled teams believe they always are right. Empowered teams can understand organisational context and apply critical thinking to arrive at a solution — even if it’s not their first preference — whereas entitled teams struggle to consider outside constraints. And entitled teams often don’t close the loop on the results of their decisions, so they miss important feedback about the quality of their decisions.
In real life, it can look like this:
An entitled team wants to push a tech debt project ahead of other priorities. They get frustrated with their business partners because they believe that everyone should just trust them when it comes to whether the project is important or not. They know better, because they’re in the codebase every day.
An empowered team knows when to push back on priorities, and how to articulate the value of a maintenance or tech debt repayment project for their business partners. They also know that they know better because they’re in the codebase every day, but because they’re also responsible for results, they make sure that the tradeoffs are visible to everyone.
What empowerment isn’t
Empowering your team doesn’t mean ignoring results in the spirit of “letting them make their own mistakes.” It’s holding space for them to experiment within clearly defined parameters, acknowledging their responsibility to deliver, and making it okay for them to speak up with troubles, dissenting opinions, and to ask for help.
Many leaders fall into a trap of holding back too much information from their teams while trying to empower them. “I don’t want my opinions influencing them too much,” is what I often hear. This is a common pattern for leaders who want to avoid micromanagement, and advocate for empowered teams. Often, this pattern can lead them straight toward a path of micromangement — exactly the thing they were trying to avoid.
Micromanagement and empowerment
I call this the micromanagement spiral. It goes like this:
In the name of empowerment, you give loose direction to your team. You might hold back your preferences or a bit of context in order to create space for your team to figure it out by themselves. They go off to work on the project, and the results just aren’t what you were expecting. You didn’t catch it sooner because you didn’t want to micromanage by asking for frequent status updates. Instead, you wanted them to feel empowered to ask for help if they needed it, or share the updates that they thought were worthwhile.
But now the project is done and the results aren’t there. You might have lost a bit of trust within the org because of this, and now you need to revisit the work: “I was expecting us to select a vendor to provide this, not built it ourselves.” “This VP is not happy that you didn’t consult their teams when making this decision.” “The CEO is really expecting a UI update along with this.”
All of these do-overs could have been avoided if you had shared that context up front. Now, you’re finding yourself getting into the details — becoming the micromanager that you dreaded.
Empowerment is not about leaving your teams in the dark to figure it out by themselves, and it’s not about avoiding hard conversations about missing results for fear of hurting feelings or being perceived as a micromanager. You need to find the line where you equip your team with the vital information they need to be successful, while also holding space for them to bring you new ideas or push back on things that don’t make sense.
Empowerment and psychological safety
Psychological safety happens when your team members feel secure that mistakes, failed experiments, and dissenting opinions won’t result in negative consequences for them. It’s highly correlated with empowerment, because it is foundational to an environment where team members can speak up and push back. It also puts results front and centre, allowing teams to align and reflect on their failures.
If you are trying to increase empowerment on your teams, and specifically, you’re looking for more discussion, more debate about decisions, and more risk-taking, it’s possible that your team members don’t feel that they’re in an environment where it’s safe to do those things.
What to do tomorrow
If you’re trying to increase empowerment on your teams:
Talk to your teams about what makes them feel empowered or disempowered. Their answers might be quite different from yours, or what you assumed. Help them understand what is possible within the constraints of your business.
Don’t ignore results in the name of empowerment. Having high standards is a signal to your team that you care, and that you’re there to support them.
Increase psychological safety through leading by example. Talk about your own mistakes and failures, and make space for your team to align and reflect on theirs.
