Poor communication lies at the root of many problems in life, not just in business and technology. Have you ever placed an order at a restaurant only to receive something completely different?
This happens frequently, even though it is a very simple task. Software can be a million times worse due to poor communication.
This article will explore effective communication with your tech partner to ensure you receive the right "order".
Understanding The Problem
We have written many articles aimed at guiding businesses towards a successful custom software project implementation, such as 5 Tips to Better Manage Custom Software Projects and 10 Fantastic Tips to Reduce Your App Development Cost.
A common theme among most of our articles focuses on understanding the problem well before beginning to put it into code.
You need to understand what it is you want extremely well before you go down the route of trying to explain it to somebody else, especially a programmer.
It is likely that the problem you are experiencing is being felt by many other people. The more people feeling the pain of this problem, the better for you, as this means that there is a potential market for your solution.
However, many people assume that this is a problem that needs solving and jump straight into the solution before ensuring systematically that the problem exists.
You can tackle two birds with one stone by talking to hundreds of different people in your organization or market to learn exactly how many people are experiencing the problem and understanding how they think the problem can be solved.
This will help you validate that the problem exists for many, understand the problem from many different perspectives and figure out what your first MVP will potentially look like.
Learn To Think Like a Programmer
Once you have a clear understanding of the problem, it's time to engage with a software developer to implement your solution. But, before you do, it's important to learn how to think like a programmer.
From a very high-level, programmers think and work in the following way:
- Understand the problem, check
- Break down the problem as simply as possible
- Try a solution
- If that solution doesn't work, try another solution
- Repeat step 2 and 3 until you have solved the problem
You are probably thinking "if I could try and build a solution, I would! This is why I am reading Appstrax blogs all day!". This is a common thought process. The good news is that you often don't need to code to solve the problem.
There are a million different tools and no-to-low-code solutions out there that can help you put together a prototype and test out your solution, even if it is extremely rough. This will save you a lot of time and money down the line.
Once you have tried many different combinations of integration tools, drag-and-drop builders and prototyped it with a few people experiencing the problem, you will have a basic understanding of how a programmer thinks (at a very high-level) as well as tested it with your potential users/customers.
This will help you engage with developers and give the developers a working blue-print of the solution they want developed (thanks to your savvy prototypes).
Familiarize Yourself With The Developer Lingo
There are a ton of different programming languages out there and developers themselves sometimes sound like they are talking another language.
It's important to understand some of the lingo before becoming overwhelmed with your software project and developers.
It can sometimes feel frustrating when developers try to explain where they are in the project by throwing hundreds of different terms at you.
The more you study up on the various common terms, the easier it will be to try and understand developers.
It is important to not try and know everything, though. Don't pretend that you understand what the developer is saying all the time. It is ok to stop and ask for a simple explanation of what your development team is trying to say.
Familiarize Your Developers With Your Lingo
On top of all of the existing terms and phrases that exist in technology, every business industry, sector or problem domain comes loaded with their own verbs. This can further complicate the communication between you and your tech partner.
For example, if you are trying to solve a problem inside the retail industry, but your developers have never worked in retail, it might be extremely difficult for them to understand what you mean by "depth of range" or "merchandisers" mean.
The best case scenario is that you work with developers who have solved problems in the same industry. Even though developers can all write code, it doesn't necessarily mean that they understand the problem space as well as you do.
The best way to tackle this is to come up with a unified dictionary specific to your problem/domain, that you and your tech partner both agree with.
This can start out small and evolve throughout the project. Although, ideally this is done during the initial workshops together.
Developers will be further guided by the terms that you use and are able to model the data and code around the domain specific terms that you and your stakeholders will be using daily.
We live in a constantly connected world. There is an abundance of software, tools and technology that allows us to collaborate and communicate.
Slack is a common collaboration tool for teams and a lot of developers like to communicate using the tool as its easy to share files, media and most importantly coding snippets.
Slack also integrates nicely with other collaboration tools such as Github.
Even though you most likely won't understand the code that gets stored on Github, the platform comes with many neat collaboration tools like Projects and Issues.
These additional features allow team members to create issues, bugs and tasks, as well as organize them into project kanban boards (similar to Trello or Asana). The best part is that they can easily be linked to the code repository that developers work in.
It will help to learn the tools that developers are most comfortable with. The longer you keep the developers focused and flowing in their code, the better it is for you.
Frequency of Meetings
It is extremely difficult to manage your software project if you are not technical at all. You are at the mercy of the technical person and have to trust that what they tell you is correct.
This often pushes clients to want an update every few hours with many different calls and status updates.
Every team and project works differently. You need to determine what frequency of meetings and demos works best for your team and project. This most often is figured out weeks after starting the project.
Too many meetings will keep the developer out of flow and will reduce their output. Developers hate meetings. One or two meetings per week should be more than sufficient to get a status update.
It is also important to be understanding of mistakes, errors/bugs and delays as they happen in every single software project.
You want to build a relationship with your tech partner that allows them to come forward with issues without feeling scared, as this may cause further issues down the line. The more open the communication, the better it is for you.
There are a million different ways to communicate and collaborate with your tech partner to ensure the success of the project.
As you have seen in this article, communication needs to happen from the very beginning all the way to the end.
A large part of the process is being able to understand the problem 150% and break it down into smaller pieces as a programmer does.
Get both parts familiar with tech and business terms to ensure everyone is on the same page, agree on one communication tool that works for both, and streamline meetings as much as possible.
At Appstrax Technology we follow those steps to ensure clear communication with our clients. If you value transparent and efficient communication, contact us. We would love to collaborate with you.
Follow us on LinkedIn and stay updated with our latest news!