Where I Stand on Software Project Management

My distaste for project managers may have first started after my first acquisition. I was a young PM on a great team with a tailwind of tremendous success. Imagine our surprise when the project managers flew in from corporate. At first it was a suggestion here and a new report there, but it wasn’t long before we were on Jira and our internal product development processes had changed entirely. This was a period of disruption for our team and significant professional growth for me. I learned a great deal from the folks at the acquiring company and I don’t blame them at all for enforcing the shift. But the approach left a certain taste. Over the following decades of my career I experienced multiple different approaches to product management and project management for software—B2B, B2C, enterprise, installed, and SaaS. Consequently I developed my own approach through trial and error and countless conversations with product folks, engineering folks, and the c-level folks. It’s rooted in simplicity, aligns with Agile, embraces change, and is geared towards rapid progress towards real company goals. And today I read the simplest way to express that opinion:

You should never let your PMs hire glorified backlog or project managers. If you do, then the entire team will lose its universal ability to solve whole customer experiences, and worse, you will dilute the reputation and expectations of what it means to have a PM on your team for the rest of the company.

Brandon Chu on Medium

In my view, the “product manager” role encompasses that of the agile “product owner” and the traditional “project manager”. His neck is singly wringable for the success or failure of a product. But he’s also researcher, tester, evangelist, intrapreneur, spec-writer, and frankly the glue for all the roles included and the deliverables needed. To divest any of these roles is to hamstring their success. This isn’t to say that work and responsibility can’t be delegated and shared! After all, the real, actual work has already been delegated to the engineering team and even saying “delegate” diminishes the hugely faceted and complex work that these teams accomplish. Additionally, talented designers and dedicated researchers provide a ton a value and direction to projects.

Ford v Ferrari,

The point I need to make here is that traditional project managers just don’t have the charge, the skillset, or frankly the empowerment from the company to make changes when the train starts to lean off the tracks. Not in the moment when a WIP shows something is a little off, and not in the macro when you realize that a project isn’t going to have the desired outcome. Project managers focus on the mechanics of the machine and that creates an abstraction from what is really happening. Human nature is too strong here and team members will allow and even celebrate not having to worry about those details. There should never be anyone insulating between the product manager and the engineering talent.

Rather, consider what Christian Bales’ character, Ken Miles, was able to accomplish with such an intimate knowledge of not only the car’s design but it’s assembly and tolerances. (The only thing I didn’t like about that movie was that it never really showcased the whole team that was perpetually standing behind the stars in a predictable oversight of character development.)

I come from a startup background where small teams and wearing multiple hats is the soup de l’année. But I truly believe in smaller teams with more intimate, hands-on exposure to the actual work, and unfiltered access to the purposes of the product. And I think traditional project managers get in the way of that.

I also don’t believe software engineers should delegate their test writing to junior developers, that QA only exists outside the scrum team, or that engineers should never talk to customers.

I’m highly opinionated. Thanks for reading!

© 2020 Ben Schmuhl | WordPress Theme: Cosimo by CrestaProject.