Building a productive working relationship

We've had our fair share of clients at Hussey Coding Limited (the company behind Developer Connection, in case you didn't know) and as I'm sure you have also found, in some cases, it can be hard to create a solid working relationship with client and developer firmly on the same page with everything from the details of a project spec to what's on the invoice. If you manage to get to this point then you have a highly productive, effective team where both client and developer work fluidly together to produce a great end result. Here the client gives the developer enough room to work effectively and the developer keeps the client in the loop with regular updates. This post discusses some of the principles we have found to work wonders in getting to this point.

Without a doubt you are going to find one principle is paramount in the smooth and successful running of a project where both client and developer are happy. That principle is trust and in this post we will be looking at ways in which you can build trust in a new working relationship but also discussing signs that might indicate the trust you need is not there yet, or if it was, is breaking down.

Take it slow at the start

The first recommendation is that in the same way as you would with any relationship, take things slow at the start of a new working relationship so that both parties can get a feel for how the other works. The main area where trust needs to be built is with the client trusting the developer. Like with any industry there are unfortunately both good and bad developers with bad developers very much being able to talk the talk, but not able to back this up with effective development skills. At the start, the client will rightly be looking to make sure they are working with someone who is a good fit for their business and has the skills they need. So expect trust to take some time to build - you might know that you have the skills and experience to complete the client's project to a great standard but you need to convince the client of that by delivering great results which demonstrates that skill and experience.

