Why project managers get no respect

There is not a child alive who dreams of being a project manager. Maybe a firefighter, a rock star or an astronaut, but not a project manager? Nope. There’s  something inherently dull about the words “project” and “manager”, the notions they generate make the flames of even the brightest imagination flicker and fade. And it follows that in the professional world saying you are a project manager won’t get you much respect either. To many being a PM means you fit this unfortunate stereotype: you were not good enough in your field to be an engineer or a programmer, and through politics and self-inflation, you find ways to take credit for the hard work done by others. It stings, but that’s the stereotype (ask at your next happy hour).

Many PMs unintentionally reinforce this view by trying to get everyone to pay attention to the work they do produce: the meta work of spreadsheets, specifications, presentations and status reports, failing to realize that to most in any organization, these are the least interesting and most bureaucratic things produced in the building. This mismatch of value sends the PM and his/her team into a downward spiral: the PM asking for more and more respect in ways guaranteed to push people further away.

The core problem is perspective. Our culture does not think of movie directors, executive chefs, astronauts, brain surgeons, or rock stars as project managers, despite the fact that much of what these cool, high profile occupations do is manage projects. Everything is a project. The difference is these individuals would never describe themselves primarily as project managers. They’d describe themselves as directors, architects or rock stars first, and as a projects manager or team leaders second. They are committed first to the output, not the process. And the perspective many PMs have is the opposite: they are committed first to the process, and their status in the process, not the output.

The result is that most of the world thinks of project management as BORING. Not sure how it happened, but instead of thinking of the great moments in PM history, say the NASA space race, The D-Day invasion of Normandy, The construction of the pyramids, the Empire State building, or any of a thousand great things made possible only by someone’s effective management of the project, people think of pocket protectors, overdesigned charts, epic status reports, and people who spend too much time in rooms filled exclusively with other project managers. If you are not going out of your way to separate yourself from the stereotype, odds are good that when you say “I’m a project manager” the person you are talking to puts you into a Dilbert cartoon in their mind, and you are the punchline.

People with job titles like “Program Manager”, “Product Manager”, “Information Architect” or “Quality Assurance manager” have similar problems. These titles all makes it hard to relate to what it really is that the person gets paid to make happen: a sure sign of title inflation, confusion via over-specialization, or abstraction from the real work. I suspect all of these folks have similar problems with getting respect from people when they introduce themselves with their literal job title (process), instead of what it is they help make (output).

The news isn’t all bad. This lack of respect creates a huge opportunity for people with open minds: their expectations of you are low. If you take the time to find out what it is that the people on the project need from you, or value from you, and make that as large a part of your job as possible, you’ll get more respect than you expect. And you may find that people start referring to you as a different kind of PM – one who has changed their opinion of what PMs can do for a team – and you’ll earn not only their respect, but their trust and best work too.

