Becoming Load-Bearing: Build Trust | Generated by AI
Question: How do you become a trusted person in a big corporation?
Answer:
Trust in a big corp is not about being liked — it’s about being load-bearing. People trust you when they know routing work through you increases the probability of a good outcome. Here’s how it actually works:
The Core Mechanic: Reduce Others’ Cognitive Load
Big corps are full of uncertainty, ambiguity, and things that fall through cracks. A trusted person is one who makes other people’s jobs easier and less risky. That’s the whole game.
What Actually Builds Trust (in order of impact)
1. Reliable delivery, not brilliance
The #1 thing. If you say you’ll do something by Friday, it’s done Friday. Not Monday with an excuse. Consistency over time is what builds the mental model that “Zhiwei ships.”
Brilliant but unreliable = untrusted. Average but reliable = trusted. That’s the math in big corps.
2. Raise problems early, not late
When something is going wrong, tell your lead by Wednesday, not Friday EOD. Early signal = you can still fix it. Late signal = you’ve created someone else’s emergency.
This alone separates trustworthy engineers from everyone else.
3. Communicate upward in their language
Managers and VPs don’t think in PRs and stack traces. They think in: risk, timeline, impact, cost. Translate your technical work into those terms without being asked.
“I found a memory leak that would have caused prod outages on high traffic days” lands better than “fixed a bug in the allocator.”
4. Own your blast radius
When you break something, own it immediately, clearly, and with a fix in hand. Don’t minimize, don’t deflect, don’t wait for someone to find it. The engineers who say “I shipped a bug, here’s what happened, here’s the fix, here’s how I prevent it next time” are promoted. The ones who hide it are eventually fired.
5. Be the person who knows how things actually work
Big corps have org charts and then they have the actual graph of who knows what. Become a node in the actual graph. Be the person who understands the legacy system no one documented. Be the one who knows which team owns that weird service. Knowledge of actual reality is a trust asset.
6. Make decisions, not requests
Junior engineers ask “what should I do?” Trusted engineers say “I’m going to do X for these reasons, let me know if you disagree.” The latter requires less management bandwidth and signals judgment. Over time, people stop checking and just let you run.
7. Don’t play politics — but understand the org
You don’t need to be a politician but you need to know: who makes decisions, who influences decisions, whose approval unblocks things. In banks especially, this map is non-obvious. A VP who never speaks in meetings may be the one whose buy-in you need.
In a Bank Specifically (Your Context)
Banks have extra trust dimensions:
- Compliance and risk awareness — know what your code touches: PII, financial data, audit trails. Demonstrate that you understand why the constraints exist, not just that they exist. Engineers who “get” compliance are rare and valued.
- Documentation discipline — banks move slow partly because of audit requirements. Trusted engineers produce clear, traceable decisions. Write ADRs. Write post-mortems. This builds institutional memory and ties your name to good judgment.
- Security instincts — flag things that look like security issues even if it’s not your ticket. This is extremely high-signal in financial institutions.
The Compounding Effect
Trust compounds. Each reliable delivery makes the next one lower-stakes to assign. Each proactive risk flag increases the probability you get looped into important decisions earlier. After 2-3 years of consistent behavior you become the person who is cc’d by default, whose judgment is cited in meetings, and whose opinion on architecture or approach gets deferred to.
That’s what being “trusted” actually looks like at the system level.
What Doesn’t Work
- Being the smartest person in the room without reliability
- Over-promising to look capable
- Disappearing when things get hard
- Solving problems silently without communicating status
- Complaining about process without proposing improvements