Engineering Journal · LEADERSHIP · February 11, 2025 · 16 min read
The Decisions a Tech Lead Cannot Delegate
The job is not to be the best developer in the room. It is to own a small set of decisions that, if left ownerless, turn into accidents the whole team has to live with.
By Golam Sorwar, Tech Lead and Full Stack Engineer in Dublin.
I spent the first part of leadership trying to stay useful in the way I already knew. Review the hard pull request. Take the ugly bug. Be available. That is not nothing. It is also how you become a very expensive individual contributor with extra meetings.
The job changed for me when I noticed that the team did not primarily need my syntax. They needed someone to decide the things that otherwise get decided by whoever is tired at 5pm, or by a date that was never a date, or by a silent assumption that "we will tidy it later." Later is a place with no owner.
This is not a career narrative. I have already written about titles, mentoring, and the first year. This is a narrower argument: there is a set of decisions a tech lead cannot honestly delegate, not because other people are incapable, but because the team needs a single place where those calls can be found when they go wrong.
Context
I lead delivery on a small product group: web, APIs, a Flutter client, the operational systems underneath a college. The work is a mix of features, integrations, and the kind of maintenance that never looks like a launch. There is no separate architecture office. There is no project manager whose only job is to protect a sequence. If a decision about risk is not taken inside the team, it is taken by calendar pressure.
That shape is common and it is specific. In a large org, some of these decisions live in staff-plus roles or in written programmes. In a small team they live in the same person who still opens a pull request. The danger is mixing those modes without noticing. You think you are being helpful in the code. You are actually leaving the decision layer empty.
Stakeholders are close. That is good for truth and bad for impulse. A request can go from hallway to ticket without passing through a design that anyone would defend a month later. Someone has to be the place that impulse stops and becomes a choice.
The real problem
The apparent problem is throughput. People want to know why a thing is late, or why two engineers solved the same category of problem in two styles, or why a "simple" integration keeps returning.
The deeper problem is unowned trade-offs. Every product has more good ideas than it has careful hours. If nobody decides what we will not do, the backlog decides by overflow. If nobody decides which boundary is real, every feature punches a new hole in the monolith. If nobody decides what "done" means for a payment or a migration, done means shipped-enough-to-demo.
A second deeper problem is false delegation. You can ask the team to "own quality" and still be the only person who is allowed to say the date is wrong. That is not empowerment. That is leaving people responsible for outcomes they cannot steer. Real delegation includes the authority to change the work, not only the duty to finish it.
I also had to admit a personal version of the problem. I like being the person who can still do the task. It is visible. A decision about scope is invisible until it saves you, and by then nobody thanks it. The ego wants the visible thing. The role needs the other.
Constraints
Time is not abstract. Term dates, payment windows, and external vendors create real clocks. A lead who ignores those clocks is not principled. They are decorative.
The team is mixed in seniority. Some people can be given a vague problem. Some people will produce a careful mess if you give them a vague problem. Delegation has to match the person, which means the lead still designs the size of the box.
I still write code. If I disappear into "alignment," I lose the right to smell a bad shortcut. If I write too much of the critical path, I become the bottleneck I was hired to remove. That tension does not resolve. It is managed week by week.
Stakeholders can overrule. A tech lead does not win every argument. What they can do is make the cost legible. If the organisation still chooses the expensive path, that is a recorded decision, not a silent one. Recording it is part of the job.
And we cannot pause the systems. Decisions happen while production is live. That is why "we will decide the architecture after this release" is usually a way of deciding to keep the current one.
Options considered
Lead as the best pair of hands. Advantage: short-term delivery, credibility, comfort. Disadvantage: the team's ceiling becomes your calendar. Risk: you train people to wait. Maintenance of the organisation is worse even if the repository looks loved. The business gets a hero and a queue.
Lead as a process clerk. Stand-ups, tickets, status. Advantage: visibility. Disadvantage: nobody is deciding the technical bets, so process becomes a way of watching accidents arrive on time. Risk: you become the person who knows the dates and not the person who knows the blast radius.
Lead by consensus only. Advantage: buy-in, fewer lonely calls. Disadvantage: consensus is slow, and some decisions are about saying no to a likeable idea. Risk: the loudest or most senior-sounding engineer wins, which may not be the one who will live with the on-call. I want debate. I do not want a vote on every boundary.
Name a small decision set and keep it visible. What we will not build. What debt we accept, and until when. Which module owns a fact. Whether a date is a wish. Whether an integration is allowed to touch money before it has a replay story. Advantage: people know where to escalate. Disadvantage: you will be the person who says no. Risk: you hoard decisions that should have been pushed down. The work is to keep the set small on purpose.
Decision
I treat five calls as mine unless I have explicitly handed one to a named person with the authority to finish it.
What we are not doing this cycle, even if it is good. What quality of debt we are accepting, written down, with a trigger to revisit. Where a domain fact is allowed to be written. Whether a committed date is still honest. Whether a change is allowed to cross a risky seam — payments, tenancy, identity, the jobs that talk to the outside world — without extra eyes.
I chose that list because those are the decisions that, if fumbled, create work for everyone else. A missed naming convention is annoying. An unowned payment state is a month of finance. A date that was never challenged is how you get a team that stops telling you the truth.
Why not more? Because a lead who decides the implementation of every ticket is not leading. They are hiding in taste. The team should own how a screen is built once the seam and the risk are clear. If I cannot let that go, I do not have a team. I have assistants.
Implementation / Process
The process is lighter than the words suggest. Intake gets a question that sounds rude and is not: what happens if we do not do this. If the answer is thin, the work is a preference. Preferences can wait.
Risky seams have a written owner and a written "done." For money, done includes a state you can explain and a replay. For a migration, done includes a rollback that is not theoretical. For a mobile API change, done includes what old clients will see. I do not need a long RFC for every ticket. I need the done that matches the blast radius.
Dates get interrogated in private before they get defended in public. If I have already sold a date I do not believe, I have chosen politics over the team. Sometimes I still have to carry a date I dislike. Then the job is to cut scope in the open, not to hope.
I stay in the code on purpose, in review and in the paths I do not want to learn about from an incident. I do not take every interesting ticket. That was a harder habit than it sounds. Interesting tickets are how you keep feeling like yourself.
When I delegate a decision, I say the words. "You own whether we extract this job or leave it in the monolith. I will live with the call." If I then override it casually, I have taught the team that ownership is theatre.
Problems and failures
I have overridden a call after saying I would not, because I got scared in review. The code may have been better. The team was worse. If you need to take a decision back, take it back as a recorded change, not as a drive-by comment.
I have also under-decided and called it trust. A vague "see what you think" to someone who needed a box produced a thoughtful design we could not operate. That was my failure to size the work, not their failure to be senior.
Saying no without an alternative made me look like a gate. The useful no includes the smaller yes, or the later date, or the risk we are accepting if they push anyway. Stakeholders can handle a trade-off. They cannot handle a mood.
I stayed too close to one technical area because I liked it, and too far from another because I found it dull. Dull areas — access, naming of statuses, the admin screen finance actually uses — are often where the organisation lives. Neglect is a decision.
There were weeks when I confused being busy with having decided things. A full calendar can hide an empty decision log. The team feels that as drift.
Trade-offs
I trade some personal coding joy for fewer surprises. I still write. I do not write the most of the fun path. That will always itch a little. It should. If it stops itching, I have probably drifted too far from the work.
I trade speed of agreement for clarity of disagreement. Writing down a no slows the meeting. It speeds the next month.
I do not trade away accountability when I delegate. If I handed you the call, I still stand next to the result in the stakeholder conversation. Otherwise people will not take the next call.
Result
The team became less surprised by me and more willing to surprise me with a finished decision. That is the direction I want. Planning arguments started happening before the code, which is cheaper even when they are uncomfortable.
I also became easier to replace for a week. That is an unromantic success criterion and a good one. If nothing can move because I have the only copy of the no, I have built a fragile organisation around my taste.
Work did not become calm. It became easier to locate. When something went badly, we could usually point to a call we had made, not only to a ticket we had rushed.
What I would do differently today
I would have written the decision set down in the first month, badly, instead of waiting until I could make it sound wise. A crude list would have saved a few silent accidents.
I would have practised the public no earlier on low-stakes work, so the high-stakes no did not become the first time people saw me do it. Muscle memory belongs in leadership too.
I would spend even less energy on being the person who can still do every task, and more on being the person who notices when a date has become a lie. The lie is more expensive than an unclaimed bug.
Broader lesson
A tech lead is not a title for the strongest engineer. It is a role that absorbs a few decisions so the rest of the team can move without waiting for telepathy.
If you cannot name the decisions you refuse to leave ownerless, the calendar will name them for you. The calendar is a terrible architect.
Closing thought
Stay close enough to the code to keep your nose. Stay far enough from the tickets to keep your hands off the decisions that only work when they have a name. The team does not need you to be everywhere. They need you to be findable when the trade-off is real.
