Expertise vs. Network: When Being Right Isn't Enough

Part 2 of a series on contextual intelligence in leadership.

Early in my career, I spent a few years at an offshore consulting firm that served US clients. The operating model was straightforward: you worked with US colleagues on a daily basis, occasionally travelled to work directly with clients, and your reputation was built almost entirely on what you produced. The quality of your frameworks, the sharpness of your analysis, the reliability of your delivery timelines. If your work was good, people trusted you. If your work was consistently good, you got stretch opportunities. The feedback loop was tight and legible. Do excellent work, get recognized for excellent work.

I internalized this deeply. Not as a strategy, but as an identity. I was the person who could be trusted to deliver, on time, with precision. It felt like a universal truth about professional life: competence is the currency. Everything else is secondary.

Then I joined a large Indian PSU, and discovered that competence is not a currency. It is a qualifying exam. You need it to enter the room. But once you're in the room, the room runs on something else entirely.

The LMS that won and lost

I've written about this in Part 1 of this series, so I'll keep the summary brief. Within six months of joining the PSU, I built and launched their first learning management system. Something the organization had been trying to create for years. It was needed, it was well-designed, and it worked.

It also fractured two HR teams into open hostility. The team that hadn't been involved felt bypassed, outshined, and politically exposed. The quality of the LMS was never the issue. The issue was that I had built it the way I knew how to build things: independently, quickly, and with a focus on the output rather than the process of getting there.

At the consulting firm, that approach would have earned applause. At the PSU, it earned enemies.

But the LMS was only the beginning. The real education came two years later, in a completely different role, with a completely different task, where I made the same mistake in a different form.

The payslip audit that nobody wanted

I moved into a zonal HR partner role. The PSU operated on a hub-and-spoke model where certain zones carried org-wide responsibility for specific tasks. My zone was the hub for payslip audits of third-party blue-collar workers: verifying that contract labourers across the country were being paid in accordance with government guidelines and on time.

The stakes here were not abstract. These were workers whose wages were governed by minimum wage laws, and the audit existed to ensure that third-party vendors weren't underpaying them. It was a compliance function with real consequences for real people.

Before I took the role, the audit was being done via sampling. It wasn't humanely possible to review each payslip manually. The previous person would pick a handful of payslips from each zone and ask apprentices, most of whom had limited understanding of labour laws and wage regulations, to review them. The output was predictably incomplete and discrepancies were missed. I took this as a challenge. I will show them how it's done, I told myself. Afterall, consulting had made me build problem-solving rigour.

I taught myself to build an Excel tool with embedded macros. The process became simple: paste the salary data for a location, select the city classification (X, Y, or Z category), and the tool would automatically flag every entry that deviated from the statutory requirements. No sampling. No guesswork. Every payslip, checked against the actual legal thresholds.

The output was a detailed, accurate, location-wise discrepancy report. I shared it with my zonal counterparts across the country, with the entire HR leadership marked on the emails, as was standard practice. I smiled smugly with the realization of a job well done as I sent out the emails.

The reaction was immediate and uniformly hostile.

My counterparts in other zones didn't see a useful compliance tool. They saw an exposure. The detailed report, circulated to senior leadership, made it visible that their zones had discrepancies. Which meant it looked like they hadn't been monitoring their vendors properly. Which, in fairness, they hadn't been, but that was also true of everyone, everywhere, before the tool existed. The difference was that now it was documented and visible, with their names attached.

Nobody told me directly that they resented it. It showed up in subtler ways. In how information stopped flowing to me through informal channels. In how my messages got delayed responses. In the how my colleagues turned quiet when I entered the room and friendly banter turned into polite exchanges. I remember waiting for my turn for annual appraisal. We had a leadership meet at Pullman Hotel, Aerocity, followed by performance reviews of all HR Officers. I saw people talking to each other. Laughing. Joking. Whispering to each other. I sat in the corner and felt one of the most profound workplace loneliness I have ever felt.

