Quick script to maintain a diary
10 annoying office phrases
Switch!
Excellent article on outsourcing
Language skills for programmers
« Jodd
» Respecting SQL
DevShed.com: “As a manager in charge of technical professionals, I have learned that managing projects with multiple team members requires certain people skills, as well as technical skills. In the world of management, there are many skills required when it comes to the management of people. These skills, and how you apply them, vary depending on the type of business you are in, as well as the type of people whom you manage.”
The author summarizes main points as:
- Get to know your team.
- Make your professionals feel part of your team.
- Keep your team productive.
- Find the right size for the job.
Personally, I think the most important thing is to define goals for the team. Teams without goals can’t exist for long. In other words, are you able to define "clarity of purpose"?
For technical professionals:
- Learn to communicate.
- If you don’t like how you are being managed, make suggestions.
- Work well with others.
- Be realistic.
Easiest way to communicate is by addressing the technology using common analogy. For example, lot of things about software have equivalents from automotive industry. Use cars as an analogy! I think working well with others is not entirely in your control. If others don’t want to work with you, one of the reasons could be that there is no environment for teamwork.
Great article and summary. Two thoughts immediately come to mind:
- Yikes! the car analogy again! It is so funny every time this gets re-invented or re-discovered. I've heard this in about 2 dozen different companies by now.
- One additional point for tech professionals, sort of an expansion on "Be realistic.": "Be flexible" - In two ways, be flexible in problem solving with your teammates. Many problems have *multiple* suitable solutions, despite our education process which so often impels us to find the one *right* answer.
And be flexible in your outlook toward team decision-making. Unfortunately for us tech-folk, the technical ramifications of a problem often make up only about 10% of the overall decision. For example, delaying a product release until *all* bugs are out may be technically best, but if this delay misses the trade show/makes investors take money elsewhere/delays the factory startup, it is overall a bad decision. This is a very difficult thing to accept, and many people go through their whole careers embittered and cynical.