Asking the Right Questions in a New Team: Who to Ask, What to Ask, and When

Ask fewer, better questions to the right people at the right time. Map who knows what before asking anything, run a short 1:1 with each key person in the first two weeks using the same script, phrase every specific question as “I checked X and Y, I think Z, can you confirm or correct,” batch questions by person instead of interrupting, and log every answer so you never ask the same thing twice. The fastest analysts to onboard are not the ones who ask the most. They are the ones whose questions cost a colleague one sentence to answer.

Every new analyst is told “ask anything, there are no stupid questions.” It is kindly meant and slightly untrue. There are no stupid questions, but there are expensive ones. “How do payments work here?” costs a senior developer forty minutes and teaches you less than an hour with the system context diagram would have. “When a pacs.002 RJCT with AC04 comes back from the correspondent, does our system generate the customer notification automatically, or does operations do it from the repair queue?” costs them one sentence, and it tells them you have done your reading.

This is part four of The First 90 Days. Part two covered how to read what the team wrote, and part three how to use AI to turn it into a questions list. This part is about taking those questions to real people: who to ask, how to phrase it, when to ask, and what to do with the answer.

Who should you ask when you join a new team?

Build a knowledge map before you ask anybody anything specific. On a payments team, knowledge is not evenly distributed, and the org chart tells you almost nothing about where it sits.

Here is the map I build in week one on a cross-border payments or ISO 20022 migration team. The roles are generic; every bank has them under different names.

Person	What they know that no document says	Ask them about	Do not ask them about
Payments operations lead	What actually happens to the payments that fail: the repair queue, manual workarounds, the customer calls	Exceptions, volumes, month-end, which reason codes they see most	Code, architecture
Product owner	Why the work exists, what was promised to whom, what is out of scope and why	Priorities, deadlines, stakeholders, the regulatory driver	Field-level mapping
Lead developer	How the system really behaves, including what the spec says it does not	Where rules live in code, known defects, technical debt	Business priorities
QA lead	What has broken before, what the regression suite covers and what it does not	Test environments, test data, defect history	Commercial decisions
Compliance or sanctions analyst	Which rules are non-negotiable and why	Screening, data retention, regulatory reporting fields	Delivery dates
The long-tenured SME	History: why it was built this way, what was tried and abandoned	”Why” questions, legacy behavior	Anything they are visibly tired of explaining; read first
Whoever is on the support rota this week	What broke this week, live	Current incidents, recent alerts	Long design discussions during an incident

The last two rows are the ones new analysts skip. The SME who has been on the team for twelve years holds the reasons behind decisions that nobody wrote down. The person on the support rota holds what is breaking right now, which is the most current and honest description of the system you will ever get. Ask your manager on day one who each of these people is, and whether you can shadow the support rota for a few days. Production support skills for analysts explains why that week teaches you more than any walkthrough.

What should you ask in your first 1:1s?

Run a 20 to 30 minute introductory 1:1 with every person on your map in the first two weeks, and ask everyone the same seven questions. Asking the same questions is the trick: the overlap and the disagreements between answers are as informative as the answers themselves.

1. What do you own? Not the job title, the actual things: systems, decisions, documents, queues.
2. What do you wish new joiners understood earlier? People have usually thought about this, and their answer is often the most useful sentence of the week.
3. What breaks most often, and how do you find out? Alerts, a phone call from operations, a reconciliation break the next morning. How they find out tells you where the monitoring gaps are.
4. Which document do you trust, and which do you ignore? This builds your documentation trust map from part two in a single question.
5. What is the thing everyone assumes and nobody has checked? Not everyone will answer. The ones who do will give you a risk.
6. Who else should I talk to? This extends your map with names the org chart does not show.
7. How do you prefer to receive questions? Chat, a batch in a weekly slot, a comment on the page, a ticket. Then honor it.

Take notes in the meeting and send nothing back except a thank-you. The notes go into your onboarding pack. Within two weeks you will have six or seven versions of “what breaks most often,” and if four of them mention the same thing, that is the team’s real risk, regardless of what the risk register says.

How do you phrase a question so it is quick to answer?

Use the format: I checked X and Y, I think Z, can you confirm or correct?

