Building space for building teams

Inspired by a comment to one of my prior posts (You know that story of the Russian cosmonaut?), a comment about noise and getting into love with it, I thought it may be worth sharing some of our experience with building (office) space for building teams.

When we moved large-scale into Lean and Agile Software Development methodologies five years ago, the role and work of “the [cross-functional Scrum] team” got more and more important and we started to consider office space concepts that would better fit the new working model than our traditional 3-4 people offices that we had in some of our development locations (e.g. in the headquarter offices).

Colleagues were in search for collaboration space, needed spots for daily Scrum stand-up meetings and their Scrum boards, needed meetings rooms for the takt-start planning and takt-end review and retrospective meetings (all at the same time, of course). Also, we wanted to be able to move individuals easily and quickly around, if e.g. teams were changed or a UX designer was supposed to join a team, and we didn’t want to always wait for weeks to get an official move approved and implemented by facilities or contractors… “Grab your laptop and make yourself comfortable at your new spot” was the goal…

As a first try, we had experimented with 3 “team rooms” which had been set up by tearing 2 walls down and making 3 normal offices into a bigger team room. While the pilot teams that moved in liked the space after some adjustments for their team related work, it quickly became clear that a) they had only accepted the room because each one of them still had their original desk in their prior office room and b) the team room was “an island” that was missing support infrastructure around: ad-hoc meeting rooms the team could retreat into to not disturb the others, “phone cells” for phone conversations that were disturbing the others or private in nature. So we figured out that we need more than “team room” islands in the classical office environment, but a space for teams that has been designed for that purpose from the ground up.

That’s how we started the initiative called “Office Space for Teams” (OS4T), a collaboration of Facility Management, our central Lean unit and “the business”, i.e. parts of my R&D unit. The goal was to pilot concepts for office space particularly tailored at teams and their need for communication and collaboration, supporting innovation and creativity.

There’s meanwhile a short video about it on YouTube that you might want to check out (3 minutes) to get an impression yourself:

We quickly figured out that in a “Lean” environment, it would be stupid to not involve the main stakeholder into the whole design exercise: the Scrum teams themselves. So we ended with having a joint team from the three units above, plus external architects, plus representatives from the development teams themselves that gave input and guidance to the actual design the architects and interior designers came up with.

The declared goal was to emphasize “networking over nesting”, i.e. priority 1 was to provide teams with an environment that would foster communication and collaboration supporting innovation and and that would not make the individual’s wish for “nesting” the main goal. “Nesting” meaning: “let me alone, I want my private spot where noone disturbs me and I can ‘nest’ in”.

The area affected was two “H”-shaped wings of our building, seating around 280 colleagues before the remodeling. The restructuring of the old smaller office rooms, meetings rooms, coffee corner into a coherent overall concept, resulted in more than 30% additional workspaces, places where people could sit and work, simply due to the fact that a lot of space was “wasted” in the past with pathways to connect the offices. So the new design made better use of otherwise “dead” space.

I don’t want to bore you with the full story and all the nitty-gitty details — this goes beyond a blog post I fear and the video above may already give you a good sense of what Office Space for Teams is about — but share a few of the insights and learnings that we have made over the past months while “living” in the new space (I myself as well):

1. Open space for helping opening minds
If you want to foster creativity and innovation — and software development is a highly creative undertaking — provide the team with light, color, diversified and a haptic rich environment.
It helps getting into a creative and open state of mind. Sitting alone in a closed room, grey walls around you, a neon light buzzing at the ceiling and a steel door keeping everyone else out, is for sure not going to help make yourself more creative. Just to paint some extremes…

2. Flexibility is key
One of our goals was to make changing teams and “who sits where” easily changeable. One can think about moving tables — even though one has to acknowledge that there are health and safety regulations in place that forbid to place tables or workstations anywhere, have power lines crawling all over the floor etc.. But one can standardize on the workplace equipment, e.g. provide everyone with a (powerful) laptop and mobile rather than a workstation and a landline phone, have people use containers with rolls rather than fixed cupboards etc.. So that in practice they can move their own stuff within 5 minutes rather than waiting for 4 weeks for a contract mover to carry their boxes and IT to re-wire their workstation… So far, from what we’ve seen, things are flexible enough in our new office space and there wasn’t a strong demand to completely rearrange everything from ground up. We have changed team mixes a few times and people have been moving around quickly and easily. So it seems that one worked out.

