The latest insights from your peers on the latest in Enterprise IT, straight to your inbox.
What 14 years as a developer taught the director of automation of an asset management giant about delivering better code faster
By Ashish Kumar Jha, Director of Automation Solutions, Invesco
Technology has become an integral part of everything that we do, from ordering a taxi to ordering medicine to booking a table for dinner or lunch – even ordering diapers for your kids. These days, everything is on a platform.
All that practice is making perfect, and as quality improves, customers’ expectations of digital services keep rising. If you ask customers to fill in a loan application or a new account application manually, they will laugh at you. They will not do business with you.
But that doesn’t mean you should develop anything in a reckless way. Growth is a journey. It doesn’t happen overnight – knowing your subject, knowing your audience, is absolutely critical. That is why I always try to proceed very deliberately.
Thinking inside the box (all 3 of them)
After 14 years of this work, I have a kind of routine worked out.
I always begin by setting an innovation strategy to support our business goals. I like the approach Vijay Govindarajan takes with his Three-Box Solution. Govindarajan, a professor of strategy at Dartmouth’s Tuck School of Business, advises planning an innovation strategy by organizing your thinking in three boxes: first, manage the present; second, selectively forget the past; and third, create the future.
Each box has its own set of questions. For the first box (the present), you need to ask: What will it take to keep our business stable? The question for the second box (the past) is: What factors of our former success are no longer useful to us? And finally, for the third box (the future), ask: What do we need to do to create the future we want?
After these first steps, I bring in design thinking. I follow that methodology to make sure that empathy for the end-customer is the key focus of everything that I do.
Empathy is absolutely critical, both for design and leadership in general.
You need to start by wanting to know someone, wanting to understand a situation. Not going in with a preconceived notion goes a long way – particularly if you know how to listen, which is a critical but often overlooked skill. It’s not enough just to nod and say “OK, fine,” but not understand what you are being told. That won’t get the job done.
If you are writing a specification, you need to keep asking yourself, is it relevant? Does this solution already exist in some shape or form or are we creating something new? And in any case, do we have customers for this solution?
This last point, identifying your customers, is crucial. Often, projects go wrong because it isn’t clear who the development is supposed to help.
Once the customers are identified, you need to define the stakeholders for your project, the right team, and the right decision makers. Once you have all those players identified, you can move much faster.
But fast isn’t the best way to do everything. One lesson I learned the hard way is that it’s absolutely critical to soft-land change. A change that people want is much easier to make than a change that is forced on them.
For a smooth landing, you need to make sure you keep your communications with your stakeholders and your customers very transparent. These days, stakeholders expect you to be open in your communication. Don’t shy away from giving bad news, because if you let bad news accumulate, it can snowball.
On the other hand, if you manage your communication properly, you get room to fail. It’s not like the old software development life cycle, where you never saw a customer until you had an application that was ready to touch and feel. Contemporary design thinking and change management principles hold that it is best to keep iterating minimum viable products and sharing them with the customer.
When you let your customer see what you have designed in chunks, you get fewer rejections. It also helps prevent closed-world syndrome, wherein you get so focused on product delivery that you forget about the latent needs of the customer.
Uncovering latent needs isn’t as difficult as you might think.
I always start by asking open-ended questions. I also use the five-whys technique from the Lean methodology, where you ask your customer why something is required, and keep asking why five times, at which point you usually see the whole sequence of requirements narrow. I like what-if scenarios. too: What if this solution is provided? And what if this solution is not provided?
Another technique that works well is to ask the customer to divide the whole requirement into nice to have, must have, and good to have. This can also bring a lot of latent needs to the surface.
Fast and Faster
Of course, it should be noted that although the human side of development never changes, automation is changing aspects of how we develop.
Just a few years ago, in a simple robotic process automation environment, you could only code so many business rules and exceptions. If the system encountered a rare scenario, it would fail it and spit the exceptions out. But now, if the system has machine learning capability built in, it can make a decision on your behalf if it sees the same exception a second time.
RPA will surely be a powerful technology for operational efficiencies, for risk reduction and more. RPA, along with complementary utilities and tools and techniques like cognitive intelligence, human-in-loop, machine learning, assisted learning, and supervised learning, will change the game.
Even so, we will still need change agents. To me, everybody in a leadership position ought to be a change agent, not as someone delivering a mandate, but – and this is crucial – as someone who helps everyone understand what changes are coming and how they affect every last person on the floor. When there is ambiguity in strategy and execution, that’s when your plan starts to fail. Open lines of communication and being transparent to the extent you can are absolutely critical.
Asking repeated open-ended questions and listening carefully to the answers is a good way to uncover latent user needs.
If you are writing a specification, you need to keep asking yourself, is it relevant? Does this solution already exist in some shape or form or are we creating something new?
For a smooth landing, keep your communications with your stakeholders and your customers very transparent.