System Engineer And What The Big Mystery Is

Have you noticed that a system engineer has somewhat of a different role in each company? And that in some places there are people in the R&D department who do not really know what the system engineer does in his day-to-day job (one of my CEOs once asked me with a very serious face “remind me again what you do here…”). Moreover, even the job title varies from place to place, in English and in other languages: System Engineer, System Architect, Technical Lead, Technical Coordinator (this one is rare, I must admit, but I have seen it somewhere).

I will start with a quote from a Mechanics team leader and for who I have, both professionally and personally, much respect: “let me remind you we have developed and manufactured quite a few products without a System Engineer or a Project Manager around”, which is, of course, absolutely true. Not every company or every project development needs a System Engineer around, and on the other hand many projects that do have a System Engineer may well have been more successful with him/her around.

A bit of history: The system engineer concept started sometime in the mid-20^th century, when the systems became larger and more complex and the industry needed technical personnel who could see the whole technical picture. It became a must in the military and air & space industries in the second half of the 20^th century as these were (and probably still are) the most complex systems around. Around the beginning of the 21^st century more and more multi-disciplinary companies and projects started sprouting, but it was not until around 2005-2010 that companies started demanding qualified system engineers and even raising their own in-house system engineers. You are invited to lookup the definition in Wikipedia for more info. BTW, it would be interesting to compare Wikipedia’s definition to that of this post’s content.

So, What Is A System Engineer?

The System Engineer is the one technical person who is responsible for the system’s total performance and manufacturing from start to finish. Total performance means everything: technical performance, customer satisfaction, serviceability, reliability, certification, regulation, safety, availability of materials, packaging, shipment – EVERYTHING from the technical side. And because of that “everything“, we need to know and understand all aspects of the product, since at any given point or another a certain aspect may have a technical impact which must be taken into account. From the client and his needs up to the last technical team and their needs we have to know everything and anything.

Obviously, we cannot know it all. Nobody can and nobody should. The different teams are the experts in their field: no one knows better about the SW than the programmer or the SW engineer who wrote the code; no one knows better about the electrical boards of the system than the HW engineers and so on. But we must know the little subtleties of each discipline in a way that each will always be before us and in our mind such that each discipline’s building block interconnects with another discipline’s building block.

Bear in mind that, in most cases, system engineer was not our first job in the industry. We usually had to grow-up as knowledgeable engineers or team leads in one or more of the technical disciplines before we are ready to handle the full technical leadership of a project.

Born or Raised

There is a question that always repeats itself in the industry: are system engineers born or raised?

On the one hand, the ability to look at a complex system and “see it all” probably cannot be taught. On the other hand, if you look at the more competent system engineers around you, you will probably notice that the more experience they have the higher is their competency. So which one is it? In my completely subjective humble opinion, a good system engineer is about 70% born and 30% raised. Right, the holistic point of view of life and systems is something that cannot be taught but even if that ability did exist, without some proper training and good engineering practices, no one can rise to be very good at his job.

Generally speaking, there are two kinds of system engineers, which often require different skill-sets:

• Product development System Engineer – the work of developing the product from the initial requirements stage till ready for production in Manufacturing. The skill-set needed here is more towards the innovative and research thinking.
• Sustain System Engineer – to ensure that the products already released in the field keep working, patch them up if needed and support every engineering issue that may arise either from the field or in Manufacturing. The skill-set needed here tends to be towards thorough understanding of existing technologies while maintaining an exploratory mind for causes and their effects on the product’s performance. A lot of projects that are born in Sustain Engineering eventually become product development ones, mainly when they have long timelines.

Both kinds are equally important for the R&D department and you can see the personnel jumping between the two types – a product development system engineer becoming the sustain system engineer for the same product and a sustain system engineer that goes on to develop the next generation product. Some of the companies even keep the product development system engineers on “sustain watch” with a few customers in order to keep them connected to the field.

System Engineer’s Roles & Responsibilities

To give you an idea of what our role includes below, but not in any particular priority order, is a list:

