Why Cuvva’s Android engineers love working groups (and how it can help your team, too!)

The problem

The world of software engineering is vast and constantly changing. Continuous learning is a requirement, and becoming proficient in every aspect of Android development is a goal that all of us have tried to pursue.

However, the complexity of the Android ecosystem is now so large that being on top of everything is rather a difficult task.

As our team gets bigger every year (we are six at the moment), decisions by consensus become a lot more time-consuming because it is increasingly hard to ensure everyone agrees on a specific solution.

Recently, it even became apparent that not all technical discussions are of interest to each engineer in a team. At one point, some of us were merely supporting someone else's solution just so that we could go back to work on what we had to do.

That's when we decided to follow what other teams at Cuvva do, and create working groups in the Android team.

The solution

Composed of an owner and an N amount of members, working groups are responsible for managing and driving all work related to a specific area in the whole application development lifecycle.

With that in mind, we created the following groups:

• User experience and design system
• Staff (hiring, onboarding and offboarding)
• Communication (processes and documentation)
• Developer experience and coding standards
• Tooling and CI/CD
• Legacy and refactoring

This new "internal" organisation for platform work is still relatively recent, but the results have been very promising:

• Engineers get to deep dive into an area of their own choice and further develop their skills in it (e.g. CI, tooling, etc.), which by itself also creates new avenues for professional growth separate from those existing within product teams.
• Decisions get made quicker and with less friction because most engineers trust the knowledge and insights of the working group to make a more informed decision around a specific topic.
• Engineers get to suggest and delegate tech debt, or any possible improvements, to an owner of a working group which will then prioritise it alongside the product roadmap. Nonetheless, non-members are welcome to drive (and complete) projects of other working groups if they want to do so.
• It creates new avenues for professional growth separate from those within product teams.

If you decide to implement a similar solution in your team, pay attention to creating groups that are neither too broad nor too specific in scope. That could lead to an unbalanced set of working groups, with too many members or none at all.

But if, like us, you have a team with a diverse set of interests, you will notice that the groups will mostly be a 1:1 match between an engineer and an area of expertise and an extra member or two that are also interested in contributing to it.

The future

How this structure will work out in the long term is not clear, especially in how engineers will feel motivated to keep working on the same area for a long time. But as we keep growing the android team in the upcoming years, many things are likely to change. Having engineers moving across different working groups each quarter, or even creating sub-working groups to accommodate a larger team, might be just a couple of changes we will have to make.

Whatever solutions we adopt, our goal is clear. We want to keep making our team stronger, happier, more collaborative, and radically better.