Being a developer is a job that presents many challenges. For me, one of the biggest challenges I have faced in my career has been effectively communicating with clients and stakeholders. As a developer at a consulting firm, my job requires me to communicate with clients often throughout the day. On my first client projects I played it safe, preferring to let the senior developers do all the talking. When I was asked questions in meetings, I would often defer immediately to others with more experience.
In some situations, because I was either the only developer on a project, or the only one present in a meeting, I would have no choice but to communicate with the client, but my lack of experience was painfully obvious, which could be frustrating both for me and the client. As a result, my impulse was to shy away from communicating even more, simply because it was stressful.
This is something that I still struggle with on a daily basis, but I'm constantly trying to improve because there are so many benefits to gaining effective client communication skills. My personal top three are:
It increases your professionalism. An effective communicator is viewed by clients and stakeholders as reliable, trustworthy, and knowledgeable. When my team receives feedback from clients, the thing they almost always mention first is that they love how often and how quickly we communicate with them.
It maximizes your efficiency. Breakdowns in the development process can often be traced back to a lack of effective communication in the initial stages. When requirements, expectations, and blockers are effectively communicated, problems can often be resolved earlier in the process.
It reduces your stress. In my experience, the stress of proactively communicating is far less than the stress caused by not communicating and being forced to when problems arise.
As I'm learning to be a better communicator, one of the main areas I've been focusing on is estimation.
I'm an optimist. In everything. Especially estimating work. I have often found myself in scrum meetings saying, "No blockers. I should be able to wrap this up by tomorrow." But tomorrow never came. Or rather, tomorrow did come, but the pull request did not. I was frequently telling clients that I was almost done, and genuinely thought I was, until a week would go by and it became obvious that I was nowhere near done.
What I've learned is that estimation is not just about how quickly you think you can get something done. You need to take into account various factors like technical requirements, familiarity with the code base and technology, and demands on time outside the project (such as meetings), before promising to deliver something within a specific time frame. So to help me with this, I came up with a set of questions to ask myself before I estimate something:
Do I understand what needs to be done?
This is most important, and the best way to avoid embarrassment later on when you spend three days working on something, only to show your progress in a meeting and find that you totally misunderstood the requirements. Trust me, if that hasn't happened to you, it's not fun. Ask the client and/or more senior developers lots of questions. Let me repeat that: ask the client and/or more senior developers lots of questions.
I think the biggest thing I've noticed watching senior developers in the initial stages of an engagement is that they ask tons of questions. While asking questions is essential, it's equally important to listen to the answers. Active listening is the best path to understanding.
By active listening, I mean more than just paying attention. I'm talking about a practice of listening that helps ensure that you really understand the information you're receiving. Asking questions is a part of active listening. Other key components are:
Asking for clarification when you don't understand something. It takes courage to expose your ignorance about something, but it is well worth the effort.
Summarizing what is said. The best way to make sure you understand what the client or stakeholder has said is to summarize it. "So, what I'm hearing is …" This way, any misunderstandings can be immediately clarified.
Do I understand what the requirements are and what steps I need to take to get it done?
If you're lucky enough to have well-written tickets that outline the requirements for your tasks, before you write any code, read through the entire ticket. Use the requirements to write out a step-by-step plan for how you will complete that ticket. That way you'll never have to ask what you should be doing next. If you don't have well-written tickets, you should write some. Now is also a good time to ask questions, even if it's just to get a second set of eyes on the requirements you've written out on the ticket.
How long will each of the steps take?
Here's where the estimation part comes in. Now that you've taken the time to understand what you need to do, and break it down into steps, write down how long it will take to complete each of those steps. Once you have that worked out, you just need to add those numbers together to get your final estimation. This is a much more accurate way to estimate than thinking to yourself, "Well, that seems like something I can get done in a week."
Is there anything outside of the project that will affect how long this will take?
If you have time off coming up, if you're starting to feel under the weather, if you have other tasks to accomplish on your project, if there is anything you can foresee that would affect your work, now is the time to bring it up. Factoring it into your estimate is much preferable to forgetting about it and having it come up later. The client will appreciate your planning and communication, and it will make your life a lot easier.
Answering these questions will help you not only give a more accurate estimation, but will help you explain to the client why you think you can complete the work within that time frame.
While these suggestions can help you develop better estimation skills, keep in mind that estimates are never perfect. Something always comes up. The problem might be more complex than originally thought, or a technical requirement might have been left off of the ticket - any number of things can get in the way of meeting your deadline. In part two, we'll talk about how to effectively communicate when problems arise.
Oldest comments (0)