What I'd Tell Myself on Day One in SAP
The skills that matter, the ones that don't, and the meetings you should skip
Early career — present
The Years, In Order
Here's what's worth saying out loud that isn't generic enough to ignore.
The 5-Year Rule (and the Mistake Worth Avoiding)
Early in a career, it's tempting to add FI. Then CO. Then some MM exposure for good measure. The resume looks well-rounded. The consultant behind it usually isn't — maybe 25% effective across four modules instead of genuinely dangerous in one.
Staying in one module a few years longer and becoming the person the project manager calls at 11pm when a pricing procedure is wrong beats chasing breadth, even though breadth looks like ambition on paper. Undoing that mistake later costs real years — developing the depth that should have been built early takes much longer once it's deferred.
Depth before breadth. Five years minimum in one module before deliberately expanding. Breadth is a complement to depth, not a substitute. The "broad consultant" play makes sense later in a career. Early on, it just means being the first replaced by someone who actually knows what they're doing.
The Status Email Formula
Writing a status email that a CFO and a basis consultant can both read and both find useful is a skill. It is not obvious. It is not taught anywhere. And the gap between people who can do it and people who can't is visible on every project.
A format that holds up over time:
Line 1: [GREEN / AMBER / RED] — one sentence explaining why.
This week: Three bullets. Past tense. Factual. No editorializing.
Action required: [Name]: [specific ask] by [date]. One line per person.
If it's longer than a page, you're writing a report, not a status. If someone has no action item, remove them from the To: line. Projects with 40 people CC'd on every status email are not applying this rule.
The discipline is in the last part. Naming a specific person with a specific ask by a specific date feels aggressive until you realize that vague action items never get done. "Team to review by end of week" is not an action item. It's a wish.
The Meeting You Should Actually Skip
Sitting in steering committees as "technical representation" is a common assignment, and the actual contribution in most of those meetings is often zero. Not low — zero. The decisions happen at a level where the technical input isn't relevant, and the time gets spent being a warm body so the attendee list looks thorough.
The meeting that's always safe to skip is the one where the honest answer to "what decision did I make or what did I contribute that couldn't have happened without me?" is "I updated people on things they could have read in the status email."
The meetings worth protecting are different. Technical architecture sessions where expertise shapes a decision that will still matter in three years. Working sessions translating between a business stakeholder and a developer in real time, where the translation is the whole value. Retrospectives where the team's process actually changes as a result.
Everything else is overhead dressed up as participation.
The political version of stepping back: you can't just stop showing up. A line that tends to work is, "I can make better use of that time preparing the technical analysis you'll need for the decision. Would it be alright if I joined only when there's a technical decision on the agenda?" It rarely gets refused. Most project managers are relieved — they didn't want to invite you, they just assumed you expected to be there.
The Business Conversation Worth Having
Early in a career, on a manufacturing client's SD implementation, the configuration was second nature. Pricing procedures could be built in one's sleep. What wasn't obvious was that the reason the client had three different sales organizations wasn't a legacy data problem — it was a deliberate margin isolation strategy, designed that way by the CFO. Proposing to consolidate them for cleaner order management nearly created a reporting problem that would have masked which product line was dragging down the company.
That came out not from project documentation but from a finance business analyst who gave the warning after a design review: "You should probably understand why that structure exists before you change it." Weeks of configuring the system had gone by without understanding the business reason for its most important design decision.
The BW consultant who understands supply chain beats the one who only knows BEx. Not because supply chain knowledge makes them a better BW consultant technically — it doesn't. It makes them a better consultant for the business, which is what determines trajectory in this field. The technical skill gets you in the room. The business understanding determines how long you stay there and whether you get called back.
"The SAP ecosystem is full of technically exceptional people who plateau because they can configure anything but can't explain why the configuration decision matters to the VP of Operations."
Building this is deliberate and slow. On every project, find one business stakeholder who will tolerate questions and ask them to explain the process being configured as if nothing were known about it. Read the annual reports of the companies being worked for. Understand the P&L impact of the systems being built. It takes years. It's the investment that makes the later part of a career look completely different from the beginning.
Two Things That Took Too Long to Learn
The career advice worth hearing isn't technical. The technical stuff gets figured out. It's everything underneath it — how to ask the question in week one, how to pick one thing and go deep before going wide, how to write an email that a CFO and a basis consultant can both use, how to walk out of the meeting that isn't worth the time. Those are the skills that stand out first when watching someone who's going to be exceptional.