·5 min de lectura

The ultimate feedback framework for SAP technical teams: drive excellence (not drama)

How to give (good) feedback that actually improves ABAP code, system performance, and project success—without fear and/or awkwardness.

How to give (good) feedback that actually improves ABAP code, system performance, and project success—without fear and/or awkwardness.

Everybody knows what feedback is but few apply it in the right/efficient possible way.

The problem:

You join a new SAP project. You notice an inefficient SELECT * inside a loop that’s slowing down a key transaction.

Do you...:

A) Stay quiet to “fit in,” (let's wait for the fire 🔥...)

B) Blurt out “This code is terrible,” or (I know, sometimes is difficult not say that 🤐)

C) Give feedback that’s actually adopted?

Most SAP consultants choose A or B.

Here I'll explain you how to master C.


Why feedback fails in SAP tech teams

We’ve all been there:

  • Code reviews that turn into SAP vs. non-SAP battles (Tech vs Functional are the classic)
  • Retrospectives where everyone says “It’s fine” (spoiler: it’s not)
  • Junior consultants who never speak up, even when they spot a major performance issue

The fix?

Structured feedback.

Not the fluffy HR kind—actionable tactics for SAP technical pros.

6 Reasons SAP Engineers should care about feedback

Kill legacy code: Stop repeating the same performance-killing mistakes all the time. I've seen code from the last century still running because it's easier to copy it and paste in a new program than create something useful from the scratch.

Speed up transport approvals: No more “Looks good 👍” comments that help nobody.

Build real leadership: Junior to Senior consultants get judged on how they uplift others. Be a helper, a real problem solver and your team will love you (ok that's too much or at least they'll feel good with you around).

Avoid go-live disasters: Fix misalignment before the system crashes in production.

Grow faster: Feedback = free (informal but effective) mentorship from your team.

Psychological safety > free SAP training: Trust beats perks for retention. We learn from mistakes if we're allowed to make them happen (but please not all the time).


The Framework (A mix stolen from Google, Netflix & SAP Best Practices)

Step 1: Set the Rules of the Game

  • Code reviews ≠ roasts: “Your ABAP logic is horrible” → “Let’s optimize this loop for better database hits.”
  • Blame the transport, not the person: “This query causes performance issues” > “You don’t understand HANA.”
  • Mandate reciprocity: If you give feedback, you must ask for it.

Step 2: Use the SBI Model (But Make It SAP-Specific)

  • Situation: “In yesterday’s BAPI implementation…”
  • Behavior: “…you used a SELECT * inside a LOOP…”
  • Impact: “…which increased response time by 40%. Using a JOIN or a FOR ALL ENTRIES would optimize performance.”

Pro Tip: Always attach a ST12 trace or SQL Monitor stats to support feedback.


5 feedback channels that work for SAP engineers

Transport review templates: Add a “Feedback” section requiring: [Situation] | [Behavior] | [Impact] | [Alternative Approach]

Pre-Go-Live checks: Before moving to PRD, make a standard to ask:

“What could break? How would we fix it?”

I always have a priority list sorted by impact/calamity/possible layoff.

SAP design review rotation: Rotate who leads architecture discussions.

This is not easy to handle for Junior at the beginning but eventually they'll get used to perform under pressure and they start to get more confidence in themselves.

The 5-min rule: Feedback must be actionable in ≤5 mins (no vague “improve performance” advice).

Don't waste people's time, it's precious.

Automate performance feedback: Use ATC (ABAP Test Cockpit) and Code Inspector alerts for recurring mistakes. But please, don't make it bureaucratic.


What SAP engineers hate (and how to fix It)

“Your ABAP is messy.” → ✅ “Let’s adopt ABAP cleaner & enforce naming conventions.”

Yeah... too politic but trust me it work.

“You don’t participate in meetings.” → ✅ “Could you present the CDS view strategy next sprint?”

Sometimes you have to act like a shepherd.

Public shaming. → ✅ **DM + Teams call. **

Don't be that person...


Real-world example from the trenches

The Performance Issue That Cost $$$

A team ignored feedback about a poorly optimized Fiori App report until this happened:

  • Situation: “Month-end processing took 5x longer in production.”
  • Behavior: “We used multiple SELECT * statements inside a LOOP instead of a single JOIN.”
  • Impact: “Delayed financial closing by 8 hours. Switching to an AMDP (ABAP Managed Database Procedure) reduced runtime by 70%.”

Result: Performance reviews became mandatory in all critical SAP transports.


Your action plan

Next retro or follow-up meeting, replace “What went wrong?” with “What’s one specific SAP performance/process improvement?”

Tag a teammate who needs this.

Don't make another useless retro, your future self will thank you.

🔥 Good to know:

Teams that master feedback optimize faster, argue less, and avoid expensive SAP downtime.

Teams using structured feedback have 51% fewer midnight BASIS calls (I don't have the sources but trust me on that one).