When developers are not in the same office as business operations, the communication between business and developers is seriously jeopardized. You can’t just walk to the developer/designer and explain what you imagined by waving hands or using body gestures.
Shutterstock
Without clear communications, people tend to assume what the other party really wants, but our assumptions can easily go wrong.
I have been working with remote teams for the last 20 years. I’ve been on both the business side in CEO roles and the development side in CTO roles, and I’ve worked with remote teams that were all in one office as well as with remote workers who worked from home, scattered throughout the country or even internationally. Here are a few key lessons I’ve learned in the process for improving communication across the organization.
How To Really Integrate Developer Teams In The Business
By nature, a business team and developers have two very different goals. Business needs a rapid development of features that will generate revenue, while developers want to work on interesting and challenging features or optimize and perfect their code. These goals rarely align.
If not handled correctly, this situation will make developers start blaming business for all of the issues they are having (e.g. a system crashes and developers need to spend extra hours fixing it; they will blame the business team for not allowing them the time/resources to do their job and code properly).
On the other side, business will grow frustrated with all the bugs as they can’t possibly make any revenue when the system keeps crashing all the time.
I have seen this happen in almost every organization I have worked with, and the best way to solve it is by improving communication, but the improvement must come from both directions. Leaders on both the business side and the dev side need to come together and understand each other’s goals, and they should understand that they actually have a common goal — to make the company grow.
The business team needs to understand the issues that dev team is trying to solve, as without great tech, it will not be possible to run the business. On the other side, development teams need to understand the business consequences of their actions. Developers are more accommodating and team-friendly when they see the big picture.
I have found that on-site visits help. Don’t wait for a specific reason to get your developer fly to the business office. Rather, add it to the costs and have someone from the team visit at regular intervals. If nothing else, this will help everyone feel like they are part of the same team, and the cost spent on travel will make the teams more cohesive, which will indirectly result in higher revenues.
How To Tell Your Developers What Needs To Be Built
So it’s clear that communication between your business and development teams is vital in helping the company grow and ensuring both teams reach their goals. This comes to the forefront on projects. When working with remote development teams, especially those in different time zones, you can’t give them half-baked ideas. Otherwise, they will either just come back with more questions, or they will make assumptions and build things in a way you didn’t intend them to be.
Through years of refining the process, what I’ve found works best is for every feature to go through the following steps before development even starts:
- Business Requirements
This is where business will define what needs to be built and why. The business team will create a document with a list of requirements and/or user or system behaviors.
- Include A Senior Tech Person In Your Planning
Once you have put general ideas in your requirements doc, you should send them to your developer or product lead. They love to be included in the planning phase and will also continue building on top of your idea. They will come back with additions, questions and ideas.
- Create Wireframes, If Needed
Once the requirements are finalized, if the feature includes changes to the user interface, it is best to create the wireframes. This process will include all of the possible scenarios and make sure that the software is easy to use. Wireframes will also ask the business to finalize all text.
- Tech Planning
With requirements and wireframes completed, most of the questions should be already answered. This is a perfect time to get ETAs from the team and decide if the investment in time and money will be really worth it. In tech planning, the specific tasks will be created to complete all the required functionalities. Well-organized teams will always have a few projects backlogged that are fully planned out with all the documentation.
Communicating Priorities
Imagine a developer getting up in the morning and finding multiple emails from a member of the business team. At that moment, the developer needs to select one task to start with. Even if all of them are important, one developer can work on only one task a time.
Tools like Trello are awesome for this. Just make sure that all tasks are in Trello and ordered by priority from top to bottom. Business members can also choose to mark specific tasks as high priority.
Evolve Your Process
Whatever process you start with, make sure to re-think it every few months. No process is the same for two companies as no two companies are the same. Start with something, test, make changes, test again.
[“Source-forbes”]
