Difference between revisions of "Deutsche Bahn"

Revision as of 04:52, 22 January 2012

DB Logo

iPhone Touch&Travel Home Screen

I was an intern at Deutsche Bahn (the German national railway) during summer 2010 in Frankfurt (M). I worked in the PPX (project Mobility)/Touch&Travel department.

My boss had the title "Innovations Manager NFC." He was responsible for pushing NFC (Near Field Communication; basically RFID in cell phones) forward both inside the Bahn and with partners in Germany.

I worked on two main projects. First, I prototyped the look of the new Smartphone version of Touch&Travel and I developed the architecture for how the application could be securely integrated within their existing infrastructure. The look and the methods that I developed were scheduled to be adopted in the application. Second, I prototyped (mockups) and developed (PHP, MySQL, HTML, JS/AJAX) a concept for pulling data together from different data "silos" within the Bahn to give consumers quick access to data to make their trip easier. (Sorry for the generic language, but I am under NDA)

I also took part in business meetings between Deutsche Bahn and tech providers as well as potential partners. I discussed strategy before the meetings and I wrote up reports of how the meetings' content would help the project.

See Touch&Travel to learn about the program I worked on

What I learned

An employee is wiping the ICE Windshield in Frankfurt(M)

Looking back, my experience at Deutsche Bahn was good. The job that my HR contact found me was very good; I think she brought me to the right position in the Bahn. I worked on projects both immediately needed and a further out prototype. I worked fairly independent, taking what I knew about the Bahn and converting it into a vision of what could be. Hopefully the management will follow the theme I demonstrated, and what I have made will make a difference in the world by making it easier for people to take public transit, thus cutting CO2 emissions. Unfortunately I can not write too much about the positives, since the joy I got from making them requires disclosing the details of what I did, which is not allowed due to the NDA I signed. If or when my work becomes public, I will update this.

This summer I experienced a lot of bumps along the road, and I learned a lot about how big companies work . My biggest complaints was that DB provided no free, or even discounted, train travel, aside from a pass to work. This was made clear to me before I signed up, but I still found the policy maddening. A larger salary would cost them money out of their pocket, but train tickets cost them nothing. (Perhaps some internal funny money, but that is another issue entirely.) Train travel costs them nothing, besides perhaps, my loss revenue if I chose to pay for the trip. The free ticket could be a low-priority, only-if-there-is-space, no-seat ticket. It could be limited to inside Germany if outside costs them money. But they offer nothing. For international interns especially, free train travel would be a great perk. I have no clue why they don't do it. Employees receive some amount of free travel.

