We all want to “raise the bar.” What does it actually mean, though? Assessing R&D organizations often shows a clear dichotomy: sometimes, we need to genuinely raise the bar. That means that a new capability or profession are lacking and require rapid injection. For example, the company suddenly realizes that it needs a mobile application and currently has no one with relevant experience. The other part of the dichotomy—which I find vastly more common—is the need to level the bar.
Leveling the bar is when we realize that you already have pockets of talent in your organization whose performance is visibly better than the rest of the team. I love spotting these cases since it acts as a proof of concept. We have demonstrated that it is possible to possess these skills or processes in your company. Now we just need to permeate it through the team.
Culture Setting
As with a lot of organizational development efforts, leveling the bar starts with making your leadership team aware of this concept and realizing that it is already within their grasp. Like with design patterns for code, naming a concept allows us to understand it better and primes us to better notice areas where it can be utilized.
The get the ball rolling, you should make your leadership team accustomed to this concept and preferably even demonstrate it yourself. For example, is there anything done in another department that your team can benefit from? Show example by getting advice from your peers and showing them what they’ve taught you.
Lubricating Serendipity
Once the team is aware of this concept, let us try and create an environment where we can more easily spot these opportunities and leverage them. Especially in current work environments that are remote or hybrid, it makes sense to create organization-wide forums for people to get together, share their progress, and participate.
In The Tech Executive Operating System I mention different support systems for managers and ICs, and a common one is guilds. Setting up professional forums that bring in people from all around helps make people reconsider their assumptions and become aware of what others are doing differently. I recommend putting in place regular guilds, including leadership/management guilds.
Another example would be to make it normal to ask for someone from team A to ask someone from team B to review a pull request or to have people from different teams present in post-mortems.
Maximize
My wife and I always say that our eldest daughter is a “maximizer.” No matter the circumstances, she’ll try to get the most out of it. Long drive somewhere? She’ll bring games and try and find interesting things to spot along the way. We do something cool? She’ll take pictures and ask me to prepare slides with her so she can have a “show and tell” about it at school. Whatever cards she is dealt, she utilizes them to the fullest.
The same applies to our teams. Let’s say that you had a team do something incredible. Of course, we’re going to celebrate it, but maximizing means that we’ll have them share the lessons learned with the rest of the organization. An outage? Maximizers don’t stop with fixing the issue. They find the root cause, make similar problems less likely, update onboarding documents, and so forth. Making the team cognizant of this concept can help the bright spots—the best performers—in the organization share their learnings and really leverage every learning opportunity. Start leveling the bar today; it’s essentially maximizing capabilities and knowledge your team already possesses!