Today I want to talk about generalists and system engineers: why they’re important and why they’re different from each other.

Specialists and Generalists

A specialist is someone who has a very deep understanding of a particular subject, and spends much of the time working on aspects of that subject. Few others are capable of doing the specialist’s work. I recently wrote an article on gate drive design (Lost Secrets of the H-Bridge, Part V) which goes into some pretty arcane detail. But I don’t consider myself an expert on the subject. In my mind, a gate drive specialist is someone who can design robust gate drives for many different power transistor circuits, and who can do it better than a generalist engineer. I could probably do it for a circuit board rated at a few hundred watts, but if you ask me to design a power stage for a 10 kilowatt 400-volt system — nope nope nope. Call in the gate drive specialist. Perhaps there are some companies where power electronics is a key aspect of their business, and someone could make a living providing high quality gate drive designs. In a more general role, a power electronics engineer could still be considered a specialist if they focus on circuit designs including power transistors, gate drives, magnetics, and capacitors. It’s all relative: the gate drive specialist would consider a power electronics engineer a generalist, whereas a general embedded systems designer would probably consider most power electronics engineers a specialist.

I always prefer to hire and work with generalists. There are a few reasons for this.

The main issue: most of my team works on a changing series of projects that are not always well-specified. So we have to figure out the challenges along the way, and we need the flexibility of people with different skill sets and experience.

I’ve also found that generalists are more open to many different approaches to solving problems. Some specialists view their particular skills and techniques as a favorite tool to be used on many occasions. (As Abraham Maslow wrote in the 1966 book, The Psychology of Science, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”)

That doesn’t mean I look down on some degree of specialization. It’s a must-have, in my opinion, to be a generalist, but when I’m interviewing someone and find out that not only are they able to handle questions on a variety of topics, but they also have some areas of deep expertise, it’s a good sign. Even better: someone has two or more areas of deep expertise that are distinct, like gear design and database programming. Because this tells me that they can adapt and learn.

The third reason I prefer to work with generalists, is that by learning about a variety of different subjects, you start to see connections between different things that behave in similar ways. Classic examples are analogies between different domains, such as mechanical-electrical analogies or thermal modeling. Other subjects that have multiple applications are random processes and diffusion. A good understanding of how one type of system works can apply to other systems, and lead to some important insight when someone is faced with a situation that is new but has familiar characteristics.

So in our motor control group, for example, I like to see familiarity with problem solving, circuit design, embedded firmware, and signal processing. It’s hard to find people that have strong expertise in all of these areas, but as long as they have some exposure to all, and can learn quickly, I’ve found they do very well.

System engineers

System engineers are a little different. The concept is somewhat nebulous — you look up “system engineer” and you start to see vague buzzwords like multidisciplinary and requirements and complex systems and system life cycle, and when I hear someone talk about this it just makes me want to go into another room.

So I have my own view of what system engineering is. If I had to summarize in a sentence, a system engineer is someone who can effectively think about a system on multiple levels, from the bottom to the top, in the same general context. But there are some nuances here, and they’re not so easy to convey in a sound bite.

I would also say that most system engineers are generalists. You can’t think about a complex system with one particular view in mind. Let’s say that you’re working as a system engineer on the Magic Happy Mobile Blender. You need at least some general understanding of motors and batteries, and circuit design, and safety, and what makes a blender work well. Someone in this role could get by with a superficial understanding of each of these, as long as they can rely on other staff who cover each topic in more detail. But a good system engineer would have some reasonable depth of understanding in most of these topics. Hence the need to be a generalist.

My experience with system engineers is that this familiarity with different aspects of a system “creates synergy” in being able to do the right thing for the system as a whole. This multi-aspect familiarity leads to an ability to see linkages between several issues, where the right system design involves global compromises that may not be obvious to someone working on only one piece.

Tension in Voltage

