What I learned leading a team of four engineers
For four years I was the tech lead at KitchenSync, a US company that automates accounting for restaurants. I led and mentored a team of four engineers, owned code review and CI/CD, and worked directly with product, business analysts and customers.
Accounting software has an unforgiving property: a small mistake shows up weeks later, in someone's month-end close. That shaped how we worked. Here's what I'd keep doing on any team.
Small pull requests
The single most useful habit was keeping pull requests small.
- A small PR gets a real review. A huge one gets a quick "looks good".
- It's easier to find what broke, and easier to revert.
- It forces you to split work into steps that each make sense on their own.
When a change is naturally big, split it into steps that can each be reviewed in one sitting, for example the data model first, then the logic, then the UI.
Review is mandatory, and it's for learning too
Every change was reviewed before merging, no exceptions for seniority.
Review did two jobs. It caught problems, and it spread knowledge: after reviewing someone's code on the reporting module, you know a bit about the reporting module. With a small team working on a platform with a shared TypeScript library of 16+ modules used by every service, that shared knowledge mattered as much as catching bugs: with four people, nobody can afford to be the only one who understands a module.
For mentoring, review comments worked best when they explained why, not just what. "Use the shared validation module here, because the reports and the audit trail rely on the same rules" teaches something; "use the other function" doesn't.
CI does the boring checks
People shouldn't spend review time on things a machine can check. Our CI pipeline, on GitLab with containerized deployments, ran the tests on every change. If it wasn't green, it didn't merge.
That freed reviewers to focus on what machines can't judge: whether the design fits, whether the naming is clear, whether the change solves the actual problem.
Periodic quality audits
Reviews look at one change at a time. Some problems only show up when you look at the whole codebase: duplicated logic, modules that grew in the wrong direction, tests that no longer test much.
So from time to time we ran quality audits: a deliberate look at an area of the system, with a short list of improvements to schedule. It's a small investment that prevents the slow drift that makes a codebase painful.
Settle technical debates with data
Engineers disagree, and that's healthy. What doesn't work is settling it by hierarchy. "Because I'm the lead" ends the discussion and teaches nothing.
What worked better was agreeing on how we'd decide before arguing about the answer: a quick benchmark, a small prototype, a look at the actual data, or the trade-offs written side by side. Often the data made the decision obvious. When it didn't, at least everyone understood why we went one way.
Close to product and customers
A lot of the hardest work wasn't code. Accounting requirements are complex, and they often arrive as "this is how our accountant does it". I spent real time with product, business analysts and customers turning that into features we could build and test.
Engineers who understand the business make better decisions on their own, so it pays to bring them into those conversations instead of translating everything for them.
The short version
- Keep changes small enough to review properly.
- Review everything, and explain the why.
- Let CI handle what machines can check.
- Step back regularly to look at the whole codebase.
- Decide with data, not rank.
- Keep engineers close to the people who use the product.
None of this is new. The hard part is keeping it up when deadlines press, and that's exactly when it matters most.