10 little success rules for Linux project managers

I just found the following on my hard drive. I published it in a book when I was still doing major projects.
It doesn’t have anything to do with Open Source & Linux, but it’s still too bad to let it gather dust on my hard drive.

.:.
10 little success rules for Linux project managers
.:.

Rule 1
People like to be interested in their work. This is even more true in projects. As a project manager, you should visit everyone involved in the project. You should know what these people are contributing to the project result and you should be able to make these people feel that you are interested in their work. And you should have gotten to know the managers of these people.
.:.
Rule 2
As a project manager, you should know what drives team members, external consultants and suppliers to “perform at their best”.
Find out whether the company has a reward or bonus system, whether there is a special form of awards or what else could motivate employees.
If you have a very demanding Linux project, put
together your own “project motivation system” in consultation with the line managers .
.:.
Rule 3
The IT world is small. And the Linux world is only part of it. Treat the people you are
dealing with on the project with respect and fairness. You will meet many of these people again later, but you do not
yet know under what circumstances.
.:.
Rule 4
There are brutal, obnoxious, and unpopular project managers who are very successful. But there is hardly anyone with a good heart
Humans, a permanent procrastinator and superficial yes-man who survived more than one project. You should be ready to risk your job as a project manager for the project every day.
Safety thinking is not part of the “project manager equipment”. Nonetheless, your project team is looking for this security.
.:.
Rule 5
Not all successful project managers have achieved their success solely through competence. And not all failed
project managers are incompetent. A key factor is luck.
It seems like happiness comes to the people who believe in it and work hard for it.
.:.
Rule 6
Express your opinion. But always be able to change them. Create a project culture in
which project members can and want to express their opinions. And create a way for project staff to send an anonymous message to the project management. This way, bad news that the team members want to get off their minds can get through to you in time. Perhaps this option will not be used. But if it does, it is priceless.
.:.
Rule 7
A project manager leads the project. That’s all.
In Linux projects in particular, you will find project managers who want to program or produce other technical results. These projects fail. It would be like doing heart surgery on yourself.
.:.
Rule 8
There are endless ways to waste a day – but not a single one of getting it back. There’s no point in rushing through project life at top speed. Take your time for the moment. But write the word DO clearly visible at your workplace. It reminds you to “stay tuned” to your project day and night.
Read backwards, it reveals the most important rule in the project: do
not need to dawdle!
.:.
Rule 9
Most people do not realize that the subconscious cannot process the word “not”. Therefore, do not say what you do not want, but start using clear, targeted language for your project. Say what you want. Request this from your teammates. Anything else leads to misunderstandings, even though the same language is spoken. Imagine an unclear language in an international project with the business language English.
.:.
Rule 10
A joint project places high demands on communication. A successful project manager keeps his partners up to date with regular information. He should consult these partners before making an important decision and consider your reactions. This creates a well-functioning early warning system “on the side”. Take into account all parties involved, including those who are only marginally affected by a decision.
You should also learn the technical jargon of a Linux project quickly and use the specific terms consciously in daily communication. This gives you a high level of acceptance from the project environment and a greater understanding of the matter.
—