Ask a Project Manager #1: What Should Developers Know About Project Management?

Welcome to our second edition of a series with our resident advice columnist (or as our UK constituent of the team calls it, “Agony Aunt”), where we aim to get real, get deep, and get practical with your most burning questions about life and career in the creative industries. Today, we’re saying hello to Rachel Gertz, instructor on our Digital Project Management course, as she takes on the mantle to answer your PM questions.

Dear Keen Dev,

This is my favorite kind of question and I’m pumped that you want to support your project managers. They need a lot of love. Great project management is supposed to be invisible (just like code), so it’s often difficult to see it in action (in fact, according to Nancy Lyons of Clockwork Media “…project management is like air quality. If you can see it, it’s probably killing you.”)

It’s great to hear you want to support your PMs at your new role. Project management often gets a bad rap from developers who sometimes see it as a barrier or a distraction from the deep focus they need to get their work done, and they’re not entirely wrong. You need long, deep half-days or even full-days of focus so you can solve complex problems or knock out bugs or try out a new framework and the urgency of project management can sometimes feel like it pushes you in the opposite direction. Sometimes it can feel pretty distracting—IF you don’t take steps to align PM and development. Luckily, you’re already thinking about it and this is something that really great developers shine at.

As a developer, when you take the time to share your thinking and approach, and understand and measure the work you do, you can become your PMs’ biggest ally. Plus, you empower them to run smoother, more successful projects. Here’s how:

Share your thinking and approach

Developers think logically, rationally, and intuitively. You solve complex problems by deconstructing them into components and modules so you can parse them and translate functionality. But here’s an interesting fact you might not have considered: 50% of your job is development work, but the other 50% of your job is communicating the approach, risks, constraints, and process you use so that your code and ideas hold up when you’re selling them to your team and the people funding the project. Communicating about your process also helps you build internal alignment so there are no surprises when you merge a branch or deploy your next release.

The good news is PMs are also very rational, logical thinkers: the good ones are looking to understand how the system around the project works, what all the pieces are within it, and why the team is doing the project in the first place. This is in addition to removing barriers to the team, communicating like a champion, and making sure that the work quality holds up and meets its goals.

Use Feynman’s Technique to teach complexity in a simple way

Richard Feynman had a terrific approach you can use to teach your PMs, now known as the Feynman Technique. It’s about making the complex simple. His method is about taking a complex topic and breaking it down until you can describe in terms so simple a six-year-old could understand it. This is not to say PMs are stupid and can’t understand development. Explaining a complex concept in a simple way makes it easier for you and your whole team to get alignment. When your PM understands which requests or features are more complex to build, they’ll be empowered to speak up and protect you if clients or executives start pushing back or asking for ‘one more thing.’

💡 Try this: It’s a good idea to set regular time aside (like an hour every couple weeks) to teach your development or workflow approach back to your PM—think of this as proactively tackling your process debt.

Here’s an exercise you can run: each of you fills in the steps for what the other person does from start to finish on a specific project or feature set. You are attempting to flesh out the high-level pieces the PM needs to do, and the PM is attempting to flesh out yours without any context. This reveals mutual gaps in your understanding and helps focus on places where you can build knowledge in a neutral, non-judgmental way.

I recommend doing this with small groups of PMs and developers so you can share group knowledge and break down any silos that build-up due to miscommunication. You will be blown away by how much this can improve your handovers, your project schedules, and your team’s overall happiness.

Stay true to the goals of the project

Sure, you can build out your feature set using the latest javascript framework and gold plate every possible piece of functionality so it has more bells and whistles than a Cybertruck—you can also do the opposite and build a low fidelity prototype with limited functionality in Figma to test that feature with minimal risk. The thing to ask yourself here is: “Yes we can build it, but should we? And if we do, how should we build it?” As a developer, you can lead a solid discussion with your PMs to weight priorities. You can ask questions like:

