Having met the odd traffic planner/civil engineer in the past year, one problem is that they have a technical language to describe things, a language they use to communicate with their peers -but also to exclude those who are not educated in civil engineering. What to do? Josh Hart is going for the "learn the language" approach, by studying at UWE.
The rest of us don't have the time to do that. Instead I'm guest lecturing at a local university on computing topics, which is going to provide the answer. Instead of wasting time learning civil engineering concepts and terms, take software engineering/computer science terminology and apply it to traffic. The advantage of that is that you don't need to understand the details, to be able to handle the reply when you say "The O(1) scheduling algorithm delivers fairness but under 80% saturation the router tends to drop packets on the floor". Because if you are saying it to the traffic planners, they don't understand either. But it scares them. Which is important, as from the early findings, there isn't much in the way of science in traffic management; there's no experimentation. Just some simulation programs written in the early eighties based on inadequate data. That's a belief-driven approach, not the evidence-driven one that is the basis for sciences.
If it were a proper science, it would be data driven, from repeatable experiments. For example, before proposing replacing zebra crossings on Blackboy Hill with puffin crossings, they'd check to see if pedestrians would stop on the red light,. Once they knew what number of people would ignore the light, include that in their simulations and risk analysis. Then they'd stick up some temporary lights to see what happens to the congestion, before dropping a few hundred thousand pounds on it.
Anyway. Henceforth, this blog will sometimes introduce computing terminology for the reader. Enough to intimidate the odd traffic planning consultant. Especially once we start collecting the data they don't seem to have. First up: deadlock.