Skip to Content

Why so curious?

I recall babysitting my niece a few years back when she was about three.  She was at an age where she loved to have a chat and would ask heaps of questions. Actually, scrap that. I’m wrong. She liked to ask one particular question. A question that was so succinct but would drive me crazy. And for every answer I had she would follow up with that same question. Her question was “Why?”.

There would be no end to her repetitious “Why” unless I did something. I’m actually surprised my patience lasted as long to as it did when I eventually ended with asking her “Why” as my answer. I knew I had won that round when she paused and then thoughtfully responded with ‘Mmmmm’ accompanied by a cute smile and giggle. I have no idea what we talked about except for her constantly asking ‘Why’. Five minutes later, the game started again.

My observation across a few spaces SCN made me think about my niece and her thirst for knowledge. This got me wondering: Why is it that as a child we have an incessant desire to find out the WHY in life but lose that curiosity as adults? Do we get to the point in life where everything is hectic and we just want to the comfort of knowing how and what we must do to get through the day (or the latest SAP incident)? Does work become more manageable when every situation can be reduced to a process flow with a few repeatable steps? Success is guaranteed if I follow these <insert number> to achieve <insert goal>… apparently.

Learning “how” is an important first step to mastering the system. And sometimes learning the basic steps build the confidence we need to continue to the next level. After all, we have to begin somewhere. A beginner must demonstrate their basic understanding of a system before being allowed access (or we can hope). Typically they would demonstrate this through training and a regurgitation of the steps. But wrote learning cannot be the only part of the equation.

I remember interviewing for a junior SAP Security Consultant and I asked them about CUA (central user administration). They gave me the correct steps to configure it but they could not tell my why changes fail to process or how to identify a potential problem in the system. Their focus and education was on learning the steps but they failed at knowing when to go “off script” and deviate from their set of instructions as they did not understand how the CUA works. They never thought to ask their teacher why. Their confidence in answering the how failed them when I asked why.

You may wonder why the curiosity? Mastering the skill of why means we can make better decisions. It means we can identify the root cause. If we know how and why the systems functions the way it does, we can decide which option is better. If we understand impacts and consequences we will know when we should choose one option over the other. We can then ask: Is there a better way to design this system? And, if we’re ever stuck with a red, nasty error message and there is no-one available in the office (or even on SCN) to help us out, we might just be able to critically analyse the error and figure it out ourselves (of course if we already asked SCN we would pop back in and share the solution).

My advice to you: rediscover your inner child and get curious. Start asking why. Even if you only take the moment to ask yourself. It’s a skill worth developing. Next time you ask someone how you should do something don’t forget to ask them why – after all, in SAP there is more than one way!

What are your thoughts? Do you wish more people took the time to figure out why?



