Giving Feedback When You Are the New Analyst: Fresh Eyes Without Burning Bridges

Keep an observation log from day one and judge nothing for a while. Raise anything with regulatory, data protection, security, financial, or live production risk immediately. Hold everything else for a structured readout around day 30, by which time you will know which of your observations were real and which had a reason. Give feedback on artifacts as observation, evidence, impact, and suggestion, give feedback on behavior with Situation, Behavior, Impact, and ask for feedback on your own work at 30 percent rather than at 100.

Being new gives you something nobody else on the team has: you have not yet stopped seeing the strange things. The workaround that everyone runs every Monday, the Confluence page that contradicts the configuration, the test data that has not changed since 2022. In three months you will have stopped noticing all of it. Right now you can see it, and it is valuable.

It is also delicate. A new joiner who arrives and announces what is wrong in week two is not giving feedback. They are making enemies, and half the time they are wrong, because the strange thing has a reason they have not heard yet. This is part five of The First 90 Days, on how to turn fresh eyes into feedback that actually lands, and how to get useful feedback on your own work in return. It builds on part four, because most good feedback starts as a well-asked question.

Why does feedback from a new analyst matter?

Because the fresh-eyes window closes fast, and what you see in it is hard to see any other way.

Teams normalize their own friction. The manual repair step that takes operations two hours each Monday was a temporary fix three years ago. The regression suite that nobody trusts is run anyway because it is part of the release checklist. Nobody is negligent. People adapt to their environment, and after a while the environment becomes invisible.

A new analyst sees it because they have to learn it, and learning forces you to ask why. Many teams know this, which is why a good manager will ask you at your 30-day check-in what you have noticed. Have an answer ready, and make it a good one.

What is an observation log?

A private list of everything that surprises, confuses, or worries you, written at the time, with evidence, and with judgment deliberately postponed. Observe now, judge later.

#	Date	Observation	Evidence	My first reaction	Reason found?	Status
3	2025-10-05	Runbook and config disagree on AC04 handling	Runbook section 4.2; mapping config rule	Runbook out of date?	Yes: config changed in March, runbook not updated	Fix proposed, accepted
7	2025-10-08	Every cross-border test payment uses four free-text address lines	Test data repo, outbound pacs.008 fixtures	Risk for November 2026 CBPR+ structured address rule	Partly: data set predates the change; no story yet	Raised, see below
9	2025-10-09	Ops re-key some rejected payments manually every Monday	Shadowing session with operations	Automation candidate	Yes: vendor fix scheduled, workaround is deliberate	Closed, no action

The “Reason found?” column is the discipline. Observation 9 looked like an obvious improvement. It turned out to be a known, deliberate workaround with a vendor fix already scheduled. If I had raised it in week one as “we should automate this,” I would have spent credibility on something the team had already solved, and told them I had not done my homework. Most entries in a healthy log end up closed with a reason. The few that survive are the ones worth raising.

Keep it private. It is a working document, not an indictment. Some entries will be wrong, and the first-reaction column is supposed to be candid.

What should you raise immediately, and what should wait?

Two speeds. Anything in the first group, raise today. Everything else waits for the readout.

Raise immediately:

• Regulatory or scheme risk. A rule that is about to change and the system is not ready, a field required by a usage guideline that is not populated, a sanctions screening path that seems to skip a field.
• Data protection. Customer data in a place it should not be: a test environment populated from production without masking, a shared spreadsheet with real IBANs, screenshots with account details in a Confluence page.
• Security. Credentials in a repository, a shared admin account, an API token pasted in a chat channel.
• Financial loss. A reconciliation break nobody is looking at, a duplicate payment path, a missing idempotency check.
• Live production. Anything currently failing for customers.

For these, being new is not a reason to wait. It is a reason to be careful about how you raise it: privately, to your manager or the relevant owner, with the evidence, framed as a question. “I may be missing context, but I noticed X in Y; is this known?” A new analyst who notices a data protection issue and sits on it for a month to avoid looking pushy has made the worse mistake by far.

Hold for the 30-day readout: process friction, documentation quality, tooling preferences, meeting structure, naming conventions, ways of working, and everything you would describe as “we could do this better.” These benefit from time: you will understand more, you will have seen the pattern repeat, and you will have earned some trust.

How do you give feedback on a document, spec, or test case?