3. Not all teams like such a collaboration environment
It seems that in particular teams, that rather are groups of people that work more or less independent from each other, consider a less “collaborative” environment more preferable as it is less distracting for them. If you’re in a team that is heavily interacting, e.g. because you are working in exploratory mode on a brand-new product idea, then the situation is very different. Feedback from such teams has been very positive. Which leads to the next finding:

4. Believe it or not, but people are different
No matter how well you design the workspace, people — and teams — are different. What works well for one, can be a pain in the neck for the other. So it seems advisable to provide people with enough “variation” of workplaces: some Design Thinking rooms for whole teams when in creative mode. Some more separated spots where individuals can work if they need concentration and don’t want to be disturbed. One developer wants to work rather isolated for a while, while others prefer to be more part of the group etc.. The only thing limiting what one could provide is normally space constraints. Or the fact that you won’t accomodate everyone’s perfect preference and still keep a team together locally somehow. Or finally the nasty constraint called “budget” — you cannot foresee everything and planning for the extreme case means usually “over-provisioning”. And this isn’t an option in most cases. So there’s always certain trade-offs to accept. And some learnings to be made.

5. People will need time to “settle down” in the new space
Whether you come from a completely open “cubicle space” environment or from a classical “two or three people in a room” one, you will need time to adjust yourself to the new setting. Also, people need to figure out how to use the space in the best way. We have one meeting room with bean-bag like seating, no table, just a projector at the ceiling and some whiteboard wall. Originally, the feedback from the team was: we can’t use that room. Later, when we wanted to actually change the room into a Design Thinking room, the same team came back and objected and wanted to keep the room as it was: because they had figured out what meetings were best done in that kind of setting (and liked it that way). And for other purposes they simply chose a different room.

6. Beware of the “library effect”
Being part of conversations is great. But only if it concerns your work. So while teams like the fact that you are easily informed about what’s going on in your team by “listening in” or being able to easily contribute, if the communication “flows over” from some neighboring team that is unrelated then it’s considered “noise”. So better make sure that teams are acoustically separated from each other. Otherwise you will quickly end up in what we call the “library atmosphere”: everybody is so concerned about disturbing someone else with their talk that no one dares to make any noise at all any more. The result is an artificially silent space: No one wants to speak because you feel everybody else in the room can understand every single word.
So the more open a space is, the better your sound design needs to be. Concrete floors and bare ceilings, as stylish this may be as an “industrial look”, are probably not a good idea while carpets, sound absorbing ceilings and “sound breakers” in the room can make a big difference. Some glass walls (or real walls) and sound-proof doors are a great idea as well from time to time. Not everything has to be completely “open”.
As a result, we have put glass walls around the “team living rooms” that were originally openly placed within the teams regular workplaces. The effect is that these spaces now get used for various purposes by the team — informal meetings, face-to-face discussion, reading, relaxing with a coffee after lunch… The glass walls shield sounds, but keep the open and light atmosphere overall.

7. Fun is a serious thing in Germany
So you have to plan for those things very thoroughly as well 😉 We turned some former server rooms into a pool billiard and a kicker room. Who works seriously needs to have some serious fun from time to time…

We have made several surveys with people after we moved in: If asked whether they want to rather stay in the new office space or move back into the old office layout, roughly 2/3 prefer the new one over the old one. This is after 15 months “living” here roughly. This result was showing up after we had done an intensive “care-taking” phase immediately after moving in, collected feedback from the teams and adjusted dozens of specific details here and there based on input we had received. We now consider the concept a success overall, with admittedly the potential for further improvements as mentioned above. There’s always things to improve…

So that’s my personal experiences with our Office Space for Teams project, without the claim of completeness or final truth. I love to work in the new office space. But that, of course, is personal preference and taste.

