Insights

We’ve already talked about delusional mindsets behind small business website projects, delving a bit into what’s behind much of the dysfunction that can run rampant in some small businesses, along with how those symptoms manifest themselves. In this post, I’ll be breaking down bits of the developer-client relationship and what can go seriously wrong, and ways to keep it healthy. This one is a bit longer than the others, but bear with me, it’ll help you with your developer relationships so that you’re not the lucky one who never gets the phone calls returned or has their contract cancelled. This is actually a fascinating topic that skims the surface of some organizational cultures and behaviors that can ruin business prospects, and I’ll be taking perspectives from others and my own career into account with this topic. Also, when I use the term “developer”, please note that I’m also more than likely talking about their counterpart, the online marketer.

The life of a web developer and online marketer can be both complicated and rewarding, but can turn nightmarish with the wrong clients. While many businesses enjoy long-term relationships with their developers and social media managers, others create repetitive turnover rates that are embarrassing (i.e., no change in behaviors). I’ve frequented private and public forums, discussion groups, Facebook forums, and the like to see what issues developers and marketers are facing, and most issues between contractors and clients point to a central focus: a lack of value and unrealistic expectations. The client lacks both the perceived value of the professional’s services, doesn’t set or understand realistic project goals, and shows no respect for the accumulated expertise a professional contractor can bring to the table. In fact, some developers and online marketers are treated like uneducated drones, while others are manipulated and cheated out of their revenue by clients who are “never satisfied” with the finished work. These are the manipulators and complainers that end up on numerous websites, posted by the contractor, where others can read about what took place (and stay clear of them). Yes indeed, developers and marketers talk. A lot.

Problems like this are prolific throughout online contract and freelance boards where many new and well-established developers and online marketers advertise services and bid on jobs. Unfortunately for the developers, these platforms, many of which have been restructured at the hands of corporate mergers, are now “client-centric” versus developer or contractor-centric, so the developer and marketer are always wrong, no matter what. If the client complains, out pops the funds that were just paid, and the client walks away with a free website or advertising campaign. This has left a huge loophole available for unscrupulous clients to take advantage of those who worked for their money. Yes, these cases can be fought, but the odds are stacked against the contractors in cases like this. Welcome to the new “fast-food” contracting business model.

Outside of these contracting platforms, businesses and developers can connect in the traditional B2B fashion (e.g., email marketing, finding a developer’s website online, networking, and phone calls). When combined with the other issues I’ve brought up in the past regarding delusional mindsets and whether or not the site is treated like a part of the business, the relationship with the developer can fade. Quickly. Those of us who are developers with formal business backgrounds are trained to look for warning signs during initial client communications and negotiations for services, while there are many who know just a narrow part of their field, which is how to code. The one thing we all have in common as freelancers and contractors, especially those who have been burned by clients, is that we can evaluate a level of trust right away. Therefore, there are numerous ways to upset developers before, during and after the relationship that can cause them to pull the termination clause in the contract, or not even engage at all. Let’s take a look at a few important ones.

Things not to do before work even gets started

1. Immediately ask about price. If the first thing that’s brought up is price, then that tells us that (a) you don’t have a plan, (b) you have a plan that may be unrealistic that’s going to need to be cut way back, or (c) you’re shopping “cheap”, which isn’t going to do anyone any good except for amateur developers that might not be able to finish anyway. It’s not about price, it’s about having a plan and realistically discussing that plan, and only then can an expected expenditure or project price be determined. You’re dealing with skilled labor, not buying sneakers. Their hourly rate is not negotiable, but a project price may be, depending on the contract’s terms and scope of work.
2. Start off a conversation with, “All I need you to do is…”. Discuss your project with the developer and they can determine what you need and what you don’t need. Remember, this isn’t your area of expertise, and that a relationship with a developer is collaborative in nature. They’re to be treated like a peer with a different disciplinary background, not an employee or slave laborer. Starting conversations off like this tells developers that you’re going to control everything, even if it’s wrong, which makes them look bad. It also tells them that they may not get paid, because you’re still focused on cheap and if their hourly rates are negotiable.
3. Describing the work to be done as ‘not hard’ or ‘easy’, or even adding that it should not take long. Again, these are red flags, and can be considered micro-managing, condescending, and unprofessional, as you’re telling the developer what to expect and how they should perform their work. Instead, discuss your needs with them, and allow them the space to come back to you with some solutions and proposed courses of actions. Chances are, the business owner or manager doesn’t even know themselves what’s required or how long it will take. You can’t nail down timeframes in a lot of cases, as it really depends on the project’s scope.

Things not to do during construction