For example, in battery design, it is more reliable to use one large cell than multiple smaller cells. Mobile phones do this; typical lithium-ion cell voltage is in the 3.5 – 4.2 V range, which is in the right general range for the circuitry in consumer electronics. (I just ran an app called AccuBattery which claims my phone battery voltage is 3.948 V. It presumably relies on Android’s BatteryManager.EXTRA_VOLTAGE feature, which gives apps access to voltage sensing via an analog-to-digital converter.)

That’s fine for a small consumer electronic device, but imagine that you are designing some sort of motorized power tool or appliance. I could use several smaller cells in series to get a larger voltage. Should I? If so, what system voltage should I use?

• A battery designer would probably tell me to use the minimum number of cells. Aside from simplicity (fewer connections), cells in series have the complication of needing to be balanced. A cell that is charged or discharged too much undergoes a chemical reaction that can degrade the cell’s useful life. When cells are in series, they share the same current, and small differences in cell capacity or condition will lead one cell to reach full charge or full discharge before the others, causing degradation that, over time, can make those small differences larger. So multi-cell batteries — especially for lithium-ion batteries — will have circuits that shunt away charging current from cells with higher voltage, preventing this divergence of cell conditions. Batteries with two or four cells aren’t impacted by this effect too much, but there are applications with higher power levels that use more cells in series, such as electric vehicles. For example, the Toyota Prius Prime from the late 2010s uses 95 lithium-ion 3.7 V cells in series, for a nominal battery voltage of 351.5 V. At this high number of cells in series, a battery-balancing system is critical.

• A wire harness designer would tell me to use a higher voltage, rather than a lower voltage, to keep the current down and allow use of smaller-gauge wire, reducing cost and weight of wire and connectors. Okay, how about a 25 mA 4800 V system instead of a 2.5 A 48 V system? Um, too much, perhaps; there are standard voltage ratings of wires and connectors, so at some point, going higher in voltage will rule out more and more of the possible components.

• A motor designer would tell me it doesn’t matter that much, as long as the voltage isn’t too low or too high. Too high of a voltage leads to exotic wire insulation; too low of a voltage requires thick wire in the windings, which is harder to manufacture, because of the difficulty bending around the stator.

• A circuit designer would tell me to pick a voltage that works well with the generally-available ratings of power transistors, capacitors, gate drive ICs, and other circuit components. If the current is too high, the circuit board design techniques start to get exotic; if the voltage gets too high, creepage and clearance distance requirements start to make life more interesting.

• An electrical safety engineer would probably tell me to make sure I’m sticking with Safety Extra-Low Voltage standards to mitigate shock hazards.

These perspectives have conflicting guidelines, which need to be resolved at the system level. For these reasons, a nominal voltage of 48 V is finding common application in many automotive subsystems, aside from traction power itself. Cordless power tools are an example of system engineering in practice: these vary anywhere from 6 V to 48 V, with a strong correlation between power level and voltage. A system engineer would handle the global optimization of system voltage selection for a particular product.

So arbitrator-among-subsystems is one responsibility of the system engineer.

Another responsibility has to do with visibility, risks, and follow-through, and is a little bit more difficult to summarize. Which brings me to Sheep Bridge.

Aerial view of Verde River Sheep Bridge, looking southeast. Taken March 1987 by Dale A. Politi, Gerald A. Doyle & Associates, Phoenix, Arizona, for the Historic American Engineering Record of the National Park Service.

Sheep Bridge

One of my coworkers, Thomas, recently told me about a place he’d visited, called Sheep Bridge. (Thomas is quite the generalist: he likes building things with electric motors, programming in C and Python, working on his car, and exploring Arizona.) I doubt I will ever go there; it requires travel with a high-clearance vehicle on a rough Forest Service road to a remote area of Tonto National Forest on the Verde River.

In 1942, a certain physician in Flagstaff, Dr. R. O. Raymond, purchased the Chalk Mountain grazing allotment in the Verde River Valley. Raymond owned the Flagstaff Sheep Company and grazed 4,852 sheep on the Chalk Mountain allotment. One of the major trails for driving sheep between summer and winter pastures — known as “driveways” — was located on the west side of the river, but portions of Raymond’s allotment were on the east side of the river. A historic marker puts it this way:

