Why You Stink at Hiring Web Developers

p>Usually, I wouldn't direct a blog post at potential clients with the accusation that you actually "stink" at doing something. But – this was literally what a prospective client said to me on a call the other day. And, that got my mind thinking. On the call, we discussed some past issues with developers and the history of those relationships. My counterpart on the call at one point simply asked me: "Why do you think I'm so bad at hiring developers?" Well, in this particular case, there were a few reasons why their past engagements failed. But, this has been a recurring theme throughout my career. All too often, my initial calls with prospective clients is a therapy session of past negative developer interactions. I've literally had clients in tears telling me their stories of past failures and money lost.

Why is this?

Well, it is usually due to a recurring series of reasons. In this post, I want to look at a few of them in detail. But before I do, I also want to say one thing, which if we were speaking about this topic on a call, I'd be sure to bring up. A failed relationship is, in most cases, a two-way street. It's never anything you did all by yourself. Sure, you signed the paperwork, so I have to hold you to that part of it... But as the cliché goes, it takes two to tango, and if anything, the onus is on the agency to work with you to achieve success, not you to mold yourself around the agency. So, don't take it all personally or internalize too much, because it isn't all your fault. The developer has a more significant role to play in any issues you may have had!

So, in no particular order, here are some reasons why your past development projects may have failed. And, these are all things you can have some level of control over in future procurement processes.

Being Distracted During the Sales Process

I often see customers who are focused on the wrong things throughout the sales process. For the most part, I'm going to identifying this as focusing on bells & whistles, which matter very little in the grand scheme of things.

One area where this comes up is location. I get calls from clients sometimes overseas who want the "New York" experience. Well, first off, they are calling New Jersey, but we're pretty close, so I'll forgive that. But I always laugh because I feel this is a total waste of time and often, money too. City-based agencies cost more, typically have younger staff with higher turnover. There is no indication that they are any hipper to trends or influential in their space. I never understand why this is that people geographically care about agency location. In light of recent events with the Covid-19 crisis, I suspect this will matter even less. But I'm sure to an extent, it will linger for some time. Digital services are geography independent. It's just that simple.

I'm also amazed at how folks are so easily distracted by office space and ping pong tables. This is another area that I feel will change after this crisis is over. I've known some agencies that were fully distributed for years, and I suspect that will continue to happen. If this crisis has proven one thing, it's that people can do their work remotely and maintain a similar level of productivity. And that's with the kids at home continually pulling on their legs!

Finally, in terms of distractions, I am often frustrated at those who hire agencies based on a celebrity factor. There are a few out there who are headed up by what I could call the "celebrity chefs" of the digital world. In almost every case, their business model isn't based on long-term relationships. That is on both the client-side and the internal operations end of things. They focus on getting massive engagements, offloading them on junior personnel who turn over quickly, and then repeating the process. So many CMOs think its low risk to hire such a firm, but in return, they'll get less value for their billable hour, which in many instances is significantly higher than other firms that could do better work.

The moral of this story is to focus your attention on four primary factors: personality, capabilities, processes, and outcomes.

Trying to Conduct Apple to Apple Agency Comparisons

I think as an agency owner who oversees all of the business development at our group, this is the most frustrating thing I deal with. Clients are always interested in a myopic, apples to apple comparison of one agency versus another. This is understandable because, as consumers, we often look to make the same exact comparisons. And, we all know about RFPs and the process of corporate procurement. These devices were built with the specific purpose of making comparisons simple. However, the fact is that when it comes to procuring digital services, you really can't do such a thing.

As we've studied time and time again, the digital services business is very much unusual in that it has a minimal requirement for "parts" and is almost all ingenuity and then labor. Whereas when procuring a contractor to replace your roof, you can more or less compare material costs quickly enough, and as roofing requires less creativity, the labor costs should fall more or less in line with minimal divergence from one company to another. With creative or digital services, there are literally 100 different ways we can install that roof. As such, apples to apple comparisons are nearly impossible because every contractor will approach the problem differently.

This forces the consumer into a difficult spot. Either research technology solutions yourself and bring that requirement to the table (more on that in a minute) or attempt to compare how different agencies approach the issue and then figure out if the pricing is fair. Neither of these is easy to do if you are unsure what you are doing!

What is the better approach? It's to not focus on the apples to apples but instead focus on comparable projects, successful outcomes, and somewhat related budget ranges to determine if there is a fit there for you. Then, ask your preferred contractor for multiple options to get the project done for you.

Why multiple options? Because you need to know that your contractor isn't selling you the only thing they know how to do. If they present you with various choices, it shows they have different approaches to the project and, as such, is a more well-rounded agency in terms of skills and offerings.

Finally, look for one more thing: a personality fit! Agency services are professional services, and creative work means the agency must develop a sense of your style and personality. If you are unable to unwilling to create a relationship, it will affect the long-term success of the project and your satisfaction with the end product.

Not Understanding Project Scope

This happens all of the time with web development projects. And typically, it's a lack of patience that leads to falling victim here. I never quite understand how it can be that ambiguity can be allowed to exist with a development project. You wouldn't have your kitchen redesigned and built but not understand what the project would look like when finished. Nor for the building of a house, or even plastic surgery for that matter! The fact is, you need to understand the scope of a project and have it appropriately defined before you know what it is you're building. With a scope, you can then look at technology options, and then you can narrow down timeframes and budgets. There really isn't any other process that leads to successful outcomes.

