My wife is a Licensed Specialist in School Psychology (LSSP). For her trouble of a four year undergraduate degree in psychology plus three additional years of graduate level study, she works with the most difficult children the school system has to offer – the severely emotionally disturbed and mentally retarded. She is paid just slightly more than a teacher.
Unfortunately, the State and the school system do not arm their psychologists with the tools to make meaningful changes in the student’s lives. The Psychologists exist in a consensus world where a committee of advocates must determine what is best for the child. Parents have veto power over consequences, ask for unreasonable concessions (requests ranging from eliminating homework to bribing their child with fast food), and are otherwise difficult. Yet, the LSSP’s are expected by the school’s administration and teachers to “solve” these problem children.
In other words, these psychologists have a high degree of responsibility, but little to no authority. My wife dropped a bomb when she told me that the burnout rate was 5 years for psychologists in the schools for this reason.
Product Management has a similar dilemma. We have lots of responsibility with varying degrees of authority. In almost all cases, PMs don’t have direct management authority over the people who are essential to creating the software, service, or product. For this reason, a PM must develop awesome communications and negotiation skills to be successful and avoid burnout.
There are many leadership styles, ranging from Command and Control (“Do what I say because I am your superior.”) to Follow the Leader (“This is the path, follow me!”). I have realized in my career that my preferred style is Follow the Leader. Personally, I am more comfortable working with a team and getting them to buy into a vision than I am at issuing orders.
I have also found that issuing orders (especially to developers) is counter-productive. There is always The Game that PM and Development play; PM writes the requirements sandbox, and Development looks for the easiest way to interpret the requirements and still fulfill them. When issuing orders to Development, I have found that they are much more likely to try to find the easiest, most minimal solution to a requirement, than to attempt to meet the spirit of the requirement. You can solve for this two ways: one, you can become a PM/Lawyer and write your requirements so airtight that Development has no way out, or second, you can adapt your leadership style.
If you choose the former, you will slowly suffocate the spirit of the Developer because you’ve taken away his/her creativity. They will resent you for this and you will get dragged down into meeting purgatory asking for “clarification” on requirement 10.1.2.15.6.7a. Don’t go there, it is not fun. You’ll also damage your relationship with Development and it takes a long time to repair. There is a better way…
The more you steer towards the Follow the Leader (FTL) style, the more you must accept letting go. Command and Control PM’s are a recipe for burnout. You’ll freak out when a requirement is missed or mis-interpreted and snap. Using FTL can be more challenging than issuing orders, but I believe it is many times more effective. So how do you motivate someone who doesn’t report to you to do what you want? I use a variety of tactics to move the herd.
The Backwards Working Trick. If you are using traditional PM methodologies, you don’t start with a product in mind – you study the Market, identify problems, and express those problems to Development in the form of requirements. Trying to define too much product in your requirements usually means that you are delving too far into the design of the product, or you are in a Divination company. Either way, there comes a point at which you have a fairly good idea of what the end product will look like. Usually, if you have a good relationship with Development, there is a point where you have a whiteboarding session to draw out the potential product. You probably end up with a set of pictures and diagrams that represent what “it” will finally be. Here’s a trick that you can involve the whole team in, and test your requirements.
Backwards Working means that once you’ve completed your requirements (you don’t have to have the rest of the MRD done yet, just the requirements are sufficient), pull your Development Team Lead, Architect, or other trusted advisors into the room. Run through your requirements one-by-one, and with each new requirement start to draw the product on the whiteboard – but the true test is that you can’t draw anything that isn’t specifically memorialized in your requirements. If you’ve done a thorough job, the picture you create should match the first whiteboarding session. It is an easy way to see gaps in your requirements, especially if you are a visual person like me.
The MRD meeting. MRDs are all-powerful communications tools. They spell out the business case, requirements, and the competitive landscape. If you have a well written MRD, you should be able to send it to anyone and after reading, they should be able to answer the questions “why are we building this product?, what will this product do?, and How will this product compete in the market?”
So when you finish your shiny new MRD, should you email blast it out to the team with a mandate to implement your product? NO. ALL MRDs should come with a face-to-face meeting with your Executive team (if they are involved), and especially your Development team. Walk through every requirement and explain the spirit of the requirement as well as the wording. Give them the opportunity to weigh in on how the requirement could be worded better. Use the Backwards Working trick on the whiteboard to build the vision of the product as you go. When you are wrapping the meeting, ask the team these questions: “Does everyone understand what this product will be and what it will do?” “Do you understand why we are going to build this product and what it will do for the company?” “Does anyone see any risks or challenges that we haven’t thought of yet?” Questions like these will show the team that you value their input and they will buy into the requirements because of it.
One of the number one reasons that employees leave is because they feel like they aren’t working towards a common goal and that their feedback is not considered. Use FTL style to show them that it is.