10x Boss is (NOT) Always Right
10x Boss is (NOT) Always Right
Managing this critical relationship to drive right business outcomes
Power in Organizations
In all hierarchical organizations, the boss holds more power than the subordinate. This power differential can sometimes lead to incorrect or inefficient decisions because an employee has not figured out the right partnership model in this critical relationship. I should note that in modern management, the power comes more from influence than exercising control - and this fundamentally changes the nature of employee/manager relationship, because influential power is not necessarily position bound. [Reference: The basis of social power, and Power in workplace from mindtools (excerpt below)]
Manager Employee Interdependence
In addition to serving as an organizational information conduit, the boss is often exposed to a wider set of business challenges (opportunities) within an organization, for which he is seeking your help. A good boss also serves as a coach to develop your skills and grow your career in a direction that’s mutually beneficial for your long term objectives while balancing near/medium term outcomes for the business.
On the other side, there are many many things your boss doesn’t know, at least to a level of details they should - to name a few:
What is the complexity of your work?
Where are the technical land mines (debt)?
What’s limiting your productivity?
What are your professional objectives?
What cross-functional issues need leadership escalation?
What ground up innovation can potentially give business an edge?
Additionally, a lot of work and collaboration is taking place “over zoom” in a post pandemic world where the boss has no direct visibility or oversight. If you think about it, this relationship is based on interdependence. It is in your (and business’) best interest to bridge this perspective gap for your boss, and help them make the right decisions. Being attuned to what your boss (leadership) needs is a superpower, as it makes you a more valuable and trusted asset for the organization.
Working through Conflicts
Yet, when the “rubber meets the road”, many find it hard to disagree with the boss. There is often legitimate concern around the repercussions of this perceived pushback. Many organizations have not fully realized the value in deep partnership by breaking down power barriers and hierarchical silos. A high functioning organization relies on information and feedback flowing freely in all directions. In such organizations, from your boss’ perspective, if you are unable to bring a differing perspective to the table, you haven’t yet demonstrated sufficient ownership through independent thinking. The key is to psychologically bring both your boss and you on the same side as you try to solve a problem. It should never be you vs your boss - this is a battle you don’t want to even participate in. It should always be you and your boss vs. the problem. This means, sharing your rationale behind your approach while not getting too emotionally attached to it, and having your boss weigh in on their perspective. You should also demonstrate the maturity to own the outcome no matter whose approach prevails. You don’t ever want to leave your boss wondering whether the agreed upon decision is being followed through.
Let me share a couple of examples of “conflicts” where my boss and I had differing perspectives on how to solve the problem, how I approached it, and the final outcome.
Reorg to Alleviate Friction
I was responsible for data protection engineering teams which consisted of two teams working closely innovating together on novel solutions for hyper converged infrastructure:
Native Replication (NR) team
Disaster Recovery (DR) team
Due to both overlapping skillset and some historical interpersonal dynamics the relationship between NR team and the core file system team was prone to friction, despite several attempts to alleviate it. This friction rubbed off on the DR team as well. My boss suggested we merge NR and core file system teams, and have them work on shared objectives. And while I agreed with that rationale on principle, I was supremely concerned about the risk of attrition due to “bad blood” and dilution of focus on data protection products. We heavily debated the pros and cons of this organizational change for about a week, and although I wasn’t fully convinced, we went as one voice to the teams and announced the changes. I also shared vulnerability in not knowing how exactly this is going to unfold, and requested the team's commitment to give it their best shot for success. Within three months, we lost two out of 5 engineers, and a couple of months later, we lost one more. I doubled down on helping with hiring the right engineers to backfill those positions, and then slowly but surely the organizational friction diffused. We did take a dip in innovating along the data protection portfolio for a while but as the organizational health improved, so did the innovation.
In this scenario, my worst concerns came to light, and we paid the price by slowing down on data protection innovations for some time, but in the long term, the organization is set up better for success.
Timing the Feedback
A big project in my team was running late. The technical lead had laid out not only detailed architectural plans but I had worked with him to put in place a good execution plan to go after a massive business opportunity. Meanwhile, the existing products were proving to be quite sticky in the customer basis, and it was leading to customer escalations from time to time, as the product kept getting deployed in newer and more diverse environments. While we were able to handle most of these escalations swiftly, over the last few escalations the (same) lead engineer didn’t follow through with sufficient rigor. All the evidence pointed to severe performance concerns, and many stakeholders gave this feedback to me and through my manager. My boss felt strongly about driving this feedback right away to correct the course. I knew there was something off in this lead engineer’s personal life although he hadn’t confided in me. This was a difficult situation and I had to get it right soon else the big business opportunity was at risk and so was my team’s (and mine) reputation. I knew I had to drive the feedback clearly but I also knew that driving the feedback right away would potentially push the engineer over the edge, and I may risk further disengagement or worse immediate attrition. I discussed my rationale with my boss and suggested a timeline that allowed me to probe a little deeper, and put together contingency plans in case things go south. Although I never did probe, I learned that I had the right intuition about issues on the personal front. The lead engineer saw that he felt supported during this challenging time for him, appreciated the space I had given him, and demonstrated professionalism by owning the misses on executions and escalations, requested additional support through additional three months, and committed to driving improvements.
In this scenario, I was able to support my employee in his need while gaining support from my leadership to drive appropriate feedback with the right timing, leading to an optimal outcome. Also, I knew I had too much domain knowledge concentrated around one person in my team, and had worked out a knowledge share and transition plan. I took this situation as a trigger to accelerate those plans to further de-risk execution.
~10xManager