I have never used a clickbait thumbnail for my post before, not even when I nuked a production database. But admit it, the thumbnail got your interest this time. Let's see if I can deliver.
The role of a project manager (PM) is somewhat controversial in the software development community. Generalization is bad. There are bad PMs and there are bad engineers. But you don’t quite see the same question posed for product and engineer people, the other two pillars of software development. Google even tried to let go of all of its PMs and had all their engineers reporting to a single VP of Engineering. What makes PM different?
The opinions about PM are more subjected to bias than others. A lot of PM work happens behind the scene. When work is running smoothly and on schedule, every day is business as usual. At times, it feels thankless and unappreciated. It’s only when a project is plagued with issues that the PM starts getting attention - usually not in a good way. The strategic values of project management tend to take place before shit hits the fan. After that, primitive instincts kick in, engineers keep their heads down and work harder, the process is out of the window, and a PM seems to only stand in the way. A great PM could still shield the engineers, prioritize work so the worst fire is put out first, communicate the impact to stakeholders, and plan for the next step. But usually, a great PM wouldn’t let the shit hit the fan, to begin with. In other words, PMs are judged after things have gone FUBAR, and everyone can afford to be smart in hindsight. The same hindsight you probably had learned from your angry parents after those end-of-year conferences with school teachers. No mom, I wouldn’t have skipped school that day had I known there was a test.
Every good PM succeeds in his own way, but bad PMs all fail the same: they didn’t do what they are supposed to do. What are they supposed to do? Sadly there is no universal truth. Granted, each company operates in its own way. At some places, SWEs deploy their own code, while in others, SREs reign supreme power over the production system. Some product owners are supposed to help with GUI design (hopefully based on some standard design system) or help with market research. But by and large, the outcome of members in a tech team is bounded to tangible deliveries and the inter-company differences are within standard deviation.
The PM role? They are supposed to be responsible for the success of the freakin’ project. Now that’s wild, how is that translated into concrete action is anyone’s speculation. That might mean being the link between engineers and customers, making sure both sides get what they want when they want. It could be about being a master of process, fluent in a range of management methodologies, and having an eye on constant improvement. Perhaps it involves understanding the web and mobile architecture, knowing modern technologies, and being quick on the uptake. Or I might have as well just described an Account Manager, Scrum Master, Technical Consultant, and part-time Avenger. PM’s scope of work is ambiguous by design as no two projects are alike and project management is the glue pulling things together, but unclear expectations are the breeding ground of disappointments.
Another thing that gives the PMs bad rap is the disdain for technology of some of them. Software development is not rocket science but it is not exactly a pure exercise of muscles either. That is to say, the field is somewhat technical. And just as any other technical field, it is full of useless jargon, lame inside jokes, and know-hows that take years to pick up. Non-technical PMs, people who experience difficulties explaining how a website works to a 5-year-old, manage to navigate around this quagmire by materializing all units of work into tickets. And they proceed to treat the tickets as little black boxes. The meaning of the work is watered down into start and end dates, and a set of labels for convenient herding. This makes a complicated system simpler. Some’s navigation skills are good enough that they don’t need to know how the finished work would look like. Work to them is parcels to carriers, you are supposed to ship it, not knowing the dead bodies inside. As I work for Parcel Perform, this sounds great!
There is a problem though, most people in software development are not in the business of writing code, they are in the business of building software products - hopefully, great ones. The difference is that one is an isolated piece of work with a predefined outcome, the other is a process of figuring out the intersection of market fit and technical prowess. Building non-trivial software requires plenty of arguments, negotiations, and decisions. Non-technical PM can’t call out bullshit. They lack the skills and tools to affect the outcome and all important decisions were handed to engineers and product owners. Without that decision-making capability, PMs turn into administrative assistants, busy themselves with monitoring project status, sending out updates, and keeping track of who does what. It is nice but it doesn't break or make a project.
Some PMs are shit umbrellas. Some are shit funnels. And the canopy of the said umbrella is technical knowledge. Not the same knowledge that is required for engineers to write code, but the knowledge to see through a project with clarity, know what is important and what is not, and call the shots when needed. It is not unusual for an engineer to pick up a book on Agile to better align his working habits with Scrum’s sprints. The sight of a PM reading Google’s Site Reliability Engineering to come up with a better fire fighting routine is as common as the sight of a Saola. Isn’t that having the cake and eat it too?
Are PMs useless then? The bad ones are. Bad PMs pose negative net morale and productivity for their team. Don’t believe me? Try rewriting the software for the third time because your PM failed to strong-arm a customer to put his shit together. But the whole thing about Google not needing PMs is as much of an urban myth as it is truth. It happened in July 2001, in computer time that was a century ago. It wasn’t the mighty Google where every practice seems to be deliberated, there were around 130 engineers. The layoff didn’t stick. The engineers themselves opposed it. The whole thing lasted for less than a month and was pretty much Larry Page throwing a tantrum against Eric Schmidt’s adult supervision.
As long as software products are written by humans, the role of project management in coordinating a bunch of professionals toward the common goals is always needed. People who think project management is a good way to get into the tech scene without the background need to get their reality check. PMs are responsible for the success of a project even though they have little control over it - how exactly is that easy? It takes a lot to be a good engineer, and it takes even more to be a good PM. The more people on board with this thought, the better it is for everyone in software development. Don't let a bad apple spoils the bunch, and the best way is to work on being a good one.
No comments:
Post a Comment