Long reads thumbnail

Ops Excellence through Technology Process Training and Audit

30 Mins


By Team Artha

If you can’t describe what you are doing as a process, you don’t know what you are doing.

Edwards Deming

During my days at Virtusa, I used to visit Boston often and what never ceased to surprise me was how even in the middle of the night in some sleepy suburb, where the traffic was minimal, the cars would come to a complete halt when the traffic signal turned red. The contrast with the chaos at traffic signals in Indian cities was stark. How could human beings in one part of the world behave so differently from those in a different part? And why would human beings who behaved in one way in India suddenly start behaving differently when they moved to America? And that too on something as simple as adherence to traffic rules! We will come to this shortly, but first, a story on how we achieved such fundamental behavioural transformation in the context of a rapidly scaling start-up.

Bigbasket does home delivery of groceries. The assortment is huge, with nearly 25,000 SKUs ranging from Fast Moving Consumer Goods (FMCG), Fruits and Vegetables (F&V), Chilled and Frozen items (C&F), and more. There were many aspects of the customer experience that were broken, but we will talk of three examples and how we fixed them:

  1. The C&F items were packed in chiller boxes with frozen gel packs inside to maintain the desired temperature. The delivery staff would often open up the chiller boxes and move stuff from one box to the other to minimize the number of boxes they had to lug, even though they were told this was a process violation. This would result in a deterioration in the product quality because of temperatures exceeding the safe limits.

  2. Grocery items were all packed in crates to prevent items from getting messed up and mixed up. You couldn’t pack toilet cleaners with food items, for instance. So, each category of products were delivered in crates in different colours. And each crate was sealed with finely ribbed plastic cords similar to what some airlines use for sealing baggage. Before departing from the hub, for making deliveries, every delivery boy had to wrap a pouch around his waist. The pouch had a small cutter, among other things. The cutter had to be used to cut the plastic cords from the crates. After cutting the cords, they had to be put back into the crates and not discarded at the customer premises. The delivery staff almost always did not carry the cutter and simply ripped open the crate covers. In the process, they ended up damaging the crates, dropping the plastic cords on the floor, and creating a shoddy experience for customers.

  3. In the early stages of growth, most of the training of the delivery staff happened through a buddy- mechanism where a senior delivery executive trained a newly hired delivery executive and a senior warehouse executive trained a newly hired warehouse executive. Process updates were not reliably disseminated, and basic soft skills like greeting a customer, dealing with women and senior citizens were imparted very inconsistently. At the scale that Bigbasket had operated on until then, this approach had worked reasonably well. But gradually, the cracks were beginning to show: Customer complaints were on the rise, productivity was low, and deliveries did not match invoices, among others. And Bigbasket was growing rapidly. There were plans to hire another 6,000 associates in the next twelve months.

What we needed was a ‘six sigma’ kind of precision in the way these processes worked on the ground.

Processes work only if they are followed every time.

Nothing better fits the description of a double-edged sword as ‘Process’. The process can slow down, but the process can help you scale without the wheels coming off. Process can be stifling, but it can be liberating in the sense that you don’t have to worry whether something will get done the way you want it to. The process can slow down and even frustrate a bright and smart individual, but even average individuals can deliver an outstanding experience every time if backed by the process. And scale is all about getting average individuals to deliver an outstanding experience.

But we soon recognized that the unpleasant and inglorious side of the process is that even the average individuals who could benefit from this hesitate to follow it if it slows them down or makes them work harder.

So, we added three additional layers to make the process work every time, namely audit, training, and technology.

It is a normal human tendency to circumvent a difficult process when there are no consequences. We quickly put together strong audit mechanisms to ensure that what was prescribed in the manual was actually delivered on the ground. Game theory explains several phenomena beautifully – why individuals collaborate and work well in cross-functional teams in some companies and why they fail miserably in some other companies; why traffic rules are followed in some countries, and why they are regularly breached in some other countries. The penalty for not demonstrating the right (desired) behaviours is so high that they tilt the scales heavily in favour of compliance.

We strengthened training. We helped the delivery executives understand the consequences of breaching some of these key processes. Most individuals demonstrate change when they fully comprehend the consequences of their current actions. Operations felt that their current method of using senior role holders to train the new joiners worked well because there was no wastage of time in training. But we changed that and introduced role-based training with good content and delivery mechanisms. We even introduced a process for trainer certification.

We also took the call of soliciting feedback from customers on our delivery executives through push notifications. Feedback was categorized under a few heads, and there was space for some free text as well. With the help of our Analytics team, we parsed through reams of free text to understand the overall customer sentiment and other behavioural issues with our delivery staff. With timely feedback, some of the behavioural issues vanished overnight. Based on the feedback, we identified the bottom 30% every month. These individuals, with a special focus on the bottom 10%, were put through intense refresher training. The top 10% were invited to come to some of these refresher sessions and talk about what they did differently. A simple Pareto showed that 10% of the delivery staff were contributing to 70% of the problems. With this data, we could target improvement programs that gave us bang for the training buck.

Continuous refresher training became a way of life. As some wise man or woman had once said, “Sixty years ago I knew everything; now I know nothing; education is a progressive discovery of our own ignorance”. One could say the same thing about training as much as education. Any process is as good as the person behind it. And any person is as good as the training she has been through.

And finally, we brought in technology. All the chiller boxes were equipped with IoT devices. These devices could track temperature from the hub where the products were placed in these boxes right until they were delivered to the customers. A dashboard was available to the operations controller at the hub, who could then monitor the temperature of every chiller box that was dispatched. Any process deviation was detected, and corrective actions were initiated immediately.

Technology, Training and Audit together ensured that Process adherence became the norm.