1. Not sticking to a site plan and proposing changes after construction is well underway. The point of the site plan was to have a set of guidelines that would provide a mutually recognizable record that shows pages to be constructed, menu layers, flow, and even interactivity across the site. This is important, as your developer uses this as a roadmap to construct the site, and it also serves as a mutual understanding between the two of you on what work needs to be performed and why it’s important. Messing with any of this after you’ve agreed on it, unless it’s a dire operational need due to a miscalculation (i.e., not your own personal desires), can result in lost time, more expenses, and tons of aggravation due to the goal posts continuing to shift. This is, of course, those requests that could be considered well above and beyond what’s considered to be an Agile development standard (e.g., one of cyclic flexibility) and would instead be major proposed changes instead of minor ones. Don’t do it, unless you are okay with paying more and the job taking longer.
2. Attempting to be web designer, despite hiring one. Why did you hire a developer to begin with if you already have all the answers and the skills, right? Nothing aggravates a developer more than a client who agrees on work to be performed, only to interfere with that work and argue with the developer every step of the way. I’ve mentioned in the past that this relationship is collaborative in nature, because that’s what it should be. Two parties collaborating for the sake of the business and for the passion of what they both enjoy doing, not building a pyramid at the crack of whip, along with very wrong directions provided to the workers. Developers who are seasoned are not going to create designs, functions, apps and related assets that don’t conform with expected professional standards, nor are they going to create work that makes them look sloppy or unprofessional. In short, owners and managers, please stay in your lane and have a collaborative discussion, instead. They’ve got this.
3. Allowing personal biases get in the way of development, as if the site was your own personal page just for you. The business’ website is constructed for very specific reasons, and both customers and developers aren’t concerned with your own personal preferences unless it directly relates to legitimate branding and established business practices. Website planning can be very data and business-practice oriented, and a bias takes place with some owners and managers where they project their own needs, desires, and shortcomings into the custom profile of their business, which is nothing more than emotional and intellectual fallacies. This happens a lot and needs to be addressed professionally between both parties. The site should be designed around the customer profiles of the business, their needs, habits, and browsing behavior, along with industry cultures and trends. If the business is to succeed, the site must be built on top of data-driven facts, and changing site plans, color design, interfaces, user flow, and other areas of development based on merely the personal likes or dislikes of the owner or manager is wasteful on many levels, and the site’s users will feel a degree of cognitive dissonance as something is just “not right” with the design.

Things not to do during the deployment and completion phase

1. Complaining about the website after sign-off. Wrong time, wrong place. A web project generally has many stages involved with its completion, all of which require close collaboration every step of the way to ensure that expectations are being met from both the developer and the owner/manager. In the end, a beta test site is usually established for the client (a staging area) where they can test out the site and ensure that it’s functioning as planning and there are no bizarre glitches that will impact users when it’s deployed. Once the review is complete, the final payment is generally rendered on the account (unless a plan was in place via contract) and the site is officially deployed, with the old one being archived. At that point, the client has already rendered payment and has authorized the deployment, so any complaints after this are nothing more than… complaints. It’s unprofessional, unwarranted, and will likely be a key factor in never working with that developer again, because mechanisms for communication and collaboration were offered and clearly underutilized in that example.
2. Finding nitpicky excuses why the developer should not be paid. This happens a lot on contractor platforms but can also happen independently of them. In cases like this, the client demands the final site and then stiffs the developer, suddenly citing numerous reasons as to why they should not be paid for either “shoddy work” or various other excuses, generally behaviorally-focused ones (i.e., being rude, untimely, not listening, etc.). This is why contracts are important, and the process involved with development is generally done in stages with constant feedback that’s well documented. Generally, those who are not skilled at freelancing, and those at the very early stages of their career and skill-building who wish to try freelancing (which I don’t advise until much later) are well taken advantage of, mostly because they didn’t prepare for such situations due to a lack of real-world experience.
3. Expecting additional services or updates for free after deployment. Chances are you’ve already signed a contract and the expectations for post-deployment services have already been laid out for you. With that said, you either have an ongoing service contract or you could purchase additional services on an hourly model or a monthly one. However, knowing these options, and then attempting to add details of continued service to the contract that simply doesn’t exist, or attempting to bully or sway your developer to do extra out-of-contract after the site is done, is simply unprofessional. If the developer chooses not to engage you further after the contract is over, that’s their prerogative, and as an owner or manager, you may want to look at this in a reflective way to see if there was anything you may have done that provided them with “warning signs” that continued business with your company was not desirable for them.

That was a lot! Are you still with me? Good. As you can see, these are some very serious issues that come up quite frequently when managing the relationship between your web developer or online marketer, whether that’s an individual or an agency. Developers need both good clients and good examples of work, and if you’re both passionate about what you do, there’s no reason the end results wouldn’t be anything short of excellent for your business.