Making Technical Decisions

In any moment of decision, the best thing you can do is the right thing. The worst thing you can do is nothing.

— Theodore Roosevelt

The last few posts have talked about expressing requirements in business terms and also insisting on getting information back from Engineers in terms of the impact in business terms. What you will start to realize is that, as you help arbitrate between technical options based on their business impact, that almost everything dressed as a technical decision is actually a business decision. Let me re-iterate that for emphasis (because I know from uttering it out loud many times that it doesn’t initially sit well with Engineers):

Nearly every (meaningful) technical decision is a business decision

I don’t imagine that I need to explain why this seems offensive to Engineers. I add the adverb “nearly” since there are a few exceptions (we’ll discuss them later). I add the adjective “meaningful” because there are many technical decisions that are just technical decisions. For example (and these will make sense only to Engineers, who might be sneaking over to this part of the site to see what I am telling you business people):

• The name of your method, variable or database field
• Whether you use a for or a for.each
• Whether you use big-endian or little-endian
• How many decimals of ∏ you need to accurately calculate the circumference of the visible universe? [1]
• And so on…

But many things that Engineers think are solely technical decisions are not. Here are some examples:

• The team is choosing between two JavaScript UI frameworks: one is more widely used and supported. This can have many business implications, including how easy it is to hire Engineers who know that framework, how many pre-built components there are (which can save time for your team), etc. One might be more widely used by your Customer base (if you expose the framework as part of your technology).
• The team is deciding between two databases: one open source and one that is licensed. The choice of the licensed one can cost the company or their Customers a lot of money. On the other hand, the open source one might not be well supported and if your Customers are banks, their IT team might not accept technology using that database.
• The team is deciding on whether to solve a requirement by writing code that handles only the currently-known scenarios or anticipates future ones. If they focus on the immediate needs, the code can be written very quickly. But on the other hand, it might be better to spend a little more time now and handle medium-term requirements to save time (and money) later. But, back to the first hand, if the Engineers over-generalize, it could take forever and still not handle the future scenarios.

Trust me that you can throw just about every significant technical decision at me and I can explain why at least aspects of it (and very often the entire decision) are really business decisions. Again, as a business person, you need to use this to bolster your confidence in demanding to know the business impact of the technology issues and decisions. If you’re an Engineer (and sneaking into these posts), embrace this – business is not a dirty word and your grasping of it will make you a more effective Engineer.

This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker

Footnotes:

[1] It’s 39 digits to calculate it accurately within the width of a hydrogen atom. NASA only uses 15 decimal places for most of its calculations. Sadly, I have never needed to use ∏ or, in fact, any of the Calculus or Algebra I took in University in creating all the software I have been involved in over the course of 29 years. Sadder still, the very expensive 8.5 x 11 inch paper I received at my graduation says “Bachelor of Mathematics”.