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

• 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.

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.

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.

Name and shame them! (kidding)

Look, these things may happen and sometimes they can be amazing, sometimes they're a waste.

Ask youself why this happens? Do they see a need you're not addressing? Do they want to showcase their skills? Or is it something else?

If you build trust with your engineers, they'll tell you what they're doing and why. If you don't have that trust that's likely why the secrecy happens.

Product managers should partner closely with engineers on building a product roadmap so that everyone is bought into the roadmap and avoids the need for slipping in rogue features. I would say this sounds like a lack of trust between product and engineering. Here are a few suggestions of how to rebuild trust:

• Collaborate early and often on a roadmap with engineers and UX to make sure the entire team is bought into the plan. Encourage suggestions from engineers so that they have a voice.

• Establish a clear prioritization framework when deciding what to work on. This should be product-led but still involve the whole team. You can consider things like customer value, time to build, alignment with overall business priorities. That way when there are conflicts between you and engineers over what to prioritize, you can use the prioritization framework to resolve disagreements without much conflict.

• Share customer feedback so engineers can see the impact of their work and understand why you chose to prioritize certain features over others.

• If the engineer still insists on working on a "rogue" feature and assuming it won't damage the product, you can discuss with your tech lead if every sprint your team should reserve 20% for engineers to work on whatever they want. This allows engineers to prioritize issues they want to work on but would never be considered high priority (reliability, design bugs, etc.)