P.S.: Uh, I forgot, we heard some concerns about “private space” in an open office environment. Developers (sometimes even managers) are a creative species. Nature always finds it’s way… 😉

Think “Brain Surgery”. Think “Marriage”. Think “Three Sixty Kickflip”.

I’ve written about it before, but in late 2008, we started a major transformation of our SAP NetWeaver development approach, processes and organization: We made a bold move with my world-wide distributed, 2000 people organization to adopt Lean and Agile Software development methodologies in a large-scale, systematic and consistent manner. The transformation was a major project and I have blogged about it on the SAP Community Network before (see my blog posts Square One, Good Riddance and Different people). The transformation was a major effort over several years and is still ongoing today — Lean and Agile are a journey, a mindset, not a one time act of implementation. In the meantime, we have added additional methodologies, e.g. Design Thinking, into our set of tools and they actually fit very well with Lean and Agile.

When we started the whole transformation, we often got critical remarks from people in our own organization who were concerned that Lean was a methodology originating in production environments — Lean was invented by Toyota in the 1940s already — and was not a fit for Software Development. That’s when I started to think about how to convince people that Lean (and Agile) was more than something for the automotive industry. Even in retrospective and after having had hundreds of individual talks and discussions around Lean, I like my original storyline around Lean Software Development back then. And I thought it might be worth sharing… So here’s my “dog and pony show” presentation why Lean is relevant for any larger Software Development organization:

Lean Production goes back to Toyota. Taiichi Ohno introduced it first in 1940. It was originally targeted at manufactoring. A lot of criticism we hear about Lean in Software Development seems to come from the wrong perception that we would believe we can apply this 1:1 to our business. But we know we are not building cars – luckily!

We are in Software Development which is non-deterministic by its nature. It’s much more like animation movie making or modern architecture – you need to get the craftsmanship right, but more important to success is the creative and innovative character of what you are doing. It is a creative process, it’s an information creation process, learning is part of the journey and hence change is inherent to Software development. So rather than ignoring change, one better sets himself up to cope with it right from the start.

Nevertheless, what is common between car manufacturers like Toyota and us in Software Development is the strong desire to sustainably and profitably stay in business. In essence, it means eliminating all the waste that keeps you from maximizing customer value.

Luckily, we can look outside and see that a lof of people and companies in the same business as we have thought about and made practical experience how Lean Software Development can work. Just to name some examples: IBM has e.g. transformed their DB2 business, Salesforce.com has changed an 500 employee organization to an “agile development model” in recent years as well… And Microsoft has radically changed their way of developing e.g. their OS platform and development tools following lean concepts and agile principles. Mary and Tom Poppendieck have condensed their findings into writing and the following slides will explain in a bit more detail what the 7 core principles of Lean Software Development are.

The first thing to keep in mind is the fact that “Lean” is not a one-time activity, some procedure to implement and then you are done. It is about mindset and about sometimes surprising or seemingly counterintuitive thinking. It is for sure about continuous reflection on how you are approaching things. The foundation of lean is about continuous improvement and respect for people.

Principle #1 is to eliminate waste – and without going into details, all Lean Production “waste types” translate naturally into software development process “waste types” as well…

The second core principle is about learning as much and as early as possible and about correcting what you are doing. Like training to ride a skateboard in a half- or full-pipe: repeat often, learn quickly, adapt in the next cycle. Obviously, this principle gets manifested in fixed takt cycles, shipping working software early and often, involving stakeholders and customers from the start in each takt evaluating and giving feedback about the software, doing Scrum reviews and retrospectives to thrive for perfection in execution, looking at software development from an end-to-end perspective, etc.

Fooling yourself to believe you can predict the future or making decision based on premature information at hand, can be very costly to revert if you have to change plans afterwards. So core principle #3 is about making decisions as late as possible – but not later! One example is to tackle problems with a set-based approach, trying out more than a single solution in parallel, only later deciding on the best option. Or doing early prototyping and first getting customer/stakeholder feedback…

