On building humility in software : the software we will build will end up building us.

“Learning and innovation go hand in hand. The arrogance of success is to think that what you did yesterday will be sufficient for tomorrow.” —William Pollard

It’s often the case with companies that get customer centricity and user empathy, so loud and clear in their user experiences & products that we as users/customers remark in awe, because it makes the experience so seamless, that we don’t even notice it being there at all. The best products then, are invisible, much like humble servant leaders, who orchestrate and align the team towards shared goals

That’s what great products are - Humble & Servant leaders. Because they lead with the user first. And, in this post, I will talk about my experiences/observations of what gets in the way of building such products, and two powerful questions you can ask, to get it right.

 First, It is no coincidence that the customer centricity gets baked right into the heart of some of these great products, because it is the way of a firm’s protecting and cultivating it’s core tenets . It is that knight, that holds all guards, and will go at all odds to find the common ground to do what it takes to get it right. And that becomes the normal way of getting things done.

 It’s like the David of the Renaissance period (Michelangelo, Circa 1500) , that epitomises the fundamental shift in developing perspective that becomes the new age of enlightenment and re-setting the baseline for the products & services we offer.

As you get Senior, and are involved in the fundamental trajectory of a software's evolution, your role in design becomes more than just transactional, and getting things done. If you have worked over a decade with Engineers, you will quickly realize that they are problem solvers, the left brain folks - mathematics & logic, yet so many times they forget that what they are solving for is a Business problem first. Technology is just an enabler to solving it more scalably, and cost effectively.

Here’s what solving a Technology problem(and not the underlying Business problem) sounds like -

1. “We are building a feature X, but we can’t/won’t quantify how it will move things because it’s too expensive to instrument it”
2. “We (already) know why we need a feature, so let’s get to solutioning (and be done with this)”
3. “We already have a similar solution here, that we may retrofit”
4. (Worse, still) “This is how we have always done things”

And, the single most powerful question you can truly ask yourself is “Why are we doing this, and why now? “

In fast paced environments, mindful design and the "Why" is often seen to slow things down. The hidden cost though is that, as you become senior, people look more up to you cues, so you shoulder the responsibility of the Knight. They will emulate you, and set the spiral which ever way you go. You define what “done” really means, and at what stage. You define where you can give the team some slack, because we make tradeoffs all the time and it would be unfair, even deadly to the firm’s growth, to have a purist perspective.

In fact, some of the very principles of lean and building incremental products are not at odds with spending time on the “Why” . So, let’s park the compulsion to get to how, till we are convinced on the why as a group. 

A healthy debate is not to point on someone’s rigour/pre-work of a feature, or functionality. It is so that we build a better, more mindful software and are aware of the Business it is trying to model. So, that we cover the edge cases, we may have overlooked, identify the breakpoints and limitations of the software and establish the clear boundaries on acceptable Business deliverables. 

Socrates himself, taught to learn by asking - and that became a gold standard for many institutions incl. Harvard Business school, in its Business case study format of teaching .

If there’s so much to be learnt by asking questions - why don’t all organisations do it ? Simply because -

1. People ARE organizations.
2. It feels uncomfortable, because we have been ridiculously tricked into believing in middle school that knowing answers is all that matters to any question that's asked. And, so no one wants to live through the ambiguous state of not-knowing, how something will unfold.
3. People take it so personally and mistake it to be reflective of the depth of their work.

All of these are blind-spots that most people aren’t even aware of.

That got me thinking, so what is a humble software platform anyway ? A humble software is much like any humble person you know. It is grounded in it's security of the market space it is going after(.. Which is not every "user persona" to start with), and self awareness of the technical limitations it has, both functionally & non-functionally.

Ashutosh Garg, whom is one of the most humble leaders I have had the pleasure to observe, and work with, used to say -

“ In a room with super smart people, either you know something they don’t, or they know something you don’t”.

Because it grounds you in humility and accepting our collective differences in the cognitive range of motion respectfully.

Now, the second question - "Is this the best we can do ?"

Steve jobs had this classic “ Is this the best you can do?”. In 1984, ahead of the Super bowl XVIII , a busy frenzied team was working with Steve jobs to shave off some seconds from the booting time. His vision was asking a simple question“ How many people are going to be using the Macintosh? A million? No, in a few years, I bet 5 million people will be booting up their Macintoshes at least once a day. Well, let's say you can shave 10 seconds off the boot time. Multiply that by 5 million users and that's 50 million seconds, every single day. Over a year, that's dozens of lifetimes. So if you make it boot 10 seconds faster, you've saved at least a dozen lives.”

Jobs concludes by saying, “So it's worth it to cut another 10 seconds!”, and the team was successfully able to deliver to his vision and (reproduced verbatim from Power questions, Sobel, Panas, 2012 )

In fact, Steve was once asked in an interview what his most amazing product was, to which he replied, "the team at Apple".

Practical examples are enabling a power functionality to users, but giving them tools outside of the core tool, that they must navigate to to find what it means for them (eg : calculating shipping , other taxes ) in disruptive flow. What ever happened to user-empathy, and principles of least common knowledge ? We need to address the frontier for what separates great mindful products and teams.

 It’s like an impulse response (much like GDPR, all the digital privacy wave, demonetisation in India) - that push the limits of taking the journey. It’s feels uncomfortable to the cohorts in that pipeline, but it is a journey we need to take.

..Because we have the moral responsibility to leave the world in a better place than we started with, and to up-level ourselves in the process, and push the frontiers of the humanity's cognitive range of motion.

Software is not built in vacuum. There are business realities, trajectory changes. The design has to be logical, feasible, cost-effective, scalable, and intuitive to multiple levels of the technology organisation .

Parting note - Not every firm has the same risk-appetite and financial muscle to fail-fast, but the core tenets on experimenting, failing, repeat, re-tuning hold true of every situation - and that starts with right instrumentation and the culture of healthy, respectful collaboration, and learning by asking.

Be that ugly duckling if you have to. Not the whistleblower kind of ugly duckling. But one that’s continuously shouldering responsibility for what it’s obliged to do - doing the right thing on behalf of your firm.

I spoke about building mindful & inclusive products at Fifth Elephant(2016), and I continue to be amazed how much there is to learn, and that I am just scratching the surface of my own limited notion of building things users will value. Sometimes, just making the room to see the rear view, on our limitations, is the first step in that journey.

.. Because in the process, you are not just building software, you are also building yourself. Do a true service to your firm, Cross the chasm, and arrive .