Embracing incomplete information

I recently shared this thought with a colleague at work:

The ability to work with incomplete information is an underrated engineering skill.

Shortly before, we had been in a meeting with other software engineers, UX designers and product owners, to discuss the requirements of a solution a client had asked us. Some of those requirements were clear, and we only had to agree on a couple of small details. Others were still pending to be confirmed by the client, and we were not certain how to move forward.

What struck me was how people behaved when they didn’t have all the information about the problem. Some accepted the reality and were okay with doing exploratory work and solving the remaining elements incrementally. Others preferred almost perfect specifications before implementing anything. A third, more adventurous group (if not a tad irresponsible) was fine to just go with the happy path and see what would happen.

This made me think about the role that software engineers, and to some extent UX designers, play in problem-solving at this level. I understand that we can feel uneasy or overwhelmed when facing problems with many unknowns. But it shouldn’t surprise us when product owners, whose role is usually to “bring problems” worth solving for the business, also feel frustrated if we constantly ask for unambiguous and detailed information1.

I sometimes wonder if software engineers focus so much on the parts of the profession we love, e.g. programming, that we forget we have a responsibility to contribute in other areas as well. Getting a detailed list of specifications and spending time coding in our favourite language or technology is great. But if we settle just for this, our value to the business decreases. Software engineering is much more than programming.

That’s why I said to my colleague the quote at the beginning. Being able to provide solutions, or at the very least a way forward, even when we don’t have all the information, is a skill that we as engineers don’t seem to value enough. But other roles certainly do, and will. And collaborating with them will make us stand out and give us a competitive advantage.

  1. Adrian Kosmaczewski framed this tension between developers and product managers more generally in The Impossible Dialogue