If they are not busy enough, that’s management’s fault.

If they ‘feel’ like they can do everything, they need to learn to be a team player and work with others. There is nothing wrong with being good at a lot of things. In a team environment, however, more people produce exponentially more work and/or better quality work if it is run correctly. As such, they need to be a part of that.

If leadership isn’t put in place to be held accountable for this person’s actions, this is both the fault of management for not having the proper leadership setup, and for not setting proper expectations of the employee.

I’ve found most things in IT are all managements fault. I’ve f’ed up royally a few times, but I agree with the statistic thrown around online that 95% of all IT projects that fail are not a result of any IT or technological failing, but rather management.

The designer hybrid we had on our project was great. He knew the business, knew the tools, and could help out a lot. Therefore, I threw a ton of work his way. If he’s busy working, he isn’t asking to do our work.

I agree about learning your co-workers, and getting a feel for each other. As a consultant, I’m learning how to get integrated and up-and-running quickly. I changed schools a lot as a kid, and thus had to learn to adapt to new social situations quickly to fit in. I think that is serving me now to quickly learn who someone is and how to approach them. You can then use those same people skills to see how they interact in social situations, and recognize the good interactions and bad ones, and do your best to facilitate the positive ones.

People have buttons too. You know which ones to press, when, and which ones not too. If someone is good at quickly knowing some one, they can also be a mediator. I feel I’ve been good at keeping the peace since I f’ing hate conflict and loathe drama. It’s best to get the crap out the door, and quickly.

Obviously, it’s best if someone is assigned this role, like a manager / team leader / architect, etc. Accountability for your leadership role is important. Sometimes these things are defined, and other times you just play by ear.

To give more concrete examples, I learned I couldn’t sell my developer team member on Flash best programming practices. He was too much like me, and could see through bullshit. So, together we did things horrible, and then did things right. This allowed him to gain the appreciation I had, in the exact same way I had. While it took longer, it was the most effective; I would know since we are a lot a like.

The designer constantly had feelings he wanted to express. I could tell by his body language and response to statements about what to do next. Consistently, his knowledge of the business helped define better plans of attack for the entire team. So, instead of stating things, I’d ask rhetorically, and be sincere in asking for feedback.

One developer consistently questioned our development strategy. At first I didn’t feel like explaining, but realized that was extremely unfair since we were all equal. I actually ended up liking it because it reminded me of myself questioning everything. So, using a viable task, I set him upon tackling a more challenging aspect of the project. Upon integration, he started recognizing a lot of the reasons I took the approaches I did. I also learned that his questions always had an ulterior motive and as long as I worked to facilitate his research rather than take over it, we had good synergy.

The other designer I learned was most productive and happy when given clear directions. For someone so easy going, you’d think it’d be easy to please him. It wasn’t mainly because I had so much whack stuff on my plate, and it was hard to give clear direction when I barely knew it myself. As long as I was honest, he was cool with that rather than being fed a line of bs and getting irritated further.

I found the team was productive when left to their own devices; when outside forces inserted doubt or uncertainty, productivity went down. I did my best to spearhead any unsure initiatives, or quash any outstanding unknowns. Management was very helpful & supportive in this endeavor.

Going out to lunch, frequently, helps better to get know your team. You don’t have to talk to them, just listen; watch their interactions. When something frustrations them, don’t get frustrated too; try to understand why they are frustrated. You can act to avoid those frustrations in the future.

The direct approach is great to. What do you like? Why are you here? What are you doing this for? This line of work; what is the point? Those kinds of hard line questions give you a better sense of the person, but can be perceived as being very personal. Alcohol helps remove inhibitions to answering those questions.

Finally, making sure everyone was in their niche. If you are doing something you are good at and like, you can get in the zone. A group of devs in the zone is a neat thing to see and good work, good teamwork, comes from it.