• The first is misaligned goals.
• The second are undisclosed concerns about the risks of collaborating.

Dare Obasanjo aka Carnage4Life wrote a great story in his blog:

The truth is often that the so-called jerks are really just thinking “You’re not my manager, so I’m not going to ask how high when you tell me to jump.” Once you find out you’ve hit this problem then the path to solving it is clear. You either have to (i) make sure all collaborating parties want to reach the same outcome and place have similar priorities or (ii) jettison the collaboration effort.

The difference between a good engineer and a great one has little to do with technical skill, but a lot to do with all the other stuff.

It’s easy for IT managers to get bogged down in day-to-day activities and lose sight of the bigger picture of leading their staff. Whether you’re a seasoned pro, or new to the game, the following tips will help you effectively manage your team.

1. Spend time (and money) developing your people

IT is a constantly changing field, and many IT workers love to learn about new and improving technologies. For many, learning is not just enjoyable, but is necessary to do the best job possible. IT Managers should budget for training and development and encourage staff to participate in events whenever possible.

If your budget is tight, explore free regional presentations and workshops, set up in-house training, and get creative with your development dollars. Don’t forget about cross-training exercises as well. Even in a large IT group, there are jobs that only one person does routinely. Make sure others know what to do if that person is suddenly gone for an extended period.

2. Get to know what your staff really does

Although you don’t need to master every task your staff handles (see the next item), you should understand your staff’s normal work routine. Familiarise yourself with each person’s responsibilities, if you aren’t already. Ask team members to explain and demonstrate important tasks – such as data backups.

I once had an existing IT employee transferred to my sub-group. Immediately after the transfer, I began working with the individual to learn his job role. One month after the transfer, during a key production period, the employee suffered simultaneous tragedies – a parent died and the employee developed pneumonia. With no direct backup, I jump in and accomplished the job with the knowledge I had learned during the first month and a great deal of help from others.

As a result, I gained a great deal of respect from the employee, who had previously suffered negative experiences with management. Understanding what your staff does not only increases their level of respect for you, but it also makes you more credible as a manager when faced with difficult situations or decisions.

3. Don’t do it for them

If you move from an “in the trenches” IT worker to a management role, avoid the tendency to take the reins too quickly. Your knowledge and skill level may exceed your employees’, but you must help your staff learn and grow. There is a fine line between coaching and doing. A good manager will know the difference.

While there may be an initial training period where you are more involved in doing the day-to-day work, use appropriate delegation and training strategies to move the work into your staff’s capable hands.

4. Know the business and make sure they know you

It is almost a cliché, but all IT managers must understand the business they support and use this understanding to build services and infrastructure that support business goals. You should also show your direct reports how their work affects overall business goals and ensure that business administrators understand what IT does for them. Showcase your department’s activities through annual reports, regular communications, and frequent project updates.

5. Treat communication as a busy, fast-moving, two-way street

Information is not a limited commodity to hold. It should flow freely and easily between management and workers. If you sense that you are not getting important information, consider ways to increase communication. Likewise, don’t hoard information, unless it is confidential. What seems irrelevant to you may be highly relevant for someone else. Reward information sharing between your direct reports.

6. Encourage everyone to work as a team

The whole really is greater than the sum of its parts. Encouraging collaboration and teamwork helps remove silo-like isolation that often occurs in technical organisations. Cross-functional teams are extremely important because small changes in one area can have significant ripple impact across other IT units. Reward efforts that allow for collaboration and develop an environment where workers can feel comfortable asking for and giving assistance to one another. Frustrations often result when one team member knows something that others spend hours working to resolve. Teamwork will fuel your communication vehicle.

7. Provide feedback regularly and let employees know what you want

Some IT jobs make people feel like islands. They work on a project or assignment independently and may not regularly interact with their manager or co-workers. Be sure your staff knows what they are doing well and what needs improvement. These can be casual conversations, formal performance reviews, or public praise events.

If someone isn’t living up to expectations, be sure that person knows what those expectations are. Staff members may not realise that the assignment you gave them last week was a priority item for a high profile project. Be clear and direct when making assignments. When employees finish a job, make sure they know how pleased you are with the work they did. Geeks need love too!

8. Hire well

If you have never hired before, ask for assistance and do your homework. Hiring poorly can be more costly than not hiring at all. Technical skills are only a small piece of the puzzle. You should know if a person will integrate well with the team. It may also help to get your team involved in the hiring process, when it’s appropriate and allowed. Your staff can help you determine whether the applicant relates well to others and has the appropriate soft skills.

9. Understand best IT practices but don’t just make them buzz words

Learn and understand the best practices that apply to your environment and measure yourself and your department against them. Explore ITIL and determine whether you should implement at least portions of it in your department. Ensure your disaster recovery plan is up to date and ready for action. Perform regular security assessments. Proceed with caution, however; throwing around buzzwords won’t gain you any clout. You must truly understand the ideas and their application to your environment. Then, plan and implement appropriate related changes.

10. Be a good project manager

Did your last project suffer scope creep? Most projects, particularly IT ones, don’t fail because the project itself was bad. Most failures are a result of weak project management. If you haven’t had any formal project management training, find and invest in a good program.

Don’t fall into the trap of thinking that simply by having regular meetings, you are managing the project. And since IT usually has more projects than people, be sure to train lead workers with basic project management skills so you can delegate specific aspects of the project or even entire projects to their control.

Pitching Agile to Senior Management – This inability to articulate to senior management why they should adopt agile techniques is ironic considering our focus on communication. Ambler’s experience is that management is often very willing to become more agile if you’re able to describe to them the costs and benefits in an understandable and meaningful way.

Read more: http://www.ddj.com/dept/architect/199300107

PHASE 1: Auftauen (unfreeze):