Core Principle #4: Deliver as fast as possible – both internal and external. It’s the-fastest-to-market who wins, not the biggest! It helps to avoid “inventory” on the shelf, gives you feedback early and allows you to put the right things into the next (short) development cycle – maximizing customer value!

Most challenging is “think different” probably for management – which is why we need “lean freaks” in management. It is about the insight that you get the best results, if you empower the teams, the colleagues who know best how to get things done, how to approach a certain goal. It is about respect for people. It is about getting rid of “process police”: you manage things, and you release people.

If you want to deliver fast and are dependent on fast feedback, if you want to maximize customer value, then quality cannot be an afterthought. You have to build quality into the product and the process simultaneously. And quality is more than defect-free software! It is about change-friendly code and architecture, about usability, about flexibility – it is about the integrity of the whole product.

Finally, think from a customer perspective – think from the delivery side. Don’t just optimize one area, but strive for making the whole a success.

To become “lean”, all of the 7 core principles have to be considered jointly, not “pick some, ignore the others”…

That’s why Lean and Agile make perfect sense in software development as well. Dear Automotive Industry — no offense meant! 😉

Long-living or rather living teams?

Another recurring question I have been running into and have heard heated debate about is whether our cross-functional teams have to be “long-living” (sometimes “forever-living”), i.e. they don’t change their setup and mix of people, or should rather be “living” in the sense of adapting them optimally to the changing tasks at hand. Do you bring teams to work or work to teams?

As I had written in my prior blog post before, a well-functioning team is a huge asset. So you don’t kill productivity achieved in such a team light-heartedly by ripping the team apart every now and then for arbitrary reasons. Rebuilding a team and getting it back into a high level of productivity is time-consuming and hence expensive.

At the same time, sticking to an existing team setup just because it’s a functioning team but seeing that the product priorities and goals have over time changed so much the current team setup is more of a misfit than a fit, doesn’t look reasonable either.

So somehow one needs to find a healthy balance between long-living and living team setups. As always, before triggering any change, why not empower those impacted and potentially best knowing what to do ideally, i.e. the teams themselves, and let them work it out on their own? 😉

To co-locate or not to?

In late 2008, we started a major transformation of our SAP NetWeaver development approach, processes and organization: We made a bold move with my 2000 people organization spread out into development labs world-wide to adopt Lean and Agile Software development methodologies in a systematic and consistent manner. The transformation was a major change effort and I have blogged about it on our SAP Community Network before (see my blog posts Square One, Good Riddance and Different people). Looking at where we stand today as an organization, our ability to deliver customer value, to deliver reliably, to adapt in an agile manner, to interact with customers and to innovate our product portfolio in a high quality manner, I consider this multi-year transformation a big success!

With the move to systematic, standard Scrum methodology within the organization, cross-functional teams moved into the focus of our interest. “Cross-functional team” meaning people across the necessary disciplines working closely together as “one team”, namely software developers, software architects, information developers, UX designers, Scrum Masters and Product Owners to name the usual suspects. The great thing about these “cross-functional” teams is the ability to optimize the interaction between everybody that you need at the table to get the product done: efficiently and effectively. The more closely we can get this team to cooperate and interact, the better. They will share a better understanding of the overall goal of what they are trying to achieve, communication paths have been shortened as much as possible, diverse skills will increase the ability of the team to develop better ideas and approaches to the problem at hand, delivering more customer-centric results. All of this is also supported by the principles behind the Design Thinking methodology. And last but not least, once being “standardized” on Scrum approach, you can start training and developing complete teams in certain further skills, e.g. agile test practices, increasing likelihood to establish new software engineering practices in a sustainable manner.

Well functioning teams are a huge asset! While we sometimes like to see software developers as creative artists that can barely be forced into any constraint — at least that’s the romantic point of view that I myself tended to fall into when I was still developing software myself –, a fact is that almost all bigger software development projects are not done by a single individual but quickly by a number of people that somehow need to collaborate to get something relevant done. So the infamous “lonely guy behind a door” is something one does not necessarily see as the ideal working setup if you want to keep your customers happy and your business secured. Well functioning Scrum teams with predictable and transparent progress on the tasks at hand can be a big relief here.

