One Year at Cellulant

1. And there was evening and there was morning - year one

This month I clocked 1 year at Cellulant, and it has been an incredible journey for me. Different workplaces have given me different types of opportunities to acquire and exhibit different skill sets.

It’s been 3 years now that I have been managing remote teams located across different time zones, getting the job done excellently well while having some fun along the way 😁. One thing that I can say for sure is no two teams are the same.

I want to share with you some of the challenges I encountered at Cellulant and how I was able to solve them. Who knows? One or two points may help you in your own team/organisation as well.

2. Let there be focus time

The very first thing I noticed is the team has too many meetings. Although well-intentioned, it is not delivering the expected outcomes.

Our daily stand-ups used to be an hour long instead of the 30 minutes on the calendar. We all know it is a problem. We solved it by ensuring each team member strictly adheres to status updates.

No architecture design discussions, no debugging or such other side quests. If someone has got side quests, they’ll have to wait until after the stand-up to discuss them with concerned individuals rather than hold everyone hostage.

By the way, these “side quests” drastically reduced after we adopt async communication. Information is constantly flowing in the team’s Slack channel.

Instead of waiting for a particular “stand up time” before asking for help, you ask on Slack and get response ASAP.

We used to have a ~4-hour-long meeting on Fridays for demos. During this meeting, backend, frontend, and mobile Engineers will share what they worked on and receive feedback from the team.

Imagine sitting through such meetings where you may not even have anything to contribute in some sections. Worst still, imagine the strain on the team leads that has to be actively present throughout this session.

To reform this, we started by getting selective about who can present. If the frontend Engineer already demo, there’s no need for the backend to do another “API” only demo. After all, the frontend utilises the same backend API.

Then we move to demoing only what’s completed and ready for release.

These meetings got shorter and shorter. I institute an improved SDLC which made this demo meeting redundant and we scrapped it totally.

The team used to organise a code review session. This one is another 4+ hours-long meeting. Each Engineer will present the features/APIs they want to take live. This is a highly technical deep-dive session.

The presenting Engineer will take questions, comments, and recommendations from other Engineers in the team - more like a grilling session.

This was brutal 😭 for the Engineer presenting. It is demoralising and not scientific. Going off-track is always an imminent risk. For the few ones I attended, I couldn’t bear it.

How did I solve this? Simple, I introduced pull requests review. Every pull request must be reviewed by a Senior Engineer before it is merged into the master branch. It was a bumpy ride, but I can say that it is our culture now.

Oh yes, we cancelled that dreadful code review meeting, never to be seen again. This merge request review came along with the reformation of the SDLC for the team. The new SDLC I championed allows us to work in bits.

We break down User Stories into smaller Tasks. Each task is associated with a single pull request.

There were other meeting-related challenges that I solved by simply cancelling them or turning them to async that we can have on Slack.

Of course, the problem of too many meetings is not gone completely, but all in all, I will say we’ve been able to reclaim ~6+ hours weekly that is now channeled into more productive work.

3. And you shall know the truth

Another challenge I tackled with the team was democratising knowledge. You see, before I joined, each member of the team do get assigned major projects to complete end-to-end. This unintentionally led to pocket of specialisations within the team.

So you’ll have someone that only knows one service but struggles with another. Engineer A is able to provide support when it comes to this type of payments but not others.

Furthermore, by virtue of tenure, some team members do have a lot of know-how when it comes to how the global systems work. They’ve been there the longest, solved similar challenges in the past and naturally become an expert in that regard.

So we find ourselves in a situation where some team members are overwhelmed and can’t even take proper vacation because no one else knows how to do what they do or have done it before.

I solved this with two approaches: first, I introduced a production support duty rota. Every member of the team takes turn to be the main support Engineer in the team. Any escalated issues will be primarily handled by them with a provision that they can ask for pointers or helping hands.

The first few weeks were not perfect, but you see, as other team members gets exposed to the same challenges they develop the capacity to solve them and thus load becomes evenly distributed in the team.

