What’s between geography, system integration, R&D and human resources trends?

I acquired my first major back in the late 1990s in Electrical Engineering and Computer Sciences. Already during my academic studies I started working in the high-tech industry as an Integration Engineer in Gilat Satellite Networks. I was responsible for bringing together various components of hardware, software and RF, and testing the integrity of the system as a whole, as well as the functionality of its individual components. I built customer tailored setups, examined new components and their affect on the system, detected problems and suggested improvement ideas. I used the broad knowledge I gained about the system for customer installations, training and support.

For years, I believed that it was the right job, as it enabled me to pursue my hobbies of travel and world exploration, geography MA studies and environmental activities: I felt that all aspects of the work as an integration engineer did not require much effort, and were almost a second nature, so my mind was free for the other disciplines. People were always puzzled: “what’s the connection between being an engineer and studying geography”. Although I didn’t feel any contradiction, I never gave it too much thought. I usually replied: “One for the kitchen, one for the soul”, which sounded right, reassuring a good work-life balance. What baffled me, though, was that I was never really attracted to development work such as programming. I enjoyed it when I briefly did it during my studies and more broadly as part of a final B.Sc studies project I did at Gilat, writing a new management system module, but I did not feel I want to do it further.

It took me about ten years to understand…

A while back I had one of those techies conversations with a good friend – originally a software engineer, who has been working as a technical manager of a new product in the unmanned aviation industry. I noticed that on our latest interactions he passionately tells me mainly about problems in the system, and how they detect, investigate and solve them. I should mention that although not traveling extensively like I do, he has a good sensitivity and exploratory nature as a traveler, likes bird-watching, and stories about his challenging parts of past travels still dominate our close friends’ group meetings.

It then struck me that what I was doing as an integration engineer was exactly what I was doing as a geographer-traveler. It was not  “One for the kitchen, one for the soul” (well, of course high tech salary supported travel…) or “one for the left side and the other for the right side of the brain”, it was simply doing similar things. The geographer-traveler explores specific places and phenomena and builds a larger picture of earth and its systems, may take it a step further to pursue environmental improvements, using interactions with the ‘natural system’ and people to do it. Both disciplines – system integration and geography and exploration start with curiosity, sensitivity, exploratory character and a general desire to make things better. Saying that system integration was “a second nature” for me, couldn’t have been more literal…

Now let’s dive a bit deeper. When you travel, you can do it in two different approaches: one – a very orderly manner, where you meticulously plan your schedule, the other – roaming spontaneously and letting places and interactions lead you. In the former approach you may not miss what you intended to see, but you might miss great unplanned experiences you could not foresee. The latter approach brings you great experiences, with the price of missing some “known” sites and sights. If the former is a quantitative approach for tourism, the latter is more of a qualitative one, and I should mention that as a traveler, the latter approach has always brought me more joy and satisfaction from the trip.

Back to system integration. When you test a system you can do it in two methodologies. One is by meticulously writing test procedures which aim at covering all potential scenarios and then carry them out. The other is doing unit testings or simply using the system and carefully monitoring what it’s doing. As an integration engineer I used both methodologies, but I can definitely say that we discovered most of the main issues by a spontaneous use of the system, and not only that – doing this was faster and more enjoyable than spending hours writing documents only to discover minor issues. Well, we said that the first approach is ‘quantitative’ and the second is ‘qualitative’, and it’s all about QA – “quality assurance”, isn’t it..?

But seriously, the more complex systems are, the more difficult it is to prepare test scenarios ahead and expect that they will cover all potential bugs and ensure system integrity. In interconnected systems with various components, many problem sources cannot be anticipated, therefore a thorough use of the system is required. Of course a good integration engineer will use both approaches, knowing when and where each approach is suitable.

 Let me remark that my MA thesis was in “Geography of Telecommunications”, analyzing traffic in a Gilat satellite phones network in rural Peru…

Now it’s time to look at another aspect of technology industry – “Research and Development”, “R&D”. Usually one department in a technological company, but actually occupying several different disciplines. The researcher is the curious, sensitive, exploratory character who deals with the existing, and wants to tell something about it to the world. In that sense, someone responsible for studying existing and evolving technologies, or someone who does business development, as well as system integration people – all share this same notion. The developer (in the mere engineering aspect) is the punctual, goal oriented character who deals with the new and needs to actually build a system that gets a certain input and provides a defined output.

Since these are totally different approaches, we usually have ‘intermediate’ positions to bridge between ‘the existing’ and ‘the new’. A product manager, for example, understands the existing state, the technological need and potential, and translates them to product design and specifications.

The use of the term “development” is confusing in this case, since the common meaning of develop is “grow, advance, expand, progress, evolve”. The term “developer” in a technology company usually refers to the person who actually writes code that implements specifications defined by other roles in the company – system architects and  system engineers, who themselves are guided by product managers and support personnel – and they are the ones who actually lead the development of the products, although sometimes they seat outside the R&D department…

Are managers and human resources personnel aware of these characteristics? Do they see the resemblance of occupations such as journalist, documentary maker, geographer and integration engineer? Do they really distinguish between a “developer” and a developer? Is it reflected in the company’s organizational chart?

I doubt it.

While in start-up companies this is less relevant since few people do everything, and while cutting edge high tech companies like Apple understand the contribution of artists, most companies hold a pretty narrow minded old fashioned disciplinary approach when they recruit and assign people to positions and build teams. The dichotomy of disciplines and the inaccurate and misleading definitions of positions is a barrier to clever recruiting and manning of positions, and further to the success in carrying out missions. In the global era of everyone and everything interconnected, a flexible interdisciplinary approach is needed.

Unfortunately, as recruiting processes become more and more mediated, with algorithms judging people’s destiny according a word they included or forgot to write in their CV, we are going in the wrong direction. A quick look at LinkedIn, currently a leading recruiting tool, is enough. If you are not an engineer, you are not there.

In the era when people breath technology anyway, companies should look at other qualities rather than a software engineering degree, a love for shiny gadgets.