I had a really difficult conversation with a couple different managers recently. They talked about how despite the constant messages and reminders to the team to "do the right thing" and "try something, anything, let's see if it works"... nothing seemed to really change. New words were used by the team, but their behavior didn't change much, if at all. Language is very powerful so this made me suspicious of the manager(s). After asking some questions about their approach, and confirmed they were NOT the problem, at all.

They believed and understood their teams are perfectly capable to make the right decisions. They support the team, trust them and even when they screw up, "so what, they tried something instead of sitting on it -- what did we learn?". Yet still, despite this, why are things not really move forward? What's happening that's stopping the teams from moving forward? Where's the blockage?

What has not been accounted for are a type of person I've coined the "oracle" - tenured and respected people on a team that have an amazingly robust set of knowledge of "why?" and highly valued for their contributions. They know why things exist the way they exist, why that decision was made, why this is the way, how to make things run. The catch? They have "the way" of working, and actively resist any new way of working. Their value system has been built around authority of knowledge. In their eyes, these have been done before, and didn't work - their way is best, proven and safest because it always works. Any other ideas or changes? Sorry, there's a reason why it cannot be done. This can turn into a big, ugly problem that needs to be addressed.

As a manager, how do you identify this and evaluate if you have an oracle or not? Based on the data I have (it isn't much, but it's trending), three things are common.

1. They've been on the same project/product for 5 years or more.
2. They've been in the same role for 5 years or more.
3. During team conversations, their opinion is the loudest.

To be completely clear, not everyone that satisfies this is instantly an oracle, far from it. It's simply a data point I've found to be consistent. The managers, they had suspicions but did not have any evidence to back up their hunch that someone was causing the lack of progress. It takes some observation of how the team works and every manager knows if they have an oracle or not -- there's just no clear way on how to address it. That, tagged with the fear of killing morale or the "wrath" of the oracle if they challenged their ideas. When pushed, the manager pointed out the oracles ideas always seemed to "win" - even if another idea was better. This isn't ok, nor is it what the organization wants. It's also a huge risk to the business for one person to have all this in their head and not automated, streamlined, etc ...so what's a manager to do?

Releasing the authority of knowledge

with automation, good code, culture design and practices

In product development, most larger companies have a special way to get their build to work on their local box. The oracle must be consulted not only for where this information is, but for help because it hasn't been updated. Have them help automate it with the help of newer members. Start to find and uncover things that new developers need on day zero. This can include reviewing the build process and having them help break it apart and get the builds going faster. Get that knowledge out of their head and automated. In short, you'll be removing the authority of knowledge, releasing them from the need.

If this sounds like a bad thing, it isn't. Freeing them up to never be that single point of knowledge and be responsible for always being on call or needing to be part of a conversation is liberating them from that. Have fun with it, ask them questions like "we don't have to call you for this now, what will you do with all this new free time?" -- and I'm serious about it. In my experience, this has been a relief for not only the oracle, but the team as well. New problems can be addressed and focused on instead of playing the "where's the document?" game.

When to part ways

not so fun stuff

If those changes and improvements are not part of their message, I do not envy the decision that must be made. Here's the big ugly. Sometimes it's necessary to let them go. They've become the barrier to progress and there's no way to say it nicely - barriers need to be removed

Let me be blunt for a second. Most managers are horrible at firing people at the right time. They'll wait too long, trying things to make it better -- and it doesn't. After it's completed, wish they had done it sooner. As a leader or manager, if bad behavior is allowed to continue that is eroding the hard fought progress, that's the culture you created and cultivated - and this cannot be allowed. It is not leading nor managing. It's no different than allowing comfort in a bad process or bad relationship. It still exists, and worse, the team will see it and accept it. It's your job to fix it, correct it and defend it. Head on. This goes for anyone on the team.

Despite the efforts of yourself and others on the team, progress is not being made. The oracle has dug in and now launching a campaign to block any and all changes. This is where it gets tough. It's time to let them go. Worse, you might have a relationship with this person, maybe even a personal one outside of the office. With regards to the organization, fear of losing their knowledge, their skill, their level of contributions, all out the door. Literally. They'll now be back in the job market and you might feel responsible and worried for their well being. They are human after all. It'll be ok, everything will go on and get better. Just remember it's respectful to the team, the organization and them.