The Language All Polyglot Programmers Should Know: Business

You can leap buildings with a single C++ statement and you can move faster than a locomotive when it comes to Python, but when it comes to speaking the language of business with the executives, it becomes your kryptonite! We are all masters of the universe when it comes to our domain of software development but we just can’t seem to get the hang of translating why something is cool or needed to those guys over in the plushy offices. They simply don’t think like us. But hey, they are the ones with the money and so we have to make speaking business another language we must learn. Here are a few tips to help do that.

Tips for Speaking Business/Business++

• Lesson 1: Tie everything to the bottom line – Business guys understand money. When you say that implementing your fabulous and wonderfully leet project is the way to go, they want to know why they have to implement it and how it effects the bottom line of the company. So before approaching them with an idea, show how implementing your changes are going to make them money. This can be done by explaining how it would generate revenue, cut costs, increasing the amount of work that can be done in a given time (productivity) or improve the quality of the products/services that can help them snag bigger customers.
• Lesson 2: Keep your emotions in check – It is ok to get excited and passionate about a new project or how you can make the company oodles and gobs of money. But despite the excitement most business people want to see a sound logic from start to finish. Ok, you want to switch the product from a VB.NET base to a C# one. Why? This is where it helps to list several advantages and disadvantages. Don’t sugar coat it. If the advantages far outweigh the disadvantages then they are usually interested.
• Lesson 3: Keep the jargon out of it – Even if the business folks are technically inclined they may not know all the latest buzz words or technologies like you do. Even if they do, just keep it simple. Why complicate things and possibly get a “no” just because they feel like they don’t understand your solution? This makes your proposals seem like a “no brainer” and that “even a child could do this”. By keeping the lingo out you are going to make things clearer and straight forward for business people to see how all the pieces fit together and construct the “road to riches” in their mind for your project. They also want to know how to explain it to their big customers they are golfing with next week.
• Lesson 4: Be a master at speaking with analogies – I can’t tell you how many times I have spoken with an executive, talking about an API, and watch their eyes glaze over. When I then mention that it is a service that applications can talk to like a bank teller executes services on my behalf at the bank, then they come right back to the table. They get the idea of someone doing something for them… like a bank teller. Now they know the general idea behind an API. The bank teller is the interface of a bank’s API.
• Lesson 5: They may say no now, but what about later? – Even if they say no to your ideas now, never keep the idea too far away from their minds. When you are working on something, perhaps completely unrelated, show them that even though the system gained 10% efficiency, your earlier idea would added even more value. The trick here is to remind them of the earlier project, provide them real world examples of how your idea can be applied and quantify results. They may come around after seeing how things would have been better and keep it in mind for a future project.
• Lesson 6: Stats and charts are your friend – Nothing speaks louder than a few pictures. You can say something saves 55% more money, and that is fine, but when a pie chart shows even a sliver over the half way mark they think “Wow! That is a lot!” They also love line / bar charts that start low on the left and increase as they move right… when it comes to revenues and productivity not costs.
• Lesson 7: Use sources that are respected in business – If you are going to talk to business guys about your idea, don’t be afraid to quote your sources and make sure they are high quality sources in the business world. If you can show your new CMS concept will improve productivity by 23%, quoting the source as Berkshire Hathaway (perhaps a user of the CMS you want to implement) is better than joeschmoe.com that has a site designed for IE 6 users and records a whopping 10 users a month in traffic. Sometimes the fact may not be very strong but gosh if Warren Buffet’s company is using it, it must be good!
• Lession 8: Keep the company fiscal year in mind – If your company is busy trying to close out its last quarter of the fiscal year in July, it might not be a great time to try and roll out a change that costs money. If your company is publicly traded then you can watch this more closely but always keep in mind when it is a good time to propose change. Let the business person know by saying something like “I would like to do this project, but knowing we are closing out the quarter, we can look at this next week when the new quarter begins.” Let them know that you have the company’s financial interests in mind and that your change is not meant to rock the financial boat. You are considering the business needs in your proposal.
• Lesson 9 and most important lesson: Never over exaggerate the numbers – I say this because you never want to be caught in the position where they ask you about a figure you are throwing at them and you either have no answer or can’t arguably justify the soundness of a stat or point. It will kill your whole momentum and can label you for future proposals. If the numbers don’t show what you want them to show, then perhaps you are looking at the wrong numbers or perhaps you can alter your project a bit to achieve results that will impress. It is ok to change an idea before you present, not when you are in the middle of presenting.

By using the language of business to help articulate programming project ideas into something a business person can understand, and more importantly RELATE to, the better chance of getting that god awful version of PHP 4.0.1 from the year 2000 off of your production site and upgraded to something that reflects 2013. Stay rational, tie it back to the bottom line, show the advantages outweigh the disadvantages and it is hard to say no. Even if they do say no, if you keep tying current projects back to your idea, over time they may see the benefits more clearly.

Thanks for reading! 🙂