As engineers and engineering managers our minds are wired to build. Give us a problem statement and we will get on solving it. This force is tremendous and makes us very successful at what we do. However, while building or even before building, we are risking to deviate from the originally-intended user’s purpose of the project. We can deliver something perfectly working, but for a non-existing customer.
What is perfection?
What is perfection anyway? A flawlessly working mechanism? Something that is infinitely flexible? A work of art or a work of science? I think the more we consider the word, the more it starts to deviate from our objectively considered engineering model and moves more into a realm of art and interpretation. As I have spent more time in the world of engineers and their customers, the more I started to conclude that the definition of perfection really belongs to the users. We try to think that as long as we make something shinier, faster, smoother, longer, shorter, we will inherently make it better. However, if that is not how the product will be used, then all of our efforts will be in vain. Let me share a short story, which depicts the disconnect that I am trying to highlight.
Story Time
It goes something like this. An aspiring engineering entrepreneur travels in Nepal and checks out various projects that are happening there. He happens to stop by a Buddhist monk monastery as part of a side attraction. He witnesses something strange. As he walks through the compound, he sees a lot of monks doing manual construction work - digging, chiseling, carrying water, etc. What intrigues him is that all of this labor happens manually and without any automation. Right away, his engineering mind jumps into action and he can’t wait to share it with his guide, who is also a monk. He asks, why don’t you use all of the automatic tools? They will make the work very easy and fast. To his surprise, the monk replies that this is the point. Monks want to fill the day with productive work and meaning and if we start using automated tools, then we will run out of work very fast. It is our preference to go hard and slow.
This non-intuitive approach to labor brings us to the concept of unique needs that our users have. We, as engineers, sometimes tend to interpret what is being asked for something that needs to be optimized and perfected to our own liking too. While sometimes a healthy dialogue is useful to narrow down the requirements, it is important to know when to listen to our internal engineering voice. While the voice is well-trained from an engineering standpoint, it might not yet have developed itself to dissect the true purpose or meaning of the user’s request and how we decide to execute it.
Healthy Dialogue
So what can we do about it? How can we nurture a dialogue with the users that can raise up many possible points of friction? The most important step is listening and not jumping to conclusions and keeping your engineering mind at bay. That mind is ready to jump on the user at any moment to tell them how impossible the task is and how technologically incompetent the user might be. Does not sound like a friendly relationship right?
A more collaborative way is to resort to open-ended questions that help uncover more meaning and purpose in the product requirement. Questions like, “Can you walk me through the user’s journey in this scenario? Step-by-step?”, “Can you expand on this “magic-happens-here” concept?”, “While I understand that you have a huge trust in us to build a time-machine, what are the alternative implementations that you would consider?”. This type of language facilitates better understanding of where the users are coming from and helps us to optimize our engineering minds towards a common goal instead of a statically engineered one.
What are some other techniques that could be used? I am sure most of you are familiar with the concept of sprint and scrum. However, what I want to highlight is how the concept of iterative development allows us to deliver products to the customer that they truly need. Now, I will say something that might be a bit intuitive, but it is true. The customer does not always know what they want, but they know that their feelings directionally are right in the moment. Our responsibility as engineers, through interactions, to make the tiniest steps possible towards chiseling out the eventual product that aligns with what the customer wants. Customers are also on the same journey as us discovering what needs to be built. We are there to guide them through to what is possible.
Not building
As part of that journey, it is also a good idea to step back and consider whether anything needs to be done at all. Yes, we are wired for building, but not-building might also be a solution. Why do we need to optimize something that is working perfectly well for the current and also predicted set of requirements? Do we expect the capacity to exceed the current limits? What are the additional benefits of additional development? What is the goal of the additional implementation?
Conclusion
In conclusion, I want to reiterate that there is the world of the user and then there is the “perfect” world. This perfect world is not everybody’s world and differs accordingly. Don’t fall in love with your model of the universe. Most of the time you are building for someone else who will be using your engineering. Think of what they will need in that world, what is important for them, what kind of questions can you ask them to highlight their needs. This guidance will help you find a much better fit in your team and organization, but also will help you decide when to apply the most energy of your engineering mind. It is very powerful when active, but should be supervised. Yet, please don’t hesitate to optimize something for yourself when nobody else is involved! Happy Building!