This is a great question! It inspired me to take action and do some research of my own. I interviewed one of my techie colleagues, and I wrote this blog post titled [Monday’s interview – Tech Talk with Ciprian](http://dana-about-pm.com/2014/03/03/mondays-interview-tech-talk-with-ciprian/). I asked some more questions related to the same issue: "how much tech is too much tech in PM" :). I hope this helps! **Here's a snippet from the interview that helps further answer this question:** > **Dana:** When the developers give an estimate for a technical task, how important it is for the PM to know what is being told to decide if is reasonable? > > **Ciprian:** Extremely important. The project manager needs to have a clear understanding about any technical task being estimated. Deciding whether or not the estimate is reasonable, the PM needs to have a very good an honest relationship with the developer (or designer) giving the estimate. The PM needs to ask a lot of questions to try and understand fine aspects of the task, trying to keep in mind any technical roadblocks that might throw off estimates. One last point is that the PM must clearly report estimates particularities to client service or directly to clients so that they will have a clear understanding about what are they paying for. Being technical as a PM basically can help improve the relationship between the PM and developers/designers, since they'll speak the same technical language. > **Dana:** When the developers specify a technical impediment, how much involved should the PM be to resolve it? > > **Ciprian:** PM needs to be aware of any technical impediment, especially ones that will affect overall architecture. The PM and developer (or designer) must work together to come up with a reasonable solution. The PM must not rule out getting advice from other technical persons or anybody who can provide consultation on the issue. Check out the [rest of the interview](http://dana-about-pm.com/2014/03/03/mondays-interview-tech-talk-with-ciprian/) for more information.