Category: tech, startups, internet

When I was a youngster, I would labor at the keyboard of our family computer trying to make it do as I said. You might say I “taught myself” how to program. What does that really mean? It means I learned by borrowing others’ code and asking the kind strangers of the internet (often on Stack Overflow) for help whenever I got stuck.

This long experience taught me never to underestimate what’s possible in the digital world. And this lesson came with me into the world of business.

Assume everything is possible until proven otherwise and shift the burden of proof to the programmer. Below I’ll show you how I do that.

Meeting Mr. Impossible

Early in my career, a friend (we’ll call him Bob) hired a programmer (we’ll call him Mr. Impossible) to develop a custom tool for his business. The tool was basic, but specialized: an order management system for Bob’s manufacturing business. Each item on an order had a price that would vary two ways:

1. Discounts for bulk orders based on quantity
2. Adders for certain sizes of product, regardless of quantity

One fine day, the programmer told Bob that building this functionality was impossible. Wisely, Bob sought a second opinion. Looking at the problem with fresh eyes, I recommended logic that surely wasn’t pretty but got the job done. Mr. Impossible scoffed that it, “looked like Excel logic.” He was right, for Excel was my default tool of choice in those days. But more importantly, he was also wrong – turns out it wasn’t impossible.

The bottom line: had Bob taken Mr. Impossible at his word, a critical function of his tool would be missing.

Never trust a programmer who uses the word impossible.

Now, Mr. Impossible was an off-shore, low-cost programmer. Frankly, that’s probably what earned him the job in the first place. But the US and other high-income locales are not immune from the scourge of impossible. I have seen this behavior repeated too many times to count during my career. So, I offer you this maxim: never trust a programmer who uses the word impossible.

“I.T. said it couldn’t be done!”

How does this play out in everyday businesses?

Someone whose specialty is technology says that the objective you want to achieve can’t be done.

Obviously, you want to give them the benefit of the doubt – this is after all his or her field of expertise.

At the same time, you can’t forget the maxim!

Uncover the Hidden Constraint

Ask your technologist to fill in the blank:

“This can’t be done unless ____.”

The unless is key here. There’s a constraint at play that the technologist is taking for granted. This constraint may be very real. But it may also be removable with your help! Unless forces the constraint to become explicit so that it can be discussed.

Constrained by Time and Money

Typically, the constraint is time, money or knowledge. Filling in the blank should make it clear to everyone. Only then can you make an informed decision about whether to work to overcome it.

If the constraint is time, maybe the team can direct more labor resources at the problem. While oftentimes more people do not equate to faster development, sometimes an extra pair of hands does just that! If the constraint is labor, can others pitch in? Can you solve this problem with extra funds to bring on additional programmers or other contributors?

My e-commerce company once had a project with a short deadline. We upgraded the way we stored product data, and then needed to bring our catalog of 30,000 SKUs up to spec quickly. We brought in a team of contractors for six weeks, demonstrating that sometimes it does help to, “throw bodies at a problem.” As a surprise bonus, we liked one of the contractors so much we decided to bring him onto our core team!

If the constraint is money, maybe the team can re-evaluate the problem’s importance. Should you redirect budget from other tech projects, or from other non-tech activities? Or maybe not, and the outcome is that everyone ends up clearer on the priorities.

Constrained by Know-how

If technical knowledge is the constraint, it can be a delicate issue. We simple humans bias toward defensiveness when our egos are at risk. First, seek to understand whether the necessary technology does not exist in this world today and must be invented, or merely doesn’t exist within the organization and must be acquired. Don’t neglect your own research, for Louis Pasteur taught us, “Fortune favors the prepared mind.”

If the former (invention required), you are probably barking up the wrong tree unless R&D is the mission of your organization. If the latter, however, there are many tools available to your team.

Every day, programmers help one another transfer knowledge on forums like Stack Overflow. If the knowledge is particularly specialized or particularly in-depth, hiring a contractor may be a useful move. At my previous company eComfort, we hired a contractor to help us configure and optimize our search server technology – this helped us get it done right the first time.

Hidden Differences of Opinion

Another potential reason your programmer threw the impossible card at you: he or she doesn’t believe the problem you want to solve is worth addressing, and also doesn’t feel like debating the matter with you.

If this might be the case, consider a different approach.

Creating software is a pursuit rooted in logic, reasoning, and problem solving. We nerds seem to love sinking our teeth into juicy problems! Try adding context to your request about why you believe the problem is important and interesting. Include details about the potential positive impact for the business, the user, or the customer.

Understand Context and Add Pressure

If you’ve ever watched a show about renovating old homes, you know that generations of infrastructure are often built over, used, and reused. Software can be similar. There may be generations of code debris, aka technical debt.

Encourage your programmer to consider the problem from outside the current codebase. Imagine a solution in a debt-free world, and maybe that inspires a new approach.

As the colorful General George S. Patton, Jr. once remarked, “Pressure makes diamonds.” Lest we forget, coal and diamonds are the same except for one secret ingredient: pressure.

Apply your own pressure to create diamonds in your organization. Push back on technologists, respectfully, by applying logic and posing questions to improve your understanding. The byproduct: sharper thinking all-around.

Agree on Outcomes, Then Get Out of the Way

While adding pressure, it’s also your duty to avoid interfering with the talent. Remember, you are not the technologist! Programming computers to do one’s bidding may be called “computer science”, but involves a healthy dose of art.

And as with most times when something must be created from nothing, the exact form will vary by artisan. You and your programmer should agree on outcome, and then you should generally stay out of their process.

One final maxim to keep in mind: “Always know if the juice is worth the squeeze.”

Just because something can be done, doesn’t mean it should be done! Invest the time to make sure the goal is well-defined and worth the cost.

---

Thanks to everyone who read earlier drafts of this post and helped improve it! Kim, Zach, Christian, Scott, Alex, George, and Raj.