In the exciting fast-paced world of technology startups, communication failures between different departments can spell disaster. As the founder of a company that builds software to streamline and optimize communication on teams, I know subjectively and from customers, that this problem is pervasive between technical and nontechnical teams.
And the communication gap can’t be bridged with project-management software. Basecamp, Trello and other scrum platforms are amazing, but the kind of communication breakdowns I’m talking about run deep. It’s almost as if one party were speaking English and the other Japanese, and all are tossing their heads in misunderstanding.
But don't send a marketing guru to night school for computer science. Some clear and easy ways can prevent company initiatives from becoming lost in translation.
Related: The Two Words Steve Jobs Hated Most
1. Startups must be agile. Sometimes creative staffers have only a vague idea of what they want and the product evolves as it’s being built. Really diligent and aware nontechnical employees will set expectations for what things are most important. They will delineate nice-to-haves, must-haves and what to avoid.
Software can be built in many different ways. Knowing ahead of time that it should have the capability to be easily modified helps developers tremendously. When a nontechnical person communicates which product features or designs are most likely to change and those that should be set in stone, the expectations for malleability are set.
The engineer can then be forward thinking about how to approach the coding. Think about designing a house. The door is set at the entrance, with only tiny allowances made for materials and aesthetics. The windows, however, offer more opportunities for variation -- in size, shape or position. When the creative team explains that a certain software feature should be the equivalent of a window and not a door, builders can invest the right time at the outset in designing and save time on adjustments down the road.
2. The why is as important as the what. Providing a vague description of a desired design or functionality is a starting point. But scenarios and use cases add a ton of color to an idea. At my company, a team member requested changing an application so that employees could be able to edit a report after a manager's review. The requester thought this would be a simple change, until the engineer pondered it for a minute or two and came up with four possible interpretations.
When a goal is specified as well as a detailed flow chart for proposed user activity, the developers can think of different scenarios and arrive of options beyond the original proposal. They can raise objections on a cost or time savings basis.
Related: How Thinking Like a Hacker Will Grow Your Business
3. Try thinking like an engineer. Technologically challenged employees can learn to make things way easier on a software development team. Going through the following iterative process will enable them to conceptualize their problems in new ways and think more like engineers:
Consider all the angles for the functionality or feature desired.
Succinctly describe how it should work and the reasoning behind it.
Provide a prototype or schematic or even chicken scratches on a napkin.
Offer screen captures and a link to already existing products with similar functionality. Developers can glean an enormous amount of information from the work of others that will help them decide where to start the project.
4. Find that common language. Creative employees can overcommunicate and essentially try to write the program for the developers in English instead of code. While their intentions are good, developers find trying to translate these messages quite time consuming and frustrating. When there's effective collaboration and communication across teams, developers feel less frustrated and more highly valued by their organization and satisfied by their work.
Think through what's needed and why. Then communicate it as concisely as possible. A good creative person explains his or her needs in a way that leaves few unknowns unresolved. A good developer is then able to think about how the user will perceive what is being built.
No collaboration tool can replace staffers' spending time together and talking about things. Paint a picture of what's desired and how it will be used. Elaborate on the greater business goal. The developers can extract insights to build something that will delight customers, and every employee involved will gain a sense of personal fulfillment and team camaraderie.
Related: Developers Are in High Demand. How Do You Recruit the Best?