Working With Difficult Engineering Teams Part 2
By Brian Lawley, President, 280 Group LLC
In the last issue we started the first part in a series about working with difficult engineering teams. As we mentioned in the previous article some of the engineering teams that you’ll work with as a Product Management professional will be very professional and a pleasure to work with. When you work with a team like this Product Management can be very rewarding, and you can really make an impact on the marketplace. On the other hand, there will be other teams that present more of a challenge, and thus we continue with our article on “Games Engineers Play”.
Game #3 Changing Feature Definitions
Imagine this – you deliver a great MRD that clearly spells out the market needs and required features for your product. You sit down with your team and talk it through and they deliver a functional spec and schedule that appear to meet what you need. Part of the spec calls out one or two of the features by name (XYZ) that you specified in the MRD as being high priority (i.e. would not ship the product without them), and the team agrees that these are critical and must be in the release.
Things are going fine until you see the first version working version of the product. The feature that you had clearly agreed on is there, but it doesn’t deliver anywhere near what you intended at all. You bring this up with the team get the response that “we thought that’s what you meant by XYZ”. To you it was so obvious what you meant that you didn’t go into great detail in the MRD or discussions. But nonetheless there was a disconnect and now you have a product that may not be viable or that may need to miss its schedule to meet market needs.
This situation is one reason why it is critical to deliver a well-written MRD that spells out in as much detail as necessary exactly what your customers need. One technique that will help you to do this is to create a brief glossary of terms as part of your MRD and review it with the team. Scan your MRD for any features or terms that might have any ambiguity, write down a precise definition of exactly what they mean and then review it with the appropriate engineers.
Game #4 Features, Schedule, Performance: Pick Two
One of the engineering managers I used to work with had this statement taped on his office window. Frankly, I don’t blame him – in the company we worked for his priorities for the product would be constantly shifted – one week he would be asked to add significant new functionality, then the next week management would insist on pulling in the schedule.
The challenge here is if a statement like this is presented to you as a Product Manager in absolute terms. The fact is that each one of these elements can be broken down into smaller, more manageable chunks and handled accordingly. For example, performance improvements can be focused on the top five most common tasks that customers perform, rather than sweeping performance improvements across the whole product. And a good engineering team can always work with you creatively to see if there is a slightly reduced feature set or a shift of team resources to make the feature set and schedule stay on track.
Game #5 Using The MRD Process To Stall For Time
Occasionally you’ll run across a team that asks for multiple rounds of clarification on the MRD you have delivered. They may ask for an extreme amount of detail or they may delay meetings and push the process out accordingly to buy themselves time.
One of the teams I worked with kept the process going for a good two months before I caught on. In reality they were actually doing quite a bit of background work on other projects and stalling for time before they would have to deliver a spec and be pressed to commit to a schedule.
Of course, when the schedule was published they then pointed to my group and said that if the MRD had been delivered on time the schedule could have been pulled in, but now there was nothing they could do given the realities of how long the development would take.
In retrospect, to avoid this situation I would have insisted that the team make getting to the MRD signoff and spec/schedule agreement their highest priority. Setting milestones for delivery of the MRD and spec and setting the expectation in the company that they would be met would have helped control the process, and I could have put up some red flags if they were not meeting their side of the commitments.
In the next issue we’ll wrap up this series on working with difficult engineering teams.
Brian Lawley, CPM/CPMM, runs the 280 Group, a Marketing and Product Management consulting firm in Silicon Valley. See www.280group.com for details and additional resources.