Most of the time where I have seen teams to be dysfunctional or failing, have less been a general issue with working in cross-functional (Scrum) teams but rather could be attributed to the following:

1. Bad cut: The team did not work on a common problem, but was just a collection of people working on unrelated individual topics; sometimes “cutting” teams in a different way made this issue disappear

2. Bad chemistry: There were individuals in the team that did just not buy into the team as such; sometimes just assembling teams a bit different made this issue disappear

Very often I have been hearing discussions about the question whether teams have to be co-located, i.e. all team members being in the same physical location, or could — or even should — rather be distributed, e.g. across different locations or timezones.

I think either position — when taken rigorously — is somewhat shortsighted. Here’s why I think so:

We form cross-functional Scrum teams to make the group internal communication and interaction as efficient and “personal” as possible and get diverse skills to the table. Of course there are modern means of communication like phone, instant messaging/chat, Skype, telepresence etc. that have made the physical distance less of a problem. Still, if you imagine that a team sits in the same office physically and makes use of these communication means mentioned, you would ask yourself whether it wouldn’t be more efficient to just ask the question across the table or listen in on some side-discussion going on spontaneously on the whiteboard behind at the wall? Would be strange, wouldn’t it? So while it is not impossible to work together even when distributed, it is probably more efficient to be co-located. At least in most cases.

At the same time, there are good reasons to accept or even actively establish a “distributed” team: e.g. if your product manager needs to be local to your customers in a certain region or a certain market. Or if there is specific or outstanding talent that you did not find “locally” but had to look for abroad. And this was considered more valuable than the potential loss in optimal communication efficiency associated with it.

So I think the important thing here is: there may be very good and valid reasons to accept that a team is distributed, but those reasons should be well considered and consciously decided. Not arbitrary “accidents”. And they must for good reason outweigh the benefits of co-location.

Rules should cover the common sense 80% case. Exceptions always apply.

Glory Days

I believe it’s the best times ever for software developers.

Software developers never had more influence than today. Look at companies like Apple, Facebook, Google, Amazon, Microsoft, SAP and others, to name just a few, that have made it into the top ranks of fortune 500 companies within the past few years largely based on software assets directly or indirectly. Starting as startups and outgrowing many other industry players by sheer speed and total market capitalization. All based to a large extent on the work and intellect of software developers.

At the same time, it has never been easier and cheaper for a software developer to get her hands at an abundance of hardware power for a bargain price and software components for free:

1. Cloud computing with hourly or resource based hardware subscription prices make upfront investments into expensive computer infrastructure unnecessary
2. There are few problems where there wouldn’t be a number of Open Source software components available on the Internet free of charge to be thrown at the problem you’re trying to solve. The tools necessary, you get for free as well.
3. You are not familiar with any technology used? No problem: There’s tons of information on the Internet, readily accessible if you have a rough idea what to “google” for. And if you are tired of reading, how about all the video tutorials on YouTube?
4. You need to market your product? It has never been easier and cheaper to get your message out to millions of people via social media.
5. Last but not least, the Apple Store or Google Play allow you to easily distribute your product to millions of potential users — and they even do the invoicing for you.

 

Back then when I started developing software myself, things were quite different. You had to invest in hardware upfront, software libraries and frameworks were rather the exception than the rule, the Internet did not exist and what you needed to learn you were teaching yourself out of books that you got in University libraries and bookstores if you were lucky.

I can still remember that during my first “professional” software project — I was freelance student programmer at SAP in 1988 — I was coding a graphical windowing system on my own as part of some graphical org chart rendering and manipulation product that connected to an R/2 Human Resource backend system initially and later to an R/3.

These graphical windowing systems were state-of-the-art on the computers I knew from home, a Commodore Amiga or the famous Atari 512, but if it came to Personal Computers in the office environment, the DOS console was still predominant. As Microsoft Windows was still not something to be assumed commonly available at customer sites, I had to come up with my own solution. So I coded a windowing library, mouse drivers, clipping algorithms, UI control libraries, printer driver code etc. What a stupid idea from today’s perspective, but back then? OK, perhaps it was even stupid back then… But nobody kept me from doing it 😉 The more concerning thing though is the following: How often do we make the same decision today? Re-invent rather then reuse? That’s why I believe Open Source is the way to go in many many cases.

