For my first 6 months as a Tech Lead I did not know how to say no, and every deadline got pushed. My answer was two shifts: we plan releases instead of features, and the product document replaced the codebase as the source of truth.
I'm Panth Patel, Tech Lead on Envizom at Oizom. This post is about process, not code.
What the job turned out to be
I started as a backend developer. I could debug anything in the stack, and I was comfortable helping with product design and the roadmap. None of that prepared me for a product that sells to clients.
Some features were wanted right now or the client wouldn't buy. Others were insistent suggestions that could sit in the backlog for months before anyone asked for an update. There was no cap on how many came in. As a dev you think everything is doable, until you realise you are no longer a proof of concept and people expect professional experience.
And I kept running into one question. If you expect no bugs and a stable release, how can you commit to a client on a 1-week timeline?
We were selling almost everything, about 80-90% of what clients asked for, and the team was praised for it many times. But every deadline slipped, and every release took new features at the last moment. Clients expected a stable system while we still acted like a startup. To scale, Envizom had to become a separate product, with client customisation in a proper framework instead of production code changes.
So I spent 2 months reading how professionals run this: how they scale, how they set KRAs and KPIs, how big tech manages a codebase with frequent releases. Some of it was too much for us and some too little. What we ended up with is good enough, and it works like a machine: each part has one job.
Shift 1: the document changes first
Every feature now starts as a 5-10 minute group discussion, without waiting for a standup. It defines the exact change to the product document before anyone implements anything. Product development happens there, and execution doesn't. If the feature needs research, a separate R&D task starts and blocks it.
Then the feature doc goes to three people at once:
| Role | Before | Now |
|---|---|---|
| Lead | came in only if needed | estimates from the doc |
| Dev | built it, then explained it to the product owner and QA/QC | implements and tests their own work |
| QA/QC | driven by the dev | writes cases from the doc, runs them, attaches a report |
The last row is the one I care about most. QA/QC reads only the latest feature doc, so a bug gets caught the way a client would hit it. Before this, the product truth always ended up being the code.
Each task also attaches two short videos: one explaining the product, one explaining the development interfaces and contract. The product owner and dev lead confirm the original clarifications were met, and only then does it go to QA/QC.
Shift 2: features have no deadlines
Nobody asks whether a feature is "immediate" any more, and nothing is "4 days" or "1 month". A feature goes into a release, and no work happens until a release is defined. A feature can join a release only when no R&D is left, just implementation. Only the release has a deadline and an estimated dev time.
The calendar has rules:
- At least 2 days of code freeze per release.
- 1 extra QA/QC day after the release.
- Releases happen on working days, with at least 2 working days ahead and no consecutive holidays.
Git follows the release too. Each release has a dev branch and a prod branch. Every feature and bug-fix branch comes off the release's dev branch and merges back to it. The prod branch has two environments: demo, recently cloned from the prod DB and running the upcoming release, and prod itself, updated on release date.
The comms come first as well. Change logs, product updates and press releases are defined at the start of release development and go out to client-facing colleagues, devs, QA/QC and leads.
Where in your team does a feature get its deadline: when someone asks for it, or when it joins a release?
Top comments (0)