Why doesn’t Engineering report to Product Management?

Open question:

There are lots of discussions about how Engineering and Product Management should be structured and interact.

But one I rarely hear discussed is that of Engineering reporting into Product Management.

To clarify, what I’m talking about is a structure where Engineering and Product Management of course, both report up into a VP of Product Management. i.e. Engineering has all the normal structures such as QA, Documentation, Development Managers, Program/Project Managers, Architects etc. etc. But that whole hierarchy reports up into the VP of PM.

I’m not saying that Engineering teams etc. should report into Product Managers specifically. Thus from an executive point of view, Product Management is held ultimately accountable for what is delivered in the product, but also has the authority to structure the Engineering resources as needed to optimize for the business goals they are trying to achieve.

Do you know of any companies where they’ve implemented this?

Are there certain situations where it can work or should be used?

What are the pluses and minuses here?

Whether you are an engineer, product manager or in another field, I’m really looking forward to your comments.



23 responses to “Why doesn’t Engineering report to Product Management?

  1. For me, the biggest issue comes from the ego of the engineer. Engineers love little more than making jokes about PMs, whether about their uselessness, their hand-wavingness or their flip-flopiness. It’s harder to joke about your boss, and it’s harder to joke when organizationally you are more like a peon than a decision maker.

    That’s not to say that in practice, engineers don’t report to a product manager, even if not directly. Engineers might follow directions, but they need to be able to tell themselves “well that’s just because the product manager works on all the business stuff that I don’t care about.”

    (note: I am an engineer so factor that in however you want)

  2. Why would they?

    Typically engineers do a lot more work than what the product manager manages. A lot of times they spend as much time maintaining old code, doing intra-office or intranet application type work, and more. The PMs usually don’t (and shouldn’t) manage that.

    It’s also really hard to report to someone you don’t respect, and many engineers don’t respect people who can’t walk the walk. In other words, many engineers perceive PMs as little more than Excel jockeys (which many PMs are), so why should they respect them, much less report to them?

  3. I don’t know if they should report to Product Managers, but they should be working together. You can move an engineer into PM mode after some training. I think that would be the best route, as the PM still hold respect as a qualified engineer. No engineer is going to willing jump ship to business type, so the incentives better be good.

  4. Hi,

    Thanks for the comments. I updated the post with more detail on the structure that I’m thinking of when I ask the question. Take a look at the additional detail and let me know if it clarifies anything that may have been confusing or missing.


  5. At one company I worked for, the VP of Product Development had Engineering and Product Management reporting into him as peer functions, and the Veep himself advanced up the Product Management career ladder, not Engineering.

    That company had the most functional Engineering-Product Management relationship of any company I’ve been at.

  6. Ross Patterson

    I’ve seen it done the other way around, similar to Sue’s case. In particular, a CTO-and-VP-of-Product (yes, “Product”, not “Product SomethingOrOther”) who owned Product Management, Engineering, and Quality Assurance as peer organizations. It actually worked quite well. But the CTO/VP was qualified to run any one of the three groups himself – something neither the average Engineering Manager nor the average Product Manager is up to.

  7. We’ve actually got a similar setup to Ross in our company. The CTO has product, engineering and operations (including QA functions) reporting into him. Unlike Ross however, our CTO has come up the engineering side and shows no desire to pick up the product side. The end result? The product team is slowly being turned into nothing more than a bunch of glorified business analysts.

    To me, the initial idea of engineering reporting into a head of product is a good one, or at least it would be in my company. The ongoing politics between engineering, product and QA cripple the company. If one person controls all that resource and is bought into and understands the product roadmap things would run much more smoothly, but maybe that’s just a pipe-dream!

  8. Saeed: you seem to view having engineers reporting to PMs as being a strange way to do things, isn’t it really the way things should be done?

    I believe that it all comes down to clearly defining who owns the product. The worst thing that you could do is have engineering own the product (I’m an engineer so I get to say that). You really need a customer facing organization (like PM) to be running the show.

    All too often companies forget this and get lost. Apple got confused in the 90’s and lost their way. It was only after a strong marketeer took over (Steve Jobs) they they got their mojo back.

    – Dr. Jim Anderson
    The Accidental PM Blog
    “Learn How Product Managers Can Be Successful And Get The Respect That They Deserve”

  9. Jim,

    I don’t think engineers should report to PMs directly for a number of reasons. First, it would turn PMs into a form of Development Manager. How can I do my job as a PM when I have a team of developers reporting DIRECTLY to me? Development (and QA and Docs etc.) need their own management layers who are dedicated to those roles. This would get even worse if there are offshore or distributed teams.

    Secondly, how development teams are organized and structured wont always map directly to how Product Management is structured. Product Management needs to be organized along lines that make sense for the business. Dev teams need to be organized along lines that make sense for the development of the product.

    Engineering cannot own the product. I agree with you 100%. A business facing owner — like PM — must own the product. As an analogy, if the product were Tide Laundry detergent, the chemists don’t own the product, the Brand Manager does.

    Engineering is a valuable resource. It must be leveraged efficiently. BUT it must also be aligned with business objectives. Ideally a VP PM has both PM and Engineering reporting up into him as parallel teams.

    I’ve worked in companies where this was the case, but the VP of Products at the top came from the Engineering side, so he gave preference to the Engineering side of the house. It was a miserable place to work for many product managers.

    Some Engineering VPs “get it” and understand that the pool of resources they manage must be flexible and be utilized to align with business objectives. But many don’t get it, and you find engineering teams who feel they own the product, and can do what they want, ignore requirements etc.

    It’s a sad situation in many companies and one that leads to incredible amounts of wasted business opportunity.

    There’s probably a longer article I should write on this topic, as it seems there is a lot of interest in it.


  10. Saeed,

    I agree with your view that PM can’t and should not be involved in managing engineering resources. Engineering management is an operational role whereas a PM role is a strategic role. But, some of the irritants that one often faces as a PM:
    1. Lack of say in quality and timeliness of engineering delivery.
    2. In general lack of respect for PM opinion from engineering.

    Now one can pass this off saying that these are part and parcel of a PM job, but it become much more compounded when a PM is faced with the nightmare of being the PO for scrum teams and more still when a PM reports into an engineering manager.

    For some reason , I have failed to understand that why does engineering org not understand that a PM is not someone who only plays with numbers , but someone who can comprehend technical stuff. Also engineering probably needs to have an appreciation of the fact that the PM org is one which can cause a success or failure, so supporting the PM org should be an objective.

    My suggestion:
    PMs should be placed at mimimum at Director levels when compared to engg managers.
    Engg VPs should have P/L responsibility too.

  11. IMHO, it doesn’t matter who reports to whom if you have the right people at the right places. If you have product managers who are sensitive to engineering complexities and can appreciate the nuances, nothing like it! On the other hand, engineering manager should be sensitive to business needs.

    The two parties are in doldrums when the PM comes up with idiosyncratic requirements and also tries to pressure the engineering team to deliver against a pre-decided time line. This will not only turn off the engineering team, it will not get the job done anyway. On the other hand, engineering manager should be accountable for time-lines once decided and keeping all parties abreast with development efforts.

    The two functions are like the two wheels in a bicycle, any one goes flat and it will hurt.

  12. Nimit,

    In an ideal world how things are organized wouldn’t matter, as everyone would know what to do and then do the right things. But that’s not where we exist. Organizational structures are critically important to business success. How organizations, measure, manage and optimize how they operate is as important as what they build and sell.

    There is an assumption in all of this that people are competent in their roles. So the case of the idiosyncratic requirements is a problem no matter what the org structure.

    In the end the org structure must bring alignment and optimization to the business. If that means a reporting structure where the VP of Products is business focused but the technical teams report up into him/her then that should be as acceptable as any other structure. Egos etc. need to be left at the door.


  13. Most product managers actually do have a fair appreciation of engineering activities. After all most of them would have been engineers themselves at some point of time. Most of the times we would hear from engineering that PMs have come up with requirements that do not make sense and thats usually because engineering will look at things at best a 6 months horizon while a PM is looking at a more longer term horizon. The horizon may not always be in terms of time lines but rather in terms of strategic business value. A PM typically is constantly building the blocks and foundations towards a larger goal. Constrained time lines in my experience occur mainly due to poor project and people management and rarely due to Product management. A PM would always balance out time against the priortized features…

    To reiterate my previous suggestion, have VP Products (or Product Leaders) for each product even if that means with in the same BU and assign them P/L responsibility. The product line’s PM and engineering report to this entity. In addition the PM has an equally strong line reporting to the BU level PM org. While it is necessary for a PM to focus on a particular product, it is equally important to stay tuned on other corners of the org to have the correct alignment.

  14. The VP of Dev has plenty of infrastructure and people to manage. He is a busy guy. He is not focused on customer needs, and he shouldn’t be. If he was, he wouldn’t be able to fill those needs.

    The PM has much more to do than interact with dev. They also have to interact with every in-offer department, not just dev. If dev reported to them, when why not marketing, customer service, shipping, and accounts receivables.

    Some PMs might want dev to report to them, because that’s where their skills are centered. They need to broaden the scope of their view of the job.

    Some PMs might want Dev to report to them, because they could in fact do the job better, but then they couldn’t do the PM job better. The politics might be that they are stuck with a dev that doesn’t have a reliable estimation and scheduling capability. It might be that the VP of Dev is working the problem and dealing with the change management involved.

    Take your VP of Dev to lunch. Get to know his issues and where he thinks he is at. Develop a rapport. Find ways to help him achieve success. Enable. Gain influence.

    Having direct reports doesn’t teach you how to influence. Running a line organization would just make the PM more reactive. The PM wouldn’t have time to be proactive. The PM wouldn’t have time to gain influence.

    The PM would also find themselves short of managerial focus. When a specialization emerges, it does so because it is better at dealing with certains issues and scope than those in other positions. It doesn’t mean that the others couldn’t do their job.

    Be the PM. Be Happy.

  15. This post seemed to generate a more downbeat response than I thought.

    I believe Saeed is proposing that VP of Product Management is better suited to lead the team(s) tasked with delivery of the product. These teams include Product Management and Development. I believe he is proposing two branches off the hierarchy, one for engineering/development and one for product management. Much like it is today for some companies except instead of having a CTO (or some other technical-based role) at the top, it is a product management/marketing type person.

    I like it. -Stewart

  16. Pingback: links for 2009-02-04 • Bare Identity

  17. Pingback: Why Doesn’t Engineering report to Product Management (redux) « On Product Management

  18. Most of the comments I’ve noticed respond to the basic question of who should report to whom. Somehow, this suggests that one function is a better function than another. Is Development better suited to ‘run’ product? Is Product Management better suited? What about Marketing?

    Our collective perspectives are built on the age old defense for organizations that are organized by functions – or in functional silos. Functional organizations exist because each function provides unique expertise to the running of the business. Product managers certainly ‘grow up’ in a bunch of different functions (I started out as a Financial Analyst) but some how end up in Product Management (read The Accidental Profession in The Product Manager’s Desk Reference).

    However, Product Management isn’t really a vertical function like Engineering or Manufacturing, Finance, or Supply Chain. Product Management acts more like a horizontal function. Product managers are the business people who know how to bring people from different functions together on behalf of their business – the product, product line, or portfolio. Product managers are market oriented business generalists who have to earn their credibility in leading a team of people from different business functions. Think football. Think Quarterback. The Quarterback calls a play and gets all the different team members to carry out their assignments. No one questions the QB or the team becomes vulnerable to the competitor. You cannot get a Linebacker to be a Quarterback. They just don’t have the expertise and they cannot pass the ball. They don’t see the big picture. Neither does anyone else in the organization – see the bigger picture. It’s the product manager. And if the product manager doesn’t see a bigger picture, cannot get others to see it, and cannot get them to strategize about it and come together tactically to carry it out, then forget it – there is no business because there’s no product leadership. In this case, the next ‘strongest’ function, usually Development or Engineering steps in. And they will come up with every excuse on the planet why they should be in charge.

    In football, like in the military, there’s a command and control structure. In companies, we collaborate. So product managers need to be especially expert to convince their peers and bosses that the collaborative activities of a product team result in the best decisions that improves the probability for any product achieve its desired market, financial, and business objectives.

  19. Steven,

    Thanks for the comment. In general I agree with you, but I do want to caution against the quarterback analogy. It focuses too much on the individual. One of the problems I see is that people don’t view Product Management as a full fledged business function, but simply a collection of individuals with narrow responsibilities.

    Also, who reports to whom is not intended to imply one function is senior to the other, but simply what is the optimal organization to achieve business goals. While it may be important early on in a technology company to be technology centric, that phase quickly passes, and it’s the objectives of the business that must drive the technology focus and efforts.

    This is a hard pill for many on the engineering side of the house to swallow. They have large numbers and in theory a lot of political power, but in reality unless they align optimally with business objectives, they are a major business inhibitor vs. a business driver.

    Product Management needs to be staffed and structured for success. Most of the time, unfortunately, it is not. This is one of the root problems for PM/Eng dysfunction, and a problem that will take a lot of effort and eduction within the technology industry to properly address.

  20. Saeed,

    The reason I use the QB analogy is because that role cannot function on its own – it depends on others sticking to their roles – and since football is command and control, it works fine. However, the true challenge for PMs is in finessing what I refer to as negotiating horizontal contracts with people in other functions.

    I also agree with you that PM should be afforded its own “function” in business.

    As another data point, in most industries outside of tech, PM tends to report to Marketing. However, even when it reports to Marketing, when PM doesn’t have enough control or influence of other marketing mix elements, then you get what I call “sub-functional” silos where even the marketing people cannot get coordinated and work on their own agendas.

    In tech (where I spent my PM years), I always reported to Development, except in one instance at AT&T. I worked for a woman for 3 years – she had both tech and PM reporting to her, and, she was AMAZING at leading both of these functions, and, it made my job easier in negotiating with my peers (there were 3 tech directors and me, a pm dir).

    I think we’re all on the same page. What I would like to see however, are truly empowered cross-functional product teams that own the product, and are accountable together for results. We’ve seen this in companies we benchmarked (during my corporate life), and in a few of the companies I’ve worked with in my current life.

  21. Pingback: Where does product management belong in an organization? « Ramblings on Product Development

  22. I agree with some answers above. I don’t understand why they would. No doubt they need to work closely together. But engnieering answers questions with yes or no, not I’m not sure, I will check that out, or some other marketing answer. Customers want to know now, not days later if they have technical issues. Ive been working for 20+ years in engineering and have never seen or heard of this reporting structure.

  23. Pingback: Happy (belated) birthday to us (again)! « On Product Management