April 15th 2020
Digital PM trainer and Digital Project Management course instructor Rachel Gertz is our resident advice columnist for our 6-part Ask a Project Manager series, where we aim to get real, get deep, and get practical with your most burning questions about life and career in the creative industries. Have a question for her? Submit yours here. Today, Rachel writes about a common situation: how to do the job you were hired to do, and do it well, when there's no project manager to help set expectations and spot red flags.
I’m a developer and I currently have a client that I provide sporadic development support to. There’s no project manager in the work we do together and it’s become apparent that my client isn’t thoroughly QAing my changes before approving them. I always send a staging preview and ask for feedback/approval before pushing live. Typically, they OK my work with little to no feedback. Inevitably, bugs slip through the cracks. These can go unnoticed for days or weeks, but when they become apparent, I then receive the blame for the issue, even though the client had the opportunity to QA and didn’t notice the issue either.
In other projects I work on, 1-2 rounds of QA and fixes is typical and when a bug does make it live, I’m not personally blamed for it since many sets of eyes did not see the issue before OKing. I have seen in many developer contracts wording about review periods, the protocol when deliverables are “approved” and subsequently a bug is identified.
I’m not sure how to communicate to my client that I can’t be the sole point of QA or held solely responsible when they have had the opportunity to review and provide feedback before approving. I’m used to a project manager filling this space and taking on the role of communicating and aligning on expectations. What do I do so that I don’t keep getting blamed for issues that aren’t really my responsibility? How do I do my job well and get the feedback I need?
Signed, Not a Project Manager
Dear Not a Project Manager,
I feel you. It’s frustrating to be in a situation where you’re trying to release high quality code and getting late, sporadic feedback as well as blame for latent bugs. Let’s walk through this scenario you’re experiencing and explore some different ways to deal.
The way you describe the ad hoc nature of your relationship with this client, it appears like they are super busy and super reactive, or they are uninformed about how a development and quality assurance process should work. My gut says it’s probably a splash from column A and another from column B. As you navigate the complexity of the situation you’re dealing with, you’ll want to ask yourself a few questions:
Let’s dive into the first question.
Are your clients uninformed? Or just on fire?
To know what you’re really dealing with here, you have to get to the root of the problem. Are your clients acting this way because they don’t know any better? It sounds like you’ve already primed them with staging and approval processes, so that’s less likely. Or do they exist in a highly reactive state where it wouldn’t matter how much time you gave them — they would consistently push changes live at the last second because your code is one of a million things they need to review? Or is it possible, that they don’t know exactly how to give you helpful feedback AND they leave it till the last minute because their plates are full of other projects?
Clients typically don’t sabotage us on purpose. If they leave reviews until the last minute, it’s because they looked at the mountainous pile of things they had to do, cried a little, and let yours fall to the bottom. Maybe your work looked so great they trusted that everything was fine, or they didn’t know what or how to test it so they left it alone until an error turned up for someone else further downstream. This is pretty normal client behavior and once you know how they operate, it’ll be easier to know how to respond.
If uninformed, educate
If you’re not getting feedback and your clients don’t understand the process of how QA works or why they need to check your code before it goes live, they’re not being lazy: your clients might genuinely not get how the whole development process works. Laziness often masks the real culprit; ambiguity. If you’re not sure of their comfort level, this is an opportunity for you to sit with your point of contact and train them on some typical testing frameworks and user flows. One neat way you can do this is, instead of expecting them to understand what to watch for, prime them on the things that commonly trip up users and things that you might miss as a dev because you’re in the weeds (for example, microcopy, redirects, form errors). Spending an hour or two with them on a screen-share teaches them what to look for and how to give you the most useful feedback when you need it later. You can set this up and bill for all time required because it’s imperative for you to do your job.
You could say:
“Hey [client], it’s been a few weeks since our last deployment and users have caught bugs that should have been squashed during our first code review together. I’d like to set up a quick call to support you folks so we can identify why this is happening and isolate some prevention strategies on both sides. I have some ideas I’d like to share that will help smooth out this process.”You can adapt this guide we put together to help your clients know what kind of feedback you’re looking for: How to give great feedback.
If reactive, make proactive
If, on the other hand, your clients understand the flow but don’t make time for reviews, be proactive. Set up standing realtime code reviews in advance so you can gather immediate responses for UI or UX bugs with them on a more regular cadence. If errors are turning up on the backend, put your project manager hat on and coordinate review periods for your stakeholders (set it up as blocked out time on their calendar) where you’ll be accessible if they need you. In your meeting, have them commit to reviewing your code before you deploy. Make sure to communicate your office hours, best communication channels, and formats, too.
You could say something like:
“Before we get off this call, can I just get a verbal commitment that you be available on Fridays at 11 am for all future code reviews? I’ll follow up with a quick email to confirm your commitment.”
Clients want to know how much effort they need to expend to work with you. To support them, it’s a good idea to tell clients in advance how much time you expect them to set aside each week for testing, to help them plan their week (testing typically takes ~20–25% of your overall budget, so you could divide this into each development cycle). If you’re consistently noticing they don’t have enough time, see if you can get a dedicated point of contact to step up and be available for these check-ins. You have the right to ask for an approval flow that works for the project and relationship.
I’ve said this before, but it rings true here: Half your job is development, the other half is being able to communicate why and how you do the work. As a contractor, you are also a salesperson and a PM, so it’s super important for you to feel comfortable in that skin. Most of this comes from practicing tough conversations.
If slippery, set boundaries
Like I mentioned above, clients don’t typically undermine your process on purpose. But sometimes they can treat you like a vendor where you are not given strategic decision-making power or collaborative input: AKA “We give you the work, you do the work.” I’m not sure of your specific situation, Not A Project Manager, but it’s a good idea to assess your relationship and determine how you’ve set up your agreement and boundaries. Do they think of you as a strategic lead? Indispensable to their team? Or do they treat you like an implementer who gets stuff done and goes away? Clues to watch for:
If the majority of these answers scream ’don’t think, just do it,’ you are a vendor, my dear, and the only way to claw back the respect you need for your process is to have some tough, calculated conversations. To do this, you could set up a call with your point of contact and reframe the relationship together.
“Hey [client], I wanted to arrange this call so we can revisit our relationship and how I can most help you with your goals as a business this year. To date, I’ve done x, y, z, but I have some additional ideas for how we could move your business forward this year and [generate more revenue, more users, lower churn]. To do that, we’ll need to set up a more collaborative relationship with more frequent reviews so bugs don’t get missed in QA. Here’s what I’m thinking…”
Instead of waiting for clients to come to you with requests, you’re going to them with a planned roadmap of additional features that will help their business grow. You’ll increase the value you’re creating as well as the capacity you’re putting in (aka the value you get out). This makes it easier for you to set a clear schedule for reviews and approvals.
If your client shuts down and doesn’t want to proceed, you have your proof: you’re simply a replaceable vendor to them, and it might be time to ask yourself how much this relationship is worth to you. On the other hand, if they are open to your ideas, this might be the perfect opportunity to build your relationship and reset some boundaries that will make this development contract worthwhile. Ultimately, this is what your client is waiting for. They want to feel like their relationship with you helps them improve their business.
Do you want to work with these clients?
Finally, it’s a good idea to vet the relationship you have with your client to see how aligned they are with where you want to go in your own career. Do they take you closer to those goals (fun company, awesome projects that push you further, easy to communicate with)? Or do they introduce so much risk or delay that you can’t stop face palming? If you can afford to (on whatever level feels comfortable to you), you may want to consider asking yourself some tough questions so you can decide whether these slippery QAs are even worth your while.
Check out our six part series on client and goal alignment if you want to vet your own project and client alignment.
Not A Project Manager, I salute you! Being a development contractor is a super complex role with many hats. I can’t wait to hear how this relationship evolves when you reset the boundaries. Either way, you make the call. Here for you.
Your PM pal,
Ask a Project Manager #1: What Should Developers Know About Project Management?
Ask a Project Manager #2: How Do I Navigate Internal Politics to Get the Right Things Done?
Ask a Project Manager #4: How Do I Make Sure My Team Adheres to Deadlines?
Rachel Gertz is Co-founder of and a Digital PM Trainer at Louder Than Ten. She trains apprentices in digital project management so they can work full time while learning to keep their companies happy, healthy, and ready for the future. Rachel works on raising tides that float all boats to elevate the technology industry. If you have any creative career questions you’d like answered, you can ask Rachel here.
Illustration by Tom Redfern