A developer is only as good as their project manager
…and vice-versa.
When the dev-project manager relationship is harmonious, magic happens ✨, but there are often roadblocks along the way to achieving the perfect symbiosis.
Over the years, I‘ve had the pleasure of working on many diverse projects, spanning from large agencies and startups, to solo clients and small businesses. In doing so, I’ve experienced the absolute joy of working with some truly exceptional dev project managers, and experienced the frustration of working with some otherwise exceptional project managers who just don’t understand the dev world.
As a web dev, one quickly comes to appreciate the fact that the language you’re writing today could be old news tomorrow. Blink once, and all your knowledge is rendered useless. You‘re back to rookie status, scrambling to keep up. The key to being is dev is: Don’t blink 🤕. But honestly, there’s never a time to sit back and be ‘comfortable.’ We must always be reading, researching, and learning.
Being a dev project manager is a slightly different story. Not only do you need to understand the languages and systems your devs are using, you also need to understand your clients, their needs, and the industry they’re in. That’s an awful lot of work, and I appreciate the pressure. However, I think there’s a place in which devs and project managers can strike a perfect balance between having to understand too much, and understanding too little.
Hire the right person, or train well.
I’ve been in the unfortunate situation on more than one occasion of being paired with a project manager who a) knows nothing about the dev world and b) has not been offered any kind of on-the-job-training. If you’re thinking this sounds like a recipe for disaster, it is.
From a dev perspective, it’s extremely frustrating to be locked into designs, timelines, and product features that are nearly impossible to complete. It’s even more frustrating to come back to your project manager with questions, concerns, and alternatives, spend 2–3 hours explaining the ins-and-outs of the problems, trying really really hard not to use unintelligible dev jargon and be told ‘But that’s what the client approved.”
However, it’s equally frustrating from a project manager’s perspective. They’ve been hired for their knowledge and expertise in getting-sh!t-done and are employing it the only way they know how. Lacking basic web training, they’re wading in a sea of unintelligible acronyms like GIT, JS, AJAX, DOM, JSON and whatever-the-f!@# a WYSIWYG is.
Developer: “The CMS doesn’t handle that. It’s AJAX’d in through a REST API which we render into the DOM.”
Project Manager: “…”
It’s in everybody’s best interests to hire a project manager with prior web agency experience or offer on-the-job training prior to throwing them into projects with tight deadlines. Otherwise, the friction created can really erode employee morale.
Train them in what, exactly?
Excellent question! Like I said above, it’s a lot of pressure to expect project managers to continue being excellent at everything they do and know all the ins and outs of the dev world. If I could choose three things to train them in they’d be these:
- Common terms, acronyms and phrases.
This is so essential for good communication! Everybody working on a project should be speaking the same language and know what, say, an anchor link is. They should also understand the difference between a section and an element, an interaction and an animation, dynamic vs. static content, etc. They should be taught common acronyms like the ones listed above, and common abbreviations like IE, CSS, or CMS.
The below links are super handy if you’re a project manager yourself, and want to brush up.
- https://www.smashingmagazine.com/2009/05/web-design-industry-jargon-glossary-and-resources/
- http://www.thinkingit.com.au/glossary-of-website-terminology
2. The time consuming nature of coding
As a non-coder, it’s almost impossible to imagine the amount of work that can go into something as simple as vertically centering an element, or styling a <select /> dropdown. We’re all so used to having buttons to press or click, that do these things for us. In development, there are no buttons. Everything is coded from scratch, and so it’s really useful to show new hires that code. Show them something practical, like a button, and then go ‘behind the scenes’ in a less than glamorous version of a backstage tour. Once they see the lines of code that go into such simple things, they’ll start to understand why that new landing page won’t be ready for tomorrow morning.
3. Ignorance is not stupidity
We need to create a culture in the workplace that highlights the difference between ignorance and stupidity. Nobody should be afraid to ask a dev to explain jargon to them. It doesn’t mean you’re not smart, or bad at your job, it just means you’ve encountered something you have never come across before (or maybe you encountered it last Friday, and it was explained then, but how can you be expected to remember anything somebody told you on a Friday?). Rather than hiding that fact and either becoming frustrated, or trucking along acting like you know exactly what’s up, all team members should feel comfortable saying “…..what the F!@# is that?” and all devs should make time to hop on a call and bring everyone up to speed. It’ll save time down the road. Trust me.
Frustration leads to 0% work-getting-done
I’ve come across the unfortunate situation in the past of working with project manager and devs who just don’t care anymore. They’ve spent so many years mis-communicating that they can only see one another as antagonists. The dev is convinced the project manager is useless. The project manager is convinced the dev is an @$$hole. Projects get pushed back, hung up on misunderstandings, delayed due the lack of a basic will to go on, and as a result the entire enterprise is in a constant state of emergency.
But when companies work to make sure devs and PMs get along? Everything is unicorns and rainbows. Honest.
