Field Manual - Log EntryVol. 01§V · Entry3 min read

leading-a-mobile-team-for-the-first-time.md

§V · ENTRY

by 3 min read

I explained the architecture badly and my team built the wrong thing

The first time I led a team, my worst mistake wasn't technical. I described an architecture that was clear in my own head and assumed that was the same as having communicated it.

At an2 cabs I led a team of three building React Native driver and rider apps for a ride-hailing startup in Guwahati. Two of them were frontend. One was backend. I was the frontend lead, which on paper makes that last part odd, and in practice made complete sense: it was a startup, the work did not arrive sorted by job title, and someone had to own the whole path from the driver's screen to the server.

It was the first time I was responsible for code other people wrote.

The mistake

Early on I explained the architecture to the team. I knew what I wanted. I had the shape of it clearly in my head, and I said what I thought were the important parts out loud.

They went away and built something else.

Not carelessly. They built exactly what my explanation had actually described, which turned out not to be the thing I meant. The gap was entirely mine. I had described the parts that were interesting to me and skipped the parts that were obvious to me, and "obvious to me" is not a category that exists for anybody else.

I caught it about two days in. We rewrote what they had and moved on. Because it was two days and not two weeks, the rewrite was small enough that I remember the lesson more clearly than the cost.

What I actually got wrong

The tempting reading is "I should have written a design doc." Probably true, and not the real lesson.

The real one is that I had two different things confused:

  • understanding an architecture
  • having communicated an architecture

As an individual contributor these are the same thing, because the only person who needs the model is you, and you have it. The moment someone else builds against your model, your private clarity is worth nothing on its own. The shared version is the only one that exists, and producing it is separate work that I had not done.

I had also read the absence of questions as the presence of understanding. Nobody was confused enough to ask, because my explanation was coherent. It was just coherent about the wrong thing.

What changed after

I started reading the actual code early, in the first day or two, instead of waiting for a status update at the end of the week. This sounds like distrust and isn't. People report progress honestly against their own understanding of the task, so when that understanding is wrong, the status reads perfectly fine right until the point where nothing fits together. A status update cannot catch this. Only the code can.

I also stopped explaining and started asking them to explain it back to me. It is slightly awkward the first few times. It is much less awkward than a rewrite.

The GPS problem underneath all of it

The technical core of the product was live tracking: driver apps pinging location continuously to an Azure backend so riders could watch the car approach.

Most of the real engineering there came down to two questions, and neither was about React Native.

The first was ping frequency. Ping too often and you drain the driver's battery and burn their data, and drivers notice both immediately. Ping too rarely and the car on the rider's map lags behind the car on the road, which quietly erodes trust in the entire product. There is no correct answer here, only a chosen one, and choosing it is the work.

The second was drift. GPS readings are not clean. A stationary phone reports itself wandering. A car under a flyover teleports. If you draw exactly what the device reports, the vehicle on the map jitters and jumps in ways that make a working system look broken. So you decide what to smooth, what to discard, and what to trust, knowing that every one of those choices can also hide a real movement.

Looking back

The leadership lesson and the GPS lesson turned out to be the same lesson, which I did not notice at the time.

In both cases I had a clean model in my head and reality arrived noisier than the model. With the team, the noise was the distance between what I said and what was heard. With the location data, it was the distance between where the car actually was and where the phone claimed it was. Both times the error was trusting the clean version and not checking early enough what had really landed.

Two days was a cheap price for learning that. I have paid more for less since.

--faq --questions

§V · Q&A
What is the hardest part of leading a team for the first time?
Realising that explaining something once does not mean it was understood. As an individual contributor your understanding lives in your own head and that is enough. As a lead, only the shared version counts, and checking that it exists is your job rather than theirs.
How do you catch a wrong architecture early?
Read the actual code in the first day or two instead of waiting for a status update. People report progress honestly against their own understanding of the task, so if that understanding is wrong, the status sounds fine right up until nothing fits together.