Where the Rubber Duck Meets the Road
I swear a good part of my day is spent listening to developers make a case for why something can't be done—it's too hard, it will take too long, it will introduce another bug, it will require convoluted code or introduce a tremendous amount of technical debt—and then synthesizing their argument and making a case to the product owner or the engineering director that the work should be altered, put off, or just axed entirely... only to find that when I've successfully argued the case, the developer has just gone and done the work after all. This usually involves a shrug and a, "oh, it turned out to be easier/not as bad as I thought" or "after I thought about it some more, I came up with an approach that would work."
While I do occasionally wince and wonder if my product owner and boss think I'm an idiot, for the most part I don't mind as long as the work ends up getting done, and done well—and I suspect the product owner and my boss feel the same. I consider it part of my job to be a rubber duck (I like to think that the advantage I have over that inanimate object is that I ask questions), and to represent the concerns of the developers up the chain. Sometimes I end up doing the latter when the former has already planted the seed that solves the problem.
I think if there's any efficiency to be gained in this process, it's to have some kind of formula for how long to wait before raising the issue up the chain. I don't have one yet—I mostly judge each case based on the level of panic or anger coming from the developer, how well I know him or her, how likely not doing the work is to be a major problem, and how likely just talking about it is to lead to a solution. At that point I factor in my own level of panic, and make a decision about whether to speak up.
--
I'm not sure if this observation or others like it will be of any use to anyone, but I've been thinking that I want to capture more of these random thoughts about what my job entails and what it means to be good at it, for my own edification if for no one else's. It can sometimes be difficult to describe what I do all day and why it's valuable, especially to people who work at companies where Engineering Managers are engineers who are also responsible for assigning work, reporting status, and writing annual reviews in addition to coding at least 80% of the time. As one of the developers who works for me says, "I think we've proven that that model is not the one we should be following, and this model [one in which I know how to code, how to discuss code, and when to jump in and write code or fix bugs, but in which coding could never be considered a significant part of my job] works best."