From middle engineer to Android Team Lead

Together Networks

I was Android Team Lead at Together Networks from May 2013 to October 2016. I joined as a middle engineer and left running a five-engineer Android team that shipped more than 20 applications for an international online dating platform. The team owned the architecture, the releases and the quality of what went out, and I stayed accountable for all three.

The role is worth reading as two things at once. What the team shipped, and how someone gets from middle engineer to running that team in two years.

How the role happened

I did not arrive as a lead. Middle, then senior, then the team. Two years from joining to taking it, then a year and a half running it. The thing that moved it was only half engineering.

I had run a business before this, so I already had the habit of asking why a company pays for developers at all. The answer is never the code. So when a feature arrived I would ask what it was supposed to earn, what the cheap version of it looked like, and whether the thing in the ticket was actually the thing that would move the number. Fairly often I came back with a different proposal than the one requested: a faster route to the same outcome, or a smaller feature that got most of it.

That is an uncomfortable position for an engineer. You are arguing with the people who wrote the requirement, and you still have to implement whatever the argument produces. But it was visible to management, and it is the reason the progression went as fast as it did. Being useful in the business conversation while still being the person who has to build the result is what got me the team.

The team was part inherited and part hired. Some of the five were already there when I took it over, the rest I interviewed and brought in myself, which is two different problems: earning authority with people who did not pick you, and picking people who then have to fit what is already there.

The portfolio

Casual and traditional dating, mostly for the US market. More than 20 applications across it.

Not 20 unrelated products. A portfolio: largely the same product mechanics, packaged for different audiences under different names, with different feature compositions and genuinely different designs. The business wanted more of them than five engineers can write by hand.

The app constructor

The first version of this is always the same. Copy the closest existing app, change the colours, ship it. That works twice. Then a fix has to land in six places, and it lands in four.

So I designed the constructor: features implemented once as Android library modules behind a defined contract, and an application described as a Gradle product flavour saying which modules it takes, in which flow, 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 the moment two copies were edited separately.
• A fix had to be applied once per application, and usually 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 separated 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 designed that system and wrote the core of it. Looking back, it is the earliest version of the thing I kept doing for the next decade: define the contract once, implement it behind that contract, and take the repeated decision out of the place where it gets made badly. At Together Networks it was called saving time. It was the same mechanism.

The trade is also the same one. A configured application is less free than a forked one. When a product wanted something the constructor had no concept for, the honest options were to extend the contract or to accept a fork, and pretending a configuration flag could cover it was how the whole thing would have rotted.

Agile, while it was still an argument

Agile was reaching its peak around then, and inside the company it was still something you had to argue for rather than something you inherited. I was one of the people who pushed it through, and then one of the people who had to make it survive contact with a release date.

What that meant in practice: sprints with a commitment the team made rather than received, estimation done by the people doing the work, retrospectives that were allowed to change something, and a definition of done that included the crash reports rather than stopping at the merge.

We ended up delivering around 90% of what we committed to a sprint, measured in story points against the commitment. Say-do ratio, sprint commitment reliability, the name depends on who you ask. Rework stayed low, production defects stayed low, and the applications ran at a low crash rate. My team was one of the teams the company paid a delivery bonus to, which is the part I would point at: the number was not mine to grade, it was the number the business planned against.

The competency ladder

This is the part I would most want to bring with me anywhere.

The problem was ordinary. Promotion criteria were verbal. An engineer would ask what it takes to become senior, and the honest answer was a shrug plus somebody's opinion, which meant the answer changed depending on who was asked and when.

So I wrote it down. A grid of competencies per level, hard and soft, plus the project knowledge the role actually required, plus what counted as evidence for each line. An engineer could read it and know where they stood without asking anyone.

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, not a private checklist.

2. 02

   Self-assessment first

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

3. 03

   Assessment and the gap conversation

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

4. 04

   A plan against the gaps

   Concrete work that would produce the missing evidence, with a date to look again. Growth becomes a scheduled thing rather than a mood.

5. 05

   Technical and project examination

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

6. 06

   Title change

   The title follows the evidence. Tenure on its own does not move anyone, and neither does my opinion on the day.

   Evidence, not tenure

This ran alongside the company's first experiments with 360 feedback, which HR was piloting at the time. The grid gave those reviews something concrete to point at, and the two together grew into personal development plans rather than a form nobody read afterwards. I would call that a start rather than a finished system. Everyone involved, me included, was learning it while doing it.

The Teladoc version of this problem was the opposite one: a team where no titles existed to give at all. The mechanism I used there came from here, with the title removed.

What it did for the business

Mobile was a small direction when I joined. It stopped being small.

The marketing budget behind the mobile products grew several times over during that period. I am deliberately not attaching a number to it. I did not own that budget, I am reconstructing the shape from memory, and a precise figure would read as audited when it is not. What I can say is the ordinary mechanism: spend follows the channel that returns, and mobile became a channel worth spending on.

The second thing I noticed was about the people around the team rather than in it. Promotions did not stop at the engineers. Product managers and marketing managers we worked with got promoted too, in the same period. A team that ships what it committed to makes the people planning around it right, and being repeatedly right is what gets those people promoted. That is an observation from one company over three years, not a law.

Authority

What I would do differently

• Keep the sprint reports. The 90% is a recollection because I kept nothing.
• Version the competency grid and record who was assessed against which version. It drifted, and after a year nobody could say against what.
• Write down what the constructor was explicitly not for. Every configuration system eventually gets asked to configure something that should have been a fork, and the refusal needs to be written before the request arrives.
• Separate the promotion criteria from the examination sooner. An exam measures preparation for the exam, and the grid was doing the real work.
• Make the business argument in the ticket rather than in the corridor. A fair share of my proposals landed because I happened to be in the right conversation, which does not scale and did not survive me being busy.

Technologies