Back to Your Feed

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

5 Answers
Ingo Wiegand
Ingo Wiegand
Samsara Vice President of Product Management - SafetyMarch 31
  • 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.
1110 Views
Mike Flouton
Mike Flouton
GitLab VP, ProductOctober 5

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.

367 Views
Lizzy Masotta
Lizzy Masotta
Shopify Senior Product LeadNovember 18

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.
634 Views
C. Todd Lombardo
C. Todd Lombardo
Co-author Product Roadmaps RelaunchedJuly 28

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.

417 Views
Top Product Management Mentors
Sheila Hara
Sheila Hara
Barracuda Sr. Director, Product Management
Chris Omland
Chris Omland
Workiva Vice President Of Product Management
Natalia Baryshnikova
Natalia Baryshnikova
Atlassian Head of Product, Enterprise Agility
Anton Kravchenko
Anton Kravchenko
Carta Sr. Director of Product Management
Omar Eduardo Fernández
Omar Eduardo Fernández
GitLab Director of Product Management
Jacqueline Porter
Jacqueline Porter
GitLab Director of Product Management
Ashka Vakil
Ashka Vakil
strongDM Sr. Director, Product Management
Rupali Jain
Rupali Jain
Optimizely Chief Product Officer
Julian Dunn
Julian Dunn
GitHub Senior Director of Product Management
Devika Nair
Devika Nair
Oracle Cloud Infrastructure Director of Product Management