How do you prevent rogue engineers from slipping in features that are good but not prioritized?

Question

Lizzy Masotta · Accepted Answer

To answer this question, I’m going to put my PM hat on. Why is the engineer “rogue”? What is driving them to want to “slip in this feature”?

1. First, I’d talk to them, understand their frustrations, and where they’re coming from.
 2. From that conversation, I would expect to learn a bunch of stuff I probably didn’t realize about how frustrating it is to build in our codebase. The engineers and designers on your team are a key persona you must also serve as a PM. If you can make their lives better, easier, more efficient – do it.
 3. Then, I'd come up with a plan to make sure we allocate a portion of our development efforts to internal improvments. The best execution I’ve seen around making non-customer facing improvements is an approach Salesforce used called the “Trust rotation.” Each sprint 1 engineer was dedicated to “Trust.” There was a “Trust Backlog” the team maintained, prioritized and agreed upon. And, any other burning sev0 issues would go to this eng too.

Ingo Wiegand · Answer

* The first question I would ask is whether PM and engineering have aligned upfront on a mutually agreed-upon definition of the problem to be solved and the definition of success.
 * In my experience, engineers don’t just slip in features for no reason, but there might be other failure modes upstream of that decision. It’s important to understand the ‘why’ and adjust processes and behaviors accordingly.
 * Here are some typical examples of friction points I’ve seen in the past and how to potentially address them:
    * Disagreement on overall roadmap prioritization: take a step back and ensure clear alignment on the problem to solve (and how you landed on the current prioritization of your roadmap)
    * Atmosphere of distrust between PM and engineering: run a structured retrospective discussion to ensure both PM and engineers can give feedback/understand where the disconnect is coming from
    * Not all work that needs to be done in engineering has been captured in the current plans: review engineering plans and evaluate whether estimates have properly accounted for tech debt/uncertainties along the way; alternatively, consider providing the engineering team with a small ‘discretionary’ budget of 10-20% of engineering time every sprint/planning cycle to work on their own p0 items
    * More tenured engineers are looking for more challenging work: think about facilitating rotations or discussing opportunities to flex into more technically challenging work where it aligns with roadmap opportunities

* Most failure modes can be addressed with proper cross-functional communication and a focus on more stringent product development practices.

Mike Flouton · Answer

This is a classic conundrum. The good news is it’s a lot less costly when it happens in today’s agile world than it was when I started my PM career in the days of 18 month waterfall development cycles.

First, apply your PM skills and dig in and explore the problem and its root causes. Is this an isolated issue specific to a single engineer, or more of a systemic cultural issue? If it’s the former, the fix is a bit easier. Make sure you have a rock solid relationship with your engineering managers and address it with them. Any EM worth their salt knows the cost of unplanned work, and it’s especially frustrating when it’s work that could have been avoided. Sometimes you have to drop everything and fix a production issue - it happens. But when it’s an engineer’s pet project it’s avoidable.

Learn how to diplomatically “name and shame.” When I was a PM I’d do a release scorecard for management - if we missed a deadline (or opportunity to come in early), we made sure to clearly highlight the unplanned feature that slipped its way in. You don’t need to throw the engineer under the bus (and probably shouldn’t), but it’s not going to take long for the exec team to start asking questions about what the highlighted unplanned feature is and why it made it in.

If it’s a cultural issue, I’m afraid the fix is much harder. Figure out how high it goes. You may need to enlist help from your head of product if it’s systemic. If it goes as high as the founders, you might need to make the fundamental case for product management. Or find a new job.

Related Ask Me Anything Sessions

Shopify Senior Product Lead, Lizzy Masottaon Product Development Process

Barracuda VP, Product Management, Mike Floutonon Product Development Process

Momentive Vice President Of Product Management, Aleks Basson Product Development Process

Related Questions