From middle engineer to Android Team Lead

Together Networks

I worked at Together Networks from May 2013 to October 2016. I joined as a middle Android engineer and later became Android Team Lead, running a five-engineer team that shipped more than 20 applications for an international online dating platform. I owned the team's architecture, releases and quality.

From middle engineer to team lead

It took about two years to reach the lead role, followed by about a year and a half running the team. I joined an existing group and later interviewed some new members. The team was partly inherited and partly hired, so I also had to earn authority with existing colleagues. I kept asking what a feature was supposed to achieve, whether the ticket described the real problem, and what smaller version could deliver the same result. I proposed faster or smaller routes and still implemented the work. That business usefulness helped me progress into leadership.

The portfolio

We worked on casual and traditional dating products, aimed mainly at the US market. The team released more than 20 Android applications. They shared much of the product mechanics but had different audiences, names, feature combinations and designs. Copying each application by hand would not scale for a five-engineer team.

The app constructor

I designed a constructor that implemented features once as Android library modules behind defined contracts. A Gradle product flavour then described which modules an application used, in which flow and under which theme.

How a new application got built

Before

Fork the closest app

• A new product started as a copy of the nearest existing application.
• Shared behaviour drifted apart when two copies were edited separately.
• A fix had to be applied once per application, and sometimes was not.
• Design differences and behaviour differences were tangled in the same code.

After

One constructor, many assemblies

• Features live once, as library modules with a defined contract.
• An application is a product flavour: which modules, in which flow, under which theme.
• The presentation layer is separate from behaviour, so a different look is not a different codebase.
• A fix lands in the module and reaches every application assembled from it.

I wrote the constructor core and shared modules. When a product needed something the constructor did not support, we had to extend the contract or accept a fork. Configuration gave each product less freedom than a fork. Adding flags for every exception would have made the shared system brittle.

Delivery and promotion

Agile was still something we had to introduce inside the company. We used team-owned sprint commitments, estimates from the people doing the work, retrospectives that could change the process, and a definition of done that included crash reports. We delivered around 90% of committed story points, based on sprint reports from the time and reconstructed from memory.

By my recollection, rework and production defects stayed low, as did the crash rate. The team received a delivery bonus; our commitments were useful to the people planning the business. I no longer have the underlying dashboards, so these remain qualitative observations.

Promotion criteria were mostly verbal. I wrote a grid of competencies for each level, including engineering skills, project knowledge, soft skills and the evidence expected for each line. An engineer could assess their position before we discussed it.

How a promotion worked

1. 01

   Written criteria per level

   Engineering skill, project knowledge, and the soft skills the level needs. One grid, visible to everyone.

2. 02

   Self-assessment first

   The engineer marks their own position before I mark anything. Where we disagree is useful.

3. 03

   Assessment and the gap conversation

   My reading of the same grid, with evidence attached. The output is a short list of gaps.

4. 04

   A plan against the gaps

   Concrete work that would produce the missing evidence, with a date to look again.

5. 05

   Technical and project examination

   A check on the knowledge the level claims: the platform and the systems the team owns.

6. 06

   Title change

   The title followed demonstrated competence. Tenure alone was not enough, and the evidence could be discussed against the same criteria.

   Evidence and responsibility

HR was piloting the company's first 360-feedback experiments. The grid gave those reviews something concrete to discuss, and together they became personal development plans. It was an early system we were still learning to use.

My part in the work

What I would change

• Keep the sprint reports and version the competency grid used for each assessment.
• Write down where the constructor should stop and a product should fork.
• Separate demonstrated competence from preparation for an examination.
• Put the business case in the ticket so it survives beyond a conversation with me.

Technologies