I also had hiccups with the HR department. DB has a wing, or at least a contact person, in the HR department for international interns. Although my contact was very nice, I seldom got a full response. For example, I had to ask a few times if my free work ticket would work on CityNightLine. It could have been that my contact was overworked or new to the department. But I was never introduced to other sub-departments of HR that I could call directly. I was definitely more shy in contacted other HR departments because of my German and because my international situation was abnormal. Still, I was not even introduced to the HR website where the answer to my question to be found, instead I stumbled on it while browsing the intranet. (Yes, work tickets can be used on the CityNightLine, but you still need a seat/bed reservation at your expense; in fact this is how the CNL always works. You must combine a travel ticket with a seat/bed reservation.) An orientation guide, similar to MIT First Year (http://firstyear.mit.edu), would have been very helpful. I did receive one packet in German through the mail, but this was full of links to high level topics and websites I could not access, while short on practical advice.

DB in general seems poorly set up to welcome new workers. Although my computer was ready for me when I arrived (I later learned that I was lucky); I spent the whole first day trying to figure out how to get the company-issued Mac on the internet. I figured it out between talking to my boss and to a developer coworker. My boss advised me not to call the help desk because they were generally unhelpful, and the Mac was unsupported and thus they would not tell me how to connect it to their network. I never found a webpage that detailed the procedure. Other MIT interns at DB I talked to waited weeks to get online and starting working. Because this is the first impression an employee gets of a company, it is critical that it be positive.

Personally my company ID took weeks to arrive. Before I left, I sent a photo for the ID, as requested by my HR contact. When I arrived, my HR contact advised me that my ID would arrive shortly. Day after day, week after week, no ID. This was a bit of an issue because the company lunch canteen does not take cash, only company IDs loaded with a debit cards. Although I kept calling my HR contact, no ID showed up. About one month into my internship, I received my card. But it was an impersonalized, temporary card. I called the phone number of the company ID department included with the ID. The lady in the ID department had just received my info to send out a card. In addition, interns under 3 months do not receive a card. This was in conflict to what I had learned before from my HR contact, although as I later found out this was the policy on the HR website.

I really think that some of the issues I had were due to the language and cultural differences. I learned to speak German about 80% proficiently from my mom as a child. Before this year I had no experience reading or writing German. Taking German 2 helped me be able to slowly read German. However, I did not practice writing German so I felt very uncomfortable writing emails. Where as in the US I could comfortably deal with bureaucracy, German was more challenging. In the US I might have browsed the HR site and seen the phone number of the card department, so I could have emailed them. But I had to really work to read and understand German, so I did not browse the internal knowledge base.

Work at Deutsche Bahn and in Germany in general was less efficient than I am used to. Personally I felt cut off from the world without the smartphone (Palm Pre) that I am used to. However, my CDMA Pre does not work anywhere in Europe, since Europe is all GSM. I love being able to look stuff up anytime I want to. I like being able to read the NY Times when I am bored. I want to reply to emails as they come in to keep the conversation going. This feeling was somewhat tempered because the Bahn lent me an iPhone off and on. In addition, the internet at the family I was staying with was really slow, particularly the upload. Forget about uploading anything. Halfway through the summer, I found the family I was staying with a faster connection at the same price. I guess in some ways I should be thankful: When I last stayed with them 4 years ago, I got them an internet connection in the first place.

But despite having internet access at home and work, I still felt disconnected at DB in the beginning. DB does not allow its employees to access their email and calendar away from work. Managers who are assigned DB laptops can connect via a VPN to the network to download their emails. But even the managers can't read their email or calendar on their smartphones! In the beginning of the summer I found this so backwards. I feel more use to it now at the end of the summer. My work also shifted away from responding to emails to working on my project. Not having email access at home does prevent you from working on weekends or after hours. Previously I had done all my internet work on nights and weekends after school. There was one particular case not having access burned me bad. I had a business trip early the next day in Nuremburg. I needed the meeting location, directions to the meeting location, and the name and phone number of the person I was meeting. With a smartphone, I wouldn't have needed to do any preparation work ahead of time. I could look up the meeting's location on my phone's calendar; searched for directions in Google Maps or DB Navigator; and looked up contact info in my address book. However in Germany, I needed to prepare this all before hand, which I did; however, I forgot to put the print outs in my bag. I had to get up an extra hour early to stop at work on the way to the meeting to pick up my notes. Luckily DB's offices were near the train station. In several cases I've missed or miss prepared for meetings because my calendar was not easily accessible. Even DB's bosses have to boot up their laptops (which takes some time) to check where their next meeting is. In 2010, this just seems completely backwards. There isn't even webmail!

It was also hard for me to get my work done at work. DB runs a proxy between its network and the internet. This is not necessarily a problem. Companies have a right to inspect traffic to and from the network to authenticate users and ensure that no viruses, etc passes by. However the way DB has theirs set up breaks a lot of programs. You must configure each application to work with the proxy. This works fine for the major apps, which build support for proxies, but when you start getting into development tools it starts being a major pain. Not all software is built with proxy support, making it difficult or impossible to get your job done. But it does not have to be like this. Companies can inspect all traffic going out to the internet without requiring someone to specify the address of a proxy. Authentication can be done on a special website run by a network device which inspects your MAC address and asks for your username/password. This system was likely set up ages ago, before such technology was available. The inertia from this being the way it was always done does not allow their employees to work efficiently. So much time is lost as employees try and get their tools to work. It adds up fast! In my opinion a competent network administrator could fulfill the same goals of monitoring, authentication, and caching, without blocking people's work.

Some of these issues I had were due to this being my fist experience inside a big company. Previously, I had run my own company, SocialView. As majority partner, I decided how the company would go forward along with my one other partner. At DB there were several levels of management which had to approve anything. In addition, the management wanted to make decisions themselves. This seemed inefficient. For example, when it came time to implement the map I had built, I brought it to the person in charge of the project's website. We worked together for an hour to test out all of the possibilities on the website CMS. After trying everything out, including a few HTML/JS tricks I knew, I stated what I though the best option was and asked my coworker if she agreed. She stated that it was far too early to decide that. She would have to write out all of the options in a table to send to the boss for approval. It is natural for the management to want to make the decisions themselves. But this is inefficient; the better course of action would be to hire smart people who could be trusted to make the decision quickly themselves. In some ways a good manager should just make sure that his or her employees can work without being overrun by the bureaucracy.

Perhaps it is just that I am used to working with a wide variety of issues which are done by different people in companies. There is so much more than coding to website development. In my own company, I did almost everything. I came up with ideas for the site, and programmed them. I decided what features to add, and I added them. I did the graphic design and layout; although I am not an artist, I think my sites are fairly well designed. I also became interested in areas surrounding web development, such as tech policy and copyright/IP debates. To keep up with the news, I comment on tech policy on The Weekly Spin. I certainly have a lot to learn (next summer?), but the field interest me along with being something developers need to look out for. I also started following US national policy, because making sure the country and the economy is run well is similar to making a good website design - many constraints must be satisfied. Since I worked on GridView, I've learned more about business. Projects can't be developed unless they make sense. At MIT, I've decided to be a management/business major. Security is important too. I've listen to the 5 years of the Security Now podcast so I have a sense of what's secure and not. Transit is another policy area I became recently interested in. I always liked trains as a kid (but fast, sleek trains, not steam engines), and I think the country can use more of them. In order to get them, you need the right policies. I don't know, I may find myself working in one of these sub interests than costing. MIT has shown me that many of these fields are connected and I can fairly easily switch from one to another. Hopefully being aware of all these fields will be an asset, not a liability.

I think that my style of working is to do 95% of the job in a fraction of the time. Usually the 95% answer is good enough. But in some cases a company has the resources and wants to spend the time to get the 100% answer. But in many cases a 95% answer is good enough. This type of work environment may be better for me in the future.

On the other hand, this was my first experience working on a project that shipped hardware. Although we did not make the hardware directly, we shipped hardware containing our software which could not be updated after shipping. When you ship something you can not update, you must be very careful that it works really, really well. Shipping buggy hardware that had to have been recalled has cost some companies hundreds of millions of dollars. When you can update your software, there is less pressure (but not 0 pressure; your software still has to work). It was also the first time I worked directly for a big name. Even though our software was not in control of any trains, it still has to be reliable because its failure would reflect badly on the entire railway. Customers would also use our system to use money to pay for services; another risk point. With GridView, even though it had over million users, it was still a best-effort affair. If GridView went down, it would be inconvenient, but you weren't paying anything, and hopefully it did not affect your life. Failure of our software could literally strand people far from home. Another layer was that the software had to function out in the real world and we had to guarantee it. Twitter does not care if you don't have cell service and can't use it. They just make the website. Touch&Travel needs cell service at a station. You would have to know before hand if you could get service, because what if you arrived and could not check out! Thus, we must pre-confirm that the cell service works. This is not simple because Deutsche Bahn has a variety of stations from 30-track mega stations with a train every minute to pieces of asphalt in the countryside with a handful of trains a day. The app needs to be robust enough to work under all types of conditions. Also at Deutsche Bahn, there are so many exceptions and special cases to be included. These must be all handled perfectly as well.

But in many cases this level of error avoidance is not needed. If an issue can be easily corrected, don't spend so much time trying to avoid it. Iterate quickly, instead of working yourself to guess perfection. I particularly like Netflix's corporate culture policies. http://www.slideshare.net/reed2001/culture-1798664 They aim to give their employees the freedom to decide the best course of action. Of course unrecoverable issues must be avoided, but if a problem can be easily fixed, than they fix it quickly.

I also agree with other aspects of their culture. I believe you have to hire the best employees, by giving them first rate compensation and then give the tools they need to succeed. In programming, someone who really knows what they are doing is worth several report writers or two by-the-book programmers. I think that culture reinforces itself. A rule- based work environment drives away creative, top talent who can work without following every last paper-shuffling rule. The people who are left are good at operating strictly inside the rules. The ones who are good at following the rules get a promotion and manage the same way they worked before. I think you need to be flexible. Just as some things can be fixed later on, different sections of the Bahn can be run differently.

DB's purchasing polices are inflexible as well. As part of the work I was going to do, we needed to purchase an SDK in order to test what we built. I told my boss in the beginning of May that we would need the SDK. The SDK purchase was a weird event because it was not really software, but it came from a particular manufacturer. For this manufacturer we had to go through an authorized reseller to purchase anything. However, the Bahn's authorized reseller was changing in 2 weeks, so we would have to wait that long to purchase anything. The new authorized reseller didn't even know that much about the SDK; we had to educate them about the process (so much for the benefit). The Bahn's purchase paperwork took a few weeks because even though it was under $500, everyone and their boss has to sign off on it. Then the SDK manufacturer needed to check out company paperwork, because they apparently never heard of the 250,000 employee railroad. This took a few more weeks. It's a gigantic joke. Now, this purchase happened to be the perfect storm because it was a fairly non standard item and the manufacturer had a complex process too before they would sell you the item. In mid July my boss just bought temporary SDK with his personal card; I don't know why we did not try that earlier; I did not know it was possible.

I believe that you need to trust your employees. While you need to verify purchases at some level; the process will never be air tight. Someone intent on breaking the process always can though if they are dedicated enough. For the most part you are just paying people to deal with your bureaucracy. This takes time, which is expensive. My rule of thumb is that in almost every business labor is about 70% of costs. In fact, I wonder if these extra processes actually cost companies more than it saves them. You do have the deterrent effect to factor in, but all that lost productivity must add up. Of course the lost productivity is hidden, since HR costs are dealt with by a completely different process than goods. It is fairly easy to see money wasted on unneeded purchases than lost time. It is also a perennial debate whether centralized purchasing makes sense. You might save some money up front, but then you need to distribute the goods internally. You also add another middle man to the deal. In some cases the consumer price may even be lower than the negotiated corporate rate.

Now don't get me wrong. Communications is important. But as a team grows larger, the communications overhead increases exponentially. People waste time gaining knowledge that they don't need for their job. Perhaps I am the type of person that need to know everything and be involved in everything. Perhaps I can't help not being the manager. But some argue that the context approach has too much overhead. One thing I've noticed is that as you aim for perfection in communication you take far too much incremental time. When you constantly worry about adhering to the corporate design style for internal PowerPoints, you are wasting your time. When you make small changes to your PowerPoints and then have to recompile all of the different PDF versions, you are wasting your time. You get up in front of a meeting, and everything you prepared is out the window. I look forward to exploring this theme in the future, because I think this is going to get more and more important.

Many German companies spun off their IT departments to be separate companies. The theory behind this was that as an independent department would be forced to compete. The main company could choose whose services to hire and the IT company could solicit outside business. However in my opinion this is exactly wrong. If I could sum up the opinion in CIO magazine from the last 2 years it would be: IT departments must add business value, not just keep the lights on. A CIO should sit with all of the C-level execs and plan out the business' strategy. IT departments must continue to keep the lights on (or the servers running that is) of course, but the main focus is to develop and execute on ideas that add business value. By shifting the organization to only delivering contracted services, you are cutting off the ideas and innovation. On the flip side the main company should be free to choose the best service provider for their needs. But how are you going to get a @deutschebahn.com email with another provider? I've talked to many employees who are dissatisfied by the cost and quality of the desktop and email solutions of our IT company. But they don't switch - either do to impossibility or unspoken loyalty. So to me spinning off these IT departments breaks innovation, but does nothing to increase quality, value, or choice. They services don't seem very successful in attracting outside business. And since they are still owned by the mother company, competitors will not want to outsource to a competitors' IT department for competitive reasons. All that happens is internal funny money flows from one department to another.

Communication between departments was also non existent. I have no clue what anyone else in my hallway does. This is an issue, because even though a coworker with the answer to a problem you have might be in the office next to you, but he might as well be working for another company on the other side of the world. For example, Deutsche Bahn runs a GSM network for train control. Although we didn't have a direct need for cell network advice, something helpful would have most likely resulted. When we did talk with other departments, we put as much care into the sides for the inter-departmental buy in meetings as we did with external partners. At MIT, it is the exact opposite. Perhaps it is because every office has a sign on the door and an entry on the map website. Or perhaps the culture is just different. Talking to other department could incur a charge or use up your billable hours. This is another reason against spinning off the IT contractor.

Now don't get me wrong; work can get done despite these productivity sinks, but it saps employee's energy and the companies' money. This may seem like no big deal, but every time I read Fast Company I get the feeling that even the big companies, every step is important in building their next product. Even big companies must always reinvent themselves to stay relevant. In technology if you try to burry an invention because it is out of your business model, a competitor will spring up and take advantage of it. Even the Bahn is trying to move itself to be a profit-oriented international competitor. From Fast Company it seems that companies and employees cannot just coast. The problems need to be addressed sooner, rather than later. Things really do have an impact. You need drive and pressure to get a product out that addresses a market. Mediocrity can not be tolerated. For what I've seen it too often has been. Issues needs to be addressed, not swept under this "this-is-how-we-always-did-it" rug. I think that the type of employees you employ here make the difference in this. Now it could just be that Fast Company chooses to highlight certain issues, but I strongly believe that productivity sinks must be avoided. Although their have been some reports of issues with Netflix's culture, it is something that I want to try out in the future. I am interested in thinking further about management for my next 3 years at MIT.

I did really enjoy what I was working on this summer. I liked using my design and coding skills to help transit. It was fun to learn more about transit over the summer and to hopefully help mass transit grow. I really like understanding the full-circle context of something and then prototyping a solution to the issue. I think I could do that for a few years. I'll be interested to see what issues I still have inside big American companies, when I won't have as much as an issue with communications. I may want to try out a smaller company, or I just may need a better way of measuring success, which could come from being able to make decisions.

Photos

flickr > theplaz > Deutsche Bahn Internship Set

100_0590

[Slideshow]

[Map]

flickr > theplaz > German Trains Set

100_0531

[Slideshow]

[Map]

Report Card

[[File:DB MNL Logo.png|thumb|DB Logo]] [[File:TouchandTravel Home.png|thumb|iPhone Touch&Travel Home Screen]] I was an intern at [http://deutschebahn.com Deutsche Bahn] (the German national railway) during summer 2010 in Frankfurt (M). I worked in the PPX (project Mobility)/[http://touchandtravel.de Touch&Travel] department.

My boss had the title "Innovations Manager NFC." He was responsible for pushing NFC (Near Field Communication; basically RFID in cell phones) forward both inside the Bahn and with partners in Germany.

I worked on two main projects. First, I prototyped the look of the new Smartphone version of Touch&Travel and I developed the architecture for how the application could be securely integrated within their existing infrastructure. The look and the methods that I developed were scheduled to be adopted in the application. Second, I prototyped (mockups) and developed (PHP, MySQL, HTML, JS/AJAX) a concept for pulling data together from different data "silos" within the Bahn to give consumers quick access to data to make their trip easier. (Sorry for the generic language, but I am under NDA)

I also took part in business meetings between Deutsche Bahn and tech providers as well as potential partners. I discussed strategy before the meetings and I wrote up reports of how the meetings' content would help the project. [[:File:DB Final Reportcard.pdf|"Report Card" from company]] (Customary in Germany)

''See [[Touch&Travel]] to learn about what I did''

==What I learned== [[File:Wiping the ICE Windshield in Frankfurt.jpg|thumb|An employee is wiping the ICE Windshield in Frankfurt(M)]] Looking back, my experience at Deutsche Bahn was good. The job that my HR contact found me was very good; I think she brought me to the right position in the Bahn. I worked on projects both immediately needed and a further out prototype. I worked fairly independent, taking what I knew about the Bahn and converting it into a vision of what could be. Hopefully the management will follow the theme I demonstrated, and what I have made will make a difference in the world by making it easier for people to take public transit, thus cutting CO2 emissions. Unfortunately I can not write too much about the positives, since the joy I got from making them requires disclosing the details of what I did, which is not allowed due to the NDA I signed. If or when my work becomes public, I will update this.