Four parts: observation, evidence, impact, suggestion. Leave out any of them and the feedback gets weaker.

• Observation. What you saw, stated neutrally. “The mapping spec maps creditor address to four AdrLine elements only.”
• Evidence. Where, exactly. A page and section, a field, a ticket key, a commit, a test case id. Evidence is what separates feedback from opinion, and a new joiner’s opinion carries little weight. Their evidence carries as much as anyone’s.
• Impact. Why it matters, in terms the team already cares about: a deadline, a defect, a customer, a regulator, a release.
• Suggestion. What you would do, offered rather than imposed. Often the best suggestion is a question: “Would it help if I drafted the structured mapping rows?”

A real example, as a comment on a functional spec:

Observation: Section 5.3 maps the creditor postal address to
AdrLine (up to 4 lines) only. No TwnNm or Ctry is populated.

Evidence: Section 5.3 rows 41 to 44; the outbound pacs.008 fixture
in the test repo shows the same pattern.

Impact: From November 2026, CBPR+ no longer accepts fully
unstructured addresses; structured or hybrid is required, with
town name and country at minimum in dedicated elements. Payments
built from this mapping could be rejected after that date.

Suggestion: I may be missing a parser step between the channel
and the hub. If not, I'm happy to draft hybrid mapping rows
(TwnNm, Ctry, remaining lines in AdrLine) for review.

Notice what the comment does not say. It does not say the spec is wrong, or that somebody should have caught this. It says what is there, where, why it matters, and how you can help. The public rule is in structured addresses, and the general method of reviewing a spec for gaps is in the blind spot review.

The same four parts work for test cases (observation: no negative case for a duplicate UETR; evidence: the suite; impact: duplicates reach the gateway; suggestion: a case per the idempotency testing pattern) and for user stories in refinement.

How do you raise something that might make the team look bad?

Make it a shared risk to solve, give the owners the first look, and let them own the fix. Here is how the address observation above actually went.

In my second week on a cross-border payments team in October 2025, I was reading the test fixtures for outbound pacs.008 to learn the message. Every single one used four free-text address lines. The November 2026 CBPR+ deadline for structured or hybrid addresses was about a year away, the migration plan said “addresses: in scope,” and I could not find a story, a test case, or a mapping row that implemented it.

It looked like a gap the team had missed. It was also exactly the kind of observation that, raised badly, makes a whole team look negligent in front of their stakeholders, and makes the new analyst who raised it very unpopular.

What I did, in order:

1. Checked my own understanding first. I reread the public rule, searched Confluence and Jira for “structured address,” “TwnNm,” and “hybrid,” and checked the channel to see whether addresses were captured in structured fields upstream. They were not.
2. Asked, privately, as a question. To the QA lead, who owned the fixtures: “I noticed our pacs.008 fixtures all use unstructured addresses. Is structured address work planned somewhere I haven’t found yet?” The answer: it was known at programme level, planned for a later phase, and nobody had linked it to the test data or the mapping spec yet.
3. Took it to my manager with the evidence and a suggestion, not a verdict. “This seems planned at programme level but not yet in the mapping spec or the test data. Given the date, it might be worth pulling forward. I can draft the mapping rows and some structured and hybrid test fixtures.”
4. Let the team own the fix. The QA lead raised it in the next planning session. I drafted the rows. Nobody had to explain to a stakeholder why the new person found it.

The outcome was a story pulled forward, test fixtures for structured, hybrid, and unparseable addresses, and a QA lead who brought me into the next three reviews. The observation was identical either way. The way it was raised decided whether it built trust or spent it.

How do you give feedback about people?

Rarely in your first month, and when you do, with Situation, Behavior, Impact (SBI): one specific moment, the observable behavior, and its effect. Never a trait.

• Situation: “In Tuesday’s refinement on the returns story…”
• Behavior: “…the acceptance criteria changed after the developers had estimated…”
• Impact: “…so the estimate no longer matched the work, and the story came back to refinement on Thursday.”

Compare that with “refinement is chaotic,” which is a judgment, gives nobody anything to act on, and puts the listener on the defensive. SBI is also the best way to give positive feedback, which new joiners give far too little of. “In the incident on Wednesday, you posted the UETR and the timeline in the channel within ten minutes, and it meant operations could answer the customer before the second call” is specific, credible, and remembered. Positive feedback is also how you earn the right to give the critical kind later.