It does three things. It shows the work you did, so the answer can start where you stopped. It gives the person a hypothesis to confirm, which is a one-word answer when you are right. And when you are wrong, the shape of your wrong hypothesis tells them exactly which misunderstanding to correct.

Compare these pairs from real ISO 20022 onboarding situations:

Expensive question	Cheap question
How do payments work here?	I traced one outbound payment in the test environment from the channel to the gateway. I think the pain.001 is converted to pacs.008 in the payment hub, not the channel; is that right?
How do we handle rejections?	The runbook says AC04 rejections from the correspondent go to the repair queue, but the mapping config seems to send them to auto-notification. Which is current?
What is the deal with addresses?	I see our test data uses four free-text address lines only. With CBPR+ requiring structured or hybrid addresses from November 2026, is there a parser between the channel and the hub, or is that not built yet?
Do we use UETR?	Our pacs.008 mapping generates the UETR in the hub. If a customer asks for a payment trace, do operations search by UETR or by our internal reference?
How does the cut-off work?	The product page says the cross-border cut-off is 15:30 local time. Does that apply to the time the customer submits, or the time the hub releases to the gateway?

The right column takes longer to write. That is the point. Writing it forces you to do the reading and the testing first, and in about a third of cases you will answer your own question while writing it. How a technical BA investigates a failed payment shows the evidence-first habit that sits behind good questions, and the status and reason code background is in payment status codes and reason codes.

If you struggle to turn a vague doubt into a precise question, an AI assistant is good at exactly this, as long as you give it your notes and ask for the question, not the answer. The prompt is in part three, and a full library of question-sharpening prompts is in The Tech BA Prompt Toolkit.

When should you ask, and when should you look it up first?

Use a simple triage. Every question gets one of three treatments.

• Ask now. The question blocks work someone else is waiting on, carries regulatory or data risk, or concerns something live in production. Do not sit on these to look self-sufficient. A new analyst who spots a sanctions screening gap on day six and waits until day thirty to mention it has made a serious mistake.
• Try for 15 minutes first. The answer is probably in a document, the code, the test environment, Jira history, or Confluence search. Give it a fixed fifteen minutes. If you find it, log the answer and the source. If not, the question goes into the batch, now with “I checked X and Y” attached.
• Batch it. Everything else goes into a list per person, taken to an agreed slot.

The fifteen-minute rule protects both sides. It stops you from interrupting people for things you could find, and it stops you from spending a whole afternoon reverse-engineering something a colleague would explain in a sentence.

How do you batch questions without being a nuisance?

Agree a slot, keep a budget, and send the questions in advance.

With the two or three people you need most, usually the lead developer, the operations lead, and the product owner, ask for a recurring 20-minute slot for the first month: twice a week with the developer, weekly with the others. Before each slot, send the questions in writing, in the format above. Many will come back answered in chat before the meeting, which frees the slot for the hard ones.

Keep a budget of around five questions per person per slot. If you have twelve, rank them by how much each answer unblocks and send the top five. The remaining seven often answer themselves as you learn, and the discipline of ranking makes you notice which questions actually matter.

The calendar view of a good first month looks like this:

Week	Developer	Operations	Product owner	Everyone else
1	Intro 1:1	Intro 1:1	Intro 1:1	Intro 1:1s, shadow support rota
2	2 x 20 min, 5 questions each	20 min	20 min	Follow-ups in chat
3 to 4	2 x 20 min	20 min	20 min, priorities and scope	Ask in their preferred channel
5 onward	Drop to weekly or ad hoc	Ad hoc	Normal refinement cadence	Normal

When the slots stop being needed, say so. “I think I can drop to weekly now” is one of the best things a busy developer can hear from a new analyst, and it is a visible marker of your onboarding progress.

Which questions reveal the unwritten rules?

Questions about failure, exceptions, and history. Process questions get you the documented process. Failure questions get you the real one.

These are the questions that have taught me the most in my first month on a payments team:

