Unwritten Rule of Engineering #20: Cultivate the habit of seeking other people’s opinions and recommendations.
You cannot hope to know all you must about your field and your employer’s business. Therefore, you must ask for help from others; routinely seek out those who are “in the know.”
This cannot be emphasized enough and is an especially frequent flaw in newer engineers who believe they know everything. Typically they do not understand the larger context and thus make locally optimal but globally sub-optimal decisions; decisions that could have been avoided if they had asked for advice from others.
Unwritten Rule of Engineering #19: In all transactions be careful to “deal in” everyone who has a right to be in.
It is all too easy to overlook the interests of a department or individual who does not happen to be represented, or in mind, when a significant step is taken. Even when it does no apparent harm, most people do not like to be left out when they have a stake in the matter, and the effect upon morale may be serious.
Note particularly in this and the preceding rule the chief offense lies in the invasion of someone else’s territory without that person’s knowledge or consent. You may find it expedient on occasion to do parts of other people’s jobs in order to get your own work done, but you should first give them a fair chance to deliver on their own or else agree to have you take over. If you must offend in this respect, at least you should realize that you are being offensive.
Unwritten Rule of Engineering #18: Never invade the domain of any other department without the knowledge and consent of the manager in charge.
This is a common offense, which causes no end of trouble. Exceptions will occur in respect to minor details, but the rule applies particularly to:
- The employment of a subordinate. …
- Engaging the time or committing the services of someone from a different department or division for some particular project or trip. …
- Dealings with customers or outsiders, with particular reference to making promises or commitments involving another department. …
- Performing any function assigned to another department or individual. …
There is significant commentary on this last principle that should also be observed: in general you will get no credit or thanks for doing the other person’s job at the expense of your own.
Successful teams have members who communicated a lot, participated equally and possessed good emotion-reading skills:
Words about meetings:
It’s not enough to just do stuff, you have to make sure that people know you are doing stuff:
We went public:
Be careful what license you put on your work and then, when you do, don’t complain when others use it according to that license. Personally, I prefer CC-BY-NC-SA to avoid problems and here’s someone who agrees with me:
The role of a senior leader is to build a strong organization and a talented leadership team. That team then drives the results. It’s an indirect thing which makes it extra hard to do:
Part of building a strong leadership team is to adopt practices like Completed Staff Work:
It’s such a disappointment when one finds oneself in a political organization. Nobody ever starts a start-up saying “I’m going to build a miserable political culture” and yet every company ends up there:
Words on hiring:
Words about leadership and leaders:
And many other nuggets of wisdom:
For completeness, conversational replies are occassionally elided: [1
Unwritten Rule of Engineering #17: Do not be too anxious to defer to or embrace your manager’s instructions.
This is the other side of the matter covered by the preceding rule. An undue subservience or deference to any manager’s wishes is fairly common among young engineers. Employees with this kind of philosophy may:
- plague their managers incessantly for minute directions and approvals,
- surrender all initiative and depend on their supervisor to do all the thinking for a project,
- persist with a design or a project even after new evidence has proven the original plan to be infeasible.
In general, a program laid down by the department, the project leader, or the design team is a proposal, rather than an edict.