Are you reacting to them or are they responding to you?

Community Manager, Jeff Suever talks about the role of product delivery

The key question to ask yourself before every meeting: are you reacting to them or are they responding to you? Whether it be with your development team or the C-Suite, you should take a moment and evaluate: how are you walking into that meeting? Worried about what they will say? How will someone react? GREAT! Embrace it. Those feelings of anxiety are tools. Indicators that you are playing defense and you are in “reaction mode”. Now let’s get out of that.

Oftentimes, as the Product Delivery Community Manager for North America, I’m asked, “How exactly do you get out of that cyclical repetition of reactionary mode?” My answer is always, “By being prepared.”

This  interesting article was forwarded to me recently and it links to several report templates. While some of them might prove useful to you, the reports themselves aren’t the important part. What is important is knowing your facts and outcomes. That makes you equipped to turn

“What are they going to say when I tell them…”


“What do I want them to do when I tell them….”

You never want to present information inaccurately or even give the slightest hint of “spin”. However, by focusing on what outcomes YOU want to affect, you naturally show you are in control of the situation and that you have a plan. Even if the ultimate decision and direction is completely different than what you had planned- at least you had a plan and a solution. You should always have a plan.

I remember one project where the goal was to update the UI on a banking application with over 100 different customer journeys. During the statement of work (SOW) creation process, there were naturally a few voices in the room who became overwhelmed at the scope we wanted to undertake. As always, there was a tight timeline, but in typical product delivery fashion, when is there not? This forced us to get creative. More than just “working backwards” or “reusable components”, we had to take a look at our overall processes and do several things:

  • Create separate work streams so multiple teams could work unimpeded.
  • Map out user journeys and time box the effort on each one. We were able to do this by bucketing them into small, medium and large sizes (Agile 101). We knew right off that if more than “x” percent were large – we were doomed. If more than “y” percent were small – we were likely unrealistic.
  • Tight schedule tracking that was socialized with the team and multiple Agile project managers so no one became a “single point of failure”.
  • Consistent reporting so everyone knew how anxious to be (hint: a little bit all the time is better than a lot all at once).
  • Create early warning flags that went beyond “risk identifiers” so that we could say things like “It isn’t a risk yet, but we can see it from here.” These were items such as:
    • Design throughput – which we were dependent upon another team for. Are we overrunning their ability to produce approved UX?
    • QA capacity. Are we burdening our QA with too many “back and forth across the board” or are work items going “straight to done”?
    • Excess development resources. Too many is as bad as too few. Growing up on the farm my dad used to say “One teenager is a bit of help. Two is a lot of help. Three just get in each other’s way.”
    • Team burnout. While this project only lasted a few months, we didn’t want to risk any long term negative effects to our people. Do we have a plan to rotate someone off?
    • Are we tracking with our initial overall sizing distribution or are we losing ground with every journey? What’s our average size this week?

The net result was about two hours later we had a really ugly whiteboard that we were able to translate into a plan. One that gave our finance department confidence to move forward with the SOW and one that gave our teams a basis to execute from with the flexibility to adapt in flight as needed. Which they did as was evidenced by the longer the team executed, the smoother they ran.

Remember: the goal is not for you to react to outside influences. The goal is to influence responses in the best way possible to help everyone reach the desired outcome.