• What breaks every month-end? Volumes spike, batch windows tighten, and reconciliation runs under pressure. Every payments system has a month-end story.
• Which payments go to the repair queue, and why? The answer is a list of the rules the system cannot apply automatically. In ISO 20022 migrations that list typically includes addresses that cannot be parsed, missing creditor agent identification, and remittance that does not fit downstream systems.
• What was the last incident, and what changed after it? If nothing changed, you have found a risk.
• What would you never let a new person change? People answer this instantly, and the answer is usually a configuration table, a mapping rule, or a batch schedule with a history behind it.
• What does the documentation get wrong? Asked directly and casually, this gets surprisingly honest answers.
• Which customer or correspondent behaves differently from the rest? There is always one: a correspondent that sends a reason code nobody else uses, or a corporate customer whose files always need manual work.
• When did this last fail in a way nobody noticed for a while? The answers point you to the gaps in monitoring and reconciliation, which is where reconciliation design earns its keep.

What questions should you avoid?

Some questions cost more than the answer is worth, or cost goodwill:

• “Why did you build it like this?” in a tone that implies it was wrong. Ask “what constraints shaped this?” instead. The answer is usually a regulatory deadline, a vendor limitation, or a decision made with information you do not have.
• Questions answered by the document you were sent yesterday. Read first. Using the fifteen-minute rule prevents most of these.
• The same question to two people to see if they agree, without telling them. If you need a second opinion, say so openly: “the runbook and the config disagree; I asked the developer, and I want to check the operations view.”
• Design debates during an incident. If the support rota is handling a live problem, your question about the long-term architecture can wait.
• “Can you explain the whole system?” Nobody can, in a meeting. Ask for the system context diagram and one end-to-end walkthrough of a single payment instead.

How do you keep track of the answers?

In a questions log: one table, one row per question, kept from day one.

#	Question	Asked	Answer	Evidence	Date	Documented?
14	Does an inbound AC04 trigger an automatic customer notification?	Lead dev	Yes, since the March release; the runbook is out of date	Mapping config, rule RC-AC04	2025-10-07	Runbook update raised
15	Is the 15:30 cut-off on submission time or release time?	Product owner	Submission time in the channel	Product page plus channel config	2025-10-08	Added to glossary
16	Do test payments ever use structured addresses?	QA lead	Not yet; test data set predates the CBPR+ change	Test data repo	2025-10-08	Raised in feedback log

The Evidence column is what turns an anecdote into a fact you can rely on later. The Documented column is how you pay the team back: every answer that existed only in someone’s head becomes a line in a glossary, a runbook fix, or a Confluence comment. A question asked twice, by you or the next new joiner, is a documentation defect, and the log is the list of defects to fix. Row 16 in the example became the subject of a careful piece of feedback, which part five walks through.

Keep the log where the team can see it if the culture allows, for example a Confluence page under your name or a simple Jira filter. If you use Jira for this, Jira for Business Analysts shows how to set up a lightweight issue type and filter that does not clutter the team board.

How does this change by role?

The method is the same; the people you lean on change.

• Business analysts spend most of their question budget with the product owner and operations, on scope, priorities, and the exceptions process. See onboarding as a business analyst.
• Functional analysts need the lead developer and the mapping spec owner, on which rules the system actually enforces. See onboarding as a functional analyst.
• QA analysts start with the QA lead and the defect history, on environments, data, and what the suite does not cover. See onboarding as a QA analyst.
• Developer analysts ask the developers about the repository, the logs, and data access, and need far fewer meetings if they can read the code. See onboarding as a developer analyst.
• Systems analysts need the architects and the owners of each interface. See onboarding as a systems analyst.

The takeaway

Map who knows what before you ask anything. Ask everyone the same seven questions in the first two weeks. Phrase specific questions as “I checked X and Y, I think Z, can you confirm or correct,” triage them into ask now, try first, and batch, and keep a budget of around five per person per slot. Ask about failure and history to find the unwritten rules. Log every answer with its evidence, and turn every answer into documentation so the next person never has to ask.

Next: part five, giving feedback when you are the new analyst, where some of those answers turn into things you need to raise. The whole series is on The First 90 Days, and the question-sharpening prompts are in part three.

If you are joining a payments or banking team and the domain is what generates most of your questions, Break Into Banking explains how payments, core systems, and regulated delivery actually work, so your first questions are about your bank rather than about the industry. For the prompts that turn messy notes into sharp questions, see The Tech BA Prompt Toolkit. And if you want to practise investigating a system you have never seen before, the Labs drop you into Northline Pay, a fictional payments platform, with a contract, events, logs, and a database to question.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Onboarding, Business Analysis, Communication, Stakeholder Management, Payments