Pitfalls in managing juniors & projects

1. INTERNAL DOCUMENTATION. Engineers should keep internal documentation for all non-obvious things they learn. Basically, it is a guide for anyone who will follow their steps. This is useful for the following reasons: saving time on training juniors, in the long term improving training quality, and if documentation is written by engineers and reviewed by seniors, then this is a way to understand that engineers understand things properly. We keep documentation in Confluence. We keep notes about the models we are solving, issues facing, and solutions. In theory, it works well as long as someone from a team is reviewing and managing the documentation. Once there is no documentation architect, it becomes messy as it is now.
2. KEEPING TASKS. When multiple people are working on the same project, project management tools are great on a system level. Once we dive into routine work, most of the communication is done in chats like Teams. What is missing in Teams is that information gets lost, and it is difficult to share information with someone outside that particular chat. If we think of an office setup where a small team works on the same task, the whiteboard comes up as the most intuitive tool to keep track of top-priority tasks and notes. Considering that many teams are working remotely, instead of a whiteboard, a simpler text-based shared (author, assignee, and manager) notepad could work. During every conversation, the task author and assignee should add and update the to-do list. Reviewing older actions, adding new ones. Internally, in Trafolo, we use Simplenote - like a notepad that can be collaboratively modified.
3. FREQUENT FEEDBACK. All documents have to be online. This is something we are "fighting" a lot with juniors. They think that they will write all the notes in a Word document and then share. That does not work as reviewing multiple versions of those docs is messy, and providing timely feedback is impossible. The rule - all docs are online docs, so that seniors have access to provide timely feedback. Most engineers have a hard time shifting from waterfall to agile.
4. RULES SHOULD HAVE A REASON OR AN AUTHOR. There are many assumptions without or with very slim argumentation. It happens that there are design changes that do not look to make sense from a physics point of view, and then we start questioning - is that change is required by manufacturing or just a result of inaccurate interpretation of simulation results? Often no one can answer. In this context, there is one rule in simulations that most junior engineers break -
5. CHANGING ONE THING AT A TIME. It causes a wrong interpretation of the results.
6. ESTIMATING WHAT IS/ISN'T IMPORTANT. For example, do we actually need to solve full geometry or would symmetry be just good enough? Do we actually need to solve all frequencies from 100 kHz to 10 MHz with a step of 100 kHz, or can we take, like, 10 points in geometrical progression? Should we use complex 3D geometry for simulation with round corners, a bunch of small faces, or instead, we can take a simplified model while focusing all the effort on refining the mesh. This costs a lot of hours initially, as there is a natural temptation to run the most complex model on a large sweep of frequencies or currents just because graphs and pictures should look good. In reality, professional simulation engineers are not those running the most complex problems, but running adequately simplified models, + have all the necessary arguments to explain how each simplification would affect the result.