You must be Logged on to comment or reply to a post.
  • Colleen,

    I wish it nearly every day that more people asked why. If all you do is put a BandAid on the immediate symptom in front of you without asking why did this issue arise in the first place, you never get to the root cause, and the same symptom could arise again and again. It takes asking why, sometimes several times, to ensure that you have identified the real problem and can work on a resolution, not just for this user/this program/this system, but by getting to the root of it you resolved it for everyone.


  • Nice one again, Colleen! 😎

    Why is it that as a child we have an incessant desire to find out the WHY in life but lose that curiosity as adults?

    Not everyone loses it. I certainly didn’t and it helped me to be where I am today. Helped me to dive deep into a completly new world (SAP) and not only NOT drown in there, but I learned to swim. And different styles, too!

    Asking why an error or even just a strange behaviour happened made me look deeper into the system, made me follow the workflow and on the way made me understand the whole system better. I did this for “my” SAP module, the portal and IDM.

    In IDM error messages shine in a bright red and over the years one of my goals was, to reduce those red lines to zero (go figure! 😀 ). For most of them that meant to discover, what the heck was going wrong in the first place and then why and then how to change the wrong behaviour.

    Today I still have some error messages in my system. For most of them I know why and how to resolve them (those are content related, not a system problem). For some I found the why, but not a solution. I need external help for the latter, but you can bet I’ll grill the consultant about what was the reason, how he found it and how he stopped it later on and check what he did to understand the whole process, too.

    One of the reasons I take classroom trainings for the areas I’m responsible for is learning the why behind the actions I need to take on my daily job. Or why something is configured a certain way. That’s why I attend them not when I start with an area, but when I have worked in it for at least some month, so I’m not totaly confused on day 3, but get a deeper  understanding of what I do and why I need to do it this way (or learn ways to do it even better!). I found for myself, that I can take away a lot more from those trainings that way, because I can prepare my own questions about what I hope to get to know from the training and try to answer them for myself. If I can’t do that, I’ll ask the trainer. Simple.

    By the way:

    Understanding the “why” is not only important with systems, but with people, too. If you understand why a person reacts a certain why, you can make communication and working together easier by adjusting your style a bit to them or by asking the right/better questions or by simply helping them with their issue.

    And you can make your life a lot easier, if you know that a certain person reacts nasty to everyone, not only to you, even if nobody really knows why. But at least you can stop asking yourself that question. 😉

    Why people do what they do is – for me – one of the most interesting fields.

    That grew longer than I intended to, but oh well. *g*



    • Hi Steffi

      thanks for your comments. Yes, people side is a completely different aspect. I have been taught to always adapt my communication and style suit the person I am conversing with. If they are a details person who love facts and data get my numbers read. If they are an ideas person who want big picture only keep those numbers away (or provide as a reference for later reading).



  • This is an absolute prerequisite for critical thinking. You may be able to survive as a Basis admin, or any kind of system administrator/engineer, without this level of curiosity, but you’ll never shine at it unless you are willing and wanting to dig a little deeper. Sure, things get hectic and busy and there isn’t always (in fact, usually) time to delve all the way down into things. There’s a lot of business demand to “get it done, good enough” so that everyone can get through their day and you can move on to the next task. We all experience that. But whenever possible, understanding why means you might also understand how to prevent other, similar problems, or perhaps to improve the way something works. It means you’ll know that “if I make system change A, that is likely to result in downstream reactions B and C, but D should be left alone…”

    I can teach any basically competent individual the mechanics of installing, upgrading, maintaining, and managing an SAP system. What I can’t easily prepare them for is those middle-of-the-night emergencies when everything has gone wrong, and the rulebook is no longer helpful (maybe even getting in the way), and there’s no one to call on, and you have to fix it before 6am, now. When the rote procedures that usually work — and which are designed to prevent causing further problems by people who don’t fully understand what they’re doing — fail to fix the issue, that’s when a deeper-level understanding of the system’s mechanics really comes into play. That’s also when a certain amount of courage is required.

    I think this goes hand in hand with the curiosity to ask “why?” A system administrator needs to have the caution to not needlessly endanger production systems, to not shoot from the hip like a cowboy at the first sign of trouble, and to not assume that “I can do this during business hours; it won’t impact users” just because you think it shouldn’t. However, the sysadmin also needs to have the courage, when the SOPs have fallen short, and there’s no help and it needs to be fixed right now, to act on their deep knowledge of why and how things work the way they do and take a bold action. (You really shouldn’t directly edit the CVERS table with database tools, now should you? But, um…. well, sometimes, when nothing else is working and your back’s against the wall…)

    Of course, with a good backup first. 🙂

    That’s the trick: knowing when bold action is called for, and reasonable to take, and when caution is the rule of the day. Knowing why is what grants the discretion to understand the difference.

    • Matt

      That’s the trick: knowing when bold action is called for, and reasonable to take, and when caution is the rule of the day. Knowing why is what grants the discretion to understand the difference.

      Great Summary there!

      Time critical situations are exactly why you need to understand root cause. Most procedures are written based on perfect-case/standard scenario.

      The difference between a junior person and the next levels is someone who recognises their is an issue and can make an informed decision to take unscripted corrective action.

      I have witnessed too many situations where a support person deviated from script or blindly followed the steps because they did not understand what they were impacting and did not realise there was an issue. They continued through the instruction and the system was a mess. They did not realise to stop and call out the issue.

      I usually write work instructions down to a very low level. The test is to get someone who has never used the system to see if they can follow it (covers emergency situations). But there is still a risk if people only learn how to do something without context their can be problems.

      It’s on par with a user searching SCN or Google for their error message and they take the first result and apply the solution. They do not realise there can be multiple underlyin causes for the error and as a result multiple solutions. They apply the same solution for the wrong problem and make it worse.



  • Colleen, got a good chuckle out of the story – I have a distant cousin who used to torture his parents with constant “whys”. When reaching the point of exhaustion his dad would reply “perpendicular” and since the little one couldn’t pronounce it, this usually ended the interrogation chain. That kid is now a doctor, so I think curiosity worked well for him.

    Unfortunately many schools just don’t seem to be geared towards fostering the curiosity and the parents don’t always have the availability either. And in the corporate world “why” is frequently the last question management wants to hear. So yeah, I’m blaming society for this. 🙂

    It is a serious issue though and I’d love to see the healthy curiosity supported at every stage. Not spoon-feeding the solutions to the “did not Google” crowd on SCN seems like something anyone could do, eh? 😉

    • Hi Jelena

      Glad I made you laugh.

      Education system can be difficult. At home there is a lot of standardised testing to try to compare students. The problem is they end up focusing on how to pass the exam and not focus on learnings. Quite like an SAP fresher who could find themself trying to pass a certification without trying to focus on learning why systems are a certain way.



  • I always remember that a constant complaint about SAP training classes when I first started was too much focus on the theory and not the practical part.  The problem is if we don’t understand why and instead copy what was done before we can repeat mistakes or not be able to pull things apart.

    I always found it fascinating when other ABAP programmers on a project really didn’t understand the differences between the different types of work processes on a system or how memory is managed on the ABAP application server.  I think it also applies that too many developers fail to ask why when given requirements and instead just follow the instructions.

    • Hi Stephen

      I think that is where formal class-room training is just one step in the learning process. It’s there to provide foundations and introduce the terminology, basics and key concepts. From there you go out to the real world and learn how to make it work. You do rely on colleagues and mentors to continue to help you learn the right ways.

      I’m finding the need to learn topics outside of my expertise so I understand my area better.



    • Stephen Johannes wrote:

      I think it also applies that too many developers fail to ask why when given requirements and instead just follow the instructions.

      True that. There were too many times when something was given to me or my team as an ABAP enhancement and turned out to need a simple configuration change. In some cases the business requirements were not even taken correctly. Curiosity is essential especially for the ABAP developers since we need to know a lot about different SAP areas to be successful (and also avoid extra work 🙂 ).

  • Hi,

    Thanks for this interesting post, I fully agree curiosity is the essence of knowledge, and is important when you are working on SAP, especially in the technical areas (admin, dev).

    Curiosity killed the cat … but makes the SAP consultants (humans) stronger !

    I think it has to do with the definition of intelligence, finding the (unobvious) links between things.

    SCN is a great place for exercising your curiosity, but sometime it’s a bit depressive to see that many people starts asking before even searching 🙁 … passive curiosity syndrome ?


    • Hi Yves

      I had thought of the phrase curiosity killed the cat when I started writing the article. I was going to play on the words – curiosity made the consult. But as I wrote, I realised I was asking more questions than I was answering so I changed my title.

      passive curiosity syndrome

      is that a euphemism for laziness?