The Blind Spot That Slowed Me Down for Years

There was a phase early in my career where I felt like I was always a step behind.
Not because I wasn't working hard. I was. Not because the problems were too complex. They weren't, really.

But somehow, things kept getting stuck. And when I look back at that period honestly, the stuckness came from two things I'd never thought to pay attention to.

The first was vocabulary. I remember sitting in a cross-team call where we were discussing a production issue. My team kept calling it an "incident." The ops team kept calling it an "event." At some point I asked, are we talking about the same thing? Turns out, yes. Same thing, completely different words. But for the first twenty minutes of that call, both teams were subtly confused about whether the other had even understood the severity of the situation. Nobody had the wrong intention. We just hadn't realised we'd walked into the room with different dictionaries.

The second was not knowing who to reach out to. I remember one specific week. I needed a config change in a service that wasn't owned by my team. I asked in the general engineering channel. Someone said, "That's probably the platform team." I found the platform team's channel and posted there. Silence. Two days passed. I followed up. Someone replied saying, "This should go to DevOps, not us." I went to DevOps. They said it was actually an infra config, which sat with a completely different group.

By the time I got my answer, four days had passed. The actual fix took eleven minutes.

I was frustrated. But honestly? Looking back, the system wasn't broken. I was just navigating it blind. On both counts.

And that started making me pay attention to something I'd never consciously thought about before.

The Thing I Started Noticing

Once I started paying attention, I saw it everywhere.

The people who moved fast, and I mean really moved fast, weren't always the most technically sharp. Some of them were, sure. But what they almost all had in common was this. They knew the organisation. They knew its language. They knew its people.

When something was stuck, they didn't post into the void. They'd say, "Oh, that's Ankit's area. Let me ping him directly." And twenty minutes later, it was sorted.

When a cross-team meeting would start spiralling into confusion, they'd be the ones to say, "I think when the product team says 'acceptance criteria' and we say 'definition of done', we actually mean the same thing. Let's align on that." And suddenly, a conversation that was going in circles would find its footing.

I started asking myself, how do they know all this?

The answer, when I finally figured it out, was almost embarrassingly simple.

They'd learned it. Deliberately. Not from any document or training. Just by paying attention, asking questions, and keeping mental notes.

That's when I realised I needed to do the same.

And the more I reflected on it, the clearer it became that there were really two distinct things these people had figured out. Things that looked unrelated on the surface but were deeply connected.

The first was language. Not English versus some other language. I mean the internal vocabulary of each team. The specific words they use, and what those words actually mean to them. The second was people. Knowing who sits in which team, who owns what, and crucially, who to go to when things get stuck.

I'd been missing both. And honestly, I'd never even thought to pay attention to either.

Let me start with the language piece, because this one surprised me the most.

Part One: The Vocabulary Gap

Let me give you a very specific example, because I think without a real one, this sounds too abstract.

We had a project where my engineering team was working closely with the data team. At some point, we needed them to share a dataset we could use for testing. We asked for a "dump." They came back with a file export from their internal tool, essentially a CSV with raw records.

That wasn't what we meant at all. When we said "dump," we meant a database dump. A structured SQL export we could load directly into our local environment. We'd been using the word so naturally within our team that it never occurred to us it might mean something else to someone else.

They weren't wrong to send what they sent. That's what a "dump" meant in their world. An export of data. In our world, it specifically meant a DB dump. Same word. Completely different thing.

We went back and forth twice before someone finally said, "Wait, what format are you actually expecting?" That one question sorted it in five minutes. But we'd wasted two days.

Another one that still makes me laugh a little. We were coordinating a release with the QA team. We told them we'd "push to staging" by end of day. They were waiting. We pushed. They couldn't find the build. Turns out, what we called "staging" was what their team called "pre-prod." What they called "staging" was an earlier environment, one step before what we meant. So they were looking in the wrong place entirely, and we couldn't understand why they weren't picking it up.

Same environment, two different names. Nobody had ever bothered to establish a shared map.

These feel like small miscommunications. And individually, they are. But they happen constantly. In calls, in tickets, in Slack messages. And they compound. After a while, it's not just lost time. It's lost trust. People start assuming the other team is being difficult or careless, when actually they're just speaking a slightly different language.

