Leading an In-House Team as the Central Engineer
What changed when I stopped writing every feature myself and started designing the system the team writes inside of.
The hardest part of becoming the central engineer was accepting that my output is no longer measured in merged pull requests.
Design the system people write inside of
A good scaffold answers most questions before they are asked: where does this file go, how do we validate input, how do we handle failures, how do we test it. Every answer you encode in the paved path is a decision the team does not have to relitigate.
Review for direction, not for taste
Split feedback into three explicit buckets:
- 01Blocking — correctness, security, data integrity
- 02Should fix — clarity and maintainability
- 03Optional — preference, no reply required
Labelling the bucket removes the guesswork that makes reviews feel personal, and it makes junior engineers ship faster.
Make the boring things automatic
Formatting, static analysis, migrations checks and test runs belong in CI. Humans should spend their attention on the part of the diff a machine cannot judge.
Protect focus like it is a budget
Batch interruptions, keep one shared channel for questions, and write decisions down. A short architecture note today prevents four meetings next quarter.
The result
Throughput stopped depending on my availability. That is the whole job.
Building something that has to scale?
I help teams design architecture, tighten performance and ship products that keep working as the business grows.
