wiki:Playbook/SystemsGuide

2537 Guide to Systems Engineering

Memoirs and Advice from a Past 2537 Systems Engineering Lead

Note on titles and roles: the different leadership positions that I refer to are from the 2017 season, described more in "Interactions with Leadership."

The systems engineer/lead is a nebulous but well-defined role: at first glance, the job descriptions are vague and unclear, but anyone who has been a (good) systems engineer immediately is able to grasp the boundaries of the role and realize precisely what things fall into the domain of the systems lead and what falls only into their sphere of concern, but not their sphere of influence. If you don’t understand a part of the role, ask a mentor! Most have worked with or as a systems engineer, even if they’re not in the technical field (read: don’t be afraid to ask even NEMO mentors about this technical role).

The systems engineer is primarily responsible for the successful execution of projects from start to finish, especially the main robot project; this is a technical position, wherein they manage all aspects of the entire project (but not certain logistical aspects--this is covered by the project manager).

Explicit Responsibilities

There are some parts of the job that are spelled out specifically:

  • developing the robot design
    • managing design through tools such as CAD, BOM, etc.
  • maintaining interfaces/interface specifications
    • space allocations
    • field of view allocations/interference checks
    • ports/IO list
  • discovering and dealing with systemic problems as they arise (except those that are the responsibility of the project manager)
    • risk analysis/mitigation/trees
    • critical path diagrams (to look for single point of failures)

Qualities of a Systems Engineer

Besides the standard leadership qualities, there are some traits that, if already ingrained, will help you be a better systems engineer. Even if you're not currently strong in these traits, it's not too late to acquire them as long as you recognize a need. Many of these traits are broadly applicable to all leads, and really everyone, but are particularly important here.

Accountability (Consequently, Organization)

One of the difficulties in having a student-led team is requiring accountability and responsibility from high schoolers (responsibility in this case, as opposed to above, meaning taking ownership). Teenagers are inherently at a very unaccountable time in their lives; it's a difficult conundrum, and there is no easy solution. However, I'm going to list some simple solutions (simple, but not necessarily easy to pull off).

  • Stay organized. Organization is a huge part of staying accountable to the myriad tasks required at a systems-level. The specific methods you use to achieve this can vary, but here are some ideas:
    • Always have an engineering notebook with you. More than that, constantly record everything pertinent in it. This doesn’t have to be a physical one, depending on how you take notes (I personally draw and use graphics frequently, so a physical one is more suited to me). After every meeting, make sure important decisions and information is recorded with specific details--who said what, why, who else was present, etc.
    • Review what you need to do for the next meeting and the next week before each meeting. This gives you perspective for that meeting and how it fits into the larger picture, so that even if you don’t have opportunities to check with your schedule to see what specifically each team needs to be doing, you understand what needs to be accomplished for the critical path. Beyond looking forward, look back as well. For each meeting, follow a process and really examine what was accomplished that meeting and what still needs to be done.
    • Adopt a personal schedule. Scheduling and planning is not at all just for the project manager: find a system that works for you in keeping track of everything you need to do that is both flexible and detailed.

Foresight & Planning

As Shashank Sadula once said to me about the Integration Captain position, you must look at least a week ahead of the subteam leads. I extend this to essentially the entire season. Of everyone, except maybe the Team Captain, the Systems Engineer must have the most holistic and broad view of the season, from preseason to the postseason. While scheduling is the responsibility of the project manager, planning for your execution is something all leads should do, but especially so the systems engineer.

Every so often, keep everything you’re doing in perspective: begin with the end in mind. There’s at least one eventual goal at the end that you’re striving for; to figure out what you’re doing next you need to understand how it fits into achieving those end goals.

Guide by Stage

Build Season