• Is it more important that we have higher quality product or more features?

• Is it more important for us to finish this work on time, or do a great job?

• What is more important to our stakeholders? Speed to market or fidelity level?

These questions are based on the project environment (the people, personalities, goals, and opinions around the product rather than the product features themselves). Your PMs should have a solid understanding of who gets to have the most say on the project from a stakeholder perspective and you can act in solidarity when you’re pushing back against extra work that blows your budget or delays your launch.

Ultimately, together you have a better chance of rejecting change that takes you further from your project goals. And you can help your PM by sharing how your brain works and asking them sharp questions.

Simplify your scopes and estimates

Once you’ve asked the right questions, it’s time to think about how you can actually scope and estimate the work. These are tricky elements that most humans are pretty bad at (and it’s completely normal).

We have built-in biases that attempt to confirm our assumptions, we are terrible at scoping complexity, and it’s difficult to switch from deep problem solving to hypothetical planning and back again when you’re in a development flow state. To really help your PMs, you’ve got to be able to own the work you do so that you’ll know when to pull back on fidelity or complexity and when to kick it up a notch.

Think, scope, and estimate in confidence ranges

One of the coolest things you can do as a developer when working with your PMs is to simplify the scoping and estimation process by attaching a confidence level to it. Often times, when PMs ask you: ‘how many hours will that take?’, you might think to offer a single number: 46 hours. But the reality is, that number would be more helpful if it was a minimum to maximum range (and instead of hours, it was framed in days). This minimum to maximum day range frames your confidence level that the work will be completed and it reduces the friction you get when PMs accuse you of ‘padding your numbers.’ You can use our 90% confidence guide to run through this exercise with your PMs. They’ll learn a ton and you’ll feel great knowing you have anticipated all the potential ruts in the project road.

At Louder Than Ten, we created this worksheet that goes over how to coach your teammates on 90th percentile estimation. (This is something we cover in our SuperHi course on Digital Project Management too.)

Build a scope menu

When you’re thinking of how you want to approach a particular development project or feature set, it’s easy to blue sky your ideas till you have a glimmering piece of work with every bell and whistle that will blind mortals on a casual Tuesday afternoon stroll. When we love what we do, we get excited by the possibilities (which is great!). But to flesh out the full picture, the fun is determining what’s possible within real constraints. As PM keynote Meghan McInerny would say: “Delivery without constraints is fantasy.” So instead of thinking through one approach to solve the problem, dream up three or four, start with the most complex way you could solve the problem. Then simplify the fidelity or complexity tier by tier till you have a ‘bronze’ version that still solves the problem and is valuable, but takes a lot less time to implement and costs a lot less, too. Your PMs will love this as it shows that you are taking ownership of the scope and thinking critically about real constraints rather than gold plating your code for no good reason when there are budgets and deadlines to consider. It’ll also keep you adaptable if you need to shift direction midway through the build.

There are a ton more things I could suggest, but sharing your process and simplifying and owning your scope are two of the most impactful things you can do in your new role.

I’m really excited for you in your new job, Keen Dev. You have an incredible amount of power to shape your projects and support the people running them. The truth is, your PMs are your best allies to protect you from burnout and the slowdowns caused by opinionated stakeholders. We love it when you are proactive and connect the how with the why of the project and help us understand where you anticipate complexity. We also appreciate kind words and thank yous because project management (like development) isn’t always a glamorous job (as you watch the credit go to your Creative Director for the eye-popping work they did). In fact, there’s a funny but sad cliche most of us PMs joke about: we are the ones eating the bag of Doritos under our desks crying after everyone else goes home. I know devs are often the ones toeing the line and burning the midnight oil squashing bugs. Watch to see if your PMs are putting their coats on last, too. Maybe you can share a pint or hot cocoa in solidarity and get to know them in the same way they want to get to know you. They will appreciate you and your interest in what they do more than you can ever know.

Your PM pal,

Rachel