Once I started noticing this, I began doing something simple. Whenever I was going to work closely with a new team, I'd spend a bit of time just listening to how they talked. What words came up often? What did they call the things I might call something different? And when I wasn't sure, I'd just ask. "When you say X, what do you mean exactly?" Nobody ever found that question annoying. Most of the time, they'd pause and say, "Oh, good point. Let me clarify."

It felt like a small habit. But it changed so much about how I collaborated.

Part Two: Knowing Who's Who

The second thing I realised, and this took me even longer to appreciate, was how much time I was losing simply because I didn't know the right person to reach.

And I don't mean not knowing someone's name. I mean not understanding who owns what, who is the actual decision-maker for a particular thing, and who is just a well-meaning bystander.

Here's a real situation. I was working on a project that needed a third-party API to be whitelisted through our network. I asked my team lead. He pointed me to IT. IT said it wasn't their domain and suggested network security. Network security said it needed a formal request raised by a team lead, not an individual. My team lead raised it. It went into a queue. A week later, someone from network security came back saying the request was incomplete. It was missing a field that needed input from the vendor management team.

At each stage, I was dealing with the wrong person, or the right person but through the wrong channel.

And here's the thing. There was a guy in our office, Siddharth, who'd been around for six years. When I finally mentioned this to him casually, he just said, "Oh, for API whitelisting you need to go to Rohit in network security directly. He handles all of this. And you need to fill out form NW-04, not the general IT request. I'll send you the link."

Two messages to Rohit. Done in a day.

Siddharth wasn't a manager. He wasn't in a senior role. But he had six years of navigational knowledge that I was missing completely.

That interaction changed how I thought about joining any new team or organisation. I started being more intentional about understanding not just the org chart, but the real map. Who actually owns what, who the go-to people are for specific things, and where the informal shortcuts exist.

What I Actually Did About It

I wish I could say I sat down one day and decided to fix this properly. I didn’t.

There was no checklist. No framework. No "from now on, I will."

What changed was much quieter.

I started catching myself after things got stuck and asking, "Where exactly did this slow down?" Sometimes the answer wasn’t technical at all. It was that I’d used a word that meant one thing to me and something else to the person reading it. Or that I’d sent a message to a generic channel instead of a specific person who actually owned the thing.

Over time, I became a little less embarrassed about asking basic questions.
"When you say staging, is that the same as what we call pre-prod?"
"Who usually handles this kind of request?"
"Is there someone specific I should talk to for this?"

None of these felt like progress in the moment. They just felt like small clarifications.

At some point, and I can’t really pinpoint when, I noticed that things were getting unstuck faster. Not because I’d become smarter, but because I was tripping over fewer invisible wires.

I still didn’t know everything. I still sent the occasional message into the void. But I was doing it less. And when something stalled, I had a better sense of why. Which made it easier to fix the next time.

Why This Matters More Than It Seems

I think we underestimate how much of our productivity loss in organisations isn't about skill or effort. It's about navigation.

The codebase was never the problem. The work was never the problem. But not realising that what the DevOps team called a "release" was what our team casually referred to as a "deployment"? That caused confusion in every release meeting for months.

Not knowing that the right person to speak to about data access wasn't the data team manager but actually a specific analyst who handled all access requests? That cost me days.

These aren't dramatic failures. Nobody's going to write a post-mortem about them. But they add up. Week after week, they quietly drain time and energy and momentum.

And the fix is honestly not complicated. It's just attention. Curiosity. The willingness to ask, "What do you mean by that?" without feeling like it makes you look uninformed.

Because here's what I've come to believe. The people who ask those questions aren't the ones who look uninformed. They're the ones who, six months in, are moving with a confidence and ease that everyone else is still trying to figure out.

📚 About This Series: The True Code of a Complete Engineer

This is part of an ongoing series where I share things I wish someone had told me earlier — not theory, but the real stuff that shaped how I grew, earned trust, and learned to lead.

• 👉 Bookmark the full series page
• 👉 Follow me on LinkedIn — I share shorter takes there more often
• 👉 Or pass this along to someone who's new somewhere and quietly trying to find their footing.