The flip side of this, of course, is that you can have both good and 'bad' clients.  As a developer, you want a client who is willing to put enough trust in you that when it comes to invoicing, while they might not understand all the in and outs of the work you have done (and why should they, that's why they hired you!), they do trust that what's on the invoice is an accurate representation of the work that has been completed and the time it has taken.  Achieving this goes hand in hand with maintaining good communication with the client, and sometimes this can be about the developer managing expectations at the start of the project.  From a client perspective, there might well be less immediately obvious progress, in terms of visually seeing changes, at the beginning compared to say when a theme begins to be built and the changes are very visual.  As a developer as long as you are clear with the client about the work that is happening and has been done for an invoice then that first invoice shouldn't be a problem.  But if the client suddenly gets landed with a sizeable invoice when from their perspective there still isn't much to see, it could indicate a lack of communication from developer to client on the work done before sending the invoice.  In other cases however it might be that the client just has an unrealistically low expectation of the costs involved in working on the project, and this is never a great start for the developer.

For these and a great many more reasons, our recommendation is that in the first period of the project, the developer completes just a relatively small section of work and then invoices the client.  It's normal for the client to have some fair questions about what they are being asked to pay for in these early stages - this is just part of building trust.  But if the client is essentially happy to pay for the work done and hasn't baulked at the cost, then some trust has been built there already and both parties are likely to be off to a good start.

But sometimes these early stages of a project can give clear signs that it may not be all smooth sailing.  From a client perspective, it's a good idea to do a little probing into the early work the developer has done for you, so we recommend picking one or two specific things the developer has worked on and asking them to explain how the changes they have done work exactly - from an 'out of interest' point of view.  If they are able to explain it to you in plain English such that you then understand that change then that is a great sign.  We love this quote:

"If you can't explain it to a six year old, you don't understand it yourself." - Albert Einstein

Over and over again we have found it to be true that the better the understanding and experience you have of something, the more easily you can simplify it in your own mind, and so the more easily you can explain it in simplified terms to someone who has no in-depth understanding in that field.

So applied to this, if a developer is able to explain a change they have made in terms that are understandable by anyone, there is a good chance they have a high level of expertise in development as they are able to see and understand the wider picture of the changes they have made.  If on the other hand, they explain it by giving you a bunch of development terms and jargon you don't understand, be wary.  The likelihood is the end product you are delivered, while it might work as intended just won't be following best practices and this is highly likely to cost you money further down the line to fix the bad code that was written.  They are also likely to be spending a good portion of their time finding out how to actually complete a task (maybe even re-using someone else's code they don't entirely understand aka copy and paste coder) which will cost you more money in development time.

From a developer perspective, there are a few things you can look out for in these early stages as well.  You of course always hope that you get a client who will take you on, give you a project to do and just let you get on with it, trusting that you are doing the job well as you keep them regularly informed.  The reality is that this is rarely the case, and often a client will understandably want to be more involved in how work proceeds particularly at the start, but this can sometimes be taken to extremes.

It's your job as a developer to give the client all the tools they need to be able to see and track work as it progresses, and understand the time required and spent on tasks.  For instance:

• Access to a ticketing system.
• Staging environments to review and approve code changes before they go to production.
• Access to the repo in case they want to dig a bit deeper (with commit comments linking to the repo commit hash).
• Easy access to you to ask questions or get updates etc.

You are basically looking to give the client everything they need to track the progress of the project in as much detail as they want to.

But sometimes this kind of setup is not enough to satisfy the client's communication requirements, and there are signs you can look out for which can be a strong indicator that building trust with the client is going to be hard.  It could also indicate that the working relationship could break down over time.  If the client is an experienced project manager they will understand the time and financial commitments of developing a store.  If they are not however you may find they approach the project with unrealistic expectations around time and cost.  So any scenarios like the following could be cause for concern from a developer perspective:

• The client wants access to your time tracking software so they can see and question exactly how long every task has taken.  This is not about the client having a general overview of the time spent in the project, this is micromanaging every expenditure.  The client should be asking questions more like 'hows progress with the functionality from ticket XYZ' than 'how long have you spent on ticket XYZ' which would indicate they are only really concerned with cost.
• They want you to use software which takes screenshots as you work 'for full accountability'.  I'll tell you right now, many developers find screenshots while they work highly intrusive, and that's why at Hussey Coding Limited right from the start we have used Paymo for time tracking which deliberately steers clear of using screen capture. If there is trust, you don't need to see the developers screen as they work, you will be happy to see what they have been working on in what they deliver.
• You are asked to give full information on how long every task, even the smallest shortest tickets will take and in some cases require completion and sign off before payment is even considered.  This is an indication of a client who has little experience or knowledge of what's involved in development.  Any developer knows that requiring completion and sign off of all work before invoicing is totally unworkable purely from an 'I need to pay the bills' point of view.  Often in these cases when you discuss a task with the client you can quickly recognise unrealistic client expectations for the completion time of tasks.
• The client wants regular phone calls just to 'check on progress' out side of any regular scrum calls.  Phone calls when they are needed are not a problem, but good ticket updates should negate the need to have regular phone calls discussing the project requirements, plus what gets discussed on phone calls often gets forgotten, so steer clear of nailing down any detail around project specs on a phone call.  While I'm sure it's not the case every time, we have often found working relationships to be more strained when regular check-in phone calls form part of the daily work routine - it's not only disruptive to the developer who may be working on that 'down the rabbit hole' problem and really just needs to concentrate, but it also puts them under unnecessary pressure which actually hinders rather than helps productivity.

If you come across these kinds of things then you could very well be at the start of trust issues which may end up derailing the entire project given time.  So as a developer look out for signs of project micromanagement after the initial period of work.  Ultimately, developers - don't undersell yourself!  You've spent countless hours, and years perfecting your skills, and what you charge is a fair reflection of the skills and experience you have.  Situations like the above can be a strong indicator that the client is going to push for you to undersell.  You may be happy to negotiate on cost, but remember that early decision will be a permanent one - so if you are willing to cut your costs, it's unlikely the client will ever agree to pay full price for any of the work you do.

Discuss the budget

This is often considered to be one of the harder ones, but at some point both client and developer are going to need to be open about the money side of the project.

Do it at the start.

If you don't discuss the money side before it comes to sending the first invoice, there is likely to be friction and pushback from both parties when that first invoice is sent.  You want to get to the point where the client is clear, and happy, about the kind of figure they can expect to see when that invoice comes through, and the developer doesn't feel apprehensive about sending invoices in case of push back from the client.  As a developer, you never want to be in the situation where the client feels they need to negotiate on costs to make the invoice more palatable and openness from both client and developer is key to reducing the chance of this eventuality.  Make sure the following points are discussed early on:

• The clients overall project budget.  This doesn't have to be an exact figure, but should as a minimum give an indication of 'if we are getting close to this figure and there is still quite a bit to do, I'm going to be concerned'.
• A ballpark estimation of development costs for the entire project.  Again this doesn't have to be in any way an exact figure, but a best guess will let you know if client and developer are on the same page, or if cost expectations are very different.

You should discuss money as fully as is required to make sure one key understanding is in place, and that is that the cost of development is realistically never cut and dry.  This is for two reasons, firstly the spec always changes and evolves over the course of the project, and secondly, development can be highly complex and it's just not possible to predict with absolute accuracy how long development will take for a task of any complexity.  You will rarely (if ever) work on a project where the final product exactly matches the initial spec - the spec will always have evolved and changed over time.  So the developer can, by all means, give estimates to the best of their ability, but this shouldn't be considered a quote by the client, and it should be anticipated that this or that additional feature may well be added, or that the development time may be more or less time than the developer estimated.

As a developer, you might find that the client pushes for a fixed price for the work you do, but we would advise against working at a fixed price for a couple of reasons:

• The vast majority of the time either the client will end up paying too much or the developer will end up underselling themselves, neither of which is a good outcome.
• With a fixed price the client knows exactly what they are going to be spending however in this situation, the quality of the developer's work will most definitely be compromised as they will always be watching the clock to see how much more time they can spend on each task.  The result of this will regularly be a lower quality end product because the developer hasn't had the time to complete all tickets to the best standard.

Working at a fixed price has the danger of making for a considerably poorer working relationship because the developer doesn't have the freedom they need to do the work well.  Yes, there are cases where the overall project cost may be higher, but so will the quality of the product, plus the working relationship will be that much stronger because the developer will recognise the client has put trust in them by allowing them to work at an hourly rate rather than a fixed price.

So if you quickly come to blows on project costs, or either party are holding back details on this front, our advice is that the working relationship probably isn't right.  Telling a developer the project budget doesn't mean they will work up to that budget in order to get the most money from the project, it means they will be working to come in as much below that budget as is practical.  Also with knowledge of the overall budget they will tailor the way they work and the time they spend on each task to suit.

One way in which you can make this immediately much easier is for clients to create your project with us and in doing that you can add the budget to the project spec giving you access to the estimated development cost calculator.  When developers get matched to your project they will have immediate clarity on project costs by being able to see the budget you defined.  Developers should subscribe to our service and then set an hourly rate as part of their developer profile.  Then when getting matched to projects, the client will have immediate visibility of all developers hourly rates.  Also with a project budget defined only the developers with the desired rates are matched to projects anyway.  This is a great, and easy way to be upfront from the start without the need for that awkward first conversation on costs.

Sign a contract

While often this doesn't happen, it's a great idea for both client and developer to sign a simple contract whose content should revolve around the discussions from before work actually started.  It shouldn't be a boilerplate document, it should be tailored specifically to that client developer relationship according to the discussions already had.  It should be equally balanced and not overly complex.  It's really just written, signed confirmation that both parties are on the same page before work starts in earnest, and it's a good idea to cover things like:

• Invoicing regularity
• How the client will be charged i.e. hourly or fixed rate
• Whether there is scope for negotiation on invoiced project costs
• Ownership of assets and if this transfers between parties, when this happens
• Get out clause with final settling agreement decided should work need to stop for some unresolvable reason

You basically want to cover off the areas which can potentially cause friction between client and developer so that if some disagreement does arise, you already have something in place detailing how that can be resolved.

It's likely that the content that needs to be in the document will become clear during discussions but having a document like this aims to give peace of mind for both parties from the start.  So if you do find yourself in the situation where something hasn't quite gone to plan, the agreement you have should allow you to resolve things amicably.

Clear communication

This is a pretty obvious one, but boils down to the fact that the clearer the communication is between client and developer, the less chance there is for miscommunication.  Failure to communicate clearly particularly in the area of detail around the project spec and what exactly is both requested by the client, and determined as possible by the developer results in assumptions being made by both parties.  If you feel as a developer you are in any way assuming certain requirements for a task get clarity from the client before you start any work.  The onus here is however on both parties to ensure there are no assumptions made about the project details.  Clients should be fully and clearly fleshing out the requirements for every ticket before it even gets assigned to the developer, but the developer should also request clarity where anything is still not clear.

Clear communication results in the developer delivering exactly the product the client was after without any misfires with incorrectly built functionality because the requirements weren't clear, and this reduces the possibility of creating unneeded friction between client and developer.  Delivering exactly what the client requested is also a great way to build trust as the client then knows you really understand their project, and what they are trying to achieve.

Be available

It doesn't instil confidence in the client if as a developer you are hard to get hold of.  Instead give the client an easy, quick way to get hold of you that they can be sure works every time.  Often just seeing that 'I'm online' green dot next to your name on skype, and seeing those ticket updates coming through is enough.  It's not about giving the client the chance to go over the top with how often they contact you when you just need to get your head down and concentrate, it's about instilling confidence with the client that you are active, attentive, engaged and interested in their project.  Failing to make yourself properly available to a client will result in a loss of trust, and will ultimately very likely push the client away to find a developer who has more interest in their project.

By the same token clients should also make sure they are readily available to the developer.  Feeling like you are working for an unseen employer can make you question the value of the project you are working on.  How dedicated actually is the client to their product?  Do they care about the spec detail of this ticket I need to discuss with them?  Will my invoice actually get paid when I send it?  So make yourself visibly available to the developer even though the likelyhood is they won't need to contact you outside of normal updates much at all.

Hopefully, this blog post covers some genuinely useful points in building a strong and lasting working relationship between client and developer, and if you want to connect with your next valued eCommerce developer or client then create your project, or get your developer subscription with us today!