“Back then” as a developer, you were basically working in a single programming language that only changed every few years. I started as a student in seventh grade with Basic on a Commodore VC20 that a friend of mine had invested into. Only to figure out quickly that the really cool and fast stuff needs to be done in 6502 assembler/machine code. I can still remember one family vacation as a highschool student when I was writing a hundred pages of assembler program “freestyle” with paper and pen at the beach in the shade to later on type it in when I was back home — LOL.

Later I switched to Pascal, Modula II, Java and C/C++ if it came to “serious” programming languages. It was only when I ported the ABAP kernel on all the SAP supported Operating System platforms from C to C++ compilation — I wanted to embed an XML parser I had written in C++ into it — that I blew up the kernel’s binary to a size of more than 100MB due to the C++ debug information required oll of a sudden. That was when someone wise pressed the emergency button and decided to promote me away from development into management to make sure I don’t create further trouble ;-).

Today, you have to handle a much bigger number of computer languages if you want to stay up to date with the trendy programming environments. The number of special purpose Domain Specific Languages is constantly growing, each of them often coming with their own specific environment and libraries, and JavaScript is on the best way to establish itself as the universal glue language not only between all the other domain specific languages and frameworks but also as a bridge between the gazing crater between client-side and server-side software development skills.

While in a way the fundamental principles and truths about software engineering and computer science have basically not changed over time, I believe that formerly as a software developer you were much more busy doing the nitty-gitty detail, from the ground up, fixing one screw after the other individually kind of development work and today as a software developer you are much more busy with “orchestrating” how you put powerful libraries, components and frameworks together. It’s like getting from building a car in a handcrafted manner to industrial mass production of cars from pre-fabricated components. The impact you can create as a single software developer, as a team or a software company, is by factors bigger than a few years ago.

What hasn’t changed though, is the enormous fun and satisfaction that comes out of the creative work that software development meant back then and still means today. “Look, mom! Look what I have created!!!”

Hey, how come I feel so old all of a sudden???? 😉

Life’s a Marathon — The SAP Community Challenge Fund Raising Campaign #sapcc

Life’s a marathon. You need courage to start, strength, endurance and will to pertain and a bit of luck to be successful. Not all of us have their share of luck though.

That’s why Susan Keohan, one of our esteemed SAP Mentors, has initiated the SAP Community Challenge Fund Raising Campaign during SAPPHIRE NOW 2013 benefitting Doctors Without Borders.

During the 3 days of SAPPHIRE NOW 2013 from May 14-16 in Orlando, Florida, all the participants who sign up for the challenge will contribute to the fund raising by logging footsteps made, kilometer covered running, coffees consumed or any other “challenge” they come up with.

Susan put it like that:

“It is well known that over the course of the conference, attendees will be logging some serious footsteps. Some may even organize into morning runs – before the heat of the day can beat on us. Practically everyone has a smartphone that can track your distance or some other device like a Fitbit that will also track it.

If you will be doing enough running or walking, and prefer to track something else, how about how many coffees you consume, or how many evaluation cards you fill out after a session?  Or how many SAP Mentors you can get photographed with?  
You decide – anything that is fun, OK?”

I personally will contribute to the challenge by running and counting the kilometers covered. My goal is to go for the marathon distance over the three days of the Sapphire Now event. Let’s see whether I go beyond ;-)…

At the end of Sapphire Now 2013 in Orlando we will do the math, sum up all the contributions made, e.g. kilometers run, and make a corresponding donation to Doctors Without Borders based on our individual commitment.

Want to join and support the campaign?

If you want to support the campaign with your own contribution, either as participant or as sponsor of one of us already signed up participants, please don’t hesitate to sign up at our SAP Community Challenge Fund Raising site on the SAP Community Network or drop me a note that I should enter you…

THANK YOU FOR YOUR SUPPORT!