I had done something that was objectively in the organization's interest. Underpayment of contract workers is a legal liability and an ethical failure. The tool was better than what existed. The data was accurate. The process was more rigorous. And none of that mattered, because I had delivered it in a way that made my colleagues feel surveilled rather than supported.

The same mistake, twice

What struck me later (much later than it admittedly should have) was how structurally identical these two episodes were. Different contexts, different tasks, different stakes, but the same error.

In both cases, I had identified a genuine problem. In both cases, I had built a genuinely better solution. In both cases, I had delivered it with speed and thoroughness. And in both cases, the delivery itself created a political problem that was larger than the operational problem I had solved.

The consulting firm had trained me to optimize for the output. The PSU was trying to teach me that the output is only one layer of a much thicker system. Beneath the output is the process of how it was created, who was involved, who was consulted, who got to review it before it became official. Beneath the process is the relational fabric: who feels respected, who feels threatened, who feels ownership, who feels bypassed. And beneath all of that is the institutional logic: in a large, hierarchical, tenure-rich organization, stability of relationships is not a nice-to-have. It is the operating system. Everything runs on it. When you disrupt it, even in the service of a better outcome, the system pushes back. The consulting firm didn't teach me this because it didn't need to. In a professional services environment, particularly an offshore one, the relationship between you and the work is relatively direct. You produce, you're evaluated, you advance. The organizational layers between your output and your reputation are thin. In the PSU, those layers were thick, numerous, and invisible to someone who had never had to navigate them before.

The currency I didn't know existed

There's a concept in organizational theory that gave me language for this, years after I'd lived through it. Nahapiet and Ghoshal's work on social capital distinguishes three dimensions of what networks actually provide in organizations.

Structural capital is the architecture of connections. Who knows whom. Who reports to whom. Who sits on which committee. It's the org chart and its informal shadow. When I arrived at the PSU, I had some of this. I could read the hierarchy. I knew who the decision-makers were. I understood the reporting lines.

Relational capital is the quality of those connections. Trust, reciprocity, norms of cooperation, the unspoken obligations that build up between people who have worked together, navigated conflicts together, covered for each other during difficult periods. This is what lets someone pick up the phone and get a honest answer. What lets someone propose a bold idea without it being read as a threat. What lets someone make a mistake and have it absorbed rather than weaponized.

I had none of this. Zero. I was a new entrant from a completely different professional world.

Cognitive capital is the hardest to see from the outside. It's shared language, shared mental models, shared interpretation of what things mean. When a PSU veteran says "let's take this to the committee," they mean something very specific about how decisions get legitimized. When they say "we should get this reviewed by so-and-so," they're not being inefficient; they're activating a node in the coordination system. When they resist a change, they may not be resisting the change itself but the way it was introduced, because "how things are introduced" carries institutional meaning that an outsider doesn't have the codebook for.

I had none of this either. I didn't just lack the relationships. I lacked the interpretive framework for understanding what relationships were for in that system.

This is what made the miscalibration so invisible to me at the time. I thought I was navigating a familiar professional environment with some cultural differences. What I was actually navigating was an environment where the primary productive asset, the thing that made things happen, was a form of capital I didn't possess and, worse, didn't know I needed.

The payslip audit, re-examined

Through the social capital lens, what went wrong with the payslip audit becomes structurally clear.

1. I had structural capital: I knew who my counterparts were, I knew the reporting lines, I knew where to send the report.

   
   

2. I had zero relational capital: my counterparts had no basis for trusting my intentions. We had no shared history. I hadn't invested in understanding their constraints, their pressures, their relationship with their own vendors. When the report landed, they had no reservoir of goodwill to draw on in interpreting it charitably.

   
   

3. I had zero cognitive capital: I didn't understand that in this system, a compliance report circulated to leadership without prior informal discussion was an act of exposure, not collaboration. I was operating on consulting-firm logic, where transparency to leadership is default and expected. In the PSU, transparency to leadership is a tool, and tools can be weapons depending on who wields them and how.

