Time to Lead

In my past (today too), I can be a hands-on project manager. If needed, I can throw my hands and head to help. For development, it’s as a pair programmer. For QA Testing (an earlier career), I can write the test plan, test cases, and execute.

As I started leading larger projects, I noticed that I got stressed more. I read once that stress is caused by 2 primary things – (1) feeling that you did not do your best and (2) trying to control things that I cannot control. If it’s QA, it’s their responsibility to deliver (not my direct responsibility). It was too late to control the risks that were realized or the circumstances dictated to us.

One of the best decisions I made was to focus on things that I can control. I also started to move toward being more of a leader than a manager. Several books note that there are different characteristics and goals between the 2 roles.

For me, this journey (I’m not done yet) takes 2 forms – guiding principles and risk mgmt. I cannot be available 24x7 to the team – meetings, different time zones, vacation, and more. At the beginning of the project, I establish project guiding principles to help guide the team when they have questions. Some are generic such as “How does this support the Operations? Maybe there are multiple solutions available. Think about which solution best supports the operations (which may not be the easiest solution).” While others are more specific to the project.

For risk management, I’ve gone a little overboard but it works for me. In Outlook, I have a recurring task that appears every 3 weeks – “brainstorm risks.” I go to a quiet, few distractions place. I bring the project plan, last status report, project binder, and more. I brainstorm what can go wrong in our current situations and continue through implementation. I also think of mitigations for each so I can try to reduce the impact or eliminate the risk. Then I prioritize the risks and best mitigations. I tend to have 2-4 pages of risks and mitigations. Some are simpler such as what if the environment is not ready next week (mitigation – check progress and apply additional milestones if necessary). Others are more profound or larger impact and are added to the risk register – more visibility.

Last year, I led a 13-month project where my entire development and QA Test teams were located in India (9½ ahead time difference). At first, we didn’t have guiding principles. Some decisions were delayed until I could reply to an email or had a meeting the next day. Sometimes that was a day delay. Add those up and your schedule can be shot. Then we applied the guiding principles. The offshore team felt more empowered and had some direction. (One of the guiding principles was also to be more self-sufficient.) While there were some corrective actions, it mostly went well. From a risk standpoint, I was unable to manage-by-walking-around; I couldn’t just walk over to the developer’s desk to see how things were going. There was a lot of risk planning here – milestone setting, concrete/physical deliverables that could be reviewed or demos, and more. My stress was reduced so I was able to lead and manage better.

TAKE-AWAYS: Know what causes you stress and manage it. For me, it was planning for risk (so there were less surprises) and limiting how often I got into the nitty-gritty details.