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 with non PM friends).

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.

133 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.

          4. Your Boss

            I am a Project Manager. Prior to moving into project management I was first a .NET Developer and Solution Architect. I’ve implemented large enterprise systems for the Federal Government as a Developer, Architect and PM. In a pure product development environment, PM’s certainly have a reduced value; however it is now 2016 and the client service industry exploded years ago; in this world PM’s are beyond vital – more important than the rock star Architect on your team and now as a Director I would fire the Architect before the PM 99% of the time. As a PM, I was no doubt smarter than most of my Architects and can guarantee in client services the PM’s job was far more difficult and vital. Any technical experts that disagree, it’s simply because you are so short sited and buried in code that you think the world is made up of 1’s and 0’s – do yourself a favor, go thank your PM for inflated salary and growing job demand – he’s the one driving business for your company in a highly competitive market.

          5. SS


            Making sure projects are delivered on time, with high profit margins affects cashflow and client retention. This does not require technical skills but business acumen if anything. The developers on here moaning, are as you say extremely short sighted and need to spend time delivering projects. By that, managing a cross functional team trying to keep everyone motivated and on track.

  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.

          1. underrated

            We all agree that non technical PMs should not be allowed to evaluate the performance of technical employees. But Google, which is a much hyped dream company has exactly this abominable setup. Peers also provide reviews but peers’ reviews only get considered for promotions, not for calibrations which is a separate process. For calibration, the manager gives a score even if he is a non-technical idiot.

    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.

  9. DD

    All engineers are mad because the PM is above them. LOL sad but true, they hate that they cannot be leaders nor make good judgement when things get tough. PM’s are strong and good leaders so all the cry baby engineers grow up and keep working!

    1. Kp

      What on earth are you talking about you’re just a glorified secretary. What judgment ? You still have to talk to upper management and explained the risks so that you can wash your hands if it fails, remember re-mediation tasks tasks ? Can a project manager survive without an engineer or architect ? I dont think so.. But can an architect or engineer survive without a project manager? Guess how startups are made.

    2. Adrian83

      Engineers can’t be leaders? You’ve got to be kidding. Managers in engineering companies/engineering departments are promoted from among engineers and not from among project managers. In fact project managers in the overwhelming majority of cases are not even real managers as nobody reports to them not even the project team members.

      Also the overwhelming majority of decisions that engineers do care about are technical in nature. If the project manager is not also a very experienced engineer then he will not lead the engineers as they expect technical direction from their leader something that he/she will not be able to provide.

      Project managers have their very well established place in technical projects however they don’t get involved in engineering or in leading the engineers.

      1. SS

        Engineers who are Managers are called ‘Tech leads’.

        Not all tech leads are good at project managers, which requires a different set of skills; good communication skills with stakeholders and other parties; reporting (gaant, burndown charts, maintaining the product road map etc) and budgeting.

        A good tech lead should be focusing purely on the technical aspect of things, as opposed to being involved in operations which is what a PM does.

        1. Adrian83

          Engineers who are managers are called: engineering managers, directors of engineering, vice-presidents of engineering and chief technology officers. Well they don’t do much engineering but in order to get on these jobs in almost all cases you must have an engineering background. This positions are known also as functional managers (with the exception of the CTO who is an executive manager).

          Technical leads are not managers they are technical experts such as engineers who are responsible for leading a group of people from their own line of work during a work activity such as a project. The role of the technical lead is usually not permanent an engineer may function as a technical lead on a project and as an “ordinary” engineer on another.

          Project managers are not managers either, but instead they are professionals in the field of project management responsible for managing the operational aspects of projects. It is very true that not all technical leads are good project managers but in most companies technical leads are not expected to do project management so this is not a problem. :)

          In many if not in most companies engineers and project managers are at the same level (the bottom of the chart) and they have different career path options. Engineers can become functional team leads, engineering managers, directors of engineering and at the highest level possible chief technology officers.

          Project managers can become program managers and then they can end up leading the project/program/portfolio structures from the organization in which they work.

          1. SS

            There you go, that proves my point that people on here complaining about PM’s do not know what they exactly do, and therefore do not see the value of having them!

            They are not glorified secretaries.

            In a nutshell, they help run the operational side of the business whilst the tech lead/manager needs to keep up to date with tech trends and all things technical and work with the PM. The PM does not have to be technical. Though it helps.

            Skills such as:

            – Resource management
            – Stakeholder management, which for the record is very hard if dealing with impatient stakeholders.
            – Reporting progress using reports
            – Budgeting
            – Awareness of different project management methodologies and WHEN to use them
            – Planning, forecasting
            – Delivering projects on time and within budget
            – Dealing with conflicts/impediments as they occur

            These are all non technical skills a PM must have to ensure that everything on operations goes smoothly. A good PM will take the pain from the development team on the operational side so that they can focus on doing what they do best, writing code and implementing functional specs.

            For the guy who responded to me telling me that start ups need developers, but don’t need a PM. The last start up that I had worked in that took this approach ended up having endless delays from poor requirement gathering and a lack of overall planning on how work should be distributed with the Dev team. The person managing the start up was a tech lead assuming the role as PM.

  10. underrated

    SS, them PMs may bring a small value as you say, as does the janitor. Why don’t these PMs be under engineers and get a fraction of their salary, coz that’s what is the right thing to happen. Which psycho invented them to be above engineers and get paid more than them?

    1. SS

      Underrated, you are missing the point.

      They are two completely different jobs, one job (engineers) is about building things, the other is about ensuring things that are built by engineers is done in a timely manner.

      I was a former developer before being a PM, when I was a developer in some ways my life was easier. Daily routine would consist of getting a list of functional specifications, and just implementing them. I had less responsibility.

      As a PM, I have a huge amount of responsibility, I have to make sure that everyone in the cross functional teams works together in a cohesive manner to help me deliver a project on time. That is why PM gets paid a lot, the job is stressful from carrying more responsibility and with that comes more accountability when things go wrong. I.e. Delays, project going over budget etc

    2. Adrian83

      It depends on the company but usually large companies use something that is being know as the weak matrix organization. This means that the project managers are not above engineers but instead they are at the same level on the company chart as employees sitting at the bottom of the hierarchy with no one reporting to them.

      Project managers usually sit above engineers in the cases where becoming a project manager is part of the engineer’s career path. This means that the project manager in this cases is an engineer promoted to a higher position. This is known as the strong matrix organization.

      If the project manager is not an engineer then he usually does not sit above engineers and the engineers in this case report to some kind of engineering manager which is an engineer promoted to management.

      Regarding the pay it depends on the company. Usually companies value more the employees that are in direct contact with the customer and that’s why project managers that manage projects delivered to customers usually make more money than the average engineer.

      On the other hand top technical resources in many companies are paid much more than the average project manager as they are more important. Loosing a good project managers is usually less important then loosing your top technical resource. Loosing an average engineer is also less important that loosing a good project manager.

      Lastly projects are not born equal as some of them require far more project management expertise than others. This can lead to projects where there is not much work for the project manager to do. In this kind of projects the PM is essentially an over paid administrative assistant and if he/she is paid more than the engineers then the engineer’s frustration is fully justified.

  11. SS

    Once again this argument is flawed in the sense that it is comparing apples and oranges.

    In many organisations PMs and Engineers work together – Adrian, you are right, PMs have to deal with the customer, may it be stakeholders or externally which makes it a very stressful job. Anyone who has done account management would understand this. Many developers bitching on here thinking that being client facing is not as ‘hard’ as coding, but I would love for them to experience a situation where there are massive delays with the customer threatening to stop doing business with the company over it and see how they calm the customer down especially when the customer is not technically minded (often the case)

    To add to the complexity, if it turns out that the company ends up losing a client (affecting cash flow), the Dev team does not get blamed. The PMs neck is on the chopping board. The pressure from knowing that alone adds to the stress. Adrian when you think about it this way, it is unfair that you compare PMs to administrators, many admins have far less responsibility than a PM where their actions do not affect other departments in the same way – sales, HR, technical since they are not delivering projects using resources from these departments but passing information around. That is an extremely important distinction between the two roles.

    Both engineers and PMs are paid well for different reasons. Reasons such as above is one example why a PM is paid well. Other stresses in the job include leadership skills, motivating, keeping morale in the team high so that projects are delivered smoothly on time and within budget. Easier said than done, when working with difficult colleagues.

    Now to give an example of the above, recently I was in a situation when trying to deliver a project but the developer was either not doing the work, or very slowly. Now I can’t just complain about this the CEO or stakeholders, to save my neck, I have to first have substantial proof that he indeed is not doing the work from adequate reporting, once that is done I then had to find a replacement.

    Again, sounds easy? How about putting yourself in a situation when your team are not hitting deadlines for the reason above. Resolving resource bottlenecks and making decisive decisions is part of the job and requires leadership and strong management skills.

    These are just two types of scienario a PM has to deal with, there are many more.

    The problem with technical people is that they only care about technical aspects of an organisation and are out of touch with the companies strategy in the next quarter which is defined in operations.

  12. Adrian83


    I didn’t say that project managers in general are administrative assistants. I only said that this depends on the project. Whether you accept this or not there are a lot of projects in IT (usually less complex ones) where there is simply no need for professional project managers. There are projects where there is a single technical consultant/developer who talks directly to the customer figures out what he needs to do and does it by himself/herself.

    In addition some companies add enhancements to their software as part of a support contract which means that for a fixed periodic fee the users can log requests for both bug fixing as well as for enhancing the application. In this scenario we don’t even have a project.

    As for evaluating the performance of employees, project managers, unless they are also very competent technical experts themselves shouldn’t and usually are not allowed to do this.

    The fact that a developer misses dead lines does not mean that he is a poor professional. The dead line might have been imposed on him by people that have no idea of the work that needs to be done and he may not be willing to take shortcuts and deliver a poor product or a product with a lot of technical debt in it.

    The performance of a technical expert can only be truly evaluated by another technical expert. Personally I have never seen cases where the project manager can kick someone out of a project for performance reasons. The best he can do is raise the issue about the performance problem and escalate it to a decision maker such as the project sponsor or the line manager the team member reports to. If the decision maker concludes that there is no performance issue then the PM has to live with this decision. Sometimes even if there is a performance issue the sponsor or the line manager can’t find a better expert for the job so tough luck for the PM.

    In the companies for which I have worked the PMs were not solely responsible for the outcome of the projects but instead the line managers were also responsible for their part of the work. Project managers were not even recruiting team members but instead they went to line managers who were responsible for allocating resources to the projects and ensuring that they perform at their best. If a team member was not performing well on a project then his/her line manager would have been held accountable for that and not the project manager.

    1. SS

      Adrian, don’t get me wrong, coming from a technical background does help immensely. Very often when I am managing my in house team, and they run into technical problems I help them out where I can when they are stuck. I do think that all PMs should have some technical awareness in order to better understand the project so that they know what they are trying to deliver. However, they don’t need to be an expert, they just need to be competent.

      The bulk of my work however is largely focused around my soft skills rather than my technical skills. I spend A LOT of my time planning upcoming sprints on a weekly bases and ensuring the work is delivered – I’m currently leading a team building a start up product using Scrum. To do this properly, I have to work with the product owner and devise as well as maintain a product roadmap which is in line with the needs of the market based on the user stories in the backlog. This is not technical at all, but more in line of PM/business analysis.

      I disagree with your opinion that productivity can’t be measured!

      Productivity can be measured using cumulative flow diagrams , burn down charts, and allocating reasonable story points to user stories in the sprints. The story points FYI are not set by the PM but done collectively together during sprint planning sessions so that the complexity of the task is discussed and agreed with the technical team before a story point is set.

      If done properly you can work out the average velocity of the technical team using burn down charts over period of several sprints. This is then used as a guide for future forecasting on how long it will take to deliver future work and during the sprint help the agile project manager keep the team on track by reviewing the teams velocity at the end of each day on a burn down chart once the sprint has undergone.

      If the team works a certain velocity, where the velocity suddenly drops then there is something wrong. I.e if they stop meeting their sprint goals, or start to continues let fall behind on the burn downs.

      A good PM needs to also know how to switch methodologies, for some projects I don’t do scrum I do kanban. When I do kanban, I track someone’s work rate based on their cycle time.

      So you see, what I have described above is low level project management.

      Knowledge of when to apply different PM frameworks to get a project delivered in the most efficient at possible; using various reporting tools to measure productivity and KNOW HOW to do it properly adds another dimension to it.

  13. Adrian83


    Software development unlike construction, manufacturing, digging trenches, etc. is a creative activity where you can never accurately estimate the effort needed to complete a task. Because of this it is virtually impossible to accurately measure productivity in this field especially by using statistic data that tells you how fast do developers complete their tasks.

    If you are digging trenches and know in a working day, the length of the trench the workers can dig then it is very easy to estimate how much time the whole trench will take to complete. If you want it done faster, you can add more workers in shifts and you can accurately estimate the new end date.

    The trench estimation however does not work in software development. If you look through statistics and find out in average the number of tasks/user stories a team or a developer completes in a certain period of time it is foolish to use this information in order to calculate the number of tasks the developer or the team will complete in a future period of time.

    Even if the developers work as hard as they did before and have no impediments it is perfectly normal for their “rate” to variate, sometimes even dramatically. I can think of a lot of reasons for that: the complexity of the tasks is much higher, the complexity does not change but the developers have to use different APIs or algorithms that they haven’t used before, the developers have to pay the technical debt that they had either produced in previous projects/ sprints/ project phases or the technical debt was already there produces by someone else. Not to mention the lack of inspiration that developers can have some times. If you are working on a more complex task the idea on how to do it can come to you straight away or in a couple days or maybe never.

    While my work now involves a lot of coding I am not a pure developer as I also interact directly with users on gathering requirements and defining solutions for their problems. At my beginning of my career I worked as a pure developer and one of my first assignments involved outsourced bug fixing and enhancements. My company was paid by the number of bugs fixed. You can imagine by yourself what happened, we worked as hard to fix as much bugs as possible without carrying too much on the quality or on preventing technical debt. Many of our bugs returned to us as they failed technical review or testing and even those that passed were a sloppy job as all we cared about was speed.

    If the developers line managers look at this kind of statistics for performance review and pay raises purposes, then things can get really messy as less competent developers may end up with better pay because they worked on easier tasks that they were able to complete faster.

    1. SS

      Adrian, the whole point of agile is to not 100 percent work out how long a task will take, but to plan your sprints based on the complexity of tasks relative to others.

      If this is done well, you’ll eventually see a pattern over several sprints with regards to how many story points the Dev team can complete on average. You can find this information by comparing past velocity on burn down charts.

      My Dev team for example completes 9.5 points on average. Hence, if I plan the sprints with less points, I often have found that they end up finishing well ahead of schedule. Similarly, if sprints are planned with more points then they risk not finishing all of the work in the week. It’s the PM job to work out the happy medium.

      Finally, and the point that you are missing. The agile PM does not decide the story points of tasks without first discussing this with the Dev team. The whole point of the discussion is so that the team as accurately as possible measure how ‘complex’ a task is (note: this not measured in time) relative to another.

      A skilled PM, knows how to consistently do this. They can also use this as a guide to measure productivity, if for weeks on end my team are completing 9.5 points worth of work, than all of a sudden can only complete 3 points worth, then it’s reasonable to believe that there is something wrong – either with the developer not working hard enough or if the tasks are not properly estimated.

      In addition, you can use a cumulative flow diagram to see the overall progress of one developer.

      I can tell from reading your post, that you are not a PM at all but a pure technical person that has probably worked in non agile environments.

  14. SS

    @Adrian, to add.

    The fundamental problem with your whole approach, which is basically leaving the developers to self manage is that you leave yourself vulnerable to a developer setting unrealistic timeframes, in turn producing very little.

    In addition, when dealing with stakeholders you need to be able to give them timeframes as accurately as possible. You cannot go in and say:

    ‘Hmmm I don’t know, the problem with software development is because it is hard to estimate mmmm…how long is a piece of string?’

    Agile is not meant to be 100 percent accurate, but it is a lot better than the way you are doing things, which is pure guesswork and does not scale when trying to work out the work rate of whole Dev teams.

    Commercial development does not work this way. Like it or not, developers need to deliver work based on timeframes.

    1. Adrian83


      In all activities, whether or not we talking about software development, the subject matter experts that have experience in doing the work are the best people to do the estimation for the time needed to complete the work.

      I don’t want to offend you in any way ( I don’t even know you) but saying that the software developers are not the best people to estimate the time needed to complete software development tasks is simply absurd. It is statements like this that make some project managers get no respect from technical people.

      Is like you are saying to a professional in a certain field that he is too stupid to estimate his own work and you, even if you are not as good as the expert or are a total non-expert, can better estimate then he can. And the bottom line would be to hold accountable the expert on the estimation that you as a non-expert or as a less competent expert did.

      On all the projects on which I have worked the effort needed to complete certain tasks was either estimated by me or by a better technical expert that was on the team (technical lead, solution architect).

      If the estimations are too long then the project manager will try to find solutions by engaging other people or trying to get new members on board to help. It is the technical people and not the project managers the ones that will find the solution, the project manager will just guide and engage the experts and other stakeholders on finding the solution. If everything fails then is it the obligation of the project manager to raise the issue to the sponsor warning that the project has a high probability of failure because of unrealistic expectations.

      On the projects on which I have worked the project manager (when one actually existed) was not responsible for taking decisions regarding the project but instead he/she had to find out what decisions have to be taken and then ask the right stakeholder to take them. When it was time for estimations the PM asked the technical experts to produce them.

      In my opinion, unless we are talking about less complex projects, the role of the project manager is very important but his value doesn’t come from getting the status, writing reports or from gathering statistical data but instead from managing the communication between stakeholders and translating the status of the project to the customer in such a way that the customer will be happy and be convinced that he will receive a good product or service. In my opinion only for these activities the PMs deserves a high pay.

      The best project manager is the one that makes all the stakeholder happy. :) A project manager that doesn’t do much stakeholder management does not bring much value and he/she is basically a glorified secretary.

  15. SS


    I never said that software developers should not estimate their work, more to the point during ‘Scrum planning sessions’, I encourage this and it leads to a discussion. I just think that you should not blindly accept developer estimates when you are managing them.

    As a Agile PM/Scrum master, I often challenge the development team (I come from a technical background so I can do this) in case they give an estimate that is too conservative. I have seen this happen many times, where the developer judges the complexity of a task to be 3 points worth, but after the team questions why and discuss the problem throughly, the effort can be less.

    I totally agree that stakeholder management is important, it is something I do daily in my role when I report to the product owner. Often this is very challenging if the stakeholder is non technical and when things are not going well.

  16. Adrian83

    At the beginning of my career I worked as a developer on a Scrum team responsible for the development of a software product. This was not part of a project, we were not directly delivering anything to customers and as such there was no project manager on the team ( there was no need for one).

    This was my only interaction with the Agile world so I am not an expert on this. However I have learned that self managed teams is one of the core values of Scrum Agile. This means that the Scrum Master/PM is just a facilitator that is not allowed to take decisions but instead he/she must help the team take decisions. This means that the Scrum Master/PM can’t theoretical change the estimations made by the team.

    The reality however is that even in non-Agile projects the PM in most cases still acts as a facilitator who is not authorized to estimate the effort needed to complete tasks. Many if not most of the software PMs (either Agile or not) don’t come from a developer background and as such they lack any competence on this matter.

    Of course this doesn’t mean that the PM has to blindly accept any estimation made by the developers but he can’t reduce the estimations either. He must ask the team to reconsider the estimations (if they are too long) and engage the team members to find solutions on completing the work in less time. This however will usually result in technical debt or in a large number of bugs as the team will not have the time to write quality code. If the team (technical leads especially) remains firm on its estimations then the PM has no other option then raising the issue to a higher level.

    Now regarding managing developers it is important to understand the difference between managing the tasks of a group of people that are involved in an activity and managing people.

    Managing people involves things such as:
    – hiring an firing employees,
    – managing the work assignments of employees (for example on which projects they should work),
    – providing technical leadership in guidance to employees,
    – taking high level technical decisions,
    – evaluating the professional performance of employees and taking actions to improve it,
    – managing the employees rewards system (pay raises, bonuses, other benefits)
    – sanctioning the employees for wrong doings.

    Managing people, as a general rule, is not the responsibility of the project manager but that of the functional manager and technical leads. In smaller companies however the same persons my play both roles.

    1. SS

      Indeed, that is how Scrum works.

      I do not decide the estimates for the team, they do but I do during sprint planning session question why the estimate is that and if they should reconsider. When I ask them to reconsider it is based on experience – if the developer says ‘the task is 3 points worth’ but then in previous sprints they had done something similar and saw that the complexity is less than what they are estimating now. I know that they are misleading me in order to be less productive.

      There is a lot of reporting tools in agile where even if you are not technical can get an idea of the teams overall performance. The whole point of the scrum master is relaying progress back to the stakeholder and optimising the sprints so the time the developers have is used efficiently.

  17. SS

    @adrian, Google ‘poker planning sessions’ to get an understanding on how I do my estimations.

    Actually, the following is a good article that covers this activity:


    There is a lot of discussion with the scrum team in the planning, which is extremely important.

    1. M

      Some PM definitely got plenty of time to reply every comment and fight back to prove his/her little use. Keep up the spirit! lol

      1. SS

        Maybe because I am getting email notifications on my smartphone…moron.

  18. Kp

    Holy cow this thread has been running for an epic long time, but yes think of a project manager as a glorified secretary. They are necessary to report to the higher ups on the status of the project. however technical leads and architects are way more important than project managers don’t think that the project managers are all that believe me a project manager is much easier to replace as every non-technical IT personnel that I’ve bumped into wants to be one . You look technical.. But are you?

    1. SS

      @kp you are comparing apples with oranges. Technical people do technical work, a PMs responsibility (well mine) is to ensure the operational side of the business is running smoothly. This might sound easy, but it isn’t….finding the resources and managing them so that they help you deliver work smoothly can at times be extremely tricky. For example, last week I was in a situation where a sub contractor I was working with was threatening to stop working on a project I was delivering because he felt that he wasn’t paid enough. I spent the whole morning sorting this out and it was extremely stressful since I need him to complete his work so that we can deliver it to the client without going out of budget.

      Meanwhile the technical team, are sheltered from this. Whilst I am sorting that out , they are coding etc.

      So no comparing PMs to glorified secretaries is extremely disrespectful. We have huge responsibility and accountability, we have to make sure projects are delivered in time and on budget. If we do not then the company can fold, since customers will not be willing to pay, or sub contractors such as the above cause the project budget to go out of whack affecting the companies revenue stream.

      1. Adrian83

        Yes I agree that comparing PMs with glorified secretaries is disrespectful, even in small projects where PMs are actually performing a work similar to secretaries. However I find it equally disrespectful for PMs to claim that they deliver the project and the team members only help.

        Saying that the team members help the PM deliver implies the fact that the team members play a minor role in the project. In reality however if you drop the PM you can still deliver (and many small companies do deliver projects without PMs) but if you drop the team members then you have no project.

        Since the project manager is an optional resource on a project team it is him/her the one that helps the team deliver and not the other way around. Any member of the project team can perform the work of the PM but in complex projects it is not a good idea to have a team members doing this work and it is much better to employ a professional project manager.

        I also find it disrespectful when PMs claim that they ensure that the project is being delivered on time and budget when in reality equally important if not more important is the effort made by the team.

        1. SS

          At the end of the day, yes, a PM role is optional, but then that goes with many roles that are not technical. I have worked in start ups where they carry a ‘do it yourself’ approach for sales, and marketing. Only because it ‘looks easy’ does not mean it is.

          Before I took on my current role as a PM, I worked in one company that is a start up, where I was a web developer, the organisation took your approach and left all managerial responsibility to the tech lead. Guess what happened? In that instance, the project quickly spiralled out of control in terms of budget and delays. Despite the tech lead being technically able, he was very bad at putting *non technical* processes in place to make things more efficient by reducing costs and ensuring things were delivered smoothly. Similarly, when any impediments arose with his colleagues, instead of diplomatically resolving the situation, he created a culture of blame.

          Project managers are hired for a reason, they are not there to provide technical support, they are to ensure that things are extremely organised where impediments are dealt with quickly in the smoothest way possible. A lot of this is on the operational side of the business and requires strong organisational plus interpersonal skills – they also need to have commercial awareness of how the business operates and what it is trying to objectively achieve. A secretary doesn’t, and is not part of the bigger picture which is why it is an unfair comparison.

          It is good for the PM to have technical awareness, and it helps me a lot, but at the same time, I do not need to know it at a very low level, just enough so that the developer doesn’t bullshit me and even if I didn’t have any technical knowledge with the right reporting I could still work out if the developer is bullshitting me i.e. if the developer constantly commits to delivering work, but fails time and time again.

          Frankly, it is the arrogance that is displayed in this thread that is really pissing me off. Developers on here are clearly frowning on PMs, yet don’t realise how important their role is ensuring that everyone is motivated and in turn productive which in turn leads to a project being delivered in a timely manner tying into the commercial objectives of the business. That is the reason why many digital agencies hire Digital project managers, along with larger companies.

          1. Adrian83


            “It is good for the PM to have technical awareness, and it helps me a lot, but at the same time, I do not need to know it at a very low level, just enough so that the developer doesn’t bullshit me and even if I didn’t have any technical knowledge with the right reporting I could still work out if the developer is bullshitting me i.e. if the developer constantly commits to delivering work, but fails time and time again.”

            The above is probably the proof why some PMs don’t get any respect from technical experts. You are basically saying then a person with limited or no technical abilities is able to tell when a technical expert is right or wrong on issue related to his/her domain. Don’t you think this is absurd? I mean how can a reporting tool determine the technical difficulties faced by developers in their work?

            Also software development is not digging trenches so you can’t accurately estimate the effort needed to complete a tasks. Estimates in software development have always been a problem and continue to be one as it is not possible to get accurate estimations no matter how good your so called methodology is. That’s because software development is a creative activity and trying to finish something faster will results in a large number of bugs and in technical debt which means extra work.

            But even if the developers do give bullshit to PMs and to other non-technical employees, what can they do about it? Maybe ask for a 2nd opinion from another technical expert but if the 2nd opinion is the same then the non-technical people can’t do anything about it.

            From my experience however I have learned that PMs are not held accountable for the fact that the developers are not able to finish the project in time since they have no control over this matter.

          2. SS

            @adrian83 simple – the developers are part of the decision making process. During the discovery phase, PMs work with the developers to approximate how long a piece of work will take. Ultimately, they have the final say since they are the one’s doing the actual work. Once the developer has committed, they have to deliver as agreed.

            This whole argument a non technical PM cannot measure performance is rubbish, if they take the approach above and missed deadlines happen consistently.

          3. SS


            By the way, whilst I agree that it is hard to quantify the exact time to investigate and solve a problem it should not be used as an excuse to not get work done in a timely manner. Every successful business operates with tight deadlines, and a good PM can optimise the process so that the team is more efficient.

            It sounds like you are making excuses for yourself when you can’t complete a piece of work quick enough. As opposed to looking at how you can complete it quicker which is where PM comes into play.

            Besides, good reporting tools such as burn down charts measure the average work rate of the developer. If you have ever used one, you can get a good idea of the skill level and speed of the developer over periods of weeks/months based on the type of work that has been completed by the developer. So as a quick example, if the developer is completing 6 points of worth of story points on average over q period of 3 months, then that dips to 3 points for the next period of time and the tasks are similar. It is safe to assume that there is something wrong with the developer.

          4. Adrian83


            “This whole argument a non technical PM cannot measure performance is rubbish, if they take the approach above and missed deadlines happen consistently.”

            In software development the speed at which a developer completes tasks does not equal with performance. A developer can finish his tasks pretty quick but his code most likely will be full of bugs and/or will contain a lot of technical debt that will make it very hard to maintain or further develop. Also code written in a hurry many times will suffer from performance issues.

            Another developer may take longer to complete tasks but his code may be more efficient, less buggy, and much easier to maintain and further develop.

            Of course there must a compromise between speed and quality but this is something that technical experts and technical managers are responsible for and not PMs (unless they are also very good technical experts).

            If the technical experts don’t want to compromise on quality in order to gain on speed then there isn’t much non-technical people can do about it. Larger software companies however also have CTOs that are part of the executive management team and take all the high level technical decisions in order to put in practice the company decisions.

            A non-technical PM will consider more productive the developer that finishes the tasks faster not taking into account the quality of the code and the impact the code will have on the future (bugs and technical debts). That’s why non-technical people or less technically competent people can’t really measure performance and usually are not responsible for doing this.

            I am not sure about the way your organization works but I have never seen a PM responsible for the performance of developers, this is usually the job of a software developing/engineering manager and technical leads. Nonetheless PMs could be responsible for developing performance only if the are also technical leads.

    2. SS


      Just to add only because you are technical does not mean you can manage people. I have worked with quite a few tech leads when I was a developer and in terms of management they were shit.

      They had great technical skills, but that did not translate to having strong interpersonal, man management and planning skills. Both are needed to deliver a project in a timely manner. Again , please do not offend us by comparing us to ‘glorified secretaries’, yes we need to relay information And report on the status of the project, but unlike glorified secretaries we have to do a lot of planning to make sure everything is delivered on time managing cross functional teams. A secretary will never have this level of responsibility and experience the level of stress that comes with this ever!

      1. Adrian83

        As I said in a previous comment project managers, as a general rule, don’t manage people.

        Managing people involves:
        – hiring an firing employees,
        – managing the work assignments of employees (for example on which projects they should work),
        – providing technical leadership and guidance to employees,
        – taking high level technical decisions,
        – evaluating the professional performance of employees and taking actions to improve it,
        – managing the employees rewards system (pay raises, bonuses, other benefits)
        – sanctioning the employees for wrong doings.

        Employees who are not themselves managers are managed by low level managers (also known as first line managers). These low level managers, as a general rule, don’t manage projects and don’t work as project team members instead they supervise the work of their direct reports no matter if they work on projects or not. Some low level managers have a budget at their disposal so they can act as project sponsors.

        Also the low level managers in most cases are promoted from among technical experts as they do need their technical abilities to perform their work. If you are not a technical expert yourself how can you decide who is the best candidate to get hired to work in a certain technical role?

        In small companies there may be no low level managers which means that the technical experts may report to someone that has not technical background, or does have a technical background but in a different domain. The above rule usually applies to larger organizations.


Leave a Reply

* Required