The Verde River was a formidable obstacle for the sheep outfits that used the pastures along the river. Sheepherders had to swim their flocks across the river several times a year, especially in the spring going north to summer pastures and in the fall returning to the winter ranges, and could expect to lose at least a few animals to the swift currents at every crossing.

Dr. Raymond applied to the Forest Service in December 1942 for a permit to build a bridge across the Verde River, and in March 1943 to the War Production Board to purchase materials such as bolts, nails, and lumber. (One might wonder why the US government would support priority access to these materials during wartime to a sheep farmer — perhaps it was because wool was required by the US Army for winter uniforms.) The bridge was completed sometime around June 1943, with concrete reinforcements added in 1944, and was used to transport sheep until 1979.

Sheep crossing bridge, circa 1944, unknown photographer. Courtesy of the Historic American Engineering Record of the National Park Service.

Looking at photographs of the bridge, it seems rather high up; the Historic Record of the bridge states that the walkway is 45 feet above the river under normal flow. But the Verde River is subject to floods from spring snowmelt, and can rise 30 feet.

Sheep Bridge fell into disrepair, damaged by floods in 1979; it was declared structurally unsafe in 1984 and demolished in 1988.

A replica suspension bridge was built on the same site in 1989 to provide access for hikers, within spitting distance of the original concrete reinforcements, one of which is still standing.

Sheep Bridge photograph © Greg Meyer, used with permission.

The new bridge has been photographed by many, including George Stocking of Arizona Highways for the magazine’s February 2014 “Scenic Drive” feature. The description of this scenic drive is also posted on the Arizona Highways website, stating:

Length: 39.9 miles one way
Directions: From Carefree, go north on Cave Creek Road, which becomes Seven Springs Road (Forest Road 24), for 27.9 miles to Forest Road 269. Turn right onto FR 269 and continue 12 miles until the road ends at the Verde River Sheep Bridge.
Vehicle Requirements: A high-clearance vehicle is required, and a four-wheel-drive vehicle is recommended for Forest Road 269. This route should not be attempted in inclement weather.
Warning: Back-road travel can be hazardous, so be aware of weather and road conditions. Carry plenty of water. Don’t travel alone, and let someone know where you are going and when you plan to return.
Information: Cave Creek Ranger District, 480-595-3300 or www.fs.usda.gov/tonto

Okay, so by now you’re probably wondering what this has to do with system engineering. The answer involves navigation and visualization.

Thomas described to me the route he took from Cave Creek, and I looked on Google Maps, which does show the bridge and FR269, at least at small scales. Here’s zoom level 16:

If you zoom out to level 15, however, the labels for FR269 disappear.

This part of FR269 is such an unimportant road that Google doesn’t seem to care; to the northwest, however, the labels pick back up, ending a few miles east of the junction with FR24.

At zoom level 14, we lose all the road labels, but see more of the route.

At zoom level 13, we lose the more obscure, eastern part of FR269 entirely, but pick up Horseshoe Reservoir.

Finally, at zoom level 12, we get some regional context. The roads FR24 and FR269 are very faintly visible, if you look really closely, but otherwise the map is useless for seeing this route, even though these are among the few roads in this area and could easily be emphasized without overcrowding the map.

In other words, there isn’t a generalized view on Google Maps that shows these roads in their entirety, at a high-level perspective. To visualize the drive requires a different map. Yes, I could ask Google Maps specifically for directions from Carefree to Sheep Bridge, and bingo:

But I have to ask specifically for this route, rather than look on a map to browse and figure out what kinds of routes I could take.

OpenStreetMap does a bit better with a generalized map of the area, choosing a more schematic-oriented display where small-scale items such as minor streams and trails are shown, as well as abstract features such as county and land ownership boundaries:

But you don’t get to see the forest road labels until you zoom in quite a bit.

For a more navigationally-oriented map, we need one that labels even the minor roads, such as the one in Arizona Highways in February 2014, or the one on the US Forest Service website:

