Why I Dropped My Tech Obsession After 35: Learning Communication, Business, and Human Nature

What Is “Tech Obsession”?

Tech obsession treats coding as the goal rather than a means; companies pay for results, not for code.

Documentation is optional if the feature works.

Flawed requirement logic is seen as a product issue.

Optimizing an interface does not guarantee praise.

Only the API implementation is considered necessary.

Why Leaving the Technical Island After 35 Is Required

1. Technical value = technology × business understanding

Cache‑optimization example:

Junior engineer: QPS rises from 1,000 to 5,000.

Senior engineer: knows the interface validates inventory before payment; each 100 ms latency reduction lifts conversion by 0.3 %.

The senior can discuss ROI directly with leadership; the junior’s improvement may go unnoticed.

2. Communication amplifies technical influence

A perfect micro‑service architecture can fail to be adopted when:

Product does not understand the terminology.

Operations consider deployment too complex.

Testers lack coverage for edge cases.

Framing the solution as “an automation script that requires a single button press” increased proposal acceptance by 80 %.

3. Understanding human nature avoids career pitfalls

Team leads assign dirty work to “easy‑going” engineers who never voice dissent.

Proposals are rejected when the engineer has not aligned privately with key decision‑makers.

Promotions are missed when managers see the engineer only as a doer, not a team representative.

Technical work solves deterministic problems; human factors address the ~90 % of workplace uncertainty.

Three Practices to Break the Obsession

1. Actively attend non‑technical meetings

Listen for:

Customer complaints.

Risks the boss fears.

“Impossible” features promised by sales.

Closing information gaps creates opportunity gaps.

2. Rewrite technical proposals in business language

Replace “We’ll use Kafka for decoupling” with “A message queue reduces order‑cancellation latency from 30 minutes to 5 seconds, cutting complaints by 30 %.” Speaking the decision‑maker’s language brings the engineer into the decision circle.

3. Practice non‑violent communication

Instead of blunt criticism (“Your logic has a concurrency issue!”) use a collaborative tone (“Your change looks great; if 1,000 users act simultaneously, could we see data overwrites? Want to review together?”). Respecting intent while adjusting the approach preserves relationships and gets work done.

Final Thought

After 35, technology remains the foundation, but communication, business insight, and understanding of human nature are the factors that enable growth.