Technology Scaling and Debt

Rakshit Daga’s career in SAP began with a role in the office of the CEO and one of its legendary founders Hasso Plattner. He got to see from close quarters Plattner’s evolving belief in building products that incorporated design thinking. The principles behind design thinking have been around for a while, and like most concepts and frameworks in management, it is old wine in a new bottle. Design thinking is a combination of going beyond self-imposed constraints and mental models on the one hand and a deep understanding of the users on the other. It has been known by various names in the past, ‘thinking out of the box and ‘problem solving’ being some of them.

A few months into his new role, Rakshit was tasked with setting up a team within SAP Labs called AppHaus (house of apps) that would build apps on top of the SAP platform. AppHaus was set up to work like a start-up even though it was part of a global organization. A few months into this role, Rakshit’s boss wanted to know if he would be interested in moving to Bengaluru to set up an AppHaus team in India. After some thought, Rakshit took on the challenge of moving himself and his family back to India. It seemed to be an opportune time to move to India, both professionally and personally. Professionally, this was a great opportunity to manage a global team across India, China, the US and Europe. Personally, it provided his kids with the opportunity to study in India during their formative years while allowing Rakshit to be close to his ageing parents.

The India that Rakshit came back to after a decade in the US was different from the country that he had left. He observed that the India he was returning to was a resurgent economy characterized by a young population. Rakshit tried replicating the start-up culture of AppHaus of the US in India as well and succeeded to a great extent.

Having seen both sides (Silicon Valley and India), he had some great insights to offer.

The average age of a developer in India is around twenty-five years, and in Silicon Valley, it is more like thirty-five. This is the genesis of some of the key differences in the software development practices between the Valley and India. While the work ethic of the engineers in India is second to none, this difference in the demographic profile of developers has generally led to some challenges.

‘Technical Debt’ is prevalent everywhere, but it is much more accentuated in India. Technical debt (also known as tech debt or code debt) describes what results when in trying to expedite the delivery of a feature or functionality, the development teams resort to shortcuts in terms of documentation and architecture that later needs a lot of rework. This happens when speed to market is far more critical than good code.

In India, there is a tendency to throw bright people at problems, including the most successful start-ups. In software development, there are often multiple ways of solving a problem, and mathematically smart people always find solutions. However, they have not yet been exposed to good architectural practices. As a result, they bring the product to market pretty quickly but incur a lot of technical debt in the process. In the Valley, because of more senior engineers in the team, the core infrastructure is created more thoughtfully in a way that reduces technology debt and allows scaling to be more seamless. This is a result of their having solved complex problems earlier which gives them an innate sense of how architectural frameworks would scale in the long run. The interesting point is that the effort involved in getting the plumbing right at the very start does not really slow down development or delay the product launch. It is just that most young engineers simply do not even know of the existence of these nuts and bolts.

For example, it takes a while for a young engineer to figure out that not all code needs to be synchronous. As software operations become large and complex, synchronous code becomes very slow and fragile to execute. Designing databases that can scale by minimizing computational load is another important component of scaling. These are practices that come with experience. In India, the very successful IT services industry had created managers out of engineers and no engineer was keen to code after a certain point in time. Managing large teams was considered cool. As a result, there was a big gap in good software developers in the 35-40 year age bracket. While this is changing rapidly now, this resulted in the way software development was done at start-ups. Often the first version of the product would be a prototype that would keep expanding in a random fashion when developers kept building on top of the prototype. Add to this the poor quality of documentation, after a while, no one knew how the code really worked. Since the business was always growing rapidly there was no time to think about the scalability challenge. Bright engineers were always busy solving problems around the same architecture and ended up with a system that consumed more energy, time and money to serve the same traffic. At some point, the burden of this technology debt begins to weigh heavily on performance, stability, and scalability.

In the last decade, there has been rapid development in technologies like virtualization and cloud computing that has made scaling far simpler. Fifteen years back if you had an e-commerce website that was expected to see a spike of say 10X in traffic because of a promotional sale or if you were an online video streaming platform and you expected a 100X spike because of a popular game, there was no way you could handle these peaks without a huge investment in large data-centres. This investment would be underutilized after the spike disappeared. Today, developers need not worry about hardware limitations to the same extent, or for that matter plan a lot in advance.

In 1998, a personal computer with 512 MB RAM would have cost $700. Today a smartphone with twice the computing power comes at a fraction of this cost. This has provided a strong client infrastructure at every developer’s disposal that could then be used to interface with large server systems powering the world’s most common apps.

As start-ups scale, they need to rethink how they should organize their technology teams. The start-up culture of everyone pitching in and doing anything that needed to be done would result in work being assigned based on bandwidth and not on expertise; this would result in knowledge of any system being fragmented amongst team members. A dedicated ‘platforms team’ that would act as a single-point owner for the IT infrastructure becomes essential to deliver performance at scale. The architecture needs to be reconfigured to a micro-services model. This would help compartmentalize the code base and isolate the risk of performance issues to the specific micro-service rather than the entire codebase and data store. One needs to watch against bureaucracy at this stage because it could lower the average productivity of developers.

In Conclusion

Technology, Process, and Training are three very powerful enablers of scale. As your start- up scales, you would need to hire people in the leadership team who understand these very well. The unstoppable march of technology has put immeasurable power in the hands of those who know how to harness it. Leadership teams, and even individual leaders, who do not recognize the power of technology and the strategic impact it can have on the business are doomed to be laggards.

Process and Training, as enablers of scale, have been enduring and timeless. However, their power is often underestimated because they tend to be a bit soft and intangible. Together with technology, they make a formidable combination that can power a start-up in the journey of scale.

Author image

Team Artha