Lead Forensics

Blogs

Part 1 – Code to Customer Series: Where did all the developers go?

12.02.19 Ajay Kumar Jain

Any CEO worth their salt should take a moment to consider which disruptive technologies, innovations and business/delivery models could positively impact their business.

Our world, as it stands today, is built on a series of disruptive technologies. Those companies that thrive today, will do well to not rest on their laurels as chances are there is someone right behind them already working on how to deliver the same product or service, better, faster, cheaper and smarter.

One industry that is taking note is the automotive sector. In 2014, Google revealed a new prototype of its driverless car, and for a while, it looked like Silicon Valley was on track (pun intended), to win the race to build autonomous vehicles.

Although driverless cars have yet to take off, and with Google considered a serious competitor in the self-driving car market, a few major car manufacturers have announced plans to build their own driverless cars, or to partner with tech companies. Last year, Fiat Chrysler announced plans to develop self-driving minivans with none other than Google.

Brave New Tech World

How about insurance? Where does our industry fit into this? How can we avoid making the same mistakes that Blockbuster and Kodak made, and how can we accommodate disruptive technologies to remain relevant and competitive?

Let’s face it, insurance isn’t exactly shiny or glamorous, and it doesn’t deliver instant gratification. Those insurance marketing folks don’t have it easy. The best way to understand the service is when we make a claim.

Working for an organisation that designs insurance software, from day one we collaborate with our customers, who give us instant feedback.Identifying the solution is not key, identifying the problem is. Too often we see a myriad of IT ‘solutions’ that don’t really have a problem to solve. Identify the problem and the solution will follow.

With this mantra at the heart of our organisation, our Code to Customer (C2C) philosophy is about pulling down barriers between code and customer, without cutting out the core things that make our delivery model work.

Our C2C philosophy is all about delayering the organisation and establishing direct links between the client side of the business. It’s about the user defining their need and the provider’s software coder fulfilling that need.

For us at AdvantageGo, C2C is about creating a mindset, tool-set and skill-set that empowers coders to be in touch with the consumers. The philosophy extends inwards as well, with the aim of breaking down barriers within teams, where everyone has an equal say and chance to contribute, and where accountability rests with the team, not just one person. The picture, accompanying this blog, shows an AdvantageGo team of senior managers, directors and junior software developers, and despite the cheesy grins, it’s impossible to identify who is who, and that’s how we want to keep it.

Team third floor

In my next blog, I’ll outline a real case study taken from a software development industry forum and will discuss how applying the Code to Customer philosophy can solve some of these problems.