Skip to Content

Introduction

“We are all part of teams. Java teams, ABAP teams. Communication in these teams can be a challenge”

This is how we opened our Demo Jam entry last week at the SAP TechEd in Berlin – the complete script is here. Based on my experience in Berlin, lately I have been thinking a lot about communication and its relationship to a team’s success.   

The story behind the Demo jam in Berlin

How do you define “success”? This one word has a multitude of meanings – many of which are subjective in character. For me, “success” means overcoming adversity and the ESME demo in Berlin is an excellent example of a team dealing with enormous pressure and not crumbling under it.

Not many people know the “real” story behind our participation in Demo Jam and what happened during the Demo Jam itself. Craig said that we had a problem with one of our servers. What really happened was that there were network problems with our main ESME server. The reason for this problem has been discovered but is largely irrelevant to the point I want to make in this blog. We discovered the problem at the final technical check 5 minutes before the Demo Jam started. Darren Hague, Anne Petteroe and I took Darren’s laptop back stage and tried –along with the technical staff associated with the Demo Jam – to localize the problem.  After realizing that there was a problem with our initial server, we first tried to correct the problem. When we realized that this wouldn’t work, we decided to use a secondary server.

You have to remember that all this time the clock is ticking and Craig Cmehil, Jeff Word and other DemoJam staff are getting increasingly worried.  Are we going to make it on time?

Since the Java logger code was created by Darren, he could make the changes himself. The ABAP code, however, was contributed by Thomas Jung and Athavan Raja Durairaj  Thomas Jung was somewhere in the audience of over 2,500 screaming fans. We had to find him and fast. Anne went out and found him and brought him behind stage to fix the ABAP code. At this point, we had about 15 minutes before we were supposed to go on. 

At some point, Dennis Howlett  came back stage to see if he could help us. During this time, he sent off a tweet on Twitter with one word “backstage”. For all those who follow Dennis on twitter and know his wit, such one word tweets are exceedingly rare. This one word was proof of the strain that he (as well as the entire team) was experiencing.

Originally, we were the fifth from six teams. Realizing that we needed more time, we asked if we could go last.  We were granted this request. We had gained 6 minutes. Finally, after changing the code to communicate with the new server, we had to test our demos.  At this point, Craig came back stage and asked how long we needed. We said “10 minutes”. Craig then said “You have 10 minutes”.  We struggled and tested everything as much as we could. At two minutes before we were to go on stage, Jeff came and asked “Are you ready? Yes or no?” We said “Yes” and went on stage. As Anne was setting up the laptop on stage, we realized that we didn’t have a password to logon to the remote desktop. I had to race back stage, grab Darren and race back on stage to unlock the Remote Desktop. After doing this, we were ready but were still very worried. Moving from back stage to center stage meant disconnecting from the network and then reconnecting. We had no idea if everything would work.  When the lights focused on us and Craig started talking about sacrifices to the Demo Jam God, I thought to myself “We’ve sacrificed enough in the last hour: 3 kilos and 40 new grey hairs.“

For the Demo Jam,  I just had to give the introduction to ESME and provide the transitions between demos, Anne was doing the actual demos. We were both under unbelievable pressure. Speaking in front of a crowd of 2500 is tough. Combine this with uncertainty whether the technology is even going to work is even worse.

Although we would have liked to won the Demo Jam in Berlin, it was really of secondary importance. If you look at how Anne and I responded after our six minutes is over, we don’t ask the audience to clap. The first thing we do is to give each other a high five. At this moment, we were overwhelmed that everything had worked. If other team members were on stage, we would have included them as well. 

Lessons from the Demo Jam and ESME

Some might say that this is a personal story and too emotional and really doesn’t belong as a blog on a technical site. That is just my point; it is this emotion – this passion – that enabled us – the ESME team – to deal with a crisis.

Remember, the ESME project is composed of about 20 members spread across the globe.

This dispersion means that really have / had no possibility for face-to-face personal interaction. Although many of us had never met each other in person we had contact on a daily basis. We communicated with each other via twitter, ESME, emails, telephone calls etc. Our network was active. We were connected.

I consider these my individuals more than just “project” members -I consider them my friends.  We all have the same passion not only for ESME but also for collaboration in general. It is something we thrive on as evidenced by our exceedingly active communication with others – our networks.  When we communicate, we just don’t communicate about ESME or technology or our jobs. We communicate about our lives. It is the resulting bonds that give us our strength and our ability to master thorny situations such as the technical difficulty associated with our participation in the Demo Jam.

A note: Many of those in ESME (but not all) are SAP Mentors. If you look at the characteristics needed to be an SAP Mentor:

  • Hands-On Expert in an SAP Product or Service
  • Collaborative attitude
  • Good Communicator
  • Preferably working at a Partner or Customer of SAP
  • Interested in Improving product and services of SAP and the relationship of SAP with customers, partners and prospects

you will see that are interesting parallels to the topics that I’ve just discussed.

The current state of software development

Now, you might be thinking to yourself – “Give me a break. Where is my handkerchief? I’m starting to get teary-eyed. What relevance does this have to software?”

If you look at the how software development or projects in the current enterprise environment are typically structured, there are usually short-lived projects based on a global team that come together for the first time in the project and then disengage when the project is over. 

How often do we hear about failure in such global teams? When the distance is so great, you usually can’t really get to know one another. There might also be cultural differences which lead to misunderstandings at a personal level. Unfortunately, to achieve optimal performance, it is often critical to bond the team members as rapidly and efficiently as possible. If a problem occurs in a software project and it is necessary that team members go the extra mile to meet a deadline or solve a difficult problem, it is usually the more cohesive team that will be successful.  I’m much more willing to help some one whom I know than a complete stranger.

There are currently a number of new community projects that are being formed in the SAP communities.  Community projects are project that take place in the community – that means usually outside of work hours and usually individual participation is voluntary. What I have discovered is that what keeps those individuals involved is their passion and the relationships to others in the team. 

Conclusion

I think it was these personal bonds that allowed us to deal with the stress / pressure involved with the Demo Jam in Berlin. We didn’t want to let each other down.  We supported one another.  This experience has taught me a lot about what makes teams successful – not only those in community projects – but in other contexts as well.  It is the personal relationships – the web that connects us with others – that is critical. As I have mentioned, these bonds were largely created by communication at various levels – twitter being the probably most important, because we were a distributed team.

Thus, my experience in this community project demonstrates the importance that such microsharing tools (such as Twitter or ESME) can play in teams. Although our script in the Demo Jam focused more on interactions of a technical nature (Java logger, ABAP watch, etc.), ESME is one example of a tool that creates bonds of a more personal nature.  Such platforms are instrumental in building strong teams that act well in times of adversary or stress which are unfortunately commonplace in the current corporate environment.

To report this post you need to login first.

4 Comments

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

  1. Natascha Thomson
    Dick:

    it is nice to hear from a technical expert like you that in the end, it is all about people and relationships. I believe this from the bottom of my heart; and it is beautiful that this is the case, in this world full of great (but often anonymous) technology.

    Also did not know the behind-the-scenes story from Demo Jam in Berlin. Thanks for sharing!

    (0) 
    1. Richard Hirsch Post author
      Although in the blog, I focus on teams – the same analysis could be given to communities. What makes a community something special? It isn’t the technology or the content but the people involved.

      D.

      (0) 
        1. Richard Hirsch Post author
          Without the support of the community, the original idea would have never became reality.

          Thank you and the rest of the community as well.

          Dick

          (0) 

Leave a Reply