These maps are specialized for a particular purpose (namely navigating to Sheep Bridge), as opposed to the general-purpose maps from Google, which select an appropriate level of detail given the zoom level. I’ve noticed this several times while using Google Maps to follow small, unimproved roads that go for long distances, and it’s a frustrating detail of the Maps service that unimproved roads are not displayed at low zoom levels, even when they are one of the significant features of the area.

The selective display of detail is something that is necessary for maps, however; higher-level maps must necessarily filter out enough so that the display is not overcrowded.

Subway maps go even further; these are highly stylized maps, giving up on correctness of angles and distances, in order to improve readability and highlight information relevant to the passenger. For example, Washington DC’s Metro and Boston’s MBTA:

Realistic geography is thrown to the winds — both maps state “not to scale” in fine print — in favor of displaying subway station names at regular intervals. But at this level of coverage, there are details left out, notably nearby major street intersections, in the interest of focusing on the subway station network itself. You just can’t fit it all on one readable map. (Although I must say, the MBTA map does a good job cramming in numbered bus routes.)

We run into the same issues when documenting and understanding complex engineering systems. At some point, it’s not possible to include all of the system’s design details on a single diagram, without requiring enough space to make it impossible to use as a single diagram. The C4 Model was proposed to alleviate this issue for software, by covering systems using multiple diagrams at different scales.

"Maps of Your Code", from C4 Model Introduction.
Reused under the Creative Commons Attribution 4.0 International License.

This multiple-diagrams-at-different-levels approach definitely helps for visualization, and in my work I have found that sometimes you Do have to Repeat Yourself, at least at different scales. A system engineer needs to be fluent with both the big picture and lower levels of detail, and is often responsible for high-level or medium-level documentation and diagrams that specify system behavior.

But system engineers handle more than that. There are often important features or requirements that span multiple scales, and it is important that someone be aware of the multi-scale interaction to a sufficient level of detail to ensure that the design will work correctly. The anti-pattern here is likely familiar to most of you as the 1977 Sidney Harris cartoon where two middle-aged academics are standing in front of a blackboard with some mathematical scribbling on both sides of the words “THEN A MIRACLE OCCURS”; the one pointing to this phrase says to the other, “I think you should be more explicit here in step two.” Handwaving has no place for system engineers.

As an example, suppose the design team for the Magic Happy Mobile Blender includes a quadrature encoder with index pulse on each of the traction wheels, in order to determine wheel position. Some of a system engineer’s tasks might include ensuring that:

• the encoder signals (A/B/index) are routed from the encoder to appropriate counter input pins on the microcontroller
• the polarity and connections of the A/B signals produces an increasing count for the intended direction of rotation
• the number of pulses per revolution is appropriate for both the angle accuracy requirements and the limits on maximum pulse rate at the highest expected speed
• if there are absolute positioning requirements, that the encoder disc is keyed to align mechanically with a feature on the wheel axle
• encoder count registers are read at an appropriate rate
• encoder position is scaled properly for software purposes
• if velocity is required, a reasonable algorithm is used to derive it from position
• there is an opportunity for the wheels to rotate past the index pulse, if knowledge of absolute position is important

This is an end-to-end signal integrity check, covering mechanical, electrical, software, and signal processing domains. Some of these tasks may be delegated to appropriate engineers to cover various pieces, but someone needs to connect the dots and ensure that everything comes together properly.

If you are an engineer working on a particular subsystem, you can practice your system engineering skills by looking outside the scope of that subsystem and making sure that you understand the interoperation of your subsystem with others: where the signals go, what kinds of challenges may occur with integrating your piece with others, and what kind of global tradeoffs may apply that push tougher requirements on your subsystems in order to reach the right design at a system level. It is very easy to say, “I did my part”, and let things rest there, but cohesiveness does not spontaneously arise; it takes effort to pull a properly-working system together. Someday the success of your project may depend on it!

Wrapup

In this article, I brought up the topics of generalists and system engineers, and some of the ways in which system engineers do more than just think at a high level, or plug pieces together. The complexity of today’s electronic and electromechanical projects rely on competent engineers to ensure proper operation of the system as a whole.

© 2025 Jason M. Sachs, all rights reserved.