5 Things Project Managers Should Know About Web Developers
Understand how developers think and work so that you can create project cycles that work better for everyone.
At Dodgy Code, our individual backgrounds include working at larger tech agencies where we were individual pieces of a production team. Together we’re now one(tiny) team, each of us taking on production work and project management to varying degrees. We know that project managers and devs often have similar goals, they just aren’t speaking the same work language.
Project management for web development is often chaotic. Dealing with fast turn arounds, rapidly evolving situations, and unique project requirements are par for the course. When you add working with teammates who are deep into problems and situations that you can barely understand — things can get really tense.
So, let’s challenge some of the common misconceptions. This is the information we’ve always wished our project managers understood. It’s also information we tend to forget when we’re managing projects ourselves. Our hope is that it’ll help guide you to a better Dev/PM relationship.
Cheers!
“Can we do it?” is a terrible question.
While this question seems innocent, it’s actually a pandora’s box. Experienced developers can do almost anything you ask, but with great coding powers comes great responsibility. Here’s some problems:
- Developers can be pretty literal and there’s a huge difference between ‘can’ and ‘should’. Be specific about which one you want an answer for.
- There’s often a catch. Can we do it … on X budget? Can we do it … by Y deadline? Tell your developer what the parameters are for the situation.
- Some requests are not a simple ‘yes’ or ‘no’ due to complexity, budget, developer experience, or other impacting factors.
- It can be difficult for developers to articulate that something is new for them, or outside of their skill range (especially in a competitive field). It’s possible the developer isn’t sure they can tackle it, or whether the request is even feasible. This often leads to a developer being overwhelmed by taking it on anyways, or a missed project opportunity if they turn it down.
Ask instead “How feasible is it?”, “What’s the level of effort?”, “The client wants …, how should we reply?” or “What’s your thoughts on this?”
Time estimates are time consuming.
Creating a time estimate takes decent amounts of experience to do well. To create a proper breakdown, the estimator needs to review the situation, investigate further information, solicit feedback, and ensure all potential issues are accounted for. Sometimes this can involve multiple conversations with project stakeholders or doing independent research.
DEV: Why Development Estimates Suck Especially, How to Do Them Anyways
https://dev.to/loetcodes/why-your-time-estimations-don-t-work-and-how-to-get-better-at-estimation-2jc7
As a project manager, expect any requests for an estimate to take time. Check-in with the developer for ways to assist, such as tracking down information, or soliciting feedback. Additionally, keep an eye out for billable ‘discovery’ or ‘research’ tasks that may need to be addressed with the client.
Be clear about priorities if the developers are also working on existing projects when you need estimates. Typically, the existing project will take their attention unless they’ve been told otherwise.
Your quick question is (probably) not quick.
Most of the time, project managers face inquiries that seem simple enough. And, instead of logging them in a task tracker or other channel, we feel it’s simple enough to simply ask the developer a quick question.
Then, we find out that there’s not enough information for an answer. Or the answer is complex due to factors we weren’t aware of (something about branches being out of sync and needing a force-push to allow merges??). Thirty minutes of discussion pass and the quick question is now a feature altering conundrum, and your developer seems agitated. It’s not your fault, you had no idea, so why are they upset?
Web development is an engrossing line of work. Have you ever gotten into the ‘zone’ of a good book, or the plot of a movie? Try doing that while your chat program dings at random intervals, or while someone asks you a point blank question. You’d probably lose your train of thought, forget details, and need some time to get back on-task.
Truth is, the human brain really sucks at multitasking. “Makers” in the industry (developers, designers, etc.) need uninterupted brain time with their work. Interrupting their cycles repeatedly reduces their speed, concentration, and generally just irritates them. There’s a lot more on this topic over on Maker vs. Manager Schedule from Friday, but the takeaway is this:
Reduce how often you interupt your developers.
Try scheduling a check-in to ask all your important questions for the day, or have a de-prioritised communication method the developer can check and respond to at their own pace. Keep direct interruptive communications to real (job threatening, time sensitive, life saving, etc.) emergencies, where you expect them to drop what they’re doing and provide you with undivided attention.
Project bandwidth is not the same as developer bandwidth.
As a project manager, you are the guardian of a project’s pace, goals, and budget. This usually places you in command of scheduling, and with that comes bandwidth — the amount of time available on someone’s schedule.
Contrary to popular belief, there’s more to bandwidth than working hours. It makes sense on paper that a developer can work eight hours on four projects in one week. In reality, we know few developers who can juggle more than two. That’s because developer bandwidth never matches project bandwidth.
Wired UK: Individual Bandwidth and Productive Working Hours
https://www.wired.co.uk/article/working-day-time-five-hours
Working on a web project requires keeping lots of information at hand, and using it to make decisions on a micro-scale within the codebase. Humans can only keep so much data in a readily available state, meaning the more project data they keep in mind, the more likely they are to forget something, miss a use case, or overlook an issue. You’ll find more bugs during QA when the developer was tackling too many projects during development, exceeding their developer bandwidth.
The Harvard Business Review: Are You Relying Too Heavily on Key Staff?
https://hbr.org/2014/06/good-managers-look-beyond-their-usual-suspects
Try to limit the number of projects a single developer works on to no more than three, and be sure to alternate crunches with time to recuperate.
Developers do appreciate when you try to learn.
One of the largest disconnects between a developer and project manager is a lack of common knowledge and vocabulary. I asked our project guardian, Ben, what would make working with one of our developers easier on projects. He answered: “Explaining technical things in a non technical way would be swell, I can’t understand most of his magic spells.”
To Ben’s credit he’s been picking up courses and articles to get more familiar with the web side of things. As a result, many client requests arrive more fleshed out and our developers have an easier time explaining the complications that affect development. This position also makes Ben feel like a teammate, rather than an adversary on tougher development hurdles.
When project managers don’t understand development processes or the basic functionality of the web they often become a parrot for client requests, or an additional stakeholder for the developer to appease. Learning the basics can give a major boost to a project manager’s skillset, ease communications with the client, and result in some major brownie points with the development team.
Recommended Resources:
- Learn Javascript (Free Course) https://www.codecademy.com/learn/introduction-to-javascript
- Learn HTML (Free Course)
https://www.codecademy.com/learn/learn-html - Google Analytics Academy (Free Course)
https://analytics.google.com/analytics/academy/ - MDN Web Docs (Free Developer Articles) — How the Web Works
https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/How_the_Web_works - Learn SEO Basics (Free Articles)
https://moz.com/beginners-guide-to-seo
Ultimately, the developer / project manager relationship has the potential to be a strong one. The key to success is teamwork, starting with communication and support for one another. Once harmonized, the projects become more efficient, the expectations clearer, and the team morale increases. We encourage you to be that teammate — because afterall, you’re in this together.
Want to work with us? Send your project inquiry to info@dodgyco.de
