From management point of view, System Engineering is a very interesting and complicated entity in the R&D process. Mostly, in the industry, System Engineers are not managers by definition unless they are defined as Technical Leads and even then, the System Engineers do not directly manage the R&D team members. Nowadays the structure of development teams is multi-disciplinary in a way that in many cases the only official “manager” of a certain development process is the Project Manager (PM) and even that person has to compete with the direct managers of the different R&D team leaders. Having said that, in some miraculous way the R&D team listens to the System Engineer and follows his\her instructions – to a point. So today in my post I will try to cover where that point lies and why. Although the following text refers to the specific interactions of the System Engineer with the rest of the team, note that any tips given in this post are also relevant for a PM and/or any other official or non-official management position.
How come the teams lets the SE be a technical lead in the first place?
Let’s begin with what I always thought of as a mystery: how come the R&D team members follow the System Engineer’s instruction to begin with, even in cases with more experienced developers? I think the source of this mystery is divided into 2 parts i.e. cultural and personal. In recent years, the culture that evolved in multi-disciplinary R&D teams is that the System Engineers are in a way the leaders of the projects when it comes to the technical (and sometime not so technical) stuff. Add to that my personal observation that most of the people that became System Engineers and survived the wrath of the PMs and R&D director to stay in that profession are usually technically broad-minded engineers with a good few years of experience behind them. These two phenomena together are the pillars on which the inherent authority of the System Engineer is based. Have you ever wondered why soldiers in the army blindly follow their platoon commander even after the army service is over? The army culture is that you follow your platoon commander’s instructions while those chosen to be commanders are usually the ones with the ability, in army standards, to make the right choices. Fortunately, we are not in the army (not in the army anymore if I may add) and the professional world is “slightly” more flexible and open minded 
.
We have to remember that the interactions between you and the R&D team do not live in a void. So here are a few tips on how to maintain these interactions such that everyone in the R&D team will come to the office in the morning with a smile and similarly in the evening go back home with a smile while maintaining the project objectives led by the System Engineer.
Be Courteous & Respectful
At the outset, I must point out that I am not a behavioral coach and this is not the intention that of this blog. However, I have noticed that in certain cases engineers lose their respect for their peers when they start rising up in the ranks. Remember what Uncle Ben said to Spiderman – “with great power comes great responsibility” (we will cover the responsibility further down this post). Great responsibility does not mean condescending behavior. Explain and require but don’t command. When things are bad and have to be delivered in the form of a demand, try to deliver it to the team in a manner where “we are all in the same boat” and not as “do as I say because I know best”. It is important to note that not all your team members will be as courteous as you are. If I may quote one of my former SE mentors, “none of us is here because of his social skills and personality or his beauty for that matter”. You may get at times an amazing professional with shitty social skills but even then, keep your respectful manner.
Be Available
No matter how overloaded you are and how many tasks you have to push back due to lack of time, try to be available for the team as much as possible. When someone in the R&D team needs an answer for some kind of a technical query it may end up in exactly two ways: either it comes from a certified source or it doesn’t. If you are the most qualified point of contact for these questions or you know who is and has the answers make sure to communicate the information to that team member. If you turn your colleagues away too many times, they will stop consulting you, and eventually you will stop being on top of things.
Be Professional & Knowledgeable
Make sure you are completely fluent with the system requirements, development plans and processes, integration plans and everything else inside your realm.
Keeping within this line of thinking, know your system’s core technology. If you are not familiar with it, sit down and learn even if this tech is not within your technical expertise. I will elaborate: say, if the core tech of your system is a single mode laser, even though you may not be a physicist get to know everything there is to know about single mode lasers. If the core technology involves high speed signal processing, even though you may not be an electrical engineer get to know about it.
And last but not least, don’t make up answers. It is better to say you don’t know and search for the answer than to make something up that is inaccurate.
I could have started my tip list with this paragraph, but I truly believe that for a system engineer inter-personal behavior must come first.
With great power comes great Responsibility
Stan Lee, Spider-Man, Amazing Fantasy #15, 1962
Be Responsible
I think that this goes without saying. Be the rightful owner of your tasks. Take ownership of your mistakes as you would and do of your successes. Any confidence or respect you may have had will be lost very quickly if you take ownership of a success story that is not yours or, conversely, put the blame on others for your mistakes. Furthermore, the more corners you round or cut the more corners you will see being rounded by the rest of the R&D team. Responsibility in this sense also means setting an example.
Listen
In nearly all cases, the system engineers must need the technical experts’ constant advice. A good system engineer keeps his ear in listening mode to identify better solutions or potential problems. A good listener reads also between the lines. Try to get there to get the best from the R&D team.
Protect & Support The Team
In multi-disciplinary companies the different teams usually work in parallel on multiple projects. It often creates conflict on the personal level of the engineers. Working closely with the R&D team enables the system engineer to be the one who feels the pulse of the team. As such, when the team is overloaded, worn out, does not get the right work-life balance you are in the position to pass this info upwards to whomever needs to know and make sure that the team members are getting the well-deserved rest that they need to perform to their best abilities or a nice bonus. Now, let’s be frank, sometimes you will be able to take some of the burden off the team and sometimes you won’t. The system engineer is in a unique position such that with a bit of sensitivity may be the one behind the scenes that takes care of more than just the technical stuff. BTW, I did not make all this up – I often see the lead engineers (not necessarily system engineers but usually it comes from the system) take care of the extended R&D team more than just in the professional day-to-day needs. That is leadership. It is an acquired attribute, but once someone in the team has it, it will make you and the R&D team work better.
Keep Periodical And Non-periodical Meetings (but only when required)
This is a simple technical tip. Conduct periodical meetings where everyone may share their problems and success stories over the past week. If you lead them correctly, the team will be looking forward to these meetings and these meetings will become very productive. The main point here is that if there is no need for such a meeting on a specific day, do not conduct it. If the team feels you are wasting their time you will find yourself hopelessly running through the halls trying to get the team members to join your meeting.
Looking closely at the list above, you may notice that only 2 tips are purely professional or technical. The rest are in the realm between behavioral soft skills and team leadership. That, in my opinion, is the essence of system engineering: it is not a pure technical position and as such we may not neglect the applied day-to-day inter-personal relations with the rest of the R&D team. Some system engineers even refer to the R&D team as “their team” although obviously it is not exactly so.
To sum up, if you are a system engineer in the beginning your career, be professional and courteous and let the team guide you if you were not born an SE. On the other hand if you are an experienced SE and are considered a good one by your peers this post probably didn’t tell you anything new – pass the knowledge on and mentor the young ones so they too will become good SEs. And always remember, the two most important things are to achieve the project’s objectives and go home with a big smile every day (not necessarily in that order…).