Getting started
What Junior T24 People Should Learn First
New T24 professionals often arrive to find a pile of module names, tool acronyms, and version numbers that all seem equally important. They are not. The fastest way to become useful is to learn the shape of the platform before you learn the fragments.
If you are new to T24, the first thing you will notice is that there is a lot of it. Modules, tools, versions, batch processes, interfaces, development environments, and a vocabulary that assumes you already know what everything means. Someone will hand you a list of acronyms and say "you will pick these up as you go," which is technically true in the same way that being dropped in the middle of the ocean means you will eventually learn to swim.
The natural instinct is to try to learn everything at once. Read the documentation. Memorise the commands. Understand every module. This instinct is wrong. Not slightly wrong — actively counterproductive. T24 is too large to learn from the outside in. You have to learn it from the inside out: what matters, what moves, and what tells you whether things are working or not.
This article is the order that works. It is not the only order, but it is the one that produces people who can actually help within a few months rather than people who can recite module names and still freeze when COB does not complete.
A better starting order
Before you learn any tool, any command, or any module detail, there are four things worth understanding first. They are not technical skills. They are mental models. But they are what makes every technical skill you learn later actually useful.
1. What business flow the system is supporting
T24 is not a collection of screens and tables. It is a system that moves money, records obligations, and tracks state through a lifecycle. Before you learn how to use a tool, understand what the business is trying to achieve with it. A transaction enters, gets authorised, gets processed, and ends up somewhere. If you understand that arc, every detail has a place to live.
Related reading
Five Things to Check Before Escalating a T24 Incident
The difference between a junior analyst and an experienced one is often ten minutes and a short checklist. Five questions to answer before you pick up the phone.
CareerHow to Position Yourself as a T24 Migration Specialist
The TAFC-to-TAFJ migration wave is still moving through the industry. Consultants who can credibly pitch migration expertise are commanding better contracts. The three knowledge layers, how to frame your experience, and the mistakes that make experienced people sound junior.
CareerThe T24 Interview Process: What They Actually Ask and What You Should Actually Say
A practical guide to interviewing for T24 roles — what the questions really mean, what answers actually work, and how to navigate the unique absurdity of T24 interviews.
2. Where control points and state changes matter
Most T24 incidents are state problems. A record is in the wrong status. A batch job expected a field to be populated and it was not. An interface picked up a file before it was complete. Understanding where state changes happen — and what healthy looks like at each point — is more valuable than knowing twenty enquiry codes.
3. How support teams know what is healthy versus unhealthy
Every experienced T24 person has a mental checklist they run through when something feels off. They check the TSA service state. They look at the queue depths. They glance at the COB log. They know what normal looks like because they have seen it fail enough times. You can build that same checklist in your first few weeks — not by memorising it, but by watching and asking "what would tell you something was wrong here?"
4. Where data or processing moves next
When something completes successfully in T24, where does it go next? Does it sit in a queue? Does it write to a file? Does it trigger another process? Understanding the handoffs between components is what separates someone who can trace a problem from someone who can only react to symptoms. It is also the skill that makes you look like you have been doing this for years when you have actually been doing it for weeks.
Once you have those four mental models, everything else starts to attach to them. A command is no longer a random string — it is the thing you use to check the queue that feeds the interface that sends the file that the downstream system needs. Without the model, the command is just noise you have to memorise. With the model, it is obvious.
What to actually do in the first few months
Knowing what to learn is one thing. Knowing what to do on a Tuesday morning is another. Here are four actions that produce the fastest return.
Follow a transaction end-to-end before touching any tools
Pick one transaction type — a simple customer payment, a term deposit opening, a loan disbursement — and follow it from the moment it enters the system to the moment it settles. Do not worry about the tools yet. Just understand the path. Who creates it? Who authorises it? What happens during COB? Where does the money actually move? You will be surprised how much of T24 suddenly makes sense when you have one complete journey in your head.
Attend a COB cycle before being asked to support one
If you have never watched a COB run from start to finish, you are not ready to support it. Ask someone to walk you through the sequence: the pre-checks, the date rollover, the batch jobs, the post-processing, the completion. Watch what they check. Watch what they ignore. Ask what has failed before and what they look for first. A single COB observation is worth more than any documentation about what COB is. It is also the only way to learn that the COB log is not actually a log — it is a novel written in a language the author barely remembers, and you are expected to interpret it in real time.
Ask why before asking how
When you encounter something unfamiliar, the most useful first question is almost always "what is this for?" rather than "what command do I use?" Understanding the purpose of a tool or process before using it prevents a large category of mistakes — specifically the kind where you run a command that does exactly what you asked it to do and absolutely nothing like what you intended. T24 will let you do a lot of things. It will not stop you from doing the wrong one.
Build a short personal reference for what healthy looks like
What does the TSA service state look like when everything is running normally? What does the JBoss log show at a clean startup? What does the queue depth look like during a normal interface window? What does a normal COB duration look like for this environment? Those baselines take a few weeks to build up, but once you have them, detecting anomalies becomes much faster. More importantly, when someone asks you "is this normal?" you will have an answer that is not "I think so?" which is the technical equivalent of a shrug.
What not to worry about yet
Equally important is knowing what you can safely ignore in the first few months. The following things will matter eventually, but they are not where you should start:
- Every module name and purpose. You do not need to know what every T24 module does. You need to know the ones your environment uses. The rest will arrive when they become relevant, usually in the form of a support ticket that starts with "have you seen this module before?" and the answer is no, and that is fine.
- Every command-line tool. T24 has a lot of them. Learn the ones you use daily first. The others will appear when you need them, usually at 2am when the person who knows them is not answering their phone.
- The full history of TAFC versus TAFJ. You need to know which one you are running and what the practical differences are. You do not need to know the architectural history of the migration. That knowledge arrives naturally after your first "why does this work differently in TAFJ?" moment.
- Every possible failure mode. You will learn failure modes by encountering them. Trying to pre-learn them is like trying to memorise a map of a city you have never visited. You will forget most of it, and the parts you remember will be the wrong parts.
Why this matters
The strongest junior T24 professionals do not usually start by knowing the most. They start by building the right mental shape of the platform. That is what makes later knowledge stick. It is also what makes them useful faster, because they can reason about problems they have never seen before rather than waiting for someone to tell them which command to run.
There is a reason experienced T24 people can walk into a new environment and be productive within days while a junior with six months of training still struggles. It is not that the experienced person knows more commands. It is that they know what to look for, what to ignore, and what questions to ask. That is not experience — it is pattern recognition. And pattern recognition starts with understanding the shape of the system, not the details.
The bottom line
If you are new to T24, learn the flow before the fragments. Understand what moves, what changes state, and what support teams watch. Once you have that, the rest starts to make sense. Without it, you will spend your first year feeling like you are catching up — and you will be right.
The good news is that the learning curve is real but finite. The first few months are the hardest because everything is new. After that, new things start to look like variations of things you already understand. And one day, someone new will ask you "what should I learn first?" and you will realise you have become the person who knows what to look for. That is the moment it clicks. It happens faster if you start with the right shape.