At Def Method, we work with many non-technical business leaders as well as technical team members and understand that it can be difficult when the two groups don’t “speak the same language”. If you’ve found it challenging communicating with your engineers, you are not alone, and we’d like to help. Here are some tips on how to improve communication with your engineering team and streamline your development process.
Just like you have skills that help you shape product strategy, the engineers have skills that help them build the product. Remember that just as much as the language they use may sound foreign to you, your language about product strategy may sound foreign to them.
If you had thought something should be “easy” but the engineers do not, ask why. You may find that there are friction points that you can help resolve. These might be process improvements, organization improvements, tools or equipment that needs buying/upgrading, or training that needs to be done.
If you’d like to know more about something in their work, ask them to explain it. This has two benefits: 1). you learn a bit about their work, making communication smoother and 2). you find out which engineers are good explainers. The latter is a very valuable skill for an engineer.
At the same time, be open and willing to explain your work to them. You may find that they are interested in how you do your work. It will improve communication. Furthermore, when engineers understand the business behind the product they are building, the quality of the product will increase.
Try not to create roadmaps and plop deadlines in front of your development team. Instead, work
with them to create estimates and milestones. Deadlines imposed from above will not incentivize all people and may backfire, leading to work slowdowns/work-to-rule behavior and people leaving your team. Additionally, setting a deadline that that is too tight may lead developers to believe that cutting quality corners is desired. Setting a deadline too far out may lead to Parkinson’s Law (“work expands to fill the time allotted”).
When you want to know when something might be done, ask for estimate ranges. A single date is unlikely to be correct. A range should also have some form of likelihood for both ends. Work with the engineers to determine what amount and type of padding they have already included. They may have left out standard padding used to take into consideration holidays, vacations, or sick-days. As engineers do their work, they will get a better idea of how difficult the work is. They may find places they thought were hard but are easy and vice versa. So periodically ask for updates to the estimate range. If the estimate ranges do not fit within needed dates, work with them to refine scope, find blockers/friction points to remove, or change the needed dates.
Do not demand that they just work faster.
There are always pressures from above you in the orgchart. Let the team know about these. Then work with them on how these pressures can be addressed and removed. But do *not* simply let those pressures flow through you to the team, protect them.
Watch out for engineers complaining about existing code and the "need" to rewrite it. Often engineers think that rewriting existing software will solve a host of problems. But it can be very costly and must be done carefully.
Ask what your development team needs to improve their skills (technical and otherwise).
If you do not help your team become better, they may not do it on their own. Software development is a complex and ever shifting craft that requires continual learning from your engineering team. By giving your engineers the time and budget they need to continue to grow as a developer, you are ultimately investing in the quality of your product.
In conclusion, your team is made of people not resources. The key is to communicate with each other and build an environment of safety where people can work collaboratively, teach each other and learn from each other.