This is where you shine. Each captain (at least from our 2017 season) has to each their own sub-season. The strategy captain has the competition season: they interpret the game requirements and define a team strategy (the “end” that you begin in mind with), then execute on that strategy, which is of course in the competition season. The team captain, although generally responsible for the overall success of the team and its members, takes the postseason; a strong team captain will use the postseason (including any offseason time) to improve the team dynamic and force year-to-yet improvement, which should also be continued (considering our limited productive use of the postseason, take what you will from that concerning our past team captains. hint: it's not a simple answer). The analogy breaks down somewhat when it comes to matching the project manager with the preseason; in everything they do though, they should wield foresight and a programmatically broad perspective that comes with planning (not that the project manager is the only one capable or responsible for planning). But the build season, the most-exciting (in my humble, unbiased opinion), intense portion of the season, falls primarily under the leadership of the systems engineer.

Competition Season

During a competition it is essential that a well-defined, well-understood process is implemented. From checklists for the pit crew to who should be at the post-match debrief, the systems engineer has a finger in many pies. Although the strategy lead is primarily responsible for what happens at competition, the systems lead is more process-oriented and can and should be responsible for maintaining the robot and modifying it as deemed absolutely necessary. Although a departure from the waterfall method is warranted, the cost model still holds some truth. At each further stage, the cost and risk is compounded exponentially. If a change was easy to make during brainstorming week one, it's now several magnitudes more risky and/or costly. Being at competitions is still considered a “deployment phase,” so changes are incredibly ill-advised.

Pre-/Post-Season

Once again, while the team captain should be the one spearheading team improvement with post mortem meetings and after action reporting, the systems engineer should be an integral part of the discussions, however, not really any more than the other leads. All should be involved in actively addressing issues that were unable to have been addressed during the tense build season and continuing to fulfill the responsibilities of each role until a new lead has been chosen (for example, if robot projects are continually developed after competitions, the systems engineer can assist in that capacity; likewise, continued software development would inherently involve the software engineer).

Interactions with Leadership

First, let me begin by listing the primary positions which I believe are essential to a well-greased machine, with the names used in this document (in each subsection, I list alternative names for the same position). However, before you object, person /= position, with the symmetric property applying here as well.

"Systemic Leads"

  • Team Captain [grease]
  • Systems Engineer [driving sprocket]
  • Project Manager [chassis]
  • Strategy Lead [terminating sprocket]

"Subteam/Department Leads"

  • Operations Lead [electrical power source]
  • Software Engineer [chain]
  • Mechanical Engineer [chain]
  • (Electrical Engineer) [master link]

If necessary, the prefixed name "lead" may be added to almost all of these in order to delineate from others who might fit the general description.

A few more definitions:
junior leadership - leads in a leadership position for the first year
senior leadership - leads in a leadership position for two or more years

Team Captain

Also known as President, Captain, Starfleet Commander, Team Lead

Broadly speaking, the team captain is responsible for the people on the team, whether it be relationships between leaders or among non-lead students; bring the line of communication between mentors, parents if necessary, students, teachers, school, and sponsors; keeping leadership accountable and on task; looking at the overall team vision; and helping to set goals as to where we want to be (e.g. if we want to have more people come in during our "Academy," how to achieve that in working with the school, mentors, teachers, and students to organize such an event). The team captain is more than just the face of the team, more than an operations role. A strong team captain is vital to smooth overall progress and effective cohesion. The team captain ensures that the team is effective, beyond being efficient.

Remember that a lot of these responsibilities are not to be ignored by other leads; just the team captain focuses on addressing them and holding the other leads accountable to a high standard. The team captain is concerned with all the members of the team, but truly only has broad influence over their experience on the team (broad, while nonspecific, can in some cases still be extremely damaging or inspiring). In contrast, the other leads, while narrow in who they can directly influence and impact, can be the one thing between an enjoyable experience and a unpleasant enough one to cause them to not come back the next year or quit mid-year.

Strategy Lead

The strategy lead sets a goal for that year's game, and when the time comes, decides how the robot will be used during competitions. While the strategy lead still has influence and the right to change the strategy between these two points, their authority stops before the project itself. The strategy lead cannot play the part of designing the robot, nor scheduling practice time for the drivers. It is prohibitive for the systems engineer and project manager to involve the voice of strategy at such a level.

How then does the strategy lead have their voice heard? By working with the other leads to develop requirements that meet the strategic priorities. A couple examples to illustrate the point: In deciding subteam teams, the systems engineer and project manager should advise the subteam lead on the best course of action based on the holistic perspective offered by the systems engineer and the programmatic viewpoint offered by the project manager. The subteam lead takes those perspectives into account, but this decision is a project management issue, and so should not involve the strategy team. (Distribution of human resources is not only dependent on strategy's weighting.) The human interfaces should be discussed with the strategy team and the software engineer, with the systems engineer present to facilitate. In this case, while the systems engineer doesn’t have to be involved, they should be made aware.

The strategy priorities should include a prioritization of each use case following a use case analysis and different levels/degrees for each if applicable. Traditionally, our team used to always specify strategic requirements in such a way: for example, the strategic requirements from Recycle Rush involved “easy to get goals,” “achievable level goals,” and “stretch goals” (they didn't use those names luckily, and you want to tailor them to the specific atmosphere of the team that year, which is usually determined by the team captain’s activities).

The systems engineer then must translate those priorities into concrete requirements for the design, of which there are multiple types (this is done in collaboration with the project manager).

Project Manager

Also known as Program Manager

The project manager is responsible for the programmatic and logistical aspects of projects; the systems engineer is responsible for the technical aspects and most other aspects. In general, one way to think about the project manager is as a resource manager: they manage time, money (in terms of how it's used), people, and physical resources, which can be a venue, development platforms, materials, and the like. A fully realized avatar project manager could wield extraordinary influence over all four elements many parts of the team. But, in reality, the project manager can do almost nothing without the full cooperation and trust of the subteam leads and other systemic leads.

Because of the nature of the roles, the systems engineer and project manager need to work closely and well with each other.

Subteam Leads

There is, and really always will be, a need for a distinction between system-level leadership and subteam-/department-level leadership, but note that a distinction is not the same as a hierarchy.

Special/Other Topics

Seniority

While parts of this could easily fall under the topic of selection of leadership, seniority affects not only who is selected, but the relationships between selected leads. I've also included my thoughts on hierarchies and the pretenses of having certain positions above others, which leads to the same effect--a sort of baseless, artificial seniority.

Seniority by age is not and should not be a factor in either selection or among the leaders. While age can be correlated to experience, knowledge, and leadership skill, there​ are exceptions. (By the way, if you apply young to a leadership position, be prepared to explain how you might handle the situation if an older student believed he should have the job over you.)

Seniority by experience or years on the team is more subtle. There is a much stronger correlation there which some might even attribute to causation. For example, if there were some purported leadership skill both a younger and older student possessed, their years on the team can validate or deny that (I hesitate to draw comparisons between other leadership opportunities and those available in robotics--in general they differ too much for a usable comparison).

Seniority can play a positive role in the relationships between leadership on the team. If the more senior leads commit to helping the more junior leads in truly becoming better leads, then senior leadership can serve as another set of mentors for the less experienced leads. Previously, before Mr. Albert took it upon himself to truly mentor in leadership for all the leads, the team followed a trickle down theory for good leadership. As with all trickle down theories, they work on the premise that those who are the first to receive, whether that be there rich or the older leads, are altruistic enough to make a concerted effort in passing down good leadership. But if, and only if, that condition is met, I believe the team could be better off with a lead

Feeling Overwhelmed

If you ever feel overwhelmed, remember the all-important seventh habit (my personal favorite, despite being a tree): sharpen the saw. Forcing a blunt saw to fell a tree is incredibly ineffective, taking up time and effort. This is an incredibly common mistake, one that I’m sure every single lead has committed before. We get into a state where we think plowing forward will be the fastest since it involves only doing the one thing that still needs to get done; however, stepping back and sharpening the saw for a little bit will more than make up the time lost in doing so and make your work more productive for the long run.

Emails (& Communication)

Mr. Pellerano’s mantra for effective leadership is “communication.” Effective leadership requires effective communication. Here’s what I mean by effective communication:

  • It does NOT just mean frequent communication. Although it should definitely be frequent, it is more important for there to be open lines of communication among all groups: leadership, mentorship, studentship, parentship, sponsorship, and the school.

Aphorisms

  • Research from the Best, Invent the Rest
Last modified 16 months ago Last modified on Jun 28, 2020, 5:12:04 PM