Saying No to Scope Creep: How Web Devs Can Push Back

Episode Sponsor - Magic Mind & Wix Studio

Magic Mind returns as an episode sponsor this week and we thank them for their support!

‍Limited time Magic Mind deal for our listeners!

https://magicmind.com/HTMLPOD20 - 20% off for one-time purchases and subscriptions (Use the link and code!)

Code: HTMLPOD20

Wix Studio: The Web Platform for Agencies and Enterprises

Wix Studio is the new web platform tailored to designers, developers and marketers who build websites for others or for large organizations. The magic of Wix Studio is its advanced design capabilities which makes website creation efficient and intuitive.

Check out Wix Studio today.

How to support the show

Patreon

Prices subject to change and are listed in USD

• Support the show from as little as ~$1/month
• Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
• Help support the HTML All The Things Podcast: Click Here

Show Notes

Introduction

• As web developers we get feature requests all the time
• Some developers think that we’re simply tools of the trade and that we should complete all requests
• However, some requests come from a place of ignorance (non-technical staff) so they may be:
  • Superfluous
  • Harm the project
  • Cause a significant drop in productivity
• If you’re invested in the project (either literally, or just want it to succeed) then you may feel the need to push back on some requests you receive. So this begs the answer to some questions…
  • Should you push back at work? Against an employer? Against a client?
  • When should you push back? 
  • How far should you go to make a client’s request come true?

Should you push back against feature requests?

• As a hired developer, your work requests commonly come from people that aren’t technical
• They’re making their requests from a place of ignorance and expect you to fill the blank in their technical knowledge
• In terms of web development, feature requests by non-technical staff can easily harm a project:
  • Superfluous requests
    • Many requests are made as a matter of convenience (ie can you integrate an AI writing assistant to help me write my blog posts) could take hours to implement, when the user could simply use ChatGPT and copy/paste the results
    • Because some CMS have AI assistants built-in, it may not be immediately obvious that not every CMS is ready to have AI added in
  • Harm the project
    • Some requests may actually harm the project
    • In the context of websites, something like background music is seen almost as taboo these days and is likely to turn potential customers away
    • Websites are also at the mercy of external forces, like SEO & search engines
      • If a request would do something the search engines don’t like, then your site could fall in ranking and you could lose leads, harming the project
    • Another common harm that is easily caused is a decrease in performance
      • Requesting super high resolution images, too many elements on a single page, etc. can easily skyrocket the loading time of a website (increasing hosting costs, bouncing users away, etc.)
  • Cause a significant drop in productivity
    • Many companies are looking to build and ship fast
    • Every feature add, adds to the technical debt of the website, not to mention the initial development and shipment time
    • If a feature doesn’t align with pushing the company forward, it can easily become a time sink…disastering productivity
  • Interrupt existing timelines and feature developments
    • If you’re already working on other feature requests and have them all scheduled out, adding “just one more” could make your organized calendar into a house of cards - causing development to be rushed out at a lower quality, deadlines missed, etc.
    • Each feature should be prioritized in sequence for importance and urgency
    • And it’s not acceptable for your team to be in crunch time all the time to push out a queue of features that’s overcrowded
• Pushing back against an employer
  • This is often more difficult than pushing back against a client, as you’re commonly considered a subordinate - you’re a cog in the machine
  • Some companies (depending on culture) reject this notion, however, and want their employees to speak up when they see problems, solutions, or have ideas
  • Pushing back against your employer is a great way to make a name for yourself, if you make good suggestions, but your decision to do so should lie within the company culture itself - if your employer does not want feedback, maybe you shouldn’t push back on feature requests (within reason)
• Pushing back against a client
  • Freelancing is common in the web development space
  • When you’re dealing with a client, you’re commonly brought in as a web developer (of course) but also as a consultant - an expert in your field
  • We push back against client requests all the time, providing evidence for our decisions, but ultimately letting the client make the decision
    • The difference here is that if the client really wants something done and we are very against, we can always just leave the project (assuming the contract allows it)
  • There are instances where you’re hired into an in-house team, this situation is trickier as you may be there to be more of an employee and less of a “general helper/expert” as with ‘traditional freelancing’

How far should you go to make a client’s request come true?

• Some client requests offer them a tiny convenience, but come tied to a huge development cycle (lots of time, complexities, technical debt)
• Other client requests are really hand-holdy (making sure every edge case is covered by the CMS setup so that it’s virtually impossible for them to make a mistake on content, or page building)
• These requests are often small in deliverable…but not small in development…how should we handle it?

Shoutouts!

Michael LaRocca

• Author of the Self-Taught the X Generation blog, at selftaughttxg.com