Spend some time working directly on the front lines of tech startups, and you might notice a fascinating thing about investors, startup founders, and small company executives: they often have no idea how to tell good software from bad, nor competence from incompetence. Buyer beware!
It is all too common for a non-technical person to assume that the same web application that served fifty startup customers can also serve a thousand enterprise customers without investing in the evolution of the tech stack. They are not able to question the claims of their WordPress person, who says they can build a highly scalable cloud solution. They cannot easily tell whether the Golang-based product they have been funding will be very difficult to staff in their .NET-dominated local tech market.
In defense of non-technical folk everywhere, software development can be complex and difficult to manage. The software industry does itself no favors by adding chaos, confusion, middle management layers full of mountebanks, inconsistent terminology, and lack of standards into the mix.
So how is a business person supposed to know if they are being sold a bill of goods? Here are a few telltale signs.
Sign 1: The Smokescreen
It can be very intimidating to talk to a technical person. It is easy for a technical person to lay down a smokescreen of obtuse terminology that sounds just coherent enough to make sense, even if it is complete nonsense. It may be difficult for the layperson to understand the difference.
This is similar to an auto mechanic that takes advantage of the situation in order to make you think that the work is more complex, more elaborate, more involved, and more expensive than it really is.
One way to deal with this is to ask for a first-principle explanation of the terminology that is being brandied about. Some examples:
- Smokescreen: “The database needs indexing.”
- Ask: “Help me understand how that is relevant to our release being late.”
- Smokescreen: “The code needs to be refactored.”
- Ask: “Can you describe what net benefit will be achieved from this refactoring?”
A qualified technical resource should be able to enunciate the ramifications of technical decisions in your terms, not their own.
Sign 2: You Don’t Understand What is Being Built
They say a picture is worth a thousand words. This assertion is very true when it comes to specifying and describing software design, as I have written about here.
There is a well-known international standard for design notation, UML, which was made for the purpose of visually describing software design. Before UML, there were a litany of other design notations: Coad-Yourdon, Rumbaugh, Booch, and so forth. I developed software using a purely visual (no coding at all) notation called Software Definition Language (SDL) as far back as the 1990s.
The point is, many technical people are visual in terms of their communication style. A professional technical person should be able to make his or her point using any and all means at their disposal, including diagrams. If a technical person cannot draw a diagram to describe their own work, I would question whether they have a complete understanding of the topic.
Go ahead. Ask your technical point of contact to explain how they are going to make your product scale in terms of technology. You might not comprehend all of the words, but you should reasonably expect a diagram that will be helpful.
Sign 3: You Feel Alone
Your business probably has some unique complexities, some of which are drivers for the solution you are trying to build. Any technical help should be at least somewhat interested in understanding your business domain, understanding your customers, and understanding how you view the product or service that you are trying to build.
If your technical help is doing none of that, and you feel like you are alone on an island, you probably have the wrong help in some way or another. The relationship between business and tech is like any other relationship. There is going to be friction. However, if both sides try to understand each other, and take the energy or initiative to support each other, the relationship is that much better off.
Sign 4: The Goal Seems Misunderstood
Imagine you are building a house, and you are interviewing contractors. The first contractor arrives with a big cigar, a box of nails, and a hammer. “When can we start?” he says. The second contractor sits down with you and reviews the blueprints for the house to make sure that both of you understand exactly what is about to be done. I hope you choose the second contractor.
Similarly, nothing says “amateur night” more than a technical person that stampedes off to the keyboard to write code before they are clear on the goal. A professional technical person will try to re-state the objectives to you before any actual work is done. There should be an open and meaningful dialog about what success looks like, and what failure could mean to both sides. Often this involves early prototypes of the work, so that you can modify the direction sooner rather than later.
Summary
I’ve noticed that when non-technical people have a feeling that a technical project is not going well, there are usually some good indications that they are right. Pay attention to that feeling and get engaged with your technical team. If the above signs are there, you can understand and act on them.