Instead of having one or two people that can handle 100% of the support cases, the whole team is empowered to handle most of the cases.

In the early days of the production support, we observed that, if Engineer A, who has less know-how of the system is on duty. They’ll simply be serving as a proxy to the guy who has been doing it for years.

Introducing Runbook for common challenges alleviated this drastically. (Special shout out to that my one Engineer that’s the work horse of the team’s production support 🫡).

Aggressive documentation of processes and exposing ALL team members to ALL the projects withing the scope of the team helps us further democratise information within the team.

These documentations also include architecture documentations, coding standards to guide each team member on what’s expected in their pull requests and other contributions.

4. Introduction of Automated Testing and Development Tools

Before I joined the team, there’s a full-fledged QA team and Standard Operating Procedure (SOP) for testing. Tools like Sonar are already part of the CI/CD pipeline, and we use TestRails to manage the test cases.

The existing procedure involves the QA Engineer(s) writing test cases for each ticket and then execute those test cases before a task can move to the next status.

This may work for smaller team but as the team increases the QA stage is becoming a blocker at times.

The first improvement was limiting the QA Engineers to writing the test cases and letting the Engineers execute these test cases. So while the task is in pre-refinement/in-refinement, QA will add test cases for each task.

Once we got a hang of that, I introduced TestContainers to the backend codebase. This tool let us test the codebase without mocking the underlying database.

TestContainer will automatically start a new database Docker container when a test starts and then tear it down when the test is done. The team went on to build on this and add MockServer for mocking external HTTP calls and building assertions for them.

These tools enabled us to write integration tests - just as if a QA Engineer is using Postman to test the APIs and manually inspecting the response and behaviour. Only this time, we’ve automated it.

Our current iteration requires Engineers to write the test cases and in addition to coding them as part of their merge requests.

These improvements have freed up the QA resource, allowing them to focus more on End-to-End testing and improving the team’s testing capability. Our tickets also move faster through the development cycle.

5. Onboarding Process

During my onboarding to the team, I got help from my team members and manager, which makes it a lot easier.

However, I know we can still do better in this aspect. The usual challenge across many organisations, is for new joiners not to know what to do next in the team they’ve just joined.

Without a clear direction, it can take extra long for a new team member to contribute productively to their new team.

To improve this process, i introduce a new onboarding checklist. The checklist is a simple list of ALL the things a new joiner should do.

This list includes the tools, repositories and software they should have access to. Slack channels and Google Groups they need to belong to, a guide on how to set up their work environment, product walk-through and especially who can get/grant them what.

Still on the checklist is an item to organise a one-time 1:1 meeting between the new team member and other colleagues. I have received very positive feedback about this. It creates a good rapport between the new joiner and existing team members.

This checklist makes the process easier for an onboarding buddy. Moreover, irrespective of the tenure of the buddy in the team, the onboarding experience for the new team member will almost always be the same.

6. Team Bonding

One of the hardest things to do when managing people is fostering smooth and cohesive interactions among the team members. A team that does not work in-concert will struggle to achieve their business objectives.

To promote camaraderie, I introduced the concept of virtual hangout. It is a video-on informal gathering on Google Meet to mingle. The meeting is purely for fun activities like playing digital games, telling jokes, sharing opinions and many other fun things.

While it cannot replace the occasional in-person meetings and hangouts, it is sufficient to create that fun, relaxed atmosphere where you get to see other aspects of your team members outside of “work”.

7. Conclusion

At first, I started this article as a regular LinkedIn post but exceeded the available word limit. Now as an article, it seems to be getting longer than expected.

There are more depths to some of the items I have described above. Feel free to ask questions or reach out to me on LinkedIn if you need help implementing any of the solutions I highlighted.

A special thank you to the entire Instore team for working with me and being open to new ideas with the many reforms in a short time period.

Another special thank you to my boss, Mike, for the liberty to lead the team and drive these changes even at the organization level.

Cheers to more impacts 🥂