Dear Bob ... I was wondering if you could impart a bit of wisdom (things to be wary of) before I begin a new supervisory position in an established IT shop ... The particulars: Manager (supervising 20 or so employees) for this IT department in the city government is retiring. I have just accepted the position to lead the database and applications support side of the house and another ne Dear Bob …I was wondering if you could impart a bit of wisdom (things to be wary of) before I begin a new supervisory position in an established IT shop …The particulars: Manager (supervising 20 or so employees) for this IT department in the city government is retiring. I have just accepted the position to lead the database and applications support side of the house and another new manager will be over the networking and security side.After getting the skinny from several people, it seems that major problems that currently exist deal with our IT department staff not really working well together with the IT staff of another part of the city government (and vice versa). The other IT folks have purview over some projects, ours over others, but team responsibilities do overlap to some degree. Seems that it’s a situation of “our” project first, yours second, “our” people do this, yours do that, etc, etc.During the interviewing process, I asked my new boss what he wanted me to focus on in the first 90 days. His statement was “Bring order to chaos. It seems that nobody is working ‘with’ anybody.” I feel I’ll be able to handle the technical aspects without much trouble, but before I assume this position (30 days from now), I wanted to come up with my own game plan to see what I should do to try to make a group of people function as a team … definitely the harder of the two sides of the management coin that I’m faced with.Any ideas or pearls of wisdom?– Entering Chaos Dear Chaos …I have a few ideas. You’ll have to decide whether they’re pearls or just beads.The situation you describe is common. When two peer organizations have overlapping responsibilities, rivalry and mutual finger-pointing is a more likely outcome than collaboration and shared responsibility. A lot of factors contribute to this. The most significant is simple to understand and hard to fix: When I share responsibility with another party for achieving a result, I do my part, and it still doesn’t get done, what could be more natural than to figure it’s the other party’s fault? Of course, the other party thinks exactly as I do, and the real reason we failed to achieve the result is that both of us stayed within our boundaries to avoid annoying the other party. Which brings us to your situation. Here’s what I’d suggest.Your first step is the same as anyone else’s who is taking over management of an organization: Meet with everyone you can, inside IT and out. This is important even if you already know them all, as you know them through a different role. These are listening sessions, not talking sessions. You don’t want to make commitments yet, just understand everyone’s perspectives on issues.Do this as fast as you can, because it will give you “organizational cover” for your next step, which is to meet with your counterpart in the other IT department. Relating the consensus that emerged from 60 or so one-on-one meetings is a lot more powerful than presenting your own impression of the situation. This is important because the subject of your first meeting is, “The way we’ve been doing things isn’t working, so we need to find a different way of doing them.” Before you can fix what’s broken, you first need to establish a trust-based, collaborative relationship with your counterpart on the other side. That starts with a shared understanding that things are broken, and what’s broken about them. Once you’ve achieved that you can move on to designing a solution.Your goal is to redefine the relationship between the two groups of developers. Here are key characteristics that have worked well for my clients in similar situations:* Every project is about organizational change, not software delivery. That means project teams include process owners and end-users as well as analysts and developers. * If there is no non-IT sponsor, there is no project, because what’s the point if nobody outside of IT wants it enough to provide leadership?* Project teams are autonomous … well, mostly autonomous. In the context of each project, “we” means the project team, not the reporting organization. Promoting that mindset is one of the responsibilities of the project manager.* At the end of each project, the project manager provides performance feedback to each team member’s reporting manager for inclusion in that employee’s performance review. This is, by the way, best handled as a three-way meeting rather than behind closed doors. Employees should hear what’s said about them. Also (it’s obvious, but often not done well), nothing should be a surprise. The project manager should provide immediate feedback, positive as well as negative, to team members during the project. The most important ongoing responsibility you and your counterpart will have is enforcing team autonomy. Especially in the early stages, each of you will have project managers in your office complaining about “their” project team members. Each of you will have to be consistent in responding, “It’s your team. That person reports to you for the duration of the project. What do you plan to do about it?”Understand, this is easier said than done, and depends on your counterpart buying into the new way of doing things. If he/she doesn’t, it makes your job that much tougher. Don’t give up – you can achieve enough of this change on your own to establish a higher standard on your side of the table. By making sure your project managers adhere to this philosophy you can infect the other IT organization with your new culture, simply by having their staff experience a better way to run projects.That is, however, Plan B. Plan A works much better, if you can get your counterpart on board. I hope this helps.– Bob ——– Technology Industry