• Formulation of system requirements – translation of what the system must do into technical terms. The formulation of a system’s requirements is not a onetime event; during the development process we go back to it over and over. It is a “live” document so to speak. To refresh your memory regarding formulation of initial requirements I refer you to this post.
• System design & technical alternative search – we have to research which design alternatives are available that will cover compliance of our requirements, and design the system according to the optimal solutions we have found.
• Technical budget formulation – for each and every requirement in our list we have a technical budget: duration of response in a vision system, latency of a real time measurement sub-system, total amount of power, calculation error and so on. If and when the list of technical contributors comprises more than one discipline it immediately becomes the system engineer’s responsibility.
• Technical risk evaluation and follow up – one of the most important roles of the system engineers is to assess the possibility and impact of technical risks, having the knowledge of what technically could go wrong in the project or the product. This evaluation sets the priorities of the development process, the resources to be allocated in each stage of the project and so on. I will dedicate a separate post for the risk assessment and management process since this is an art in itself.
• Project risk advice – technical risks are in the system engineer’s responsibility; however, they have impact on the global project’s risks and globally the project’s risk have a direct effect on how we deal with the technical risks. For example, let’s say we have a risk that is related to SW implementation on the system’s PC. If Supply Chain are getting lead time of 6 months for PCs for our system this would impact the timeline of when we can integrate this PC in our integration process, which would force us to change the order in which we implement our integration, and may change the risk mitigation timeline. In such a case we would advise the project management how to proceed, and what the impact is of a non-technical risk or issue over the technical progress of the development process.
• Development plan – as the one technical persona that sees the whole development process, we are in charge of planning the developed process. If a Project Manager exists in the project this is usually done with him.
• Project \ Product Life Cycle technical management – development plan and execution are only a part of the product life cycle. The technical management of everything in the product’s life is handled by the system engineering department. That includes the day-to-day and weekly meetings of the technical teams, status presentation and reports.
• Sub-system testing \ unit testing – to be able to tell the technical effects of each sub-system we are in charge of the testing of the different sub-systems of the product.
• System testing – goes without saying. We have to know what is the technical performance of the whole system and to be able to tell if the system’s performance is in spec.
• System integration plan – the planning of how we integrate each and every component in our system, based on performance, technical risks and availability of the building blocks.
• Defect analysis & management – at each and every step of the product’s life cycle the system engineer must know which defects we have in the system and what the plan is to solve them (note that not solving a defect knowingly is also a plan).
• Troubleshooting – did something go wrong in the system in either production or in the R&D stage? We should oversee the troubleshooting process. This includes 2^nd level support.
• Resource priority formulation – we should recommend to the Project Manager how to distribute the resources available for the project. This point is merely a recommendation since the final word of where the resources go is the Project Manager’s.
• Supply Chain technical advice – when Supply Chain are trying to figure out why vendor A gives prices 50% higher than those of vendor B, we should be there to check the technical details and specifications to advise what is crucial for our project and what is not.
• Service plan – this point is a bit controversial. On the one hand, it is my opinion that a Service plan and strategy should be a part of the Product specification as it is a pure business case. On the other hand, there are inputs from the Service & Support department that must be translated into technical terms and these must be processed eventually by the system engineer so that they would get attention during development. From experience, we all remember that usually the Service features are the ones to arrive last and even turn into cases where we reach a boiling point and then the service features get their own product version (SW and\or HW).
• Testing \ V&V technical advice – as the ones who should know the system best, when the Testing reps start planning their test methods and plans, we should be there to support them. In this part of the job, I include also planning and coordinating ISO and certification testing.
• Reliability plan advice – very much like the Testing plans, we are the ones who know the interconnections between the different components, so we should be involved when it comes to reliability dependencies and their impact on the whole reliability of the system.
• Experiment \ simulations planning & execution – it does not matter in which stage we are in, be it troubleshooting or development, seed or 3^rd round, we have experiments that must be done and concepts to prove. It is amazing to see how much of this activity is directed towards the system engineering departments over the different companies and fields.
• Failure Mode & Effect Analysis (FMEA) – something goes wrong and we have to assess how it impacts the system and how the system handles this impact. There are many kinds of FMEAs, and we are either in charge or highly involved in all of them.
• Documentation – last but not least, just try to recollect when you received a SW library or a motor driver with a shitty documentation and that should illustrate the importance of documentation as a system engineer. It is not only the actual writing of the documents; it is also setting the document hierarchy and dependencies.

I am positive that there are more to this list, but these are the main requirement in our “job description”. If you look closely at the list, you can see that there is not a solitary discipline in the factory in which we do not have contact with at one stage or another of the product life cycle. This, therefore is what it means to be the technical conduit of the project.

It should be noted that these roles may change between companies, and even within the same company where different projects may handle the role distribution differently. Some of the responsibilities written above may land on the Project Manager, Product Manager or R&D Manager, some may be distributed between the other technical disciplines and some may be delegated to other disciplines simply because there are not enough system engineers around.

One other important note. System engineers sometime get mixed up with Project Managers or with Product Managers, because of the nature of our role. We have to make sure that a system engineer stays a system engineer and not turn into a position where, and here I quote a QA manager I used to work with, “he does not know enough about systems to be considered a system engineer, and does not know enough about the product to be Product Engineer”.

To summarize, if you want to become a system engineer, I highly recommend it. It is a very interesting function and plays an important role in the R&D process, with a lot of technical and, even though we are not officially “management”, managerial challenges. The role carries a great deal of responsibility with it as can be deduced from the job roles depicted above. It is a diverse and challenging job; for a good system engineer there are no two consecutive weeks in the office that are alike.