Chaos to Cohesion

Rupeek
Rupeek Stories
Published in
9 min readMay 2, 2021

-Sophia Sharma

Have you ever thought about what kind of systems we as humans prefer- A Chaotic System or A Cohesive System? The obvious answer that comes to mind is that we prefer a cohesive system because we see mostly such systems around us in all walks of our lives. We as humans have spent countless number of hours of our lives bringing structure to the world around us to make more sense of it.

But when we think of an organization, isn’t the choice of system contextual on which stage of growth the organization is?

Why Chaos?

When the organization is in the initial stages of the growth, the team is small, there’s no hierarchy and no clearly defined roles. In short the system can be called a chaotic system. In such cases, the system works as the small team is more agile-can respond to changes quickly, can pivot to other direction if required. Everyone is doing anything and everything to get things done. Don’t you think if we impose a structure on such a team in such initial stages of the organization, wouldn’t it stifle innovation, creativity, agility ?

Why Structure?

On the other hand, when the organization has grown and with its number of teams, number of people, number of focus areas have grown and there is no cohesive structure there will be unclear expectations, unclear ownership, messy flow of information and delayed deliverables which may not be upto the mark. At the end, the organization will become a confused group of talented people who’re working too hard to deliver something which might not even be required.

So, rather than preferring a system, we should understand that both systems are part of the same journey. Rather than selecting one, each organization would experience both types of systems and evolve from a chaotic system to a cohesive system as part of their journey.

Journey from Chaos to Cohesion

Moving from Chaos to Cohesiveness is not easy. It requires immaculate planning and all hands participation by everyone involved from top to bottom. As every organization is unique and has its own challenges, each organization can devise their own strategy and plan to make the change.

Below are some of the steps and best practices we the Rupeek Design team followed for moving from chaos to cohesiveness:

1. Determine when to make the shift:

This is a very contextual decision for each organization. But usually when an organization wants to scale up they need to have a structure and processes in place to ensure there are clear expectations, clear ownership, smooth flow of information and sustained quality delivery.

Since scaling up to 5x this year is Rupeek’s vision and mission. One of the OKRs for our organisation was to bring the structure to our work so that we can not only scale but also sustain the scale .This cannot be possible without bringing structure and clearly defined processes to our ways of working .

2. Understand the different processes and challenges:

At Rupeek, different design teams are working with different business units: Customer Acquisition , Loan Application and Loan Management experience . Hence each designer was following a different set of processes and procedures to suit the context of the team.

For example on one hand the Customer acquisition team had a very fast paced delivery culture, they ran a lot of experiments , designers always had to be on their toes and think about the upcoming design changes . On the other hand Loan management module had a more strategic approach to design i.e. they do a lot of user research before they propose any designs.

So, the first task for us was to speak to the teammates in the design ,product and business teams of the above modules to understand their ways of working to surface the commonalities and differences. Understanding the current challenges from both designers and product teams was crucial so that the new processes can avoid those issues going forward.

Some of the major challenges that were identified:

  1. No defined design process
  2. Ad Hoc requests coming in from Product teams
  3. No formal PRDs to start the design
  4. No set delivery timelines
  5. Developers having issues while implementing designs

3. Design and evolve the processes:

Once we had the current challenges in place, the next steps were to create the processes.

To begin defining the processes we first conducted meetings with other designers to make sure their concerns and issues have been addressed and they see value in this process. We conducted weekly UX team meetings where we showcase the work we are doing and seek feedback from the team.

Delivery timeline was the next big problem we had in the Design team. To provide any design solutions to the team, each designer has to go through a process and multiple user feedback iterations which takes time but it becomes hard to explain that to the product teams. We wanted to set a plan with which we can showcase the process that we go through so that the designers can get sufficient time to provide the solutions and there are clear expectations for the product teams regarding the delivery of designs.

Main steps identified to address the above challenges were:

  • Move away from ad hoc design requests
  • Ensure a definite start date and end date is agreed to deliver solution to a design requirement
  • Ensure better transparency of the work being done