Enough…

… of the cold. 10°C yesterday when I was out running, now we’re back at 2°C. It’s a freezing cold Siberian wind blowing from the East that takes all efforts to stop me, creeping through my soft-shell jacket, showing no merci with me. I feel like a turtle that wants to hide its head away in its shell, trying to minimize the skin surface that is exposed to fierce nature. For a moment the question passes my mind why I am out here? I wish I were 5725 miles away, somewhere warmer and less windy. But then I tell myself that I am not that easy to break. So all of me retreats into my inner shell, cutting myself off from the surrounding, my eyes locking in onto the trail ahead of me, my feet mechanically pushing me forward like a clockwork. The cold air hurts in the lungs with every breath and forces tears into my eyes. Which are nicely complemented by the song that I have chosen to keep me running today because of its powerful beat: Dry Your Eyes from Angels & Airwaves. LOL 😉

Sometimes, especially when traveling and in spots where I have not been before, I love running because it’s a beautiful way of exploring the surrounding. You take a steady pace, not too fast, and just keep going while you let your eyes absorb the scenery: a city just waking up early in the morning and people pouring out of the subway on their way to work, the illuminated shop windows in a main street at night immersed into magic neon light, majestic mountains encircling a lake in the Alps. When in “exploration mode”, I keep running and my mind nearly feels like floating around freely, open, curious, all around, going here and there, just absorbing. It’s a great way of finding out more about new places.

But sometimes, like today, when you know your way by heart, if one could send you out there with your eyes blind-folded or at pitch-black night, because you know the trail by heart, you’ve run there a hundred times, know every pothole you need to avoid and every tree root you shouldn’t stumble over, and if then the weather seems to have made plans to play games with you, then running is the exact opposite. Then I lock myself in. I don’t look left or right, just straight down in front of me. I put the music to maximum volume, have some song with a decent pace push me along, every part of my mind concentrated somewhere inside me (hopefully the head ;-)) and there is just one thing to do: Keep running. Forget all the rest. And keep going.

I like it both ways. The latter one is a bit harder to your will. But if I get into it, and add a bit of anger about the cold, or the wind, it’s the perfect mood to push myself over the limit. Just like today. Because when you start against the wind, and as usual want to return home after a while, the wind will have to blow in your direction at some point in time, no matter what. And that makes you just “fly” back home.

It got dark by the time I return back home. What a lousy weather. Enough of it now. Let spring come please. But for now I feel — fantastic again 🙂

Are we in for a long wait?

Alice: [in the emergency room] Are we in for a long wait?
Dan: [indicating an old woman] She was 21 when she came in.

[From the movie Closer (2004)]

I’ve never seen her more lovely.

“When I was a child growing up in Salinas we called San Francisco “the City”. Of course it was the only city we knew, but I still think of it as the City, and so does everyone else who has ever associated with it. A strange and exclusive word is “city”. Besides San Francisco, only small sections of London and Rome stay in the mind as the City. New Yorkers say they go to town. Paris has no title but Paris. Mexico City is the Capital.

San Francisco put on a show for me. I saw her across the bay, from the great road that bypasses Sausalito and enters the Golden Gate Bridge. The afternoon sun painted her white and gold rising on her hills like a noble city in a happy dream. A city on hills has it over flatland places. New York makes its own hills with craning buildings, but this gold and white acropolis rising wave on wave against the blue of the Pacific sky was a stunning thing, a painted thing like a picture of a medieval Italian city which can never have existed.

I stopped in a parking place to look at her and the necklace bridge over the entrance from the sea that led to her. Over the green higher hills to the south, the evening fog rolled like herds of sheep coming to cote in the golden city. I’ve never seen her more lovely. When I was a child and we were going to the City, I couldn’t sleep for several nights before, out of bursting excitement. She leaves a mark.”

FROM John Steinbeck, Travels with Charley, 1962

[Teton Gravity Research Aerial Reel – The Bay Area in 4K from Teton Gravity Research on Vimeo]
Tip: Maximize video to fullscreen! And don’t miss lighted Bay Bridge at around 2mins 45secs…

