originally posted on one of my several now defunct blogs, called On Engineering on 7th May 2012
Terracotta Warriors By xiquinhosilva - www.flickr.com/photos/xi… CC BY 2.0, commons.wikimedia.org/w/index.p…
As an Englishman living and working in Heidelberg, I am often asked if I work for SAP, the business software giant based down the Autobahn in Walldorf. I don’t, of course. If I did, I’d be writing about software development, the management thereof and how utterly astounding their legendary canteen is.
The question is not a daft one, though: around 10 thousand people work at SAP, forming a more or less willingly thrown together (or at least well-paid) melting pot of 80 nationalities with English as the working language. It’s easy to assume, then, that a middle-class, technically minded foreigner living in Heidelberg earns his crust and her Grauer Burgunders at SAP.
I know a few people who work at SAP, and they are generally of a particular ilk (physicists and mathematicians, i.e., not my type) so I know that I don’t need to yearn to work there, but there’s one thing I envy them: resources for R&D. Globally, (2011 figures) SAP has 16 thousand employees working in R&D (12 thousand work in sales…).
16 thousand in R&D…
(drifts into a reverie)
(Snaps back with a jolt)
I’m not in that place. I am a development engineer at an automotive supplier; my development activities really only skim the outer atmosphere of the unique world of R&D. Is this a surprise? Is it a disappointment?
Let’s think about the surprise factor first. When I consider my time at university, I don’t recall ever having heard the word “resource” discussed in any manner other than as a general term for learning material. We picked up the material, used the libraries and even the nascent internet; but I was never a resource myself.
Resource was always a “hidden” theme. We were aware of time pressures with the need to study such a wide range of subjects whilst maintaining sanity and health through extracurricular pursuits, but it was always a case of everybody finding their own balance.
My aerospace engineering course did involve one larger team design project that was formative, but as far as I could see, research projects could run in a business vacuum, free from excessive emails or telephone calls, requests for assistance from around the world and quality alerts to have to jump onto. Ah - there we go. Did you notice that word in there, mentioned for the first time in this post? Team.
Entering the workplace was a relatively soft jump for me: I joined Ford in the UK which at the time was recruiting heavily - and, crucially, I joined a team. By that I mean there were several of us who could do each other’s jobs, if necessary and we worked both on improving the product and on improving the ways we worked on those products.
Recently, I was part of a globally distributed team that developed a new procedure for drawing release and approval. The word ‘team’ in this case represents more a collection of perspectives than anything that could really work to fight the necessary fights. We had representatives from design, from quality, from manufacturing; but none of us were interchangeable in the way that my team position at Ford was.
Developing the process itself was the fun and interesting part. I managed to find a spare license for Microsoft Visio (alas only the 2003 version which is now looking very old indeed) and used it to create the workflow. As it is a cross-functional process, the workflow runs in lanes - development, manufacturing engineering and quality - so the visual aspect was initially quite appealing. Adding the “if… then” loops and the different entry points for product at the various stages in their drawing lifetimes certainly de-streamlined it, though.
But actually running the procedure has been no fun at all. The problem is that it was implemented as a project in itself without great consideration for the resource implications of centralising what was in effect a totally distributed (and therefore wasteful, if potentially evolutionary) process.
So the current situation is that I am currently the only person in a company of over 16 thousand who can create the drawings that those 16 thousand people need. Imagine SAP setting up a system whereby those 16 thousand in R&D could only work if I finished one particular task amongst many. It wouldn’t really make sense, and this is something that I’m struggling with at the moment.
And so to my second question - am I disappointed not to be part of that resource pool? In a word, no. It’s harder to explain, but perhaps this is only because of a lack of imagination: I simply cannot imagine being able (or only being allowed) to work on one problem at a time. Whilst I am trying to relearn the art and discipline of focus, it doesn’t come naturally to me. I thrive on bandwidth, even if the transmissions occasionally get muddled up and jam because of it. I’m a variety type.
Coming back to those cohorts of SAPlers, though: despite their numbers, there have been reports recently that even they are feeling pressured to breaking point in their jobs. Which means that you can spread even 16 thousand researchers thinly. R&D resources generally expand to fill the product lines a company is working on; even within the relatively low number of headline products SAP produces, there is a vast number of modules that require development and linking in to others, so there’s plenty for lots of clever people to do. (Google has around 33 thousand employees, Microsoft 92 thousand, of which 35k are in R&D).
So today’s R&D behemoths are commercial, distributed amongst the universities and amongst the startups that thrive or die on their findings; I’m somewhere in no man’s land - where are you?
p.s. Happy 40th, SAP!
