Skip to Content

Speaking about information gathering, preaching about collaboration

A few days ago I had an appointment with our trainees to give them a presentation about information acquisition: how to find resources on SCN, how to learn about the inner workings of the system by debugging, exploring the source code, and so on. I improvised the session completely, which is fun because you never know what happens. The session took an unexpected turn from information acquisition to collaboration – please see for yourself.

It turned out I had three key messages for my new colleagues:

1. You can’t learn much in advance

2. Think of yourselves not as developers but as information workers.

3. Contribute and collaborate.

Here they are in more detail.

1. You can’t learn much in advance

Imagine a builder who builds all the possible houses that anyone could ask for in advance: wooden shacks, skyscrapers, round houses, square houses, houses with a sharply tilted roof, and so on, to have exactly the right house at hand when somebody comes along with their precise specification: bizarre and inefficient, not?

Gathering all the skills and knowledge to solve any technical design problem is much the same. There are so many technologies, frameworks, and tools, and so many ways to combine them, and they appear and perish and change so rapidly that it would be pointless to try to have all the required detailed knowledge at hand when you need it for a particular solution.

Fig. 1: Education

Instead, you need a meta-skill: to acquire information rapidly and develop the required skills for a particular solution on demand – to learn what you need, when you need it. Therefore it is absolutely crucial to be familiar with the most valuable information resources for SAP professionals:

If you have a good command of these, you can solve every problem and you will acquire a huge body of knowledge along the way. This knowledge will help you solve future problems quicker and better, but only as reusable (and quickly perishable) knowledge modules.

2. You’re not coders, but information workers

Our trainees are at the very beginning of their careers: College hasn’t even started for them, and they have spent only a few days at the company. So I wanted to discuss some misconceptions about the work of a developer.

Usually, novices in the software industry are given small development tasks. A senior developers breaks down a problem into small, manageable chunks which are well-defined, isolated and testable. Perhaps there is even a pseudo-code specification for the core algorithm. This is the kind of challenge junior developers often get, so they regard themselves primarily as (junior) coders. They believe that as they get quicker and better, they will become senior coders, and very frequently even managers believe this absurd nonsense. 🙂

In fact, the kind of task a senior developer performs is entirely different from what we saw above. A senior developers is asked questions like:

  • “The customer wants to integrate an approval step into this business process. What would a reasonable solution look like, and how much would it cost?”

A good senior developer will add (and try to answer) many questions, of which I list only a few:

  • What does the standard offer in the current and in future releases? How reliable, stable is it?
  • Make or buy (i.e. use SAP standard)?
  • How easily enhanceable is the solution? Can it be easily adapted to changing business requirements in the future?
  • What support is there for software logistics, deployment, configuration at the customer’s site, and later adjustments (e.g. after release upgrades)?

The result of such a research task will include the costs, required skills, possible timeframe, side effects, estimate of the stability, maintainability, deployment, training, and so on. But the solution may include no coding at all.

One of my key experiences as a developer was writing a program which, as I digged deeper into the matter, became shorter and shorter until it vanished completely. Sometimes, the code you don’t write is as important as the code you do write, and the best solution is to write no program at all!

So as a developer, think of yourself as an information worker. As developers advance in their career, they learn to acquire and consume huge amounts of information, some of which has to be generated in iterative question-and-answer processes. A highly-effective information-processing process condenses and aggregates all these megabytes of information into just a few bits such as:

  • It can be done easily with customizing activity XYZ.
  • It can’t be done, but only at insane costs and wrecking the maintainability.
  • Let’s not do it. The requirement is against everything the solution was and still is designed for.
  • It can be done with a neatly integrated custom solution, and here is the outline.
  • Let’s wait one year, then it can be done easily.

To perform this kind of analysis and offer this kind of solution, you have to know how to code very well, but coding is not everything.

Coding is just what people do when the senior developer can’t find a better way of implementing the functionality.

3. Contribute and collaborate

This surprised me the most because I hadn’t planned for any message along these lines at all, but it turned out to be the most important thing I had to say. I might even have sounded a bit evangelical at this point (although I did not start speaking in tongues or scripting languages).

Fig. 2: Diving signal to be together

