Nah, Not a Team Player

A few weeks ago when I was visiting the Tech Trek in Ann Arbor, one of the recruiter types at one of the businesses I visited asked if I was a team player. I thought for a second and replied: "Nah, not really". The guy was a little taken back. He said he had never had anyone reply that way to the question. I basically said that if I am on a project and I am the most knowledgeable on the team, I want to be making the decisions. 

Now before you start thinking you are glad you aren't working with this jerk, let me give you some context. The company I was visiting was a company that did extreme agile programming. All of their programmers worked in pairs with a single computer at the same desk eight hours a day. Everyone knew how much everyone else made, and there was a very communal feel there. Their approach seemed to work and they got really good results and very high productivity. It just seemed a little too kumbaya to me.

I have never worked in a pair programming environment, and I really think I would struggle with being that directly connected to someone for eight hours a day. I have a couple of ex-wives who would argue that no one should be subjected to spending eight hours with me each day as well. I have talked to a number of other programmers at conferences who have done various pairing methods, and the consensus I have found is that pairing where you each have a computer and work on different sections of code while collaborating during the day, works really well and is the most comfortable. I wouldn't mind trying that method sometime. The new functionality coming to Visual Studio where you can pair remotely sounds really interesting to me, and I am really looking forward to trying that out. 

The committee-style approach to managing projects is something I have been involved with in the past, and I have found it extremely frustrating. I hate being in meetings where everyone is arguing about how to do a project and since everyone has an equal voice, the person with least knowledge but the loudest voice ends up getting too much say in the direction. A worse situation is where there is a leader of a project who suffers from the Dunning Kruger Effect, and he forces everyone to do things his way. Fortunately, I haven't had to deal with that in a while, it is always a happy day when PM's like that quit the company. 

For me, the ideal projects are managed where the most knowledgeable person on the project leads the technical direction, and the person with the best understanding of the business requirements leads the overall project but defers to the technical lead on anything technical. That doesn't mean that the rest of the team shouldn't have any input, good leaders will listen to all ideas and decide on a course accordingly. Having someone with strong technical skills setting the direction can really help avoid doing things just because they are easy. Typically a skilled programmer will choose the right way because it will be easier to maintain in the future. 

When I said I am not a team player, what I really should have said is that I am really picky about the teams I want to play with. If I am the most knowledgeable person on a team, I want to be the decision maker on the technical direction. If I am not the most knowledgeable, I want someone else being the leader, and I will be happy to follow. If I am put on a SharePoint project, for example, I will definitely want someone else leading it because I suck at SharePoint and I hate it. If it is an ASP.NET Core MVC project, then I want to own it, and if it were an Angular project I would really like to have someone else lead who I could learn from.

Leading a project and setting the technical direction means a lot more than just telling people what do to. If you are the most knowledgeable on your team and you want the rest of your team to follow your direction, you will have to help them gain the skills they need to meet your vision. On my latest project, I have been using Wiki's in TFS to document the structure of the project as well as the techniques I use for different sections of code. When I check code into the repository, I give lengthy descriptions and code snippets in my pull requests so other team members can see exactly how I did things, and how they can use my examples. My goal is always to help people get to a higher level so the next project will be even more exciting with new technologies. 

For the past few years, I have been on a really small development team, so I haven't been involved with many large-scale projects. Back in the nineties, I worked at the company headquarters and I was involved in a number of global projects where I worked with a lot of talented people. I am not a huge fan of meetings, but there were times where I would be in meetings with the top people from the network, database, security, and infrastructure teams, and when everyone left the meeting, we were all a little smarter than when they walked in. I really miss those days in my career. Like the old saying goes: if you are the smartest person in the room, it just means you are in the wrong room. Of course, someone has to be the smartest person in the room, so if you work on mentoring everyone else, it may end up being the right room in the end. 

It seems like every day you hear about a new approach to managing projects, teams, and development. There are so many buzzwords flying around like agile, lean, design thinking, extreme programming, etc., and everyone is trying to find the best way to utilize these concepts. Have you found an approach that works well that you like? Have you found something that was a total failure and would recommend staying clear of? Let me know in the comments.