The feature we shipped twice

Nobody tells you this when you become a team lead - whatever you decide, someone ends up unhappy with you. The job is not avoiding that. The job is choosing who ends up unhappy, and being able to explain why.

Here is how I learned it - the same feature, shipped twice, two quarters in a row.

Q1 - fast, useful, politically wrong

In Q1 my team got a new feature to build. We ran with it. We made the product calls ourselves and shipped. We did not involve our product division much.

The feature landed. It was usable, and the users liked it.

Then the feedback arrived, through my engineering manager - product had not been involved, and they were right to raise it. We had bypassed the people whose job is the product. However good the outcome, that is not a process you can repeat. It burns trust you will need later.

Q2 - aligned, by the book, wrong

In Q2 we got a request in the same area, and this time we did everything by the book. We sat with product from day one. We kept a Slack channel where we posted every update and every decision we took. We followed the mockups exactly. Total alignment, full visibility, zero surprises.

We delivered exactly what was asked. And the users did not take to it. The feature was not usable - not because anyone did bad work, but because we optimized for matching the mockups instead of questioning them.

Q1 we shipped the right thing the wrong way. Q2 we shipped the wrong thing the right way.

Alignment is not the goal

It is tempting to read Q1 as "process slows you down" and Q2 as "see, alignment does not work". Both readings miss the point. Alignment is a means. The goal is a feature users actually use. A Slack channel full of updates proves you communicated - it does not prove you built the right thing.

The real failure in Q2 was not product's mockups. It was us, engineering, noticing things that would not work and staying quiet, because this time we were determined to be good citizens. Silent compliance is not collaboration. It is just slower.

What I ask of my team now

The fix is not more process. It is one sentence, said early - "We believe this is not going to work, because of X, Y and Z."

When the team building a feature sees a usability problem - from the code, from user feedback, from experience - that goes to product before the feature ships, as an opening statement, not as an excuse in the retro afterwards. Product owns the what. But engineering sees things product cannot see, and saying them out loud is part of the job, not overstepping.

Making it scale

The obvious objection - a team lead cannot personally step into every feature. Between the features, the incidents and the administrative work, a lead who tries becomes the bottleneck, or burns out.

So we push it down. Every feature has an owner - the developer building it. They have real freedom in how it comes together, and one extra responsibility - when they notice something is off, they bring it to me and we decide together. Autonomy by default, an escalation point for the moments that need a call.

The lead does not need to be in every feature. The lead needs to be findable when the owner smells trouble.

Choosing who is unhappy

Back to the uncomfortable part - someone was unhappy with me in both quarters. In Q1 it was product. In Q2, effectively, it was our users. And me.

You do not get to make everyone happy. You get to choose your trade and own it. My rule since then is simple - I would rather explain to a colleague why we challenged their mockup than explain to a user why the feature does not work. Only one of those conversations makes the product better.