A silo-based attitude to recruitment not only artificially limits personal development but also stifles innovation.
The certificate shown below was recently given to me by the managing director of a successful meetings and events company. It marks the end-of-life for a project that a colleague and I developed in August 1998; it entered service around two years later. Not a bad track record for any software product.
Interestingly enough, we only got involved through a family connection. The company faced a challenge with reliable IT sourcing and needed someone to trust. We were hardly the natural candidates based on technical merit because we came from a background of desktop-based metrology and process control applications. There’s not an employment agency on earth that would have put either of us forward for an interview. But it was the human connection that won through, not the technical one.
We perhaps began with some trepidation, not least because a call center was an alien environment for a couple of software-minded mechanical engineers. But very soon, things started to feel surprisingly familiar. We established requirements for the project by talking to people. We then planned the project and designed it, just as you would for mechanical engineering applications.
Some of the technology was familiar, and an MFC-based front-end saw that. However, the SQL database was a whole new ballgame for both of us. That didn’t faze us, though. It was just software, something to be learned and conquered. And, as the certificate shows, we were successful in not only something that worked from the start, but in creating a system capable of growing and evolving with its owner.
A few years later, we saw the dot-com boom of the late 1990s. This time, a friend told me of a vacancy while watching a football match. Despite the apparent mismatch, the opportunity was afforded to me because software skills were in such a short supply that I came closest to fitting the bill.
Again, trepidation and another learning curve. And again, there were new things to handle. This time, it was a deep and dirty connection with the hardware, which was all alien territory for someone with a background as a mechanical engineer. There was a new set of terminology and strange equipment to learn. But again, the bottom line was that at least 85% of it involved the same problem-solving skills. It was just software.
Fast forward further, and I found myself employed as a field application engineer (FAE), traveling throughout the world, supporting people in the use of a tool employed in the development of safety-critical applications. Even in this specialized sector, there are different silos to contend with. Each of the safety-critical industries has its own ways of doing things, with its own terminology and functional safety standards, including ISO 26262 for automotive, IEC 62304 for medical devices, EN 5012X series for railways, and so on. Yet, here too, there is far more in common between them than factors that set them apart.
Users of tools like those provided by LDRA benefit from that commonality between sectors all the time, perhaps without knowing it. Many automated techniques—static analysis, code coverage analysis, and automated unit/low-level test—first saw action in the analysis of DO-178 applications. By the time the plethora of derivatives of IEC 61508 was published, the techniques were well proven and available to new practitioners, even when the standards themselves were new.
No one would have mapped out my career path, least of all the employment agencies who are so often required to tick as many matching boxes as possible. But sometimes, coming from a different sector or a different industry altogether can bring a refreshing new angle to the day-to-day problems that are always tackled in a particular way because “we’ve always done it like that.” Certainly, I would fervently argue that the diversity of my software experience has benefitted everyone I have worked with—and for—along the way.
A few years ago, my employer was looking for a new FAE to join our team. I just knew the guy. He ticked so many boxes, an ex-teacher who could deliver content. A techie’s techie, who wrote compilers to entertain himself at the weekends. Someone who knows as much about the intricacies of the C and C++ languages as anyone I’ve ever met. And yet, despite that, a sociable guy capable of making the shyest of people ask the question that they fear would make them look silly. In short, he’d have been brilliant at the job.
He submitted his CV, which made it very clear that he had no embedded software experience despite his demonstrable technical excellence. At the first interview, he was questioned about that, and his application was dismissed.
That’s a microcosm of an approach that I suggest potentially deprives employers of a team that is bigger than the sum of its parts. Assembling a collective of people with the same primary attributes and perspectives surely discourages lateral thinking and new problem-solving approaches. Ultimately, a silo-based attitude to recruitment not only artificially limits personal development but also stifles innovation.
This article was originally published on EDN.
Mark Pitchford, technical specialist with LDRA Software Technology, has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.