Paradoxes in Program Management: 5 Contradictions in Managing a Productive Scrum Team

[Guest Post: John R. Reigart III is the Senior Program Manager and Scrum Master for the WhitePages Business Search team. Prior to WhitePages, he worked at RealNetworks as the Lead Web Developer for where he specialized in building the user interface and presentation layer for the site. Before that John was a Tech Lead and Development Manager at and for 6 years.  He is a Scrum Alliance Certified Scrum Master and has a Degree in Music Technology from New York University.  Follow John on twitter: @johnreigartWP]

As the Senior Program Manager and Scrum Master for the Business Search team at WhitePages, I am tasked with ensuring the execution of a wide variety of features in a fast-moving and ruthlessly competitive space. Nimble execution and minimal waste is paramount, as is a highly functioning and unified team. Ample resources exist for maximizing process with a wide variety of Project Management methodologies (Scrum, Kanban, Waterfall). The nuances of maintaining productivity in a diverse team of carbon based life forms require an ever evolving secret sauce of interpersonal skills.  I’ve distilled down my observations into a group of paradoxes that have occurred to me over the years of managing engineers at MTV Networks, RealNetworks, and most recently at WhitePages.

Communication: Allow freedom of speech but insist on respectful treatment of teammates

Teams need to develop their own dynamic. Do not try to impose your last job’s chemistry or a recommendation from your favorite blog (including this one) on a team. An edgy, clubhouse dynamic may be as appropriate for a team as a buttoned up investment bank vibe. Where a PGM must absolutely insert himself is when communication turns negative. Do not let a team member go to bed angry. Pull conflicting parties together when there is conflict and do not stand for destructive discourse. Chastising words or a hurtful email can have long lasting effects from which some teammates may never recover.

Project Definition: Be specific but don’t spoon feed

Nothing is more frustrating to an engineer than working in a vacuum of direction. Clear goals and demonstrable business benefits need to be clearly communicated. To ensure the most rapid delivery of value to the customer, a substantial degree of ambiguity is necessary and even encouraged. I have found that there are other benefits to leaving some ends open.

Engineers always ask the best questions. They know better than anyone where the business logic will fall apart. In a highly functioning team, they will know as well as anyone how to best serve the consumer. Give your leads and your developers the opportunity to wear their product hats. Let them communicate directly with the stakeholders or external partners to impact the product. Take them off the production line and empower them to contribute to the project goals and you will be rewarded with a more engaged team that has a paternal relationship with their codebase.

Team Input: Encourage input but discourage filibustering

Great ideas are often bottom-up. Many of the most successful technology companies have made their fortune by recognizing this and empowering their rank and file to drive their businesses. By and large, technologists are a passionate, perfectionist, and opinionated lot.  To be successful, a PGM must be open to the ideas the team brings forward. The danger in this team empowerment is paralysis by analysis.

Do not hesitate to drop the gavel on a circular discussion that is not approaching an actionable resolution. Ensure teammates feel understood and respected for their input but recognize that the meter is running on a room full of your top tech talent. Think twice before consistently yielding the podium to the loudest or most persistent talker.

Respectful Demeanor: Be soft like water but stand your ground when the stakes are high

If every day is stress free, you are probably doing it wrong. People get tired, frustrated and need to vent. Be an active listener. Be the lightning rod. Accept some blame occasionally, even if it is poorly placed, in the service of team morale. Paradoxically, do not be a pushover. You need a spine to accomplish team goals. Be forceful and decisive when team productivity is at risk.

You can’t safeguard your team’s velocity if you aren’t respected. Countless times I’ve uttered the phrase “I could have done more to help, and will apply these learnings next time” to diffuse generalized frustration. Likewise I have been quick to push back on stakeholders or prod teammates when timelines were at threat due to negligence or poor communication.

Equitable Treatment: Don’t play favorites, but identify and safeguard key contributors

Diversification of personality and skill sets ensure a strong team. Support all of your contributors in their strengths and put them in situations that challenge them to improve on their weaknesses. Respect your junior members; they are your future leaders. On most teams, however, there is at least one member to whom all eyes turn when the difficult questions are posed. While playing favorites can negatively impact team chemistry, recognizing and sponsoring your key contributors is crucial. Secure their loyalty at all cost.  Study them to find what makes them tick. Employ praise (both private and public), reward, vacation, bribes, or pet projects to keep them happy and engaged. Your effectiveness depends on them.

Technology teams can be quirky. Bridging the gap between business owners and engineers requires a unique set of soft skills. Hopefully my observations give you some ideas to try out in your organization. I learn something new every day; throwing out hard learned conceptions and trying out new ones. There are no concrete rules in working with people so we all must prepare to be humbled and enjoy the ride.

2 Replies to “Paradoxes in Program Management: 5 Contradictions in Managing a Productive Scrum Team”

Leave a Reply