What "taking people along" would have actually meant, in social capital terms, was investing in relational and cognitive capital before deploying the structural capital I had. Share the tool with counterparts first. Let them run it on their own data. Give them the chance to act on discrepancies before anyone senior saw the numbers. Build a shared understanding ("we all have gaps, this tool helps all of us") before the data made the gaps visible.

This isn't just "being political." It's recognizing that in an organization where social capital is the operating currency, deploying technical solutions without social capital backing is like writing a cheque on an account with no funds.

What a consulting firm teaches you to undervalue

The reason this lesson was so hard for me to learn is that consulting firms actively select against social capital dependence.

Think about how an offshore consulting firm works - especially if you are operating at a junior - analyst / consultant level. Teams form around projects. Projects end. Teams reform. Your colleagues this quarter may not be your colleagues next quarter. Client relationships are managed at a level above you. The premium is on individual and small-team excellence, portable skills, and rapid ramp-up on new engagements.

In this model, social capital is nice to have but not structurally necessary. You don't need deep relational capital with your team because the work itself provides the coordination mechanism. You don't need extensive cognitive capital because the consulting methodology provides shared language and shared mental models. And structural capital is lightweight: you know who's on your project, who the engagement manager is, who the partner is. The connections are functional, not institutional.

This is efficient. It's also deeply misleading as preparation for any organization where the work and the relationships are inseparable. The consulting firm teaches you that relationships are the by-product of good work. The PSU teaches you that good work is the by-product of good relationships. Both are true, in their respective systems. But the second lesson is much harder to internalize if you've spent your formative professional years in the first system.

The benefit of hindsight

I truly understood what had gone wrong only after I left the PSU. This is worth dwelling on, because I think it's common and underexplored.

While I was inside the system, I could feel the friction. I knew things weren't working. But my diagnosis was wrong. I attributed the resistance to the organization's culture: it's slow, it's political, it doesn't reward initiative. This is a comforting diagnosis because it locates the problem outside yourself. The organization is the problem. You are fine. You just need to find a place that appreciates what you bring.

It was only from the outside, after I had left and moved into a completely different organizational context, that I could see the pattern clearly. The PSU wasn't the problem. My calibration was the problem. The organization was operating on a perfectly coherent logic, one where social capital was the primary productive asset. I just hadn't learned to read it.

This has an uncomfortable implication for leaders who move between organizations. The most important learning from a role might not be available to you while you're in it. The system you're embedded in shapes your perception of the system. You can't see the water you're swimming in. It's only when you surface, step into a different body of water, and feel the difference that you understand what the first one was.

I spent two and a half years at the PSU. I started learning, eventually. But by then, the relational damage from the early miscalibration was deep enough that I felt I couldn't fully recover from it in that context. I took the lessons with me to the next organization, where I think I did better. But "doing better in the next one" is a costly way to learn.

The real distinction

If I had to name the core tension between these two archetypes, it would be this:

In a professional services environment, your output is your reputation. Build something excellent and the system recognizes you for it. Social capital accumulates as a side effect of competence.

In an institutional environment, your social capital is your operating capacity. How you arrived at the output, who you brought along, whose input you sought, whose territory you respected. The output matters, but it is evaluated through the lens of the relational and cognitive capital that produced it.

Neither logic is superior. A consulting firm that ran on PSU logic would be paralyzed. A PSU that ran on consulting-firm logic would tear itself apart. They are different systems optimized for different problems, running on different forms of capital. The mistake is not in preferring one over the other. The mistake is in assuming that the capital you've accumulated in one system is convertible in the next.

Have you experienced this transition, from a system where output was the operating currency to a system where social capital determined everything? Or the reverse? I think the direction of the transition changes the lesson. Moving from consulting to institution teaches you that there's a form of capital you didn't know existed. Moving from institution to consulting teaches you something equally disorienting: that the capital you spent years accumulating might not be convertible at all. Both lessons are useful. Both are painful. Which one did you learn first?

A balancing act | Photo by Pyae Phyo Aung: https://www.pexels.com/photo/man-walking-between-floating-benches-over-water-33579446/