Speak client: a developer's survival guide

Nobody told me how to work with software clients. One might say that the best way to work with customers in tech is to pretend to be human. I say "pretend" because during my studies and my short software engineering career, I was taught to be a code interpreter, not human. After all those years, I find myself sitting in front of my laptop, with a rubber duck beside me, trying to think like a computer, waiting for the meeting with clients where I'd pretend I'm human.

I started to think that something went wrong. Since blaming others is the best coping mechanism, I started blaming my university because nobody told me there that instead of coding in my basement, I'd need to understand people who, what's worse, aren't engineers. Then I realized that I went into computer science, which didn't necessarily have to prepare me for this crucial aspect of software development.

What's even funnier is when I started applying for software engineering jobs, recruiters would ask me if I like working closely with clients. Well, I worked at McDonald's, I thought. For one month during my vacation when I was in high school. I remember all those angry, starved people yelling at me that they were waiting for their hamburger for too long — "Yes! I love working close to clients!" What was I supposed to say?

Recruiters and technical interviewers ask about experience with clients because they know it's important (or someone told them that it really is). When I was interviewed for a backend engineer role at one company, the technical interviewer asked me to describe what a bike is.

He wanted to check if I could describe something familiar to me in simple, understandable terms. Knowing that, he could conclude how I'll handle describing programming concepts to clients.

I realized that everyone in tech recruitment is trying to validate if I'll be good at talking with clients, but everyone does it differently and I saw no proof that either approach is correct or not. Sometimes we conclude and sometimes people are terrible at concluding. That's why I wanted to check what the scientific perspective on this topic is and gather it together with my thoughts here.

Research shows that only 39% of software projects are successful, and most of the issues revolve around human aspects, particularly communication. There are some clues out there that informal communication has a good impact on project success. There is also a positive relation between client satisfaction and informal communication.

Making things simpler: formal communication requires more time and energy than informal communication. This time and energy can be used for solving programming problems, and from that perspective, the conclusion about informal communication's impact on project success seems to work just fine.

Sometimes I hear my developer friends complaining that business (Mr. Buzzkill) is constantly changing requirements and they can't finish what they are working on. Whenever I hear this, I wonder if that's because business does not trust tech professionals or tech professionals aren't being professional enough.

There are some things you can expect from a professional service. When my 17-year-old car breaks down, I always expect that my mechanic will call me and tell me what the problem is, what the options are for solving it, and how much it'll cost me. I know that repairing my old car is rather cheaper than releasing a software application, but in the end, the process is quite similar and is based on trust.

Advising isn't about commanding. Advising is about listening, asking questions, and trying to be helpful. Trying is just enough, because sometimes even professionals can't be helpful, and I think it's better to say I don't know, than to say I think we can implement a class for that. I know some professionals, who are treating their job as a space for being superior. Probably it's not intentional, nevertheless any job isn't about that, even in IT.

When developers had sanctionary power over users, users would "go through the motions" of agreeing on the system solution, but their actual behavior post-implementation did not adhere to this agreement.

Some time ago, I had a discussion with a client about their system and possible ways of improving it. I had prepared myself for that meeting and explained a lot. I was trying to ask questions, be helpful, and say I don't know when I really didn't. There was a much more experienced coworker in the room. He just listened to us and at the end he asked three questions that affected all the actions we want to take now. My feeling was that he has something that I don't have yet, and it's mostly about being a good listener and that ‘s something some people will never be. This thing makes him an alpha programmer in my eyes and that totally wasn't about being a full-stack-I-can-do-everything guy, which for some people can define an alpha programmer.

I'm not an example of such an alpha programmer, but I think I know the direction to follow. I don't know if I'll ever be classified as customer fit. Maybe I'm already that, maybe not. It's hard for me to care about it because it's not something that one can check in an interview. I'm ok with that. Some things don't have clear answers and recipes, and looks like being a customer fit is one of them.

At Kellton Europe, we believe great software is built on great communication. We do exactly that – we build relationships, ask the right questions, and translate complex tech concepts into business value.

Want to work with developers who understand both technology AND business needs? Drop us a message and let's have a real conversation about your project.