But, over and over again, we see clients that commit to projects and have almost zero understanding of what they are getting. This leads to a variety of adverse outcomes. With an informational website, more often than not, you'll finish the project, albeit dissatisfied. But with more complex projects, you may end up getting nowhere.

How do you mitigate this? By undergoing an up-front discovery process to determine what your project really needs to be successful. Identifying use cases, edge cases, technology requirements, and also spotlighting any "gotchas" before they get you are all essential. In our practice, this is best realized via a discovery project, where you discuss functionality and arrive at a specification and plan of attack. However, sometimes people aren't even interested in this safety measure… Which is a segue to our next topic of discussion.

Fear of Small Expense Leads to More Risk

In our practice, we focus on smaller engagements before we propose solutions and start more significant implementations or deployments. This means a discovery session, a findings document, and delivery of a specification. Because this project often takes us at least a solid week of work, or more, we do charge for the time. Engagements can typically cost anywhere from $1500 to $15,000 or more for this service, depending on the complexity of the project and the scale of the team we are going to be working with.

What amazes us is how often clients have large budgets but are hesitant to outlay 5% of the budget (an average figure mind you) to actually define what it is they are doing! Some prefer to only put out an RFP, get a variety of answers which are nearly incomparable anyway, then commit large sums with outrageous deposits only to get to failure quickly.

What is a better approach?

It's best to slow down, contemplate what you are doing, figure out where any areas of potential risk exist, and answer those before committing to a development engagement. By doing so, you are ensuring your future success and getting a chance to determine your personality fit with the team you are working with. And remember – discovery work is always yours to keep, anyway. So even if the discovery portion fails, you'll have received value, and usually at a discount from full-service prices.

Being Closed-Minded From a Tech Perspective

The most dangerous clients (and by that I mean dangerous to themselves) that come our way are often those that have a preconceived notion of what technology solutions every part of their project requires, yet have little to no technical background. Typically, they heard from a friend who works at "XYZ Corporation" or their cousin at "ABC Start-up" that this technology or that technology makes the most sense, and therefore, they need to pursue that route without considering any others.

This is the riskiest phenomenon that must be avoided at any cost.

The fact is, there are many ways to build a website, application, or mobile app. No one size fits all. What works for your friend at an enterprise-scale corporation most definitely won't fit a start-up with a minimal budget. And the trendy technology your cousin is using at their start-up may not make sense given your use-cases or your lack of interest in supporting said technology.

The best technical choice comes down to factors specific to your engagement. First, what are you trying to do? Secondly, what long-term goals or prospects exist for iterating or growing your concept. Third, what capabilities do you have or need to have to support the end-product in the long run, and finally, when chosen, what is the security, scalability, and lifespan of the selected frameworks?

Last week, we commented about headless CMS and how it's a risky choice for most use-cases. Why? Because it's a centerpiece technology, it is offered by any number of potentially unviable start-ups, and the potential use-cases are very limited. However, people come asking for it because they hear about it from other folks. As the acronym goes, SMH…!

It's okay to come to the table with some idea of what you may want to pursue. But you must stay open-minded to the facts and the long-term implications of your choice in relation to your end goals and objectives. The right technology partner is not going to sell you on a framework or a tool – they are going to sell you on how to use a variety of tools to solve your problem most efficiently and show you how and why they came to that conclusion.

Handcuffed By Internal Process

I could have easily termed this section "being paralyzed by red tape" or "stymied by corporate policy". Either of these works to prove my point - oftentimes we see clients hire agencies that are not positioned to best meet their needs because of some level of corporate policy that makes no sense in the grand scheme of things. Last year, we bid on a project and we knew our competitor was bidding 2x our budget. This was a project in the hundreds of thousands of dollars. We got approved by the client, approved by their third party management consultants. Then the CIO needed to do the final sign-off but opted to go with the other agency because they held a partner certification with one specific technology in the stack that we didn't. The company then spent months attempting to stand the project up, and we heard via the grapevine that things didn't go well.

Would we have done a better job? I like to think so. But perhaps, the project went poorly in part because the majority of the team didn't get to work with their preferred vendor.

Why did the CIO go that route? Well, I'm unsure if the certification was really required. I'm also unsure of whether or not they had a connection with the other agency. I can suspect any number of things, but the most likely scenario is that he was under the impression that this certification would lower his risk profile. Glad that worked out for him.

We had another similar scenario where our company was in the contract phase but then was denied at the eleventh hour due to the fact that some of our team is offshore. Those team members weren't even slated to work on the project - but the fact that we had any connection to them knocked us out of the contract. Necessary? Unsure. That project is 3 months overdue and I'm sure past budget. Could we have done better? Again, I think we could have.

Both stories are examples of how corporate policy can lead people to make bad decisions. Now, one outcome I am sure of is that in both cases, despite projects not going well, no one was fired. Because red tape saves jobs. Though, I'm sure both companies would have liked to save hundreds of thousands of dollars AND gotten the project done.

If you are procuring, think about the real reasoning red-tape exists and consider if it really will help or hurt your project. Avoid similar outcomes. With minor risk comes reward.

Wrapping Up

In wrapping this post, I want to reiterate that projects fail for many reasons, and it is never 100% your fault. The real secret to avoiding hiring a poor developer is taking a small upfront risk, assessing personality and capabilities, and being open-minded to discuss the diagnosis they present and their recommended prescription for a remedy. Doing this, and not focusing on extraneous factors such as the bells and whistles mentioned above, will go a long way in avoiding future project meltdowns.