5 ms·
I spent a lot of years as a PM and PgM, and the general gist of this article seems to be that if you have better PMs your project outcomes will be better. I kn
by mdorazio 6y ago
I spent a lot of years as a PM and PgM, and the general gist of this article seems to be that if you have better PMs your project outcomes will be better. I know HN loves to talk about how much the PMs they've reported to suck, but having worked with many clients on dozens of projects, it's rarely that simple. While bad PMs are definitely way too common, so are bad development teams. And remember that PMs are usually getting shit on from two directions at once (development teams and management teams) with often very little authority to actually fix things. It's usually bad management practices and attitudes that sink projects and make life hell for everyone, and the cause of that is usually lack of understanding and empathy for how software development works.
The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales (and I've seen good PMs quit over this). We don't just need better project management training, we need better management training in general for anyone whose job is dependent on software. Also, companies need to actually be willing to pay for good PMs instead of pulling the cheapest contractor they can find and acting surprised when regurgitating the PMI handbook doesn't actually work.
- loopz 6y agoIf management don't understand the projects, and they generally don't, what are they really managing? Oh yeah, get the pay but use position as shield and sword.. You'll see the few exceptions are acting more like a PM, on and off.
- rualca 6y ago> If management don't understand the projects, and they generally don't, what are they really managing? With the inception of Agile, by definition software projects are impossible to understand in the sense of having a clear idea regarding concrete goals and risks, technical designs, and timelines. Yet, you will need to manage resource allocation, plan tasks, eliminate risks, and coordinate between stakeholders. That's what a manager does.
- loopz 6y agoThe consultants behind AM are always hired by managers. I'm sure they agree what they do get for the money. Also being in same team with a stakeholder, you minimize coordination cost and adjust goals and plans according to value. The only thing with Agile, is there's no room for a management class inside such teams. So yes, empowering the team with all those responsibilities, this puts more in the hands of the people providing actual solutions. Though, the paperwork can be handled by staff. Managers facilitating this will be more like an overall PM for multiple efforts. This across functions, as that is how you can get most value and improve culture. Such work is actually worth higher compensation too!
- rualca 6y ago> Also being in same team with a stakeholder, you minimize coordination cost and adjust goals and plans according to value. I'm not sure we are on the same page regarding what "being on the same team" means, and thus what the problems and challenges are. Agile argues in favour of shared responsibility through the direct participation of stakeholders. Yet, that does not mean that clients and product owners and team leaders and junior developers don't have goals and responsibilities and resources that need to be otimized, and more importantly that there is no accountability. In agile you still have different stakeholders with their own goals. You still have work that needs to be done and prioritized. You still have to decide what needs to be done in a given time frame. That's what a manager does. Agile does not make that go away.
- loopz 6y agoI only take some issue in last two paragraphs. I'll only mention for Agile teams, not other kinds: In Agile team, the team is responsible. Management decides how to reach accountability, though in practice the team together can pull through more. Agile team wants stakeholders in team, or close to team. Team plans work according to agreements with stakeholders, but can never ever be forced to do anything against their explicit agreement. Which is why there's no room for management on the team. Agile teams sets managenent in their rightful place, and may work well when workloads, accountability and additional complexity are balanced within reason. Ensuring this for org, is too big for each team (indians). So chiefs are still needed around. Vs projects: Agile teams isn't suited in all circumstances. There might be important stakeholders, costs, dates, hard known requirements, regulatory and coordination needs, that makes projects more suitable methodologies. Projects are temporary and manager-lead (PM on team), however. Having a manager or PM in team though, isn't an Agile team. You need servant leaders on team, and managers wield too much power and information imbalance.
- PeterisP 6y agoIt's not about not understanding the projects, it's more often about misaligned incentives. In most companies project work is the exception compared to "everyday functioning" of the company, and the line managers are managing that instead; and a typical situation is where particular resources are needed for the success of the project, but they're also needed for the non-project things that the particular manager controlling that resource cares about and is evaluated upon, so it's in their best interest to prioritize other things at the expense of that project. Or that manager might need a particular narrow subsection of that project done their way and the rest of the project is worthless to their goals (i.e. the very common 'silo thinking' in many organizations), so they might assign resources for that part of the project and 'starve' it afterwards. Management and internal politics has a big effect on which things get done and which don't.
- loopz 6y agoTraditional line managers lack interest / incentives for projects. Even though they might be high priority, different functions have different goals and measurements. The managers themselves fail every new line initiative, since they've no project / PM experience too, and also no support or real budgets. When this happens, look at the environment though for answers. This type of managing is running out of time, as it simply doesn't work that well beyond managers having eachother's backs. Managers need to involve themselves much more around projects / Agile, than just borrowing and stealing back "resources". If they can't provide servant leadership skills and healthy repurposing of roles, they need to stay away and clear blocks, allocate funds and people, from quite a distance.
- deleted 6y ago[deleted]
- CaptArmchair 6y ago> The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales It's turtles all the way down. So, let's think about executive sponsors here. Why do they change scope and requirements? Why do the act the way they do? Yes, there are executives who's career trajectory is defined largely by luck rather then acumen, let alone being knowledgeable or empathic to those in their service, or the stakeholders whom they cater to. But that's not the entire story. Businesses, whether a small 2 man outfit or billion dollar enterprise, do not operate in a void. Their behaviour is very much driven by changes in their environment. Whether that's the markets they are active in, customers they target, labour markets they tap into, competitors innovating and bringing new products and services to market, and public governance issuing a changing legal frameworks. Changes in scope and requirements are par for the course. Executive sponsors perceive those as investments and try to make risk-benefit trade off's assessing the information they have at hand. This is where uncertainty seeps into the decision making process. Even with clearly quantified information, it's still hard to predict the future. How will markets evolve? What do customers want? What will the competition do one or two years out? Strategic thinking and planning is hard because of uncertainty. In a military context, this is a clear given for leadership. Helmuth Von Moltke the Elder (1800-1891) famously said: > The tactical result of an engagement forms the base for new strategic decisions because victory or defeat in a battle changes the situation to such a degree that no human acumen is able to see beyond the first battle. In this sense one should understand Napoleon's saying: "I have never had a plan of operations." Therefore no plan of operations extends with any certainty beyond the first contact with the main hostile force. [1] [1] https://en.wikiquote.org/wiki/Helmuth_von_Moltke_the_Elder https://en.wikiquote.org/wiki/Helmuth_von_Moltke_the_Elder > we need better management training in general for anyone whose job is dependent on software For sure, leadership training is an established need. And it's also a thing that is catered to. There are entire libraries, fields of study, management courses and so on dedicated to leadership training. There's no lack of options out there. That's not the issue. More interestingly, you have to first question how executives ended up in a leadership position in the first place. For instance, many leaders don't necessarily became leaders because of innate qualities that show a due sense of what is understood as "being a natural leader", but because they were born into a context that handed them the opportunities that put them on that trajectory. Do note how I say "many". The above isn't a catch all either. How individuals end up in a leadership or management role is really a matter of many complex factors and happen stance. And so, having a social studies background, I always tend to be a bit weary when I see the "we need..." argument because (a) the "we" is never specified, (b) the "we need" negates complex contextual factors and (c) it reduces the argument into a single problem that can be resolved in general terms with a single pragmatic solution. And so that brings me to this point: > usually lack of understanding and empathy for how software development works I feel this goes both ways. Trying to understand the reasoning or the why behind shifting business strategies, and realizing that these are driven by fallible human beings who make mistakes based on incomplete information goes a long way. Working towards improving software development practices is a a great goal, but good will never become perfect. And trying too hard to reach perfection might even backfire. A lack of understanding and empathy of how software development works could be forgiven. A lack of understanding and empathy of how human beings feel and think - whether it's developers, project managers or executives - can't. It's the latter which makes all the difference at the end of the day.
- bob1029 6y agoWe just onboarded a new PM with loads of experience. I was very skeptical at first, but within 3 weeks I was being kept honest by this new manager on our daily calls. I didn't realize that we've never had a "good" one and how amazing it might be. I feel like the process for building your software is more important than the software itself. I.e. How can you worry about building cars when the factory that produces them is burning down, or experiencing a work stoppage because no one ever thought to develop a maintenance schedule for a particularly tricky piece of equipment? The more I look at this whole enterprise of software engineering as a virtual factory floor, the easier it gets to draw analogies between developers and project managers regarding how we should manage work.