The learn to code movement is all the rage these days, as it increasingly becomes common knowledge that being one’s own technical cofounder is the only path to getting a product off the ground.
While I agree in Marc Andreessen’s famous quote that there will be only two types of people in the working world – “those who tell a computer what to do and those who are told what to do by a computer” – I think there is another reason for business founders to learn to code: it can make you a better business developer.
At the end of the day, writing code and running a business are both forms of problem solving. Taking a huge problem and chunking it into bite-sized algorithms requires a similar approach to breaking down big business challenges to identify the many paths to a favorable outcome. Having a thoughtful approach on how to identify and distill challenges down to a manageable (and solvable) problem is a skill that transcends any single discipline.
Programming is a convenient way to learn the skills of taking a massive problem, breaking it down, and solving each piece a bit at a time. Here are some ways that the coding can help you when pursuing partnerships, sales, or thinking through the strategic options to create growth for your company:
1) Think from another perspective
A classic lesson in any introduction to computer science is the “PB&J challenge,” which asks students to clearly describe the steps in making a peanut butter and jelly sandwich. While there are dozens of variations, the key to the lesson is that it forces students to separate themselves from the problem and think from the perspective of the computer. Computers don’t understand instructions like “spread the jelly on a piece of bread,” so the task requires students to think about how they’d articulate each step: “Extend right hand 2 feet towards table, place fingers on knife, contract muscles in fingers to grip knife, turn 90 degrees towards jelly jar”…
In business development, it’s easy to get wrapped up in our assumptions of what will be valuable to a prospective partner or customer. Just like in programming, successful BD requires us to step outside of our own heads and understand the perspective of the other side. What matters to them? Why should they care? What information will they need in order to solve their problems?
Learning to code forces you to think from someone else’s perspective (the computer’s) and design a solution that meets their needs while also fulfilling our own goals. In BD, we must similarly ask “How can I design a solution that clearly creates value for the partner?” before any partnership or sale will come to fruition.
2) Identify several possible solutions
Programmers look to each other for help, using tools like StackOverflow to ask questions on the best approach to take to any given coding challenge. A tricky bug in your front-end design is making your site look bad? Ask StackOverflow! Just be prepared to be overwhelmed with possible solutions.
There are many ways to skin a cat with code, and the same rules apply in business development. A key tenet of good negotiating skills is to create as many options as possible, as that provides more opportunities to find a solution that fits the needs of both sides without needing compromising on what matters most.
With sales or partnerships, it’s rare that there will be a one-size fits-all solution to any problem worth solving. Any prospective partner or customer will have their own perspective on the best way for them to pursue the value of a growth opportunity. Taking the time to create and explore all of the potential ways to create long-term value for both sides of a partnership will help drive deals that matter and last.
3) Hack first, improve later
There is a saying in certain schools of thought around programming: “Do the simplest thing that could possibly work.” It’s a statement that fuels the hacker mentality of not over-engineering solutions and instead to focus on shipping code that works “well enough” quickly.
In business development, it’s easy to overcomplicate a deal. The more ways we try to maximize upside, mitigate risk, protect our long-term options, and generally play games in a partnership negotiation, the harder it will be to pass through the filters of the Organizational Mind and get the buy-in needed to move forward.
Sometimes the simplest solution in writing a program is something quickly hacked together and put into action. That allows you to plug a hole and move on to another pressing problem (and you can always refactor the code later, if needed).
The same rule often applies in BD deals, as sometimes the best road to take is the path of least resistance. Cutting down the scope of a partnership, shortening the term of a deal, or even focusing on just getting a pilot deal done before a longer-term (and more complex agreement) is in place can provide an easier pill for a prospective partner to swallow. Getting a simple deal done can provide a platform for expansion later, as you build upon your existing, simple partnership to scale the deal further.
I taught myself to code when I was a teenager and started my career as a Java developer. My transition to the business side was predicated on the same underlying concepts that I learned on the technical side. BD and programming follow parallel paths on the same course – learn to code, learn to problem solve, and you can learn to do better BD.