98 Responses to “Why project managers get no respect”

  1. SS

    As a former commercial developer that is now a PM, I can say that Project Management is very tricky.

    As a PM, I have to manage stakeholder expectations, manage my resources efficiently by delegating work to the right people as well as coaching/motivating my team. I also have to deliver projects on time and on budget, which means that I once I have organised my sprints, and the project has begun, I have to make sure that my team is on track through daily stand ups, retrospectives as well as writing well written user stories and user acceptance tests.
    Outside of this, I have to develop a good understanding of what technologies are involved when delivering the project. I am not hands on in my role, but whenever I embark on a new project I actively help the dev team with choosing the right technologies, as well as helping them devise a good software architecture.

    I think this article is very unfair in its assumption that PMs do not play an important role in delivering projects because they do not do the actual grunt work. The work we do is arguably harder for the reasons stated above.

    1. Junior Smith

      “harder” LOL. and I am sure your pick of what technology developers should use takes heavy weight in the final decision made by senior developers and architects. — Thanks for adding evidence to the above article.

      1. SS

        No, I generally let them decide, I just like to be involved in the process since it will help me understand what is technically involved.

        1. JK

          As someone who has worked on many IT projects, I find little value in PMs.
          They tend to be an overhead as they want to understand details, when they don’t need to know them. They like to control things, so it appears they have control. They want figures to present to the sponsor so it appears the project is going well, when the time it takes to gather these figures people in the project could be actually doing work. I’m sure there are some who are good but having encountered 30+ of them they’re all pretty much the same.

          1. SS

            Well the PMs you worked with were basically useless. I was a commercial developer and after making the transition to becoming a PM, it is not as simple or irrelevent as you make it sound.

            If you are an agile PM like I am, you have to make sure the productivity of your team is high and to do that, I have to monitor their progress using burn down charts, burn up release plans, cumulative flow diagrams to work out their velocity. I was recently in a situation for example where I was managing a remote subcontractor on a project that basically did little work for half of the project (this was before I introduced the reporting). It was only after looking at the CFM I had to get him back on track. The point is if nobody was managing him, the project would be severely delayed because he was coasting it – this is exactly why management exists to prevent this.

            Outside of that to make the developer life easier, I have to ensure the functional spec document is properly broken down into well organised user stories, with the right story points attached to them.

            Sure the developer can probably do this, but if he is in the middle of a sprint, do you think he will have the time to do this? Do you want him to do this work, or would rather have him write code? Especially if there are several projects to manage on the go? Do you also expect the developer to deal with client requests too? In every software build I have worked on, the client always tries to chuck additional features that goes beyond the spec, which can potentially lead to scope creep.

            I am not saying that there are not bad PMs out there, often the good ones have good technical awareness like I have since I have spent time as a developer. Outside of that I actually spend a lot of time trying to manage the project correctly by motivating, improving existing processes so that projects are delivered smoother. But by making PM sound like a walk in the park it isn’t. If anything goes wrong the PM gets blamed. If projects are not delivered on time, it affects the company, since they are unable to invoice the client which affects cash flow.

        2. Adrian83

          For me it is always funny when I hear a project manager saying that he/she lets the team decide on technical issues. That’s because very often (almost all the times) the project manager is not the most experienced subject matter expert on the team (many times he is not a subject matter expert at all) so he simply has no other choice than letting the team (actually the technical leads) to decide on all the technical aspects.

          I often hear project managers saying that they are empowering the team, giving the team members “authority” to decide, but in reality they (the project managers) lack the competence needed to take decisions of technical nature.

          Probably many project managers don’t want to look dumb in front of the team members and instead of telling them that they are unable to take technical decisions they prefer to give the impression that they are actually giving the team higher responsibilities and the power to decide.

          The reality is that most project managers always want to be in control but the fact they are not the best technical experts on their teams severely limits their ability to control the project team as they will not be able to give technical directions to the team members.

          When there are better technical experts than the project manager or the project manager is not technical at all it is clear that the best subject matter experts on the team, and not the project manager, will take all the technical decisions.

          1. SS

            You are missing the point of project management, the point of it is to help the team deliver the project on time and budget, not to be hands on with the code. Hence,it is much more heavily linked to operations as opposed to the technical side of a business. A PM might not be expected to write code, but they have to do a lot of administrative tasks – budgeting, resourcing (assembling the team for a project), QA, account management, internal and external reporting, keeping track of spirits (if running agile) using burndown charts/cumulative flow diagrams/resource management . In addition, if the project is going badly, the PM will be accountable not the developer.

            A tech lead is exactly that, a tech lead, they are expected to know technical side inside out because that is their role, and very often they are the one’s doing the hands on dev work too – which is what they should be doing, not being involved in the operational side of a business.

            For the record, I can code, have a computer science degree and spent time as a commercial developer. Having technical awareness helps, but the reason why I made the switch is because programming is a boring job where your life is coding a set of requirements as opposed to being involved in the bigger picture.

          2. Johnny T

            That is how it is supposed to work. Now if you are working on a huge global project I mean involving multi components from design, infrastructure and global implementation and major capital expenses your program and project manager would own you! You are a technical authority at best and though an important component to a project not the only one.
            on such projects a project manager is engaged pre-sales at the bid stage and is often involved in bid management to workout costs and high level time plans. On such a project your line manager would understand that YOU report to project management for the duration of you allocation to a project. You may be a shared resource but in large projects you can also be a dedicated resource and you performance on that project evaluated by a PM can propel you in a corporate structure or see you dismissed.
            Honestly, reading into what you stated shows me that you do not have such experience, your mind is simply technical.
            One issue never covered is the over use and misuse of project management especially in the IT world. Just as there is more misapplied in vogue methodologies then properly applied. The PM who mentioned he was an Agile project manager is suspect to me. I have seen that applied to everything it should not be. I have seen it create more overhead for everyone. Issue is that Project managements management (got that) often is placating purely political whims and in turn requests all kinds of info from a PM and then the PM ends up actually interfering with project progress in order to gain the required info. Info that is often so dynamic that it is useless by the time it MIGHT be looked at. Most of these IT projects that have PM’s assigned need no PM. Only complicated engagements should be so managed. NON-Cookie cutter, high dollar Million +, with multi phases. Rollout of a repeatable deliverable at few hundred thousand per does not qualify! in addition the creation of a small e-commerce web site does not qualify, lead engineers can handle this. THIS IS THE PROBLEM.

          3. SS

            Thanks Johnny for calling me ‘suspect’, admittedly I am not the most experienced agile PM since I have just started doing it, but I work hard to do my best in implementing agile in my company as a PM. I am also a certified scrum master.

            From what I can tell you, when this company (a small organisation) didn’t have any one managing their in house product or other projects using a framework, they ran into the following problems:

            1) Nobody to manage unrealistic stakeholder expectations. (big problem)

            Developers would often be given unrealistic targets by the stakeholder i.e. You have 1 week to deliver 4 weeks amount of work not taking into account what is actually realistically possible, since velocity wasn’t tracked. This also was bad since it doesn’t work well with changing requirements.

            2) When working on meeting a target, the developers would then be interrupted by change requests causing a lack of focus and rushed work as opposed to properly completing functionality one at a time and releasing the product in increments.

            3) Poor quality work being delivered – rushed.

            4) Developers who have to spend time doing administration work; internal reporting etc rather then focusing on writing code.

            5) Nobody tracking productivity properly. I use burn down charts to do this based on the velocity of my team during weekly sprints.

            6) Sales team taking on work with impossible time frames and lack of resources. Since coming into this role, I have told the sales team to think agile, that means not letting the customer disrupt sprints by asking for work to be done straight away, but to wait for the next sprint cycle before undergoing their work.

            7) No QA process based on user acceptance criteria in user stories. Nobody to ensure that this was being done properly, previously developers were doing this, we now have a dedicated QA tester doing this.

            etc etc etc

            As a result of the above, the original product had to re-written by my team. It was no maintainable (very hard coded). The company now has a working product which scales.

            As much as Project management is useful in large organisations for the reasons that you have mentioned – and I agree with them. In start ups or small organisations (the organisation I am working in), poor project management can lead to a poorly executed product which could cause the start up to fold. Telling your tech lead to project manage business critical builds, when resources are already extremely tight and you want him to code is going to slow delivery down.

  2. Bob Barnes

    Just to summarize, project managers are essential to any project and they play a critical role in delivering projects on time and on budget. The best type of power project managers can use according to PMI is the Expert power ! If you have knowledge in the field, you will get the most respect from your team.

    It’s funny sometimes to see job descriptions where employers search for candidates with degrees in journalism or communication !!. Even project managers spend 90% of their time on communication I believe that having a technical background would add extra respect and improve cooperation with your team which is a key to success.

    1. underrated

      If they do budgeting, why do they put their nose into calibrating employees? Huh? What do they know? Really, what do they know?

  3. Jane

    A majority of the PMs i work with don’t understand anything about the projects they manage. They put in the minimal hours. They take vacations during critical deadlines and are hardly ever available to answer questions about their projects nor resolve problems with the their projects. At crunch times,with limited resources, they are unwilling to put in any time or effort to assist the team.

    That being said i also have worked with amazing PMs that have been there through the entire project. They knew every little detail about their project and were always available to answer questions or help resolve problems.

    I would say that a majority of the PMs i have encountered deserve little respect and are lazy and ignorant. The few PMs that have earned my respect have not received the recognition that they deserved.

    1. Lee

      Oh for fucks sake, does this topic really matter? None of us are experts, irrespective of what talents we think we have. We’ re all doing the best we can, but ultimately we all do better when working together. Job titles are so last century.

      1. underrated

        Yes I would tolerate the PMs’ presence if they stayed away from calibrating employees and giving them a performance rating. Why don’t they stay away, and we would tolerate their presence like we tolerate the presence of non engineering staff like janitors, coffee machine cleaners, etc. Oh wait, but they actually do useful and arguably indispensable things, but they don’t take part in calibrating engineers…

        1. S

          Just like a sports team does not has a head coach?

          Like it or not projects need PM, without anyone managing a project there will be nobody to ensure that people are working efficiently enough so that the project is on track to prevent delays. That is the nature of commercial programming I am afraid. A good PM would also mentor and coach his colleagues with some technical awareness. They often also deal with client requests and since the client is setting the scope this is essential to the management part of the project – something that the dev team does not do!

          1. Adrian83

            To some degree project management is required in any project, that’s true. However in IT there are also a lot of small projects (many with a single person working) that don’t require much project management and using a dedicated project manager would be just a waste of money with virtually no benefit.

            For example I have seen projects in which a company for example wants some new features for an existing application and for that it contracts another company that does the work using a single employee. That employee is typically a technical consultant who talks to the users identifies the requirements determines what needs to be done estimates the effort, does the planning and finally the actual work. This employee also reports to the customer the status of the project.

            In this scenario the company that does the work is typically payed by hour and the time needed to complete the work is being estimates by the consultant and approved by the customer.

            While this approach may not be applicable for larger projects it makes perfect sense for smaller projects and demonstrates that a professional project manager is not always needed.

            A couple of months ago I met a person working for a very large corporation that was about to start such a one man show project for a customer. I specifically asked her if there is going to be any project manager involved and she say no as she will do by herself everything that is needed to deliver the project.

          2. SS

            The whole flaw in your argument is that there has to be somebody has to manage the ‘technical consultant’.

            If there is no PM managing them, then it will be the client. Do you think that the client has the time to manage their day to day activities. Has the time to (if following agile) to produce release burn up reports to work out if their velocity is in line with when the project should be released. The other advantage of having the middle man, is that the reporting will not be fudged but accurate.

            Also it is all good with saying that “This employee also reports to the customer the status of the project.”, what happens if this employee (sub contractor) disappears mid way through the project, who is going to chase them up – the client?

            Finally, good PMs do not let the developer do all of the requirement gathering, they do it with them. They have several meetings discussing on a high level what the client wants. They then write a functional specifications document, where every requirement is clearly broken down into user stories, with acceptance criteria’s which is then approved by the developer and the client. This saves the developer a tonne of time, since all they can then focus on what they do best, and is getting on with coding the product. If there are any problems during the build of the product i.e. client wants changes, the developer doesn’t have to worry about talking to the client, since the Project manager does that for them. Hence, the project manager ironically needs to know the project inside out to do this!

            I recently managed a single sub contractor in this set up.

          3. Adrian83


            Well the technical consultant can manage himself very well as long as the non-technical aspects of the project don’t take too much of his time so he will not have enough time to do the actual work. I have worked as a technical consultant and it was my task to gather the requirements from the customer figure out what needs to be done and then do it. I didn’t need someone such as a project manager to tell me what the business users had already told me.

            Now if we are talking about a project that implements a new software solution then yes you need some people to manage the operational aspects of the project, gather requirements discuss with the business users about what needs to be done, report, do administrative tasks, etc. Technical people usually can’t manage these things because they are too many in these kind of projects and they wouldn’t have time to focus on the actual work if they were doing those things. In addition, many technical people may not have the right skills for this.

            However, after the project that had implemented the solution had finished there will be usually someone to support the software and fix the defects that inevitably will be discovered. While using the software the users will usually also discover that they would like additional functionality or something changes in their business processes and additional features are required. Some companies include in their support and maintenance contracts the ability of the customer to add new change requests to implement new features. There is usually a system where the users can log both defects and enhancement and the developers or the technical consultants work on both, defects having higher priority. In this way software development can continue outside the scope of a project and no project manager is needed.

            The new features may be implemented also as part of small projects, which are basically a set of change requests for which an IT professional or a very small team commits of doing usually for a fixed budget. In these cases, there are very few project management issues and there is no need for a project manager to work full time. If a project manager is used for these kind of projects, then he/she will have to work on several such projects simultaneously in order to fill his/her time. Small companies may not even have enough projects to keep the project manager busy full time so they don’t hire one. Although this doesn’t happen to often even larger companies may choose not to assign project managers for their smaller projects in order to reduce costs.

          4. SS

            Adrian, if the project is very simple, say for example the project is to deliver a 5 page static WordPress web site, then you are right, the client can get away with not having a Project Manager and just work directly with the ‘technical consultant’.

            However, if it is a serious product that the organisation is building, or there are a series of projects that need to be delivered, then the organisation defiantly needs a trained Product or Project Manager, especially if there is a cross functional team assembled to achieve this. Developers, QA testers etc etc Somebody has to manage them.

            Likewise, there is also a lot more to getting work delivered then using a ticketing system. Somebody has to manage the ticketing system for started, by first talking to the client and finding out what is high priority and what isn’t. Letting the client open tickets is a really stupid way of doing things, and the Support and maintenance team should NOT be accepting tickets that are full blown features without a face to face conversation. Since, very often full blown features is often a pre-requisient to a new version of the product, where a new version product road map needs to be documented by writing really well thought out user stories with acceptance criteria. If you do not do this, you risk the developers implementing useless functionalities or even worse creating functionality that is not how the client wanted it.

            Also expecting the developers to do the admin side is a poor a way of managing any project. A good project manager will not let them do any of this, for the sole reason that their strength is coding. Many developers that I have worked with are happier with this set up, since it means that they have less work to do and can focus on their ‘sprints’ (I am an agile project manager)

            Finally, having amazing technical skills does not make you a good project manager. When I was a developer, I worked under ‘tech leads’ who were absolutely useless at management. For example, the one that comes into my mind right now was absolutely useless at resource management (how to build a team, motivate people etc). His idea of management was micromanaging and treating his colleagues as a ‘pair of hands’ using ironically a ticketing system that you’ve mentioned. It didn’t work because when he opened tickets half of the tickets were very poorly documented leading to disputes regarding if the work is done or not. Also, his reporting absolutely sucked, he did not use anything to measure productivity and just blamed the developers at the first sign of trouble.

            When you practice project management,you quickly learn that it is less about technical ability, but more about understanding people, learning how to get the best out of them, and putting management processes in the operational side of the business (reporting, structuring your resources properly) in place to get the team to collaboratively work together to help the PM deliver a high quality product.

            As a former developer/project manager that has worked in many organisations – from start up’s to agencies, aside from the above, I have seen how poor project/product management has caused excessive delays, and ends up costing the company more in the long run since it affects their ability to execute in a timely manner. Very often this in turn causes cashflow problems, or allows the competition to catch up. Having a trained project manager on board to keep things streamlined reduces the risk of this happening.

          5. Adrian83


            The idea is than in a project the role of the project manager is optional. It is possible to deliver without having a project manager and many IT projects (mostly smaller ones) are delivered in this way. It is not the team who helps the project manager deliver but it is the other way around. Project managers are brought mainly to improve the performance of the activities that involve change. The benefits that project management brings however depend on the nature of the change activity and in some activities elaborate project management methodology and professional project managers simply make no sense as they will not bring real benefits to the business.

            I will give a clear example. I had recently worked for about 2 years supporting the GIS applications used by a large utilities company. By supporting I mean I was fully responsible for all the aspects of the applications including developing new features. I was working at the customer site collocated with the team that was using the applications so for any issue they had with the applications they came straight to my desk and talk about them.

            If they wanted new features they simply came to me and told me what they had wanted, I was analyzing the requirements figure out what needs to be done and then started to do the actual work. I was working in a development environment where the users had access so they were testing during development and they were able to give me further instructions about the new features they wanted. The requirements were recorded as request for change records into a system and it was the senior user who decided which requirements had higher priority.

            While we were not using any agile methodology in my opinion this was real agile as the users were directly driving the development and there was absolutely no doubt that what I was developing was actually what they wanted. In addition, there was no pressure to finish in a set time or budget (the company was paying a fix sum for support) and the scope creep was no issue as they were able to change their mind about a certain enhancement while I was working on it with absolutely no impact on the budget. I am not sure if the contract had a minimum number of enhancements included but the users were very happy with the progress and with the ability to basically do whatever they wanted to the applications.

            Once the work was done for a requirement it entered a Change Advisory Board process and once approved I was allowed to release it into the production environment. The CAB was managing changes for the whole IT department not only for my applications.

            The real limitation of this setup was the fact that the amount of requirements I was able to complete was limited by the time I had to work on them as the defects and other issues had higher priority. If they wanted the requirements to be done faster their manager had to sponsor a project which meant, he had to allocated extra money from his budget for this. The requirements had to be estimated and according to the estimation the required budget was defined. The functional manager decided how much money he wanted to spend and as such some requirements had to remain out of scope and they were done as part of the Business as Usual process.

            When a project was started usually another consultant was assigned so that the requirements can be completed faster. Also project managers were assigned for each project but they were dealing with reporting and other administrative tasks and they were not involved at all in the execution of the project as the consultants were doing all the work including directly interacting with the customers. Each project manager was “managing” several projects simultaneously as there was not much work for them to do on each project.

          6. SS

            We are going around in circles, but to cut a long story short if you are the only person working on a client project it is NOT management. When I am managing, I am managing a cross functional team consisting of UI/UX, developers, QA testers to work together throughout the whole software development lifecycle to help me deliver a project.

            Also what you describe when it comes to agile is agile not properly executed, which is all about releasing the product in increments. If you are finding that there is a lot of change requests with the client it basically means that you have not done a great job with speccing what they wanted originally to begin with.

            Finally your project management style does not even scale, yes if you are one guy working on a client project it’s easy. But what if you have a team of developers working on it? 10 + are you honestly going to tell me that you will be able to focus on all of the technical work and manage their productivity at the same time? – basically be an account manager, developer, scrum master, product manager – you will be so overwhelmed that it will be hard to focus on coding.

          7. Adrian83


            Please don’t get me wrong I am not trying to say that project management or other non-technical activities auxiliary to software development are useless. All I am saying is that in many circumstances some of these auxiliary activities are an unnecessary overhead that brings no benefit but slows down development.

            When you implement a new solution and have a lot of stakeholders and a cross functional team then yes you definitely need someone to see the big picture and to manage the communication between all the stakeholders. I am not contesting the benefits of project management in general I am just saying that there are many commercial software development activities that simply don’t need project managers.

            When I worked on supporting those GIS applications at some point the users had needed a new type of fiber terminal in their network to model a new situation that was not present from the beginning. For this requirement the data model had to be changed to accommodate a new table and new fields and also the code had to be changed to support new functionality for the new objects.

            If this had been done through a project it would have taken much more time to complete because it would have involved more people such as a project manager, business analyst, quality assurance engineer and maybe a solution architect. The project manager had to organize meetings for all these people to meet and discuss about the new features and decide what needs to be done but I already knew what needs to be done and I needed no further help from someone else. I had just started working in the development environment and when done the users had tested and approved the change. I then got the approval from the Change Advisory Board and finally I put the changes into the production environment. Very fast and efficient with no unnecessary overhead.

            I repeat I am not saying that project management is useless and I do understand that in more complex projects there is simply impossible for technical leads or other technical people to manage the operational aspects of the project. Nonetheless even when a project manager is actually needed and he brings real benefits to the project the team does not help him deliver but instead he helps the team to maximize its potential. At least this is how I see things.

            Finally, users requesting new features after the project had finished does not mean that the project had failed to capture all the requirements. Usually users want more features than the budget allocated by the functional manager allows and the missing features are normally implemented in future projects or as part of the support operations. But more importantly, as I have already said, the business processes change over time and new features need to be added to the application in order to accommodate these changes.

          8. SS


            I am glad that we are on the same page.

            To summarise

            1) If it is a project that requires one person, and it is a short one off project, then it is probably not complex enough to warrant a PM. Many software companies and agencies, do not hire PMs for these type of roles.

            2) If the project involves getting a cross functional team together to help deliver a couples project/product than a PM is vital in order to keep the communication lines open, and delegate work correctly..

            To give you an example of my day to day duties, I am currently product managing a product of a team of 4 people. Before I came on board, the product was poorly written, working with the team my task was to help them launch a newer version of the product. Previously the challenges the company had was that they were managing it how they always had done so before, they would:

            – give the dev team a shopping list worth of work which is unrealistic in the time frame expected
            – not doing proper QA based on properly written specs leading to a lot of bugs or worse still functionality that the client did not want built.
            – asking for a 1000 change requests when the developers are already half way though working through a task. Causing them to lose focus with completing tasks from distracted, leading to poorer quality work being produced.
            – Delegating work to staff that were too junior for it

            Once I came on board, I:

            – Put processes in place to do efficient QA by writing descriptive user acceptance criterias.
            – Changed the way the company worked so that they released increments of the product every fortnight
            – If the client requested changes it was prioritised based on the upcoming sprints.
            – Managing stakeholder expectations by showing them reporting of the team’s velocity relative to the amount of work left. Changing the way they think about the process of software development.
            – Doing all the admin side – requirement gathering etc, so that the team doesn’t.

            The end result:

            – high quality product
            – happier developers
            – happy stakeholder
            – more focused team. Since they can get on with what they are good at.

            Where am I going with this, the people complaining on this blog post have no idea about what goes into project management, arguably it is much more complex then the tech side since it is all about planning and execution. Real people can also be tricky to manage at times since they have to always be motivated and have a sense of purpose in order to get the best out of them.

    2. S

      I was a developer, now I am a PM and I can tell you that PMs are extremely important when it comes to delivering a project on time in budget. I have worked with tech leads who are extremely technical but had no clue how to motivate the team to get work delivered. My ex line manager was like this.

      Sure – they are not expected to code, and often do not. But outside of that, they are the first point of call for clients; they also have to make sure the work is being delegated properly; constantly motivate the team; deal with any impediments. To top it off , PMs are often judged by how efficiently they are able to deliver the projects on time and within budget.

      It sounds like you have worked under bad PMs.

  4. EezieE

    I’ve worked with a bunch of bad ones and few good ones. The good ones prioritize requests, make educated judgement calls on which tasks a developer should devote her resources on, can answer questions about technical requirements.

    That said, most of the PMs I’ve worked with are abysmally incompetent serving as nothing more than glorified secretaries. For the recent project the one checking QA status, prioritizing bugs, confirming business requirements, is ME, THE DEVELOPER. 1. The PM couldn’t answer ANY of QA’s questions whether this or that bug is launch critical or not. 2. The PM failed to assign the most important tasks to me, 3. nor did they rank various QA feedback in ANY order of importance. I don’t know what their role is, they’re out of the office half the time. All I see them do is scheduling meetings on the calendar and taking attendance at stand-ups and ask “Is it done yet?” If it’s not, they wouldn’t know what to do. If it is, then they’ve “done their job”, which is nothing basically.

    1. underrated

      Everything you said is correct. Have you forgotten to mention that these scum of the scums however take part in calibrating their employees and give them a performance rating, and make their life hell?

      1. Adrian83

        Doing the performance review of an employee (who is not a line manager) requires the reviewer to be from the same line of work as the employee. That’s because the technical aspects of the employee’s work have to be taken into account.

        If the project manager is a good technical expert being able to do the work of the team members then he/she may be allowed to evaluate their performance or at least send performance feedback to the team member’s line managers.

        Project managers without technical background or who are not very competent technical experts are typically not allowed to review the performance of the project team members as they don’t have the competence to evaluate the technical skills.

        Companies that allow non-technical project managers to evaluate the technical abilities of the employees working on projects may end up loosing their best human resource as the work of this resources may not be well rewarded. In addition the workers may feel themselves humiliated when someone that is not able to do their work evaluates how well the work was performed.

        1. SS

          First and foremost, you are right a non technical PM should not evaluate a technical person’s work. Although as a PM, I do think that it is important that the PM should have some technical awareness, but at the same time I am aware that there are many companies who do not hire technical PMs.

          Secondly, the problem with this whole debate is that you have a lot of PMs that do not do things properly in terms of measuring productivity. If for example you do follow the right methodology it is easy to measure progress of the team.

          For example Agile, when work is delegated it is done during sprint planning sessions where with the Product Manager and the team agree on what backlog items to complete in that week. The scrum master then takes over (some do both roles) and productivity during sprints is then measured based on velocity using burndown charts etc. Hence, if the dev team agreed to complete x amount of work but never manage to meet their sprint goals and always behind on their sprints, there is obviously something wrong with either the way the sprints are organised (too much work), or the developers are just not good enough. If done properly, you can work this out as a non technical PM, you do not need to be technical.

          Now if you have a tech lead, and their strength is coding, do you not think it’s better for them to be involved with the rest of the dev team coding during the sprint as opposed to administrating it? The whole point of the sprint is that the dev team can do what they do best and NOT get interrupted by stakeholders etc…somebody has to do this job.

          A lot of the people moaning here, are clearly disgruntled developers who do not understand why project management is important. They have probably also worked with terrible PMs, who just order people around.

          From doing this, I have seen that so much more work gets done when you have a clear separation from operations and the hands on technical side of the business, since the developers become much more focused on developing new features etc.

    2. SS


      As a PM, I have dealt with other PM’s that are how you described. Since I come from a pretty technical background and do QA, and learn about what is going on (sometimes suggesting to the dev team how the problem could be solved) it absolutely pains me when I meet a PM who has no clue at all. These are the type of PMs that give the rest of us a bad name. I am no longer hands on, but I do so much reporting that I wouldn’t have the time to be. There is a lot to PM if you run your projects in an agile way.

  5. R

    A complicated task or business objective needs project managers to implement manage and deliver them, someone needs to be accountable for a projects success or failure at the end of the day, projects have critical paths and tasks that requirement such as planning, seeking approvals, time and budget management, risk management contract management and many other crucial business impacting tasks that need to be considered, Without project managers there will be no plan, no time management, budget blowouts, risks which could put the company’s reputation In jepotdy, etc etc the biggest concern for a project manager speaking from experience is “people management” if you cannot built relationships with your project management team all of the above will be a nightmare, I have seen other project managers struggle in this area and it only results in their reputation being tarnished by the team,

  6. R

    Ps – I have a technical engineering background with a project management degree and the project managers I see struggle are the ones who have no technical capability, it’s hard to build relationships with project engineers when you can’t speak their “engineer Lingo” same goes for “executive msnagement” you need to speak there lingo to that’s why I went and did an MBA after – sad but true!!

  7. R

    Btw – mind the spelling (it’s 4.30 am)

  8. Ben

    Obviously, if you think PM’s are not needed your projects are too small. I’m a technical PM but more a Delivery Manager/Solutions Engineer/Developer/BA/etc. I’ve worked in sales, fulfillment, support and development of an online marketing company. We’ve built new platforms, platform integrations, migrations..you name it, we’ve done it.

    As a tech PM I handle the managing of development, the architecture, business and tech requirements, documentation, (what API/Daemon pushes what data) and making it sure that what is being developed is functional for all channels. I work my butt off to produce and exceed expectations. Without a PM to manage the project as a whole, who drives marketing/documentation/communications and/or every other aspect beyond the technical side? Someone is going to use what is being developed and it is likely more than just CX but a global CX. Every front end also has a back end.

    I will tell you this, there are more terrible PM’s than good PM’s by a landslide. However, if you get a good one, you will know it. I don’t doubt that if you handle projects to create a simple db with a UI that’s used internally, that you do not need a PM. However, if you are developing a new control panel with integration of several other platforms, a front end user experience, a back end user experience and training several hundred sales/support/fulfillment reps on the new integrated platform, you’d better have a dang good PM running the show or that project will be disastrous.


Leave a Reply

* Required