A cheat sheet of the corporate language used in MNCs—from KT and BAU to CAB and RCA—that nobody teaches you in tutorials.
When I started my software engineering career, I thought learning React, Next.js, JavaScript, Git, APIs, and deployment was enough.
Then one day I was talking to a senior engineer from an MNC.
In the middle of the conversation, he casually said:
"We'll complete the KT first, then after the reverse KT we'll move to BAU. The CAB approval is pending, so the Go-Live has been pushed. If anything breaks, we'll open a bridge call and perform RCA."
I understood... almost nothing.
Not because I wasn't a developer.
Because nobody teaches the language of corporate software engineering.
Every company—whether it's TCS, Infosys, Capgemini, Accenture, Cognizant, Deloitte, IBM, HCLTech, or Wipro—uses these terms daily. They're part of meetings, emails, Jira tickets, production support, and client conversations.
This guide is the cheat sheet I wish I had on day one.
The process where an existing developer teaches another developer about the project.
Usually happens when:
Example:
"Your KT starts tomorrow."
Translation:
Someone will teach you the project.
After learning the project, you explain it back to the trainer.
This confirms you've understood everything correctly.
Example:
"Reverse KT is scheduled for Friday."
After the KT is complete, you officially become responsible for the application.
Example:
"KT is complete. You're taking ownership from Monday."
Regular maintenance work after a project is live.
Typical BAU work includes:
The day software is released to production.
Example:
"Go-Live is planned for Saturday night."
The support period immediately after Go-Live.
The team closely watches the application for issues and responds quickly if something goes wrong.
The live application used by real customers.
Never experiment here.
Where developers build new features.
Used by testers before deployment.
A near-identical copy of production used for final verification.
The client or business team tests the application before approving it.
Example:
"Waiting for UAT sign-off."
Testing multiple applications or services together.
A quick health check after deployment.
Question being answered:
"Did the application start correctly?"
Focused testing of the feature or bug that changed.
Issue priorities.
If someone says:
"We have a P1."
Everything else usually stops.
Defines how quickly issues must be resolved.
Example:
(Exact times vary by company.)
Not just fixing a bug.
Finding why it happened.
A proper RCA answers:
A group responsible for approving production changes.
Many enterprise companies won't let you deploy until CAB approval is complete.
Formal approval to modify production.
An emergency conference call during production incidents.
Developers, DevOps, QA, managers, and clients may all join.
A dedicated meeting where everyone works together to resolve a critical issue.
Think of it as a bridge call focused entirely on solving one major problem.
Reverting a deployment because something went wrong.
Formal approval from the client, QA, or business team.
No sign-off.
No release.
Offshore
Teams working from another country.
Example:
India.
Onsite
Developers working directly at the client's office.
Example:
USA, UK, Germany, Australia.
An employee currently not assigned to any client project.
Being on the bench often means you're available for training, interviews, or upcoming projects.
Work the company can charge the client for.
Internal work.
Examples:
Represents one full-time employee allocation.
Example:
"We need two FTEs for this project."
A record of how many hours you worked and on which tasks.
Many service companies require employees to fill this every week.
The percentage of your working time spent on billable client work.
High utilization generally means you're actively contributing to client projects.
EOD
End Of Day
COB
Close Of Business
You'll often receive messages like:
"Please send the report by EOD."
Estimated Time of Arrival.
In software, it usually means:
"When will this task be finished?"
Out Of Office.
Commonly used in email status or chat.
Paid Time Off.
Vacation or approved leave.
Loss Of Pay.
Unpaid leave.
An urgent fix deployed directly to production to solve a critical issue outside the normal release cycle.
The cost of choosing an easy, fast solution now instead of using a better approach that would take longer. Like financial debt, you eventually have to "pay it back" by refactoring the code.
Automated pipelines that build, test, and deploy code whenever a developer pushes changes to a repository.
A project management methodology that focuses on delivering work in small, continuous increments rather than one massive release (Waterfall).
A short, time-boxed period (usually 2 weeks) where a specific set of work must be completed.
Daily Status Update. A quick 15-minute meeting where team members share what they did yesterday, what they'll do today, and if they have any blockers.
Something preventing a developer from continuing their work. (e.g., "I'm blocked waiting for the API credentials.")
A meeting where the team reviews upcoming tasks, discusses requirements, and estimates how long they will take.
The most basic version of a product that can be released to gather user feedback.
A small, throwaway project built just to prove that a certain technology or idea will actually work before committing to building it fully.
Testing the entire application after a new feature is added to ensure that the new code didn't accidentally break existing features.
A formal request to merge your new code into the main codebase. This is where Code Reviews happen.
Being assigned to be available (often carrying a pager or phone) to respond immediately to production issues, even outside of regular working hours.
A large company-wide or department-wide meeting where executives share business updates, financial results, and future goals.
A quick informal meeting to align on a topic or get a status update.
Example:
"Let's touch base on the deployment plan."
Imagine this conversation in an MNC.
Manager:
"The KT starts tomorrow. Complete the reverse KT by Friday. We'll move you to BAU next week. CAB approval is pending for Saturday's Go-Live. Please be available during Hypercare. If production fails, we'll open a bridge call and prepare the RCA."
If you've never heard these terms, that sentence sounds intimidating.
After reading this guide, it translates to:
Learning React, Next.js, JavaScript, or any programming language is only one part of becoming a software engineer.
The other part is learning how software is built, released, supported, and discussed inside real organizations.
These corporate terms aren't just buzzwords. They're part of everyday conversations in meetings, Jira tickets, Slack messages, emails, production support, and client calls.
Once you understand them, you'll feel more confident in interviews, communicate better with senior engineers, and navigate enterprise environments without feeling lost.
If you're early in your career, start keeping your own glossary. Every time you hear a new acronym in a meeting, write it down, look it up, and add it to your list.
Over time, you'll realize you're not just learning new words—you're learning how the software industry actually operates behind the scenes.