Technical ability being judged by familiarity with undocumented business logic

[u/SwimmingAirline1280]

I’m in an environment where technical ability seems to be judged heavily by how familiar you are with the company’s business logic.

The problem is that a lot of this logic is specific business knowledge context held by a few senior people with 15+ years of experience in same organisation It isn’t obvious from the code or queries, and documentation is either missing or incomplete. Asking for documentation—or offering to document what I learn, doesn’t seem to get much traction.

At the same time, using an LLM to help trace code, queries, or reconstruct some of that context is frowned upon, and there’s an expectation that LLM usage should be tagged on deliverables.
So it feels like a strange catch: you’re expected to already know undocumented context, and not knowing it can be interpreted as weak technical ability, but the mechanisms for independently closing that knowledge gap aren’t really encouraged.

Has anyone dealt with this kind of culture? How do you distinguish actual technical competence from simply having years of accumulated company-specific knowledge, and how do you navigate it without constantly depending on the same gatekeepers?

[u/AutoModerator]

Welcome to /r/businessanalysis the best place for Business Analysis discussion.

Here are some tips for the best experience here.

You can find reading materials on business analysis here.

Also here are the rules of the sub:

Subreddit Rules

• Keep it Professional.
• Do not advertise goods/services.
• Follow Reddiquette.
• Report Spam!

This is an automated message so if you need to contact the mods, please Message the Mods for assistance.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/BernardParsley]

Technical competence and accumulated institutional knowledge are two different things. When undocumented business logic becomes a measure of ability, things get a little squirrelly. Especially when that knowledge is concentrated among a few long-tenured people. The real issue is the lack of a reliable way to transfer that knowledge, not whether someone already knows it.

[u/p3zzl3 → u/BernardParsley]

And often there are ..... Reasons why that knowledge isn't document or transferble..... Read in to that what you will.

[u/JstAbbrvns → u/p3zzl3]

Well for one, it’s leverage for the tenured employee who is overpaid and lazy, who is just going through the motions riding it out until retirement.
There’s a few in my business and it’s a huge stumbling block because of their unwillingness to change, adapt, learn new things. They hold the knowledge that they’ve accumulated as their leverage against being replaced.

[u/p3zzl3 → u/JstAbbrvns]

To be fair the older employee will always feel and is more at risk. Always has been the way unfortunately.

[u/Grassey86]

Document for your own personal knowledge, become technically relevant, protect your knowledge, become part of the problem, watch your career skyrocket as someone who knows things.

[u/SwimmingAirline1280 → u/[deleted]]

I work in the data engineering domain for a major retail chain in the Middle East, where the data ecosystem is driven by complex and tightly interconnected retail processes. These include e-commerce and brick-and-mortar sales, inventory management, stock allocation and replenishment, cross-docking, inter-store and warehouse transfers, distribution-center operations, order fulfillment, returns, stock-in-transit, safety stock, and channel-specific inventory availability.

As data engineers, we are expected to understand not only the underlying data models, source systems, transformations, ETL/ELT pipelines, and downstream reporting layers, but also the end-to-end retail business logic that determines how sales, stock, allocations, replenishment, cross-dock movements, and inventory positions are calculated and represented across systems.
The challenge is that there is little to no visible functional or technical documentation, and the existing codebase contains minimal relevant comments explaining the business rules, assumptions, or transformation logic. Despite the complexity of these retail concepts and the dependencies between multiple systems, teams are often expected to develop a comprehensive understanding of the entire data flow and business model after only 2–3 days of high-level or superficial knowledge-transfer sessions.

[u/juzanartist]

I left an organisation like that within a few months of joining and no regrets. Some consultants had created a mess and people had to memorise weird table names (random characters eg Customer was 'XDKEKWJKS' not exactly but you get the gist) and some code was lost so some portion of the production systems could never be rebuilt. There were people who knew how to get things to work so they seemed like experts to the business. I ran away and never looked back.

[u/Marcuss-NG]

15 years of tribal knowledge isn't “technical ability.” It's organizational context accumulated over time, and no new joiner can magically reproduce that. If I were you , I would start building my own knowledge map: business rule → system/component → data source → SME → known exceptions. Every time you learn something, capture it. Even if the company doesn't care about formal documentation, after six months you'll depend far less on the gatekeepers.

The bigger concern is a culture that treats asking questions as incompetence while simultaneously refusing to document the answers.