Tech Debt vs. Launch
As product managers, one of our biggest points of tension with our engineering partners is over tech debt. We are constantly chasing the next big needle mover and eventually that catches up with us. The engineers are painfully aware of the problem much sooner than we know.
Many of our disagreements with engineering partners is over this concept of tech debt. And so, it is a great use case for the interview question: “Tell me about time you had a disagreement with your engineering partner.”
Common Mistake
Most people start diving into the details without summarizing why they picked the story in the first place. (See introclusion). Knowing what you want to tell the interviewer about how you work with engineering on this contentious point will help you narrow down to the most important details.
Amazon has the Best Approach
When I was at Amazon, I learned about the funding model (link). The way it worked: Every engineering team got roughly 30% of the allocated time for their use - it was typically broken down into Keep the Light On (KLO) work and Engineering Excellence. It was up to the team to decide where they would spend their time. This also helped give them some manner of control over tech debt.
I want to note, that it didn’t help when there was such a big problem that the system needed to be re-architected. But even in those situations, starting where the engineering team felt they had some control over their destiny worked wonders.
I have since worked in several organizations that didn’t have this system in place, and the tech debt argument was always worse. When I join a team, I tend to use the same approach informally if the organization itself doesn’t apply it company-wide.
Therefore, when I get the tech debt question, I typically start by explaining my philosophy before diving into an example.
Right vs. Wrong Answers
All answers in this category of questions require you to explain a tradeoff from a tech perspective but also display relationship-building and communication skills. The longer-term fixes require planning, the shorter fixes can often be solved by allowing a little to be fixed as you go or running a bug-bash week - something I saw a lot at Yelp.
A good answer shows balance, don’t always lean towards a fix or the features. Explain how you prioritize the decision.
