As noted in my last post, Sales and Marketing often wonder whether Engineering is sufficiently motivated and engaged. But the symptoms aren’t so obvious to the outbound (and extroverted) part of the company. While sales teams stereotypically rally around contests, talk sports and drink coffee (which is for closers)… development teams may sit silently side-by-side-by-side most of the day engaging in multiple Slack conversations, taking breaks for air hockey or exchanging giphys, and critiquing each other’s code indents. Motivation and engagement look different on the tech side of the room: the outbound team often can’t tell whether Engineering is emotionally engaged.
Some Engineering teams are unmotivated, though. Engineering management should know it, and product management better not be far behind. If we (product managers) are working hand-in-VR-glove with our technical teams – slogging through sprint planning and user stories and estimation together; joining retrospectives; humbly critiquing product architectures; joining trips to mystery rooms; cheerleading when devs are too shy to take credit for themselves; and gently infiltrating this special developer society – we may be the first to spot motivational problems.
There are some real symptoms of disengagement: poor standup attendance; drop-off of team members volunteering to help each other with complex problems; no opinions about backlog priorities; indifference to bugs and automated test failures; angels-dancing-on-pin philosophical arguments about whether a story is “done;” short shrift on code reviews; and shrugs when asked why a particular feature or fix is important.
Development teams (aka scrum teams, squads, crews) formally report up through Engineering, but Product Management has a shared responsibility to support well-functioning teams and build trust. Product Management can only succeed through a strong partnership with Engineering. So improving
Engineering morale (and productivity and product success) is an opportunity for joint leadership and collective action.
Can’t We Just Measure Engineering More Closely?
Sales organizations thrive on weekly pipeline reviews, overt competition, leaderboards and contests, inspections, and unambiguous “is this an opportunity yet?” criteria. Staring at “percentage quota retired vs. percentage of quarter elapsed” every few hours. Sales is hard in a different way than Engineering is hard. And first prize is a Cadillac.
But top-down, metrics-driven interventions mostly fail to make development teams more productive. Deep schedule inspection by outsiders and hourly queries of “is it done yet?” have negative results. In fact, they are counterproductive. Unlike salespeople, developers are mostly not motivated by corporate revenue forecasts, demands to stay in the office later, or Sales’ urgency to earn commissions. Dev teams need more than task lists and reminders about productivity. We can’t make developers work harder, we can only make them want to work harder.
In my experience, highly productive development teams are internally motivated by a clear sense of purpose (“why is this feature important to our customers?”) and a direct connection between individual development work items and individual end user happiness (“Users are telling us they really like the updated sign-on workflow”). See Marty Cagan’s Missionaries vs. Mercenaries. When developers can personalize their specific tasks/stories by directly connecting their work to emotional reactions of users, they create intrinsic motivation to focus on outcomes, solve problems better, and build great products. IMHO, the top motivator for developers is a direct emotional connection between story-level work and individual user happiness.
While Engineering leadership is ultimately responsible for team structure and productivity, Product Management should provide a steady stream of motivational context that helps developers attach mission/meaning to their work. I have personally re-engaged some development teams with a campaign of relevant, digestible, packaged customer information: driving real improvement in motivation, productivity and product quality. Engaged development teams do better work, get more done, are happier, and stay around to share in the company’s success.
Here are some things that Product can do to (help) increase engagement and motivation:
- Set up frequent calls/interviews with actual end users. Take extensive verbatim notes (or recordings with permission, or usertesting.com videos) about each user, organization, product and any issues. Put call notes in a wiki, shared folder or other team-accessible place.
- Send out 20-to-100-word summaries to the team, along with links to the full detail via the team’s native communication channel (slack, email, chat, whatever). Team members can read summaries or dig into details on their own schedules. Earning customer cred with the team is purely intentional.
Invite team members to sit in on calls/interviews. (Silently.) Let them hear live users talk about real product experiences. This builds a very strong emotional connection between user-reported problems and requests/stories. (“Everyone knows that you have to let this machine warm up, press reset twice, and then type to the rhythm of Walk This Way. Completely obvious.”) Teams understand better what’s important when they watch users interact with products.
- Wherever possible, connect customer requests and sales wins with technical work. (“I just talked with a user at Company X who loves our new content search bar.” “We closed a big deal with BigCorp, partly because you-all built a connector to their ABC system.” “Some of you heard Polly User on the phone this morning about how she can’t enroll new learners when our login page is offline. She was in tears, worrying that they might cancel her next round of training.”)
- Periodically, walk through the product-level roadmap and broad product strategy. What’s next? Why is it important? How will we track success? How does this fit into the overall picture? Ideally each major technical deliverable can be connected to a business outcome, so the team has context for why its work matters.
- Applaud a few easily-described, easily delivered wins that make Engineering progress more evident. Make sure internal stakeholders connect the outcomes they see with what your team created. Get Sales/Marketing/Support to express appreciation when things go well. Build some positive momentum across the selling-building gap.
- Reward the team (not individuals). Create periodic excuses to celebrate (not just at major deliverables). Figure out what makes them happy.
- Share your own pride in a smoothly functioning organization.
- Buffer your team from interruptions, frequent status checks, and mid-sprint priority reshuffles. Everything except crashed systems can wait until standup or snack time. Developers may need a half hour to re-establish context when outside interruptions break their chain of thought. (So if a developer needs 30 minutes to reassemble her thinking and your CEO leans in every 15 minutes to ask if we’re making good progress…)
Product Management can’t “fix” Engineering. It’s our role, though, to help establish context and motivation. To convey to engineering the value of the work that has been done — and still needs to be done — clearly, accurately, and engagingly. To demonstrate that good work and great teams matter.
Sound Byte
We spend much of our time as product managers focused on WHAT needs doing. We’ll have more motivated teams and better results if we frame WHY it matters and WHO it is for.