The usual developer life

It used to be like this: an account manager acquires a client, next up the project manager goes to meet the client, discuss the project into more detail and then it’s up to us, the developers, to make the client’s dream come true.

It hadn’t bothered me that I never met the client. It saved me a lot of traffic frustrations and in the end, the client was happy with the result. There were however a lot of adjustments before the actual delivery. That didn’t feel awkward at first… until… the project manager got sick and I had to show up at the meeting instead. Don’t get me wrong, the problem was not the project manager nor was it the communication. It was the fact that we as developers were missing a part of the project: the human side of the project.

Why change what works?

The meeting went fine but on top of that I now had a more comprehensive vision of the client. The choices made from that point on were different because I – as a developer – could more accurately understand why the client would want option A more than option B. I could see why it would make more sense to display a property differently in the backend. Why I would need to make another choice to select something in the backend to make sure the client would not get confused when inputting his data in the cms. The end result would be more user friendly, more refined and more specific for the client’s situation.

For example, we were working on a project and had to list all properties they had in a country. We called it sites.. It was not clear for them so we renamed it to locations...the client had no idea what we were talking about, they had plantations, not sites, not locations, it was confusing & time-consuming. If the developer was more involved the backend property probably would’ve gotten the right name in the first place and use the terminology of the client but now we had extra work on this because of this lack of information on the developer side.

Another client had a projects listing on their website. We assumed a project had 1 executioner/owner but in reality it sometimes had multiple. 

I hear you thinking and you are probably right for the bigger cases, this should have been covered in the information architecture or the technical analysis but not all clients have the budget/want to spend time and money on this.

So?

Meeting the client when kicking off a project

I know it scares the shit out of most of us… meeting the client… do we really have to? I’d say yes. It costs money, I know, but in the end the advantage weighs out on the cost. It also really pays off as a developer to do the (intermediate) demo to see where you need to alter things to make it more clear & efficient. On top of that, preparing and giving a demo is an awesome oppurtunity to test the project. In the long run you become more aware of the usability towards the client. Those jira tickets hardly ever say something about the usability in the backend so it is up to the developer to cover that part. It gets overlooked sometimes but it’s something you learn over time.

So, do we need to be there in every meeting? No. I mean, unless you fancy budget discussions, workshops and other pm-related stuff. When I’m booked for a meeting I’ll always discuss the content of the meeting in advance with the pm. His time is valuable, but so is yours. Let’s be honest, someone still needs to make the projects. The kickoff however is crucial in my eyes. Most people detect if you're nervous, don't worry too much about it. It'll pass, it's even rewarding to just be there and listen. Try to feel the details of the project. It is also an excellent opportunity to ask any questions you may have. 

Can the client contact the developer directly? Nope. However, exceptions are possible but a few rules are needed. Long time clients or projects with very tight deadlines are situations where it could be an advantage to allow communication between developer and client. Verify if the developer & pm are up for it in advance. One of the most important rules: ALWAYS keep the pm in the loop and don’t take decisions that influence the budget. But also: keep your cool and be polite at all times. 

Why I’m all up for it? It makes you more involved as a developer, as a human. Which is important because you can feel the pressure more than ever. Having to please someone with your work other than your coworkers & teamlead (who love that you provide clean code) and your project manager (who wants the project to be done within time & budget boundaries).

Eventually the client’s happiness is worth more to me than having an extra line of comment in my code. ­The satisfaction you get when your client can maintain his project with ease is just awesome.

And while my teamlead and the pm are in charge, my worst fear on a project is not to live up to the client’s expectations.