Maybe this will be my year…

Today’s the day. As if the gods had known it and are for once supportive to me, the sun’s shining when I wake up. It’s still only 2°C outside, but boy, the sun is shining. Finally. Today we will have our first rendezvous this year. Like every year on April 1st. The day starts with an appropriate breakfast — pankakes, maple sirup, icecream, orange juice, and a cappucchino, to get into a mix of Californian and Italian feeling. Ready for our day.

It was a Monday as well. April 1st, 1996. A very remarkable day for me actually. It was my first day as an employee of SAP Labs LLC. At the time still in Metro Tower in Foster City, before SAP Labs moved to Palo Alto where it is still today. I had just finished my Computer Science studies at university and had been working on connecting the SAP R/3 system to the Internet as my diploma thesis, when this whole thing turned out to be the start of a development project at SAP: the Internet Transaction Server. It makes for too long a story, but I ended up having the opportunity to come to California and work on the project at SAP Labs for 3 fantastic years. 

When I open the garage, she’s still there. I am relieved. Sometimes you wonder how you would react if the door opened and she was gone. Just a small pile of red rust left on the floor. Where she had been before. But she’s still there. As I have left her last October. Hidden under a red cover. It’s almost a celebration to uncover her. Carefully pulling the cloth off and revealing her step by step. Till finally, she’s back in old beauty. A bit older, but who isn’t? Still in perfect shape and her eyes blinking in the sun… She’s my 1969 Alfa Romeo Spider 1750. A real beauty, I think.

I can still remember how exciting it was to arrive in California and start living and working there. Everything was a new experience and needed to be explored. I only knew San Francisco from the movies or stories I had heard and now being there, visiting the City in all its beauty, absorbing the buzz and the new impressions was for sure worth an experience. That’s when my love for the City got started. Love at first sight. She really left a mark with me.

Some careful wipes with a soft cloth to get the last signs of winter off — some dust here and there. We need some checks of fluids and the battery — still fine. So I carefully take a seat behind the steering wheel. Insert the car keys, send a prayer to heaven and turn the ignition. The engine gives it a try, but only for a split second. We try it a second time. Nothing. Hey, we’ll need some time together again, as it seems. Lot’s of talking. Begging. And finally, I’ll get her started… Not very smooth yet, but we’ll get there. As every year…

We worked in a small team. Just four guys and a mission: Get the product ready in no time. I can remember how we worked like crazy: Thomas G did the development and benchmarking tools, Michael B did the R/3 specific protocol adaptations, I did the server core and the installer and Michael H took care of all the rest, including our travel itineries to Germany and back every few months. Some days we worked through all night, just to get the next milestone done or reach yet another looming deadline. It was the best team I ever worked in. The most influential project that I ever had the opportunity to be part of. Lot’s of hard work, but also lots and lots of fun! 

So finally, after some time getting warm with each other, we can take off… Leaving town behind us. Driving through the open fields. The cold wind blowing around my head, the wooden steering wheel feeling nice and soft in my hands, the sun above, the heating slowly getting warmer from below. It’s that very special feeling again. The one that makes her so unique. And she’s getting into it as well. Her engine gets warmer and runs smoother and smoother with every mile that we pass. She’s back to life. Finally. I think we’re getting into it again this year. It’s all memories and nostalgia about previous summers we’ve spent together. It will take some time, but we’ll get there again. We’ll have a great time together.

The three years passed like nothing. For some or the other reason the decision was taken to go back to Germany and not stay in California. It’s difficult to tell in retrospective what set the trigger. Many reasons coming together. But I guess you have to loose something first to really learn to appreciate what you had. Till today I wonder from time to time why I didn’t stay in California? How would my life have been since then? How would it be today? What opportunities did I miss? Was it right to go back to Germany? But then, in the end, I tell myself that it doesn’t matter. Decisions were taken differently at the time. Even though it was one of the best times in my life, it’s the past. And so things are as they are. What does it help to speculate about what could have been? It’s all memories by now. The only thing one can influence is the future.

So Maybe this will be my year…