I find it impossible to recommend using SCN without contributing to it.

  • Blog about what you’ve just learned. Use SCN and find information that helps you. If you work on a topic that is not covered on SCN, learn about it the hard way and blog about what you learned (or post wiki entries). You don’t have to be the world’s biggest expert on a topic to help other people with it: Blog about what you learned during the past few days and help others conquer a new area of knowledge more quickly. Quite likely, they will reciprocate and write about their next steps, which will accelerate your learning as well. Helping others helps you.
  • Join a great network of active contributors. If you begin to contribute, you will quickly gain the recognition of other contributors. They are a friendly and supportive crowd and will encourage and guide you as you become a regular contributor. Many of them are world-class experts and genuinely friendly, helpful people, and it’s a great experience to find yourself as part of a professional network together with these people. They are a pleasure to work with – that alone is an excellent reason to start contributing today. Seeing in realtime what the most skilled professionals in your area are working on, being able to call upon them for help (or helping them if you can), tossing questions, feedback, and all kinds of ideas back and forth are an invaluable enrichment.
  • Gain recognition as an expert. If you are highly skilled in a particular field, contributing on SCN is a great opportunity to showcase your expertise and become recognized as an expert outside your own company. You might get “discovered” by a future employer, receive an invitation to an international conference as a speaker (this happened to me when I was a busy contributor to a forum in the pre-SCN era).
  • The more you teach, the more you learn. Have you ever tutored someone? I find that explaining things makes the teacher develop a much better understanding of the matter  (off-topic note: except my old teachers at school). So by writing a blog or wiki entry, you will learn and extend your own knowledge. Also, the more you contribute, the more your perspective on other people’s material will change. When I started to blog regularly, I began to follow the publications on SCN much more closely. I’ve made it a habit to browse through the list of recent weblogs and read the interesting ones almost every day, and this has broadened my horizon and helped me find my ways into new knowledge areas.


These were the three core messages to our trainees. From colleagues who work with them regularly I hear they are a bright bunch (my impression, too), so I expect they will come up with some interesting contributions. While we’re waiting for them to show up, why don’t you, dear reader, write a quick blog about that last thing you learned in your favourite knowledge area?

You must be Logged on to comment or reply to a post.
  • Thorsten, I’m trying to wrap things up today but I wanted to be the first to comment on your post and simply to say, “this post kicks butt!” Great work. More later.

    – Jon

    • Your elaboration on your third point makes my heart glad, actually burst with pride that you see it that way.  Teaching something as a wonderful way of learning something is an approach I totally agree with.  In the context of some of the more outstanding SCN members (yourself included) in the context of formal teaching (I really learned ABAP from my students) in the context of parenting (I learn much more from my kids than I can ever teach them).  As Jon says this really kicks…okay I’d rather in my own words, this really resonates with me.
  • As both Jon and Marilyn said – this is a very thoughful piece.  I am proud to re-define myself as an Information Worker – and by the way, the approval step can be added if the customer understands that this may have an impact on processing time – and sometimes they need to reject.  That is one of my favorite bug-a-boos.
    But that’s a whole other topic.  As for teaching – while I may not get to do exactly that, I do try to share and encourage sharing of information and strategies for gaining information. 
    Great stuff!
  • Thorsten

    A very nice job of writing up some of the more important aspects of a(n SAP) developer. Meta-skill, the code you don’t write, the more you teach … all very true indeed.


  • Having the weekend to collect myself, a few more thoughts. A couple key phrases from your post:

    “Instead, you need a meta-skill: to acquire information rapidly and develop the required skills for a particular solution on demand – to learn what you need, when you need it.”

    Definitely. It’s those who are most adept at shifting into new tools that are the biggest assets for their companies.

    “Coding is just what people do when the senior developer can’t find a better way of implementing the functionality.”

    – YES! There is something to be said for those who can keep the customizations lean and only when needed. It means acquiring skills beyond being a code grinder but it’s the right direction.

    My final comment is something you didn’t mention, maybe something like, “we are all consultants.” By that I mean, I think we are more and more expected to not only master specific tools, but to know the architecture and business drivers of the projects we are on, and this certainly applies to developers. We not not just hands-on anymore, we are also making a difference by being “advisors.” Of course, we have to be politically smart about the right context to express concerns or alternate approaches, and some projects give more voice to this than others. Still, it’s a good vision, I think, of the type of skills mix an SAP “technical collaborator” should be going for.

    – Jon

  • I enjoyed this alot.  It crystallizes many of the ideas that many of us have, but can’t or don’t express as well as you do (or with as much authority and credibility that you have).  It deserves higher visibility.  Thanks for sharing.

    Mark Yolton

  • Would that everyone could see her/his self as an InformationWorker and not just the computer-folk. 
    Why not and entire company bound together by a single information-processing-process based solidly on #1’s meta-skills?

    Best and Thanks!