Tech teams of smaller organizations, that are not startups, are often missing a difficult to perceive but very valuable skill: knowing what’s possible. That covers two similar concepts.

1. Knowing what tools exist or are likely to exist and being able to evaluate them quickly

For instance, just knowing that geocoding, Google Distance Matrix, PostGIS, or ACO exist. Given you know something exists, you should be able to evaluate whether it’s feasible to use it.

Furthermore, it also means either knowing about off-the-shelf solutions or being able to tell the likelihood that one exists. For instance, even though I cannot name a piece of routing software off the top of my head, I am certain that there are plenty of options to choose from.

Having a team member with this type of experience, or at least ambition, is crucial. It speeds up the IT strategy and moves it beyond building everything in-house and constantly re-inventing the wheel.

2. Knowing what type of problem is suitable for a software solution

It’s very succinctly described in this XKCD:

It’s the understanding of what kind of problems software can solve well and which problems are better solved operationally.

Furthermore, the ability to communicate whether a software solution is suitable is also crucial.

The most effective way to explain what’s not possible is to use real examples of what’s being discussed, rather than hypotheticals. It is also often helpful to follow up with what is possible. “Detecting a bird is not possible, but we can tell when and where the picture was taken, make of the camera and which way the person was facing.”

It’s often counterproductive to explain the technical detail as to why things aren’t possible. That doesn’t help the user or move the discussion along. The more important aspect is the consequences. “We can’t detect birds because image recognition is difficult and we’d have to build our own models” is useless. “Detecting things in pictures is difficult so it’ll be too expensive” is what actually matters.

Communicating what is possible, on the other hand, is even more important. Users often aren’t aware of all that tech can accomplish. For instance, explaining that information could be moved between systems is useful. Again, explaining the technical details of how that’d be done isn’t really helpful.