The Technical Analyst Skill Matrix: 25 Skills, Five Hats, Three Levels
Written by Ahmed at Analyst Engineering, a Senior Technical Business Analyst with 10+ years in banking and payments delivery.
Key takeaways
- The Technical Analyst Skill Matrix defines 25 skills across the five analyst hats, business, functional, QA, developer, and systems, each at three levels: working, proficient, and the person the team asks.
- Score yourself one skill at a time against the level descriptions, not against a feeling. The output is a profile with peaks and gaps, not a grade.
- Level 3 everywhere is not the goal. Aim for Level 3 in your core hat, Level 2 in the two hats adjacent to it, and Level 1 everywhere else.
- If you are starting the technical skills from zero, the order that works is SQL, then reading an API contract, then one scripting language, then Git.
The Technical Analyst Skill Matrix is a self-assessment framework original to this site: 25 concrete skills across the five analyst hats, each defined at three levels, with a link to the guide that builds it. Score yourself honestly and you get a profile, the peaks, the gaps, and the next thing to learn.
The Technical Analyst Skill Matrix defines 25 skills across the five hats of the technical analyst role, business analyst, functional analyst, QA analyst, developer analyst, and systems analyst, each at three levels: Level 1, working (you can do it with guidance), Level 2, proficient (you do it independently on real deliveries), and Level 3, the person the team asks (you set the standard and others come to you). I built it from what I have actually had to do across 10+ years of banking and payments delivery, not from a competency framework, which is why every skill is concrete, testable, and linked to a practical guide on this site.
Use it in ten minutes: go skill by skill, compare your real evidence against the level descriptions, and write down a number. The point is not the total. The point is the shape: which hat is your peak, which adjacent skills are one push from Level 2, and which gaps are quietly limiting the work you can take on.
How do the three levels work?
Each level is defined by what you can demonstrably do on a real delivery, not by familiarity. Level 1 means you can perform the skill with guidance or on a simple case: you have done it, but someone senior would check it. Level 2 means you perform it independently on real, messy work, and your output is trusted without review. Level 3 means you are the reference: you handle the hardest cases, you improve how the team does it, and people bring you theirs.
Score 0 when you have never done the thing at all. Be strict about the difference between having read about a skill and having done it; this matrix measures the second one. A useful calibration: if you cannot point to an artifact, a test run, an incident, or a decision that proves the level, score the level below.
The Business Analyst hat: intent and scope
These five skills are about capturing what the business needs, bounding it, and keeping the delivery traceable to it.
| Skill | Level 1 looks like | Level 3 looks like | Build it |
|---|---|---|---|
| Requirements decomposition | Breaks a clear requirement into behaviors with help | Turns a vague, ambiguous ask into precise, testable requirements, and surfaces the decisions hiding inside it | From business requirement to functional spec |
| Scope and prioritization | Applies MoSCoW to a prepared list | Holds the line on what Must means with senior stakeholders, and drives calm scope cuts in a crisis | MoSCoW prioritization |
| Requirements documents | Fills in a BRD or FRD template | Chooses the right level of documentation for the risk, and writes documents each audience actually uses | BRD vs FRD |
| Traceability | Maintains an existing matrix | Runs impact analysis in minutes on a late rule change, and satisfies an auditor row by row | Requirements traceability matrix |
| Fit-gap analysis | Classifies requirements as fit or gap against a known system | Catches the partial fits that masquerade as fits, and pushes back on unnecessary customization | Fit-gap analysis |
The Functional Analyst hat: exact behavior
These five skills turn intent into behavior precise enough to build and test without interpretation.
| Skill | Level 1 looks like | Level 3 looks like | Build it |
|---|---|---|---|
| Functional specification | Writes the happy path from a template | Specifies complete behavior including every error path, grounded in observed system behavior | Functional specification template |
| Decision tables | Reads and tests against an existing table | Enumerates and collapses complex rule sets, and uses the empty cells to force requirement decisions | Decision tables |
| State machines | Follows a documented lifecycle | Models states, transitions, and illegal moves from the real system, and turns each illegal move into a test | State machines for payments |
| Reason code mapping | Looks up what AC04 means | Owns the cause-to-code-to-message chain end to end, and verifies the codes the system actually produces | Reason code mapping |
| Story versus spec judgment | Writes stories and criteria for simple features | Knows exactly when acceptance criteria are straining to be a specification, and writes the spec before it hurts | User story vs specification |
The QA Analyst hat: proof
These five skills prove the system behaves correctly, especially on the paths nobody designed for.
| Skill | Level 1 looks like | Level 3 looks like | Build it |
|---|---|---|---|
| End-to-end flow testing | Runs a happy-path payment through a wired environment | Follows one transaction through every hop, API, event, database, logs, callback, and finds the hop that lies | You don’t understand the system until you test it |
| Negative test design | Tests the obvious invalid inputs | Systematically applies boundaries, partitions, illegal transitions, and failure injection, and finds the defects that matter | Negative test design |
| API testing | Asserts status codes on the happy path | Tests the full contract: schemas, side effects, the whole error matrix, and idempotency under concurrency | API testing end to end |
| Event and Kafka testing | Checks an event exists with help | Validates schema, key, ordering, duplicates, and consumer side effects, and engineers the failure cases deliberately | How to test Kafka |
| Regression strategy | Re-runs a provided suite | Builds and automates a risk-based regression suite that grows with every defect and protects every release | Regression testing in payments |
The Developer Analyst hat: code as a tool
These five skills make every other skill faster, because you read the truth yourself instead of asking for it.
| Skill | Level 1 looks like | Level 3 looks like | Build it |
|---|---|---|---|
| SQL | Runs a provided query and reads the result | Answers any state question with joins and aggregates in minutes, and catches the schema truths the spec missed | SQL for analysts |
| Reading API contracts | Navigates a rendered Swagger UI | Reads any OpenAPI document fluently, references and all, and spots the contract-versus-behavior divergence | Reading an API contract |
| Scripting | Adapts an existing script | Automates end-to-end checks that chain APIs, query the database, and assert events, including concurrency tests | Scripting checks in Python |
| Git and the codebase | Browses files on GitHub | Uses diff, log, and blame to find when and why behavior changed, and reviews pull requests as a peer | Git for analysts |
| Reading production logs | Finds an error when told where to look | Traces any transaction by correlation id across services, and turns observability gaps into requirements | Reading production logs |
The Systems Analyst hat: the whole-system view
These five skills are about how the pieces connect, and where the connections break.
| Skill | Level 1 looks like | Level 3 looks like | Build it |
|---|---|---|---|
| System context diagrams | Reads an existing context diagram | Draws the boundary from scratch and surfaces the integration nobody scoped, on day one | System context diagrams |
| Integration patterns | Names request-response and messaging | Reads any integration’s coupling, latency, and failure modes from its pattern, and chooses patterns deliberately | Integration patterns |
| Timing models | Knows sync waits and async does not | Designs the sync front door on the async core, and specifies the seam where real-time meets batch | Synchronous vs asynchronous, batch vs event-driven |
| Payment message flows | Knows pain is customer-side and pacs is interbank | Maps a full flow from pain.001 to camt.053 from memory, and reasons about the transformations between legs | Payment message flows |
| Reconciliation and failure design | Investigates breaks in an existing recon | Designs matching keys, timing handling, break workflows, and DLQ controls that make failure safe and visible | Reconciliation design, dead-letter queues |
How should you read your profile?
Read your 25 scores as a shape, not a sum. Most working analysts peak in one hat, hold Level 2 in one or two adjacent hats, and have real gaps in the rest, and that is a healthy profile, not a failing one. The question the matrix answers is where your next investment pays most.
Three patterns are worth acting on. A strong hat with a weak neighbor: a Level 3 functional analyst with Level 0 SQL is specifying behavior they cannot verify, and SQL is the single fix. A missing proof layer: strong business and functional scores with weak QA scores means your requirements are precise but unverified, and the end-to-end testing skill converts precision into trust. All prose, no system: strong document skills across the first two hats with zeros across developer and systems skills is the classic non-technical BA profile, and it is the gap this whole site exists to close.
The target shape is deliberate: Level 3 in your core hat, Level 2 in the two hats your delivery work touches most, Level 1 everywhere else. Level 1 matters more than it looks, because knowing what a skill is and when it applies is what lets you call in the right person at the right moment instead of missing the problem entirely.
Where do you start if the technical hats are at zero?
Start with SQL, then reading an API contract, then one scripting language, then Git. That order works because each skill makes the next one easier and each pays off immediately on its own.
SQL comes first because querying state is the highest-leverage single skill: it converts you from someone who asks what happened to someone who looks. Reading an API contract comes second because the contract is the honest description of every integration you will ever specify or test. A scripting language comes third because it turns the checks you now know how to do into checks that run in seconds. Git comes fourth because the codebase and its history answer the questions the other three cannot. A focused few weeks on each, applied to a real system you already work on, moves all four from zero to Level 1, and daily use does the rest.
Re-score yourself against the matrix every six months. The profile changing shape is the honest measure that the investment is working, and the gaps that stay stubbornly at zero are telling you something about the work you are avoiding.
About the author
Analyst Engineering is written by Ahmed, a Senior Technical Business Analyst with 10+ years of banking and payments delivery experience: ISO 20022 and SWIFT messaging, payments API integration, Kafka event validation, and production support. Every article comes from real delivery work, and each one is reviewed and updated as tools and standards change.
Related articles
- What Is a Technical Business Analyst? The Five-Hat Discipline, Explained A technical business analyst analyzes, codes, tests, and supports. Here is what the role actually does day to day in banking and payments, and how to become one.
- SQL for Analysts: Query the State, Find the Truth The SQL a technical analyst actually needs: SELECT, WHERE, JOIN, GROUP BY, and reading state during analysis and testing. Not for reports, for finding the truth.
- You Don't Understand the System Until You Test It Why testing a payment flow end to end teaches you the system and the UX better than any diagram: microservices, Kafka, the database, logs, and pain.002.
- The Production Support Skills Nobody Teaches Analysts The production support skills that make a technical analyst invaluable: triage, tracing transactions, reading logs, calm under pressure, and turning incidents into requirements.
Newsletter
Subscribe
Practical, no-fluff playbooks for technical analysts who analyze, code, test, and support. New articles straight to your inbox.
No spam. Unsubscribe anytime.