How do you ask for feedback on your own work?

Early, specifically, and explicitly. The habit that matters most is showing work at 30 percent.

A draft shown at 30 percent gets direction: “wrong structure,” “we already have a page for that,” “operations will never read a spec, give them a table.” A finished document shown at 100 percent gets defended, by you, because you have invested in it, and by the reviewer, who now has to choose between rework and polite approval.

The asks that work:

• Attach a specific question to every draft. Not “any feedback?” but “is a decision table the right format for the AC04 and AC01 routing rules, or does the team prefer the mapping spreadsheet?”
• Ask for one thing to change. “If you could change one thing in this, what would it be?” is easier to answer honestly than “what do you think?”
• Ask more and less after your first deliverable. “What should I do more of, and less of?” Ask your manager, and ask one peer.
• Ask how the team reviews. Comments on the page, a review meeting, a pull request on a docs repository. Use their mechanism, not yours.

Templates make this easier, because a reviewer can comment on structure in seconds when the structure is familiar. Real-World BA Deliverables gives you twenty proven structures to start a draft from instead of a blank page.

How do you take critical feedback when you are new?

Say thank you, ask one clarifying question, and change something visibly. Do not explain in the moment.

The instinct when a reviewer says your mapping spec is wrong in three places is to explain why you wrote it that way. Resist it. Your reasoning matters less than whether the reviewer is right, and you cannot judge that in the moment. Thank them, ask for one example if the point is vague (“can you show me one row where the source field is wrong?”), and come back with the change. If, after checking, you still think you were right, come back with evidence, and keep it about the artifact.

Then close the loop. “You mentioned the decision table was hard to follow; I split it into inbound and outbound, does that work better?” Closing the loop is what turns a reviewer into an ally, because it shows their time was not wasted.

How do you structure a 30-day readout?

Short, written, and balanced. Ask your manager whether they want it one to one or with the team, and keep it under thirty minutes.

1. What I have learned. Two or three sentences per area: the domain, the system, the team. This shows the onboarding is working.
2. What works well. Real, specific strengths, with SBI-style examples. Not flattery: things you would protect.
3. Observations worth discussing. The three to five surviving entries from your observation log, each with observation, evidence, impact, and suggestion. Ranked by impact. Each one framed as “worth discussing,” not “what is wrong.”
4. What I will focus on next. Your plan for days 31 to 60, ideally with one of the observations as your own next deliverable.
5. What I need. Access, introductions, time with a specific person.

The readout is also a mirror of the 90-day review, where you will show what changed. Observations you raised at day 30 and fixed by day 90 are the strongest evidence of an onboarding that worked.

How does feedback look different by role?

• Business analysts give most feedback on scope, process, and stakeholder alignment, often to the product owner. See onboarding as a business analyst.
• Functional analysts give it on specs and rules, where the observation, evidence, impact, suggestion format is the whole job. See onboarding as a functional analyst.
• QA analysts give it on test coverage and quality signals, and should read working with QA for the relationship side. See onboarding as a QA analyst.
• Developer and systems analysts often give it in pull requests and design reviews, where evidence is a line of code or a sequence diagram. See onboarding as a developer analyst and as a systems analyst.

The takeaway

Fresh eyes are an asset with a short shelf life. Keep an observation log from day one and judge nothing until you have looked for the reason. Raise regulatory, data protection, security, financial, and production risks immediately and privately, as questions with evidence. Hold everything else for a 30-day readout. Give feedback on artifacts as observation, evidence, impact, and suggestion, and on people with Situation, Behavior, Impact, starting with the positive. Ask for feedback on your own work at 30 percent, with a specific question, and close the loop every time.

Next in The First 90 Days: the role-specific guides, starting with onboarding as a business analyst. The series closes with the 90-day review, where your observation log becomes the evidence that your onboarding worked.

For the structures that make your drafts easy to review, Real-World BA Deliverables has twenty templates from real banking projects. To draft feedback comments, readout notes, and the follow-up email that closes the loop, The Tech BA Prompt Toolkit has the prompts. If you are facing a delicate one, a spec you think is wrong or a readout you are nervous about, a 1:1 coaching call is a working session on exactly that situation.

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, Feedback, Business Analysis, Communication, ISO 20022