For the sake of productivity, developers need to learn to say “no”

Whoever coined the mantra ‘The customer is always right’ has never tried to undertake development tasks for clients with grandiose ideas, but zero technical background.

Nowadays, every company might be a software company, but not everyone knows how to effectively manage software development projects. But give them the option, and they will sure as hell try.

In my different roles as a developer, project manager, and now CEO of a dev consultancy, I have learned that trying to bend too much to every need, wish, and whim of your clients, limits your ability to do your actual job — solving problems — properly.

Here are three reasons why to get the best results for your clients for development projects, you need to learn how to say no:

1. Not all clients are a good fit for your team

Recently, a potential client told me they were not comfortable paying up front. I offered them the chance to step away at that point with no charge, explaining that “we offer custom software, not custom processes.”

In the end, they didn’t sign up. While this wasn’t the best outcome financially, it was the best outcome for my team and my business.

My lack of flexibility on this matter wasn’t to be difficult, it was because we have developed tried and tested processes, and simply cannot adapt for every client if we want to stay scalable and profitable.

This issue was in regards to payments, but the same applies to all aspects of our business. If clients want to work with the best fit for their project, they have to be a good fit for us too.

A report from Forrester forecasts that in 2018 employers could end up paying as much as 20 percent above market salary rates for senior developers and other in-demand talent. In the midst of a ‘technical talent shortage,’ it’s relatively easy to find new clients, but much more difficult to bring onboard the best developers out there.

Requiring clients to agree to our terms helps us to manage projects, but it also shows our developers we value their work more than a paycheck from a difficult client. My business can survive for a couple of months without any new clients, but if all my experienced senior developers leave, we are screwed.

2. Clients are paying for you to be an expert, not a ‘yes man’

Many leaders are driven to say ‘yes’ to everything out of fear of losing clients, or getting bad reviews. However, the risk of these situations occurring is much higher if you agree to do things which are too far outside of your team’s comfort zones.

You don’t go to a Michelin star Italian restaurant, and then complain because the chefs won’t make you an Indian curry. You might though, if they try to make you something which they aren’t the best in the world at, and it doesn’t meet your expectations.

As such, my team and I are very clear about the services we offer, and those which we don’t. We only work with: PHP, Laravel, JavaScript, Vue.js, Node, Ionic, and Electron. These technologies are modern, mature and allow us to quickly build and scale products.

Clients are paying for your services because you can do something better — and quicker — than they could by themselves. One issue that we come up against regularly is that clients pile on extra functions or integrations which they believe are necessary to meet their goals. In these situations, it’s our job to push back, and demonstrate how we can deliver results in the most streamline, user friendly manner possible.

Another common issue, is that clients want to wait until a product is perfect before they engage a user base. This doesn’t work for us. We build software using a proven agile process, and encourage clients to get real people using the software as much and as early on as possible so we can start testing, find glitches, and improve functions.

3. There is such thing as too much and too little client involvement

Before lean methodologies became popular, it was far too common for companies to spend up to three years on development projects, only to realize that the finished product didn’t actually meet their goals. I believe that when using sprints, there’s no reason that you can’t have a functioning piece of software within three months. But running effective sprints requires our clients to be involved in the process from start to finish.

While my team and I are problem solvers, we refuse to work with clients who want to hand us a brief, disappear, and then expect a finished product (tah-dah!). Instead, we work closely with clients in a fast and iterative development process.

I believe that communication and collaboration are the lifeblood of effective dev projects, and only assign paired teams of senior developers to clients, who are expected to be available to check in at the end of every sprint.

Research shows that pairs of developers tend to consider more design options than programmers going solo, and consequently produce simpler, more maintainable end products, with fewer design glitches and bugs.

At the same time, there’s such thing as too much client involvement. Micromanaging clients distract dev teams, and can slow a project to a snail’s pace. For this reason, we offer bi-weekly updates at the end of each sprint, and only offer a account manager or project manager as a point of contact to keep a client at arms length during the crunch time of sprints, while adding any essential future tasks to the backlog.

At the end of the day, clients have chosen to work with you because they don’t want to hire and manage individual developers themselves. If you allow them to push your development projects in any direction, you’re defeating the purpose of the whole agreement. So while no client wants to hear NO too often, if you want to provide the best service, you need to take charge and know when to put your foot down.