Both win or lose are team results

Looking back gives perspective. You might be doing some reinterpretation of the past events, but if you are honest enough you might find the reasons that lead to the events. At least that is what I think.

I have been doing a lot of thinking of past events, those that lead to me taking the decision to close Sincronía, my former company. We had three unsuccessful projects after a long line of reasonable successful ones. What happened? What went wrong?

The first conclusion, that might be obvious to some, wasn't to me. Things don't go wrong just because the leading person (me in this case) messed up. Most of the people involved have to mess up for something to go bad. Working groups are able to level themselves, balance charges, deal with stress and move on until they reach the desired goal. When one person is not able to give his/her best, someone else takes over and keep going. When a project gets delivered in time, on budget and ending in a happy customer, you have to recognize that every single person in the project (and in the company's support system) was a part of that success.

Same happens the other way around: in order to fail you need all of the team to be unable to balance and support itself, you need a full team of people failing individually at the same time.

This is the first lesson I have learned, every single person involved helped in successes we had, and every single person helped in the final fail. Failing is easy, you get there by not caring, not having enough experience but still taking the job, not helping others, even have some serious cases of people liying, cheating or even sabotaging code. I ended up with a team that had it all to fail and it took us about 9 months to do it. I am responsible of not noticing it on time. But I was too, at that time, a person that didn't care much and wasn't interested in taking over some one else's work.

So here is what I learned and my list of unasked advice for PMs:

• Be sure to always care, and have the energy to do something about it. Don't let your self be so burned out you no longer care. Take a break when you think you can't take it any more (and don't feel guilty about it).
• Monitor individuals and their performances, but be sure to also monitor the health of the group as a whole. See how people interact, how they talk to each other, monitor if there is respect in the team. If you don't have a healthy team you will certainly fail.
• Don't hesitate (as I did) to fire those that are not working as part of the team (and not doing their jobs and expecting someone else to do it is one of the worst ways of not being a team player).
• Be sure to remember that a fail (even a huge one) does not define you. If you fail, don't care that much. Learn from it, pay for it (mistakes are often payed in the form of money) and then, move on. 

Geese and your team productivity

People say that the first job you have as a young professional marks you for life. I agree. When I was a grad student, just after finishing my BA I worked at ACOPI (that is the Colombian Association of Small Industries www.acopi.org.co).

Their most important project at the time was called PRODES: Programa de Desarrollo Empresarial Sectorial. It still exists and its main idea is to group similar small business to potentiate their development. For example, if negotiating raw materials for 10 companies, you could make a better deal than if negotiating individually. You can easily implement quality methodologies if you share the work, etc. It made a lot of sense and it was very successful. I didn't work on the PRODES project, but I was always listening, for I found it quite interesting. Many years later I still run my company having in mind many of the PRODES tips. Working on ACÖPI clearly marked me for life.

A basic principle in PRODES was shared leadership: the group will change the leader periodically. Leading a small company is hard; imagine leading a group of 10 companies on top of that. They used as an example how geese fly. When the goose leading is tired, it gets in the back and the one closer takes the lead immediately. The group always has a leader, but no one gets burned in the process.

Recently I have understood (and am experimenting in) a new dimension for the shared leadership. I now use it to elevate software development team productivity. The concept is simple, keep moving the pressure from one team member to other, never dropping the pressure, but never keeping it on one person for too long.

This is how I suggest you implement it:

Know your project
Functionality will have different levels con complexity: might require knowledge for the business, particular technical skills, prerequisites from other use cases, etc. You need to know as much as the project as you possibly can, keeping a general (managerial) view.
With this knowledge you´ll have what is needed to have estimates for all units of work. We have estimates based on historical averages and a bit of my own personal invention (Delphi technique, so it doesn´t sound so bad).

Know your people
Every person in your team has different skills and abilities. They also have limitations, lack experience or have certain difficulties. Since the PMs job is to make it happen in the time you have with the money you said you would, knowing as much as you can (from a professional perspective) from you team will always help. You will then be able to know what will be a challenge to one person and will kill him/her of boredom.

Know your bias
All PMs have a team member they prefer, just as parents have a kid they prefer (no matter how much they try to hide it). It's inevitable. Bias will make you assign complex use cases to a single person, or silly boring ones to the other. When in doubt, just look at your statics, that might help you remember that the good one is not so good, the bad one is not so bad and that most of the bias is a construction of your mind (we hopefully someday quiet).

Remember it's all about the money
Well, all these know and acknowledge has one single purpose: build the schedule for the development team. Now, define the time period to switch the pressure for one member to the next, and identify your critical tasks. Assign a team member to each task on the critical path, switching responsibility periodically, and shortening the time to do it. Don't use the effort you estimate on critical tasks, use less. Take no more that 10%-15% off; if you go for 50% then your schedule will just be unrealistic. Then, fill the rest of the schedule making sure each member gets a simple task after finishing a critical one. Use the regular estimation on all the tasks that are not in the critical path. Your goal is to use shared leadership in the critical path so the schedule will end with extra time and extra money. Really, it's all about the money.

You still need to monitor closely this schedule, and manage any differences from the planned schedule. But will probably get the best out of your team by using the geese technique.

By the way, PM stands for Project Manager.