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 open about his opposition against Hitler and the Nazi regime.
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.
What makes it almost impossible for an end-user to tell whether a consultant is "clever/hardworking" or "stupid/hardworking" is that the end-user has no clue whether this is a legitimately difficult problem to solve 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 digger mentality. With high hourly rates, it's not the brightest but slickest who win. So end-users often don't have the luxury of comparing clever and stupid consultants against each other.
However, there are some absolute metrics the end-user 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)
- Documentation! This, in my opinion, is the easiest way an end-user can distinguish a "clever" from as "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 broke down with a lifetime of pictures/cherished memories on it - would you trust this consultant to help? Or would you be afraid they'd make things worse?
So, great! If you've followed my advice until here, you've ruled out the stupid/hardworking as well. You don't want stupid/hardworking people. They essentially waste your time, steal your free time (as naturally, they will contact you late at night, asking you to test etc.) and deliver poor results. Due to their hard work, 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.
The cherry on top is 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 job. It means that 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. 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 think outside the box and point out that you better move your veranda to the other side to get more afternoon sun.
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. Thinks 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.
Reflecting upon my own path, it's interesting to see how I progressed: I started at "stupid/hardworking" (when I was a Junior Consultant and had no prior exposure to SAP). I always read a lot, did a lot of debugging and tried to understand the system. That helped me become "clever". I always documented my work, because otherwise I would forget what I just learned. Most people I learned from were "clever/hardworking". They knew how to solve the problem but they didn't care much about system design. That I learned later by reading about it. And since I was always a person that tries to avoid overtime, I eagerly adopted those principles that allow me to build architecturally sound systems while at the same time living a stress-free life. That's how I became a "clever but lazy" person. And I am sure there are much smarter people than me out there; my point is: I see myself fit into this bracket and it works well for me.
TL;DR:
The four types of military officers can be applied to SAP Conultants as follows:
- Stupid/Lazy: Give them menial tasks with read-only access (e.g., basic monitoring). They are too lazy to do real damage.
- Stupid/Hardworking: Keep them off your system. They will work tirelessly to cause damage they don't even understand. Classic Dunning-Kruger.
- Clever/Hardworking: Your Builder. They don’t ask many questions but deliver excellent, "in-the-box" results through sheer effort.
- Clever/Lazy: Your Architect. They ask uncomfortable questions upfront to build the solution you actually need, purely so you don't bother them with change requests later on.