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

At an2 cabs, I led three engineers building driver and rider apps for a ride-hailing startup in Guwahati. Two worked on the frontend and one on the backend. My title was frontend lead, but I was responsible for making those pieces work together.

It was my first time leading a team. One of my early mistakes cost us about two days of work.

The explanation I thought was clear

I explained the architecture I wanted and the team started building. When I looked at the code two days later, they had built something different from what I'd intended.

They had followed my explanation. I'd spent time on the parts I found interesting and skipped details I took for granted. I knew how the pieces should fit, but I hadn't given the team enough to build that version.

We rewrote the affected code and moved on. Catching it after two days kept the rewrite small.

Checking what people understood

I'd assumed that because nobody asked questions, everyone understood the plan. That was a poor check. An explanation can sound reasonable while leaving out details that only become visible in code.

After that, I started reading the implementation in the first day or two. A status update tells me how someone thinks the work is going. The code tells me whether we're building the same thing.

I also started asking people to talk through the approach in their own words. It gave us a chance to find misunderstandings before either of us had invested much time in an implementation.

The tracking work

The apps sent driver locations to an Azure backend so riders could watch a car approach. Two details took a lot of attention: how often to send a location, and what to do with noisy readings.

Frequent updates cost the driver battery and mobile data. Less frequent updates leave the car on the rider's map behind its actual position. We had to balance those costs rather than choose a frequency from the map demo alone.

GPS readings also jump. A stationary phone can appear to move, and a car under a flyover can produce a sudden change in position. Plotting every reading directly makes the vehicle jitter. Smoothing helps, but too much smoothing can hide actual movement.

That work required checking the behaviour on a device, not just looking at a clean route on a screen.

What I took from it

The mistake I remember most is still the architecture explanation. I had a clear plan and treated saying it out loud as enough. Looking at the code earlier and asking the team to explain their approach gave me a much better way to check that we'd understood each other.