As a programmer, communicating with managers is equally important as writing good code. Programmers are the solution providers for business. Because of this, you interact with individuals across different business requirements like accounting, operations, marketing, IS, etc..
Writing good software is dependent on your skills to communicate, listen and understand a wide spectrum of business requirements. It’s a two way street between programmers and managers, though. Naturally, there’s a similar blog named “How to Speak Programmer.”
Programmers with great communication but just adequate coding skill perform better in business than those with exceptional coding skill and poor communication. Let go of the concept you only write code. Comprehension and problem solving is vital to coding, and neither happen without good communication.
Development and communication is not a new challenge
A classic cartoon of the tree and swing specification has taken on many variations over time. Below is a version from 1973.
Guide to Good Programming Practice, Editors: B L Meek and P M Heath (1979) ISBN 0-85312-145-1 (Ellis Hoarwood Ltd., Publishers) ISBN 0-470-26869-7 (Halstead Press, a division of John Wiley & Sons, distributor in the US). (http://www.businessballs.com/treeswing.htm )
Avoid assumptions and misconceptions
Try to avoid misconceptions. Managers can understand tech, and programmers can understand business jargon - the common ground is logic, but in manageable terms. Avoid the nitty-gritty details and communicate the fundamentals that are pertinent to the project first. Keep things simple and clear. Listen for signs of mutual understanding or confusion. Over clarification never caused a development project to fail.
Communication builds trust
Managers have to trust you. You have to trust managers. Managers are responsible for delivering a solution, but must rely on you as a programmer to come through with the deliverable. This is stressful for the manager and why trust is key. Similarly, as a programmer, worrying about hearing too late that one item which makes your design obsolete is stressful. You have to trust the manager to communicate accurate requirements, not change them, and abide by reasonable deliverable dates.
Programmers can earn trust by asking managers how they prefer to communicate. Agree on a schedule for updates and how to show progress.
Programmers need to speak up early, before it’s too late. Keeping items to yourself avoids the discomfort of voicing concerns - but only in the short term. In the long run, not getting out of your comfort zone and being vocal early will end up being much worse
Don’t skip the requirements and analysis documentation
Don’t let managers skip the SDLC (software development lifecycle), especially the requirements and analysis phase. Explaining the process may take time, but saves much more time in the long run.
For specifications gathering, listen carefully and understand the manager's fundamental requirements first. Repeat requirements back to confirm your mutual understanding. Don’t jump ahead in logic or introduce gotchas to consider until you both clearly understand the fundamental requirements. It may seem slow going, but keeping things simple first pays off with clear requirement documents and agreement on attainable goals for a successful project.
While gathering specifications, don’t try to get all requirements in one try. Get the fundamentals down in the first meeting. Then, on your own, take time to identify the toughest parts of your anticipated design. This gives both you and the manager needed time to consider fundamental requirements and challenges from the first meeting. After completing your initial analysis, meet again and review your findings. Test again your mutual understanding of the fundamental requirements, expected challenges, and goals for success.
Document the requirements and results from your analysis. Agree on the minimal deliverables for success and the related goals.
Compromise may mean not doing things your way
Be prepared to compromise to reach the goals. You may have to take what you see as shortcuts to balance manager deadlines. Be clear how the shortcuts impact future changes and maintenance in the long term. Explain industry best practices and how they save time and cost.
Never disappear, even if you’re in the coding zone
When you start your coding, be in the zone, but don’t disappear. Find natural breaks in your process, and use them for communication as agreed upon with the manger. This is vital for maintaining trust, and for stopping yourself from going down the wrong track. As you code, you’ll likely test assumptions made in the requirements. When you find an issue, bring it up. For managers, an issue is anything related to missing deadlines, going over budget or losing any of the minimal functionality required for a successful project.
Demonstrate functionality, screens, outputs or mini reports that show progress. Reduce the tech speak in your progress reports, focusing on the fundamental “blocks” of work you need to complete for the project. Plan ahead so what you’re communicating makes sense. Two blocks of work, each being 20 days, isn’t going to cut it with most managers. Be consistent. If you stop reporting progress for a period, it will the erode trust you’ve built.
Scope creep is tempting - help the team stay focused
Dilbert Comic Strip on 2012-01-04 | Dilbert by Scott Adams
Don’t be a scope creep enabler. Keep the team focused on your agreed goals as a first priority. Ask questions like, “how does this new item get prioritized with our previous goals?” It always takes longer than everyone expects, and little things added in scope creep are rarely little.
It always takes longer than you think - pace yourself
Don’t overestimate what you can complete. Communicate early if you have issues with due dates. Don’t trade sleep and reasonable work hours for glory in meeting unreasonable expectations. Glory is temporary and often requires hasty code. Burning out, missing a deadline and losing trust is not temporary.
Here are the takeaways
Speaking manager takes practice, but can make you a programming rock-star who consistently delivers what’s required. There’s really no trick. It comes with practice and building trust.
- Coding skills are not more important than communication skills
- Successful programmers communicate well
- The specifications and analysis step in the SDLC is critical
- Communicating specifications is an age-old challenge
- Avoid assumptions and misconceptions. Managers can speak tech and programmers can speak business
- Communication builds trust that you’ll deliver as a programmer
- Compromise to reach agreed upon goals
- Never disappear, even if you’re in a code writing zone
- Help everyone avoid scope creep
- Projects always take longer than you think - pace yourself