I'm a big fan of the Lazy Admin approach. Little did I know that its spiritual father was Kurt von Hammerstein-Equord, a German general and prominent Hitler opponent, who died much too soon.
He classified military officers as follows:
I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually, two characteristics come together.
- Some are clever and hardworking; they belong in the General Staff.
- The next are stupid and lazy; they make up 90% of every army and are suited for routine tasks.
- Anyone who is clever and lazy at the same time qualifies for the highest leadership roles, because they possess the mental clarity and the strength of nerve for difficult decisions.
- One must beware of anyone who is both stupid and hardworking; no responsibility may be entrusted to them, for they will always only cause mischief.
Spot on, Mr. Hammerstein-Equord, I completely subscribe to the same principle for SAP Consultants!
Problem is that, thanks to Mr. Dunning and Mr. Kruger, end-users (who hire SAP Consultants) can rarely tell the difference between a "clever" and a "stupid" consultant. Most end-users I've worked for don't employ resources to verify the quality of the work. They only care about whether the solution works or not (test results) and not how "clean" the code is, how well the solution is documented etc. In such an environment, the only thing the end-user can tell is if their consultant is "hardworking" or "lazy", by monitoring how much overtime they work.
Having said that, an end-user will usually spot the "stupid/lazy" persona as they simply don't get the job done. That's why you see so few of those around.
In my experience, most consultants fall in the "hardworking" category. You almost get the impression that they wear their overtime commitments as a badge of honor.
You need to look under the hood to tell the "clever" from the "stupid". Because code doesn't lie. I can tell which one you are in 5 minutes:
- a clever person leaves solid code. They follow the general recommendations of Clean ABAP - even if they don't know the concept explicitly. They follow SAP's best practices. In short, they follow the tried and tested smart ideas of other people and don't pretend to be smarter than them. That's why you immediately understand what they are doing and most importantly why they are doing it. In short, when you take over a clever person's code you can get working almost straight away.
- a stupid person's code is a nightmare to read. They are intellectually incapable of learning, not from others, not even from their own mistakes. Given that they already wear the job title "SAP Consultant", they think they are highly qualified for the job - and this is why they are so dangerous (especially if they are hardworking). It's like having a toothache and going to a dentist that only knows how to use pliers ... I could write a separate blog about the madness I've seen:
- Implicitly enhancing an SAP BAdI implementation instead of simply implementing the BAdI themselves. (And their explanation that "the enhancement implementation was already there!" didn't make it any better.)
- Thousands of lines of spaghetti code, dismissed with "we're consultants, it's our job to understand it"
- Doing an untested mass-data replication directly in production and not realising that you're blocking all background work processes for several hours (until Basis locks your user)
- My favorite example (this really happened!): On ticket save in C4C you want to update an external system and store a value that system returns. You're not clever enough to understand (or even know about) the standard integrations. So you create a custom WSDL on the Internet (as your target system doesn't provide one). But you realise that if you call it in BeforeSave and the save fails, you've confirmed a save that didn't happen. You're not clever enough to understand (or know about) workflow rules that are triggered 5 seconds after Save. So you do it at the end of OnSave. But in OnSave the ticket is read-only. So do you realise you've reached a dead-end and may need to ask for help or at least admit "it can't be done"? No! This is where the stupid/hardworking person shines! They take the challenge to BTP and contrive an architecture where they are writing the value to C4C using ODATA! As the ODATA update gets the job done, they don't care about returning a valid SOAP response to C4C. (Luckily those invalid response errors lead us to discover this iflow and replace it by a simple straight line combined with a workflow rule.)
As you can see, it is almost impossible for an end-user to tell whether a consultant is "clever/hardworking" or "stupid/hardworking" because they have no way of telling whether this is indeed an inherently complex problem or whether the consultant is simply not up to it.
What makes this even more tricky is that the SAP landscape has a bit of a gold rush mentality. With high hourly rates, it attracts a lot of people who try to compensate lack of skill with hard work to make money. It's actually a win-win, for them. They're paid by the hour, so they have no incentive of working more efficiently - overtimes simply means more money. End-users, if they see through this, often don't have a choice.
However, there are some absolute metrics end-users can watch for:
- does the consultant clearly explain the challenge they face? (clever people understand the problem, stupid people tend to stay vague)
- how often does the consultant face such challenges? (clever people rarely face them as they learn from their mistakes, stupid people tend to not care)
- does the consultant deliver their projects on time? (clever people know whether they're up for the job (i.e. they know what they can/can't do) and will give you an honest estimate, stupid people know that they're always up for the job (whether that's true or not) but have no clue how long it takes, so they'll regularly blow the deadline, fixing "unforeseen errors" doing overtime)
- Documentation! This, in my opinion, is the easiest way an end-user can distinguish a "clever" from a "stupid" consultant.
- Clever consultants document their implementation, the "clever/hardworking" persona because it's part of a good job, the "clever/lazy" persona because they don't want to debug if someone in two years asks how this was implemented.
- Stupid consultants either don't care (if they're lazy) or are afraid they are giving away knowledge - they are the masters of their own chaos and their job insurance is not the quality of their work but that the end-user needs them to support it
- as a last resort, ask yourself a simple question: If your computer at home crashed with a lifetime of photos/cherished memories on it - would you trust this consultant to help? Or would you be afraid they'd make things worse?
- Note: I strongly recommend against asking specific questions like "What are the 5 most important principles of clean ABAP?". A clever consultant may follow all clean ABAP principles intuitively but may never have heard the term "clean ABAP", while a stupid/hardworking person may have prepared well for an interview and be able to throw all the right buzz-words in your face. You're screening for attitude here, not skill, so the goal is to get an impression, not tick off a checklist of buzz words.
So, great! If you've followed my advice until here, you know who your "stupid" consultants are. They waste your work time, steal your free time (as naturally, they will contact you late at night, when they work) and degenerate your system at the same time. More often than not, they will eventually and after many test rounds get there. But their solution is most likely to resemble a house of cards rather than solid engineering. You do not want them around.
As a bonus, let's look into distinguishing between the "clever/hardworking" and the "clever/lazy" persona.
To do that, we need to clarify what "lazy" means in the clever sense: It doesn't mean that the consultant doesn't do their work. It simply means they prefer meaningful work. They hate repetitive tasks. And they know that manual tasks are error-prone. Their motto is: "If you hate it, automate it!". They are interested in a rock-stable system. Because if the system is unstable, they have to do constant overtime to fix issues. And the only thing they hate more than repetitive tasks is overtime. So they will design solutions that last. They won't settle for the "requirement", they want to understand the problem you're trying to solve because they want to provide you with the solution you need. They will actively advocate against unstable solutions. They will try to reduce a cutover list to the absolute minimum, relying on transports or scheduled scripts wherever possible. Think of this guy as the "architect" of your house. They'll point out from the beginning that you better move your veranda to the other side of the house to get more afternoon sun. Because they don't want to come back next year to tear up the house and relocate the veranda to the other side because they want to get it right the first time.
The "hardworking" persona also delivers excellent results but they are more within the box. Give them a task and they'll happily code away. The solution they build will be ready in time and work as expected. It will be technically sound and well-documented. However, they usually won't point out if there's a better way. They will write that custom report even though a standard report exists. Think of this guy as the "builder" of your house. They don't care if your veranda is facing East or West but they'll build a perfect veranda nonetheless. And if you realise next year that your veranda is on the wrong side, they'll happily tear down and rebuild - they don't mind the extra work.
To give you an example from my experience of hardworking/clever vs. hardworking/lazy: As enhancing standard integrations from C4C to S/4 (or ERP) is quite challenging, especially if you want to pass structured data, we decided to use ODATA to pull the data on S/4 inbound instead of trying to put it into the payload. Both a hardworking and a clever lazy person would have reached this conclusion (while the "stupid/hardworking" person would have contrived elaborate was of getting the data into the payload without realising that such an effort can only go so far). The "clever/hardworking" person now proceeds and implements a custom ODATA call to C4C in S/4 and delivers a working solution. The "clever/lazy" person immediately sees the potential for improving stability and saving effort in the future: By using ODATA $batch and a customizing table in S/4, we can keep the interface generic and reuse for future data retrievals! All we need is a customizing entry (for the ODATA query) and two lines of code. (Beware of the next stupid/hardworking person, though! They will not bother to understand how to use the generic interface. Instead, they'll complain that the interface "doesn't work" and proceed to either copy and paste what they need or simply create a new interface.)
Reflecting upon my own path, it's interesting to see how I progressed: Even before I started with SAP, when I built (coded) something, I wanted it to be solid workmanship. Solid walls instead of Potemkin village, architectural integrity instead of quick win, leaving the campground cleaner than I found it. That's me. So when I started as a Junior Consultant, I was naturally "stupid/hardworking" because I had had no prior exposure to SAP. So I read a lot, did a lot of debugging (to understand what others did) and tried to learn. That helped me become "clever". It was always natural for me to document my work, because otherwise I would forget what I just learned. And since I am a firm believer that stress and overtime lead to poorer (and not better) results , being the "clever/lazy" persona is not something I actively choose. It comes naturally if you:
- a) know what a stable system should look like,
- b) know your limits and
- c) are not afraid to say "I don't know".
To make the above distinctions, you have to put your ego aside, by the way. A stupid consultant reading this blog will most certainly think that they are really the clever type. Due to Dunning-Kruger, this is impossible to tell! And this applies to me as well, naturally. I'm very certain there are way more clever people than myself out there and that's why I'm constantly on the lookout for ways to make my work easier (the lazy type calling). What shows me that I'm on the right track, though, are two metrics:
- I can't remember the last time I had to do unplanned weekend or vacation work. This doesn't mean my solutions don't have bugs, but they are usually simple fixes (due to my architectural approach). And if it is a complex solution, I make sure to have a thorough UAT and an agreed contingency plan with the customer before we go live.
- I'm usually the one customers turn to with designing or implementing complex solutions. Because they know: When I do it, it just works. And if they read this article, they might now even understand why ... :-)
Note: Of course, the world is not black and white and there are a lot of gray areas. So even the cleverest people are sometimes stupid, even the most hardworking people are sometimes lazy. This blog is about the general idea. The truth is - as usual - somewhere in-between.
TL;DR:
The four types of military officers can be applied to SAP Consultants as follows:
- Clever/Hardworking: Your Builder. They don’t ask many questions but deliver excellent results - and if you change your mind 3 times in the course of the project, they happily follow along.
- Stupid/Lazy: Give them menial tasks with read-only access (e.g., basic monitoring). They are too lazy to do real damage.
- Clever/Lazy: Your Architect. They ask uncomfortable questions upfront to build the solution that you actually need, saving you from three rounds of changing your mind and letting them get on with the next job instead of firefighting at the eleventh hour.
- Stupid/Hardworking: They will work tirelessly to cause damage they don't even understand. Classic Dunning-Kruger. Keep them off your system.