Entrepreneurs Are From Mars, Developers Are From Venus
We loved this article from Adriana Galue, which provides a Manifesto to tackle one of the most common shared pain points for entrepreneurs: communication (or lack thereof) with web and software developers. Sometimes it feels as though you and your developer simply come from different planets! It's not just an issue of language but communication style too. If you can relate to this, perhaps sending Adriana's Manifesto to your developer might help to ease the pain! And we wonder, if we asked our developers for a similar document, how would they ask us to communicate with them?
This month, I have been actively interacting with software developers. After attending a conference about Ruby on Rails, the importance of communication in the success of any startup became very clear to me. If you don’t know Ruby or Rails, no worries. Programming is not the subject of this post.
Most software developers at some point or another end up having to learn how to effectively interact with customers.
As it turns out, when someone commissions you to do a project, the success of it depends predominantly on how you communicate. Freelancing and consulting takes much more than just knowing how to properly code.
Critical communication elements include knowing how much information to give and in what format, when to stand up for what you believe on and when to concede. Ultimately, proper communication entails learning how to give an explanation that involves code or any other technical concept.
A consultant (you) is someone who does “things” that “shouldn’t be this difficult”. As such, if someone approaches you with a problem, you are there to provide a solution rather than to amplify the problem.
Although this concept seems pretty obvious, many fail to implement it. If you present too many options to solve a problem, your client will inevitably pick the most complex option presented. It is the nature of the consulting business. As such, it is critical that you learn how to present the most appropriate implementation based on a cost/benefit analysis. If your client only has $40K for a project, it doesn’t matter whether the best solution is one that costs $100K to implement. Solve the problem within the available budget and forget about the optimal solution. If you still think that presenting more options is better, try going to the grocery store and standing up for one minute in the cereal aisle. Our brains have not yet evolved to effectively choose between 30 different cereal brands. I still always choose Corn Flakes.
Concentrate on big picture business objectives. Don’t let the client get caught up in the small details.
Presenting too many options as potential solutions to a problem leads to an over focus in the details.
3. When a client comes to you with an obsolete solution to the problem you are trying to solve, using the phrase “no, you can’t do that” will only upset the client. In consulting, framing the use of words is critical. You need to learn how to use “yes, let’s try it” and modify the context of the problem. If a client requests a website with 10 functionalities within a menu and you know that budget only allows for four of those functionalities, just re-frame the problem that your are trying to solve so that its solution fits a menu with four functionalities. At the end of the day, it’s all about being positive. It’s all about offering smart alternatives.
Clients want to have a sense of what is coming next. Explain the process clearly and walk the client through the different project phases.
5. When giving an explanation that involves technical complexity, always begin with the big picture first. It is critical to always present a context setting prior to getting lost in the technical details of the solution you are presenting.
6. Have a plan before trying to explain a concept. Explanations are like software development: they require an agile structure. In agile, you write code, you measure, you fix bugs and you repeat the cycle. The same happens when explaining a concept. You give a short explanation and then measure whether your listener understood what you said.
An explanation has failed if your listener remains silent, gives you a blank look or asks the same question using different formats. If the explanation has failed, you need to fix the bug and explain again.
Effectively communicating an explanation is the responsibility of the speaker.
7. Most technical explanations fail because they have a gap within them. The gap exists between your words and how your listener internalizes information. From a neurophysiology standpoint, you only have about a minute to convey critical information. As such, if you get lost in jargon and in explaining complex concepts first, your listener will be mentally gone by the time you are done.
The success of an explanation depends on your ability to understand how your listener grasps information. Not everyone is created equally.
8. Successful explanations:
- Emphasize the main idea and provide context. Think big picture!
- Don’t use jargon
- Present critical information in the first 30 seconds
- Present complex information last (if at all)
- Use, if at all possible, some sense of humor!
Based in Boulder, CO Adriana Galue, started working with web startups following a career in Neuroscience. She is truly passionate about technology and entrepreneurship. In addition to owning a consulting company, Adriana teaches seminars in entrepreneurship applied to technology in several South American universities.
Prior to becoming an entrepreneur, Adriana worked for 10 years as research associate and scientist for both the academic and pharmaceutical sectors. During her scientific career, Adriana co-developed the pre-clinical studies of Kalydeco, the only treatment available up to date for patients suffering from Cystic Fibrosis.
Sign Up to our Newsletter
So you enjoy The NextWomen. Why not sign up to our monthly newsletter?
You get a Letter from the CEO :-), the chance to catch up with the best of our recent articles - and some extra things we throw in once in a while.