Zu Beginn eines jeden Veränderungsprozesses müssen Widerstände gegen die Veränderung abgebaut werden.

PHASE 2: Bewegung (move):

In Phase 2 kommt der Change-Prozess in Bewegung. Es geht darum, die Veränderungen umzusetzen.

PHASE 3: Einfrieren (freeze):

In dieser Phase geht es darum, Kurs zu halten. Ziel der 3. Phase ist daher, das neue Verhalten zu stabilisieren.

Überprüfen Sie anhand der folgenden Checkliste, ob Sie an alles gedacht haben:

PHASE 1: Auftauen

Kernaufgaben:

• Diagnose stellen: Warum muss Ihr Unternehmen sich verändern?
• Vision entwickeln
• Managementteam ins Boot holen

PHASE 2: Bewegung

Kernaufgaben:

• Ziele ableiten
• Vision, Ziele und Strategien kommunizieren
• Maßnahmen entwickeln
• Verantwortlichkeiten regeln
• Mitarbeiter qualifizieren
• Persönliche Positionierung im Changeprozess erarbeiten
• Veränderungsschritte steuern, kontrollieren und dokumentieren

PHASE 3: Einfrieren

Kernaufgaben:

• Ergebnisse reflektieren
• Stand der Veränderung festhalten
• Kontinuierliche Verbesserung verankern

Development: “You want answers?”

Marketing: “I think we are entitled to them!”

…

read the whole story:

http://blog.versionone.net/blog/2007/03/a_few_good_mana.html

Son, we live in a world that requires software. And that software must be built by people with elite skills. Who’s going to build it? You, Mr. Marketing? You, Mr. Sales? You, Mr. Finance? You, Mr. Human Resources? I don’t think so.

We have a greater responsibility than you can possibly fathom. You scoff at our open work areas and you curse our big screen monitors. You have that luxury. You have the luxury of not knowing what we know – that while the cost of delivering software may be excessive, it drives revenue and saves money. And my very existence, while grotesque and incomprehensible to you, drives BUSINESS!

You don’t want to know the truth because deep down in places you don’t talk about at staff meetings… you want me managing the project. You NEED me managing the project!

We use words like refactoring, test-driven development, continuous integration, sprint, velocity, and release planning. We use these words as the backbone of a life spent delivering something. You use them as a punch line!

I have neither the time nor inclination to explain myself to people who rise and sleep under the very blanket of software I provide and then question the manner in which I provide it. I would rather you just said “thank you” and went on your way. Otherwise I suggest you log in to a computer and write some code. Either way, I don’t give a damn what you think you’re entitled to!”

2. Keep management in the dark. The people actually doing the work have the skinny on what’s going poorly. We know when the server is overloaded, the screen shots used in training don’t match the application, or the data model doesn’t conform to enterprise standards. That knowledge gives us real power. Just keep all those juicy tidbits to yourself, and watch management scramble as the project falls apart, apparently for no reason at all!

3. Keep your customers in the dark. Putting blinders on your customers is even more effective for killing a project than spoofing managers. Don’t tell users or customers anything, especially about your deliverables. Don’t let them see anything until the last possible second, and then make sure it’s too late in development to change anything. Codify this strategy across your program by selling it to management as the best method of controlling user expectations.

4. Don’t document anything. This is one of the most subtle and insidious methods of killing a project. Take advantage of human laziness- urge people to do the fun stuff and not to worry about documentation; say “we’ll get it later, after we’re done.” Then as the natural process of project turnover occurs, enjoy the fun of watching new team members struggle to figure out what their predecessors accomplished or how they arrived at certain decisions.

5. Don’t train or allow for training. This strategy is doubly effective, because you can de-emphasize training for your project team, and this will lead to a consequent dearth of training for your users. Say things like, “you can read a book and pick that up in a weekend” or, “we don’t have the budget for that class right now; let’s wait until later” or, “our customers are savvy enough to pick this up without a guide.” (With project members, however, the best thing to say is “Training? I thought we brought you on the team because you were already qualified!”)

6. Don’t use the best technology for the job. Convincing your teammates and managers that the best-fitting technology is unnecessary can be a very efficient way to ruin a project. Think chewing gum and baling wire-build an enterprise-wide, high-volume, heavily used knowledge management system with an MS Access back-end. Or manage documents destined for multichannel publishing using WordPerfect and the LAN. Kludges always eventually fall apart, sometimes even before the first scheduled rollout.

7. Change project scope frequently. This is hard to achieve unless you’re a manager, but a scope shell game can bring a project to its knees—change early and often. Customers, consultants, integrators, developers, tech writers everyone hates working on a piece of the puzzle only to discard or significantly change their work because of a sudden, inexplicable change in scope.

8. Control scope pathologically. Oddly enough, overmanaging scope can be as effective as undermanaging it. A great example is finding a “hidden” key business need during an evaluation and choosing not to address it because “it’s out of scope” even if it’s easy to fix. Then publicly throw the responsibility for managing the core need back on the customers and watch them rebel.

9. Start writing code before gathering requirements. Unless management is really on the ball, this is a piece of cake, and the less developers know about the goal, the better. Get as many sexy features as you can up and running as quickly as possible. In just about every case, the person who creates a neat interface, training document, or data model has to throw out nearly everything once real requirements are gathered. And redoing the effort often throws the project off schedule significantly, which usually leads to the project death you so desperately desire.

10. Hire great people and micromanage them. While this technique is way beyond the average worker bee, and requires some finesse to achieve, I’ve seen it often enough in practice to know that it is far-and-above the most effective way to kill a project. If you can set up an environment in which every team member is afraid to make a decision without management input, you’ve achieved project-killing Nirvana.

Note: Article was original written by Robert H. Wallace in 2006.