After discussing we agreed that we can easily follow the above steps if we start running our well-defined UX sprints. We planned to start our sprints which run parallel with the dev team sprints. We decided to run a two weeks sprint with defined and agreed delivery scope and each designer will be accountable for the work that they’ll agree to deliver.

We have seen that a clear UX sprint plan has helped every designer and product manager to be on the same page. There was a clear expectation set for the Product team that before we start any design the PRD should be ready with a clear design scope. Similarly the expectation set for the designers was to follow the above agreed design processes, provide regular updates on the progress and provide designs at the end of the sprint.

FInally we defined an end-to-end Ways of Working journey of any requirement that comes with design scope.

It includes :

  • Identifying the different types of Design requirements coming in
  • Defining the design process to be followed for each type of design requirements
  • Defining the Process timeline and checkpoints with the product and the business teams throughout the journey
  • Planning UX Sprints

These steps help us create a well defined UX journey which covers all the aspects that are required to arrive at the best possible solutions for a design requirement.

The ent-to-end process covering the above steps can be visualized as below.

4. Buy-in from the stakeholders

We have ensured that all stakeholders from the design, the product and the business teams are always updated of the processes and the ways of working drafted through regular meetings and discussions so that we have buy-in from them.

Buy-in from the Product teams : We set up biweekly meetings with the product team where we discussed all the updates from the design team. The first step was to get approval from them since designers work very closely with the product managers. We showcased our processes and took feedback from them so that we are all aligned .

Buy-in from the Business team : Once we had the feedback from the product team included in our process , we showcased the same to the business teams to take their feedback and make any changes as per their suggestions.

As the product and the business teams understood the pain points, they helped us refine the process so that the colleagues from the different teams can work better together. We made the changes as per their feedback and have got the buy-in from them to go ahead and start the actual implementation of the aforementioned processes.

5. Implementing the agreed processes and ways of working

As mentioned earlier we agreed to run a two weeks sprint with a well defined and agreed delivery scope where each designer will be accountable for the work that they’ll agree to deliver.

We discussed the processes and ways of working to all teammates before kicking-off the first iteration. Starting with the Loan management team, we kicked off a demo sprint before starting a formal sprint so that we can get into the groove and make any refinements as required.

We encountered few issues in the demo sprint as expected but it helped a lot for all the teammates to see the process in action and to call out what’s working and what’s not.

This helped us avoid those issues when we kicked off the first formal sprint.

As of now we have successfully run three sprints and are trying to improve and fine tune the above mentioned processes with each completed sprint.

6. Improve processes by taking feedback in retrospectives

After each iteration, we’re conducting a retrospective with the team members to find out what’s working and what needs to be changed to deliver the intended results sustainably.

Areas that we have improved so far are requirement gathering and collaborating process from the product team and the delivery timelines . Apart from this we have added feedback in the design handoff document provided by the product team.

The leads/managers look for the feedback and the opportunity to identify the challenges that can be avoided when scaling up at the organization level.

This also gives opportunity to teammates to take ownership of the processes and stay invested in improving the same.

7. Sharing the findings, improvements and next steps with all stakeholders:

We have ensured to keep all the stakeholders well informed on the progress and the challenges we have been facing in setting up the processes and ways of working. As we continue to do so, we’ll also ensure to take feedback from all stakeholders to improve the processes setup which in turn will help the organization scale up. Feedback received in retrospectives is being documented to make changes and improve the processes.

Conclusion

Journey from chaos to cohesiveness can be daunting for any team or organization. But it is a journey which can not be avoided as a team or an organization grows.

While a chaotic system where anyone is doing everything is preferable in the initial stages of growth of an organization, an organization can not sustainably scale up and deliver without proper processes and agreed ways of working among various teams in the organization. Creating such an organization is important to ensure there are clear expectations for the teammates and there is a smooth flow of information . Otherwise, the organization will not be able to scale up sustainably.

In the same spirit we the Rupeek’s design team are following an iterative approach with steps mentioned above to undertake this journey. Any other organization or team can choose to follow the same or modify as they deem fit. We believe it is not important how a team or organization takes this journey as long as they take it.

--

--