Nine Months as a Technical Lead: What I Had to Unlearn

In December 2025 my title at Silk Road Professionals changed from Senior Software Engineer to Technical Lead. Nothing else changed that day. Same repository, same client, same standup. I assumed the job was the one I already had, plus meetings.

That assumption survived about three weeks.

The sharpest description of what I got wrong is not something I came up with. It is in Zach Goldberg’s The Startup CTO’s Handbook, in a short section on what he calls the professional skill tree:

“…even if you’re a Level 100 engineer you’ll start your new leadership position as a Level 1 manager staring at a mighty oak tree of yet-to-be-unlocked crucial skills.”Zach Goldberg, The Startup CTO’s Handbook

That is the whole problem in one sentence. The skill points I had spent over five years, on Java backends, Python and Django services, Kubernetes and Terraform, all went into one branch of the tree. None of them transferred. I had not been demoted, but on the branch that now mattered most I was starting from zero.

I picked the book up partly because I had already done this job badly once. When I founded eAdvisor and we raised our first investment, I was the person making technical decisions for other people, and I made most of the mistakes below without knowing any of them had names.

Nine months in, here are six instincts that made me effective as a senior engineer and made me a worse lead, and what I replaced them with. This is a progress report, not a victory lap.

1. I am the shortest path to done

As a senior engineer I had a clean weekly metric: what did I ship. Odoo modules, geospatial pipelines, an integration with John Deere Operations Center. Whether I had a good week was a question I could answer by looking at merged branches.

As a lead that metric quietly turns into a liability. The trap is specific and it comes up every week: an engineer has been on a task for two days, I can see the fix, and I could do it in forty minutes. Taking it back feels like leadership.

“…the best measure of your performance as a manager is the performance of the team itself.”Zach Goldberg, The Startup CTO’s Handbook

Taking it back costs three things, and I only counted the first one for a long time:

• The engineer gets an answer instead of a method, so the same task costs the same two days next month.
• I become a bottleneck sitting in the critical path of everything at once.
• The knowledge stays in one head. On a platform built out of microservices, queue consumers, real-time event flows and caching layers, a bus factor of one is not a people problem, it is an availability problem.

What I do instead now is hand over the outcome and the constraints, never the implementation. “This worker has to be idempotent and it has to survive a broker restart. Here are two approaches I would consider. Come back and tell me which one you picked and why.” It is slower this week and much faster this quarter.

2. Every decision deserves a careful answer

Senior engineers get rewarded for rigor, so I applied rigor uniformly. That made me slow on the large majority of questions that did not deserve it.

Goldberg borrows Jeff Bezos’s split here. Type 1 decisions are one-way doors and deserve deliberation. Type 2 decisions are reversible and should be made quickly by whoever has the judgment to make them. The failure mode he names is the one I was living in:

“…using Type 1 decision-making for Type 2 decisions leads to slowness and failure to experiment and innovate.”Zach Goldberg, The Startup CTO’s Handbook

On our platform the split is usually obvious the moment you say it out loud. How tenant data is isolated in Postgres, whether an event flow is at-least-once or exactly-once, how we shard the queues: those doors shut behind you. The shape of a folder, the name of a Prisma model, which of two reasonable libraries handles a form: those are not doors at all, and I was holding design reviews about them.

The discipline that fixed it is one question in review. Can we walk back through this door? If yes, pick one and move.

3. Disagreements are settled by whoever is most right

Between senior engineers the best argument usually wins, and that works fine. With a team of junior and mid-level engineers, and with me as the accountable person, it stops working, for two reasons. Often nobody can know who is most right in the time available. And I hold context about the client and the roadmap that the room does not have.

Goldberg gives three ways to close a disagreement, and they are worth memorising:

1. We go your way, because you made a clear and convincing argument that it is better.
2. We go my way, and here is the broader context I have as the lead that explains why.
3. We go my way because there is no objective reason to prefer either option. It is a tie, I am accountable for the outcome, so I will own it.

The third one is what I was missing. I used to leave ties open and gather more input, which feels like fairness from the inside and lands as drift from the outside. Saying “this is a coin flip, we are doing it this way, and it is on me if it is wrong” ends the conversation and costs nothing, as long as you are honest that it really is a coin flip.

The related habit I took from the book is how a decision gets drafted. Deciding alone is fastest and buys the least commitment. Deciding as a group from scratch buys the most commitment and costs the most time. The middle option, writing a straw man and handing it to the team to pull apart, is where I now default. I mark clearly which parts are load bearing and which parts are up for debate.

4. A 1:1 is a status meeting

My first 1:1s were sprint reviews with a smaller audience. I asked what was blocking them, got “nothing”, gave the time back, and felt efficient about it. Then I read this:

“Your engineers should be venting at you regularly… your job is not to solve every problem they bring up; your job is to listen, to ask questions to clarify your understanding, and to convince them that you do understand, and then steer them toward solutions.”Zach Goldberg, The Startup CTO’s Handbook

Silence in a 1:1 was not the absence of problems. It was the absence of a habit, and probably the absence of trust. Strong engineers always notice things that are wrong with the world around them, and if none of that is reaching you, it is not because it stopped existing.

The second half of that quote is the harder part when you lead juniors. Someone brings you a problem and the fastest thing available to you is the answer, so you give the answer. The answer is the least valuable thing in the room. What actually helps is the two minutes of questions that get them to it themselves.

Concretely: every engineer, every two weeks minimum, a shared running document so neither of us walks in cold, and a standing set of topics that only surface once the tactical work is off the table. Conflict. Growth. Clarity on something they are guessing about. Context on why the client wants what they want.

5. Technical debt is code that looks bad

This one embarrassed me. I had always used “tech debt” to mean code I found distasteful. The book defines it as a decision or implementation “that actively reduces the efficiency or effectiveness of the business today or in the future”, which quietly disqualifies most of what I used to complain about. Ugly code with no future consequence is not debt. It is just ugly.

Goldberg lists seven kinds. The two I had never once counted were the two costing us most:

Skill debt was the one that reframed how I spend my week. If part of the system cannot be maintained without me, that is not a compliment and it is not a staffing issue. It is a debt with an interest rate, and the repayment is deliberate pairing and handover, scheduled like any other work rather than squeezed in when things are calm. Things are never calm.

Process debt was the one I could not see because I was inside it. Three engineers solving the same class of problem three different ways is cheap once and expensive forever, and it shows up later as an outage nobody has a runbook for.

6. The client conversation is someone else’s job

As a senior engineer I was mostly shielded from this. As a lead I am in the room with the client, and the thing nobody tells you is that the correct technical argument and the persuasive argument are rarely the same argument.

Goldberg’s example is exactly the conversation I had been losing. Walk in asking for a month of re-architecture while talking about “latencies, RPC calls, dependency injection, and acronyms from your cloud service provider” and the room switches off. Frame the same request around developer productivity and delivery speed over the next six months and it lands.

That is not spin. It is converting a real cost into the unit the person holding the budget actually measures in. The engineering work of that conversation happens before it starts, when you work out what the debt is costing in weeks of delivery rather than in milliseconds.

The harder half is bad news. The instinct is to say things are fine when they are not, and the book is right that it is a slow way to destroy your own credibility. It also spends the exact trust you will need later, the first time you ask for a month of work the client cannot see.

What I still get wrong

• I still take work back when a deadline is close. Sometimes that is correct. More often I am choosing this sprint over next quarter and telling myself it was correct.
• I still under-communicate. The book has a whole section on the benefits of overcommunicating, I have read it twice, and I apply about half of it.
• I am still calibrating how much structure a team of juniors and mid-levels needs. Too little and everyone invents their own process. Too much and you get ceremony that nobody believes in. The rule I am converging on is to add process only in response to a failure that actually happened to us.

If you are about to make this jump

1. Accept the level reset. You are not bad at your job, you are new at a different one.
2. Find a mentor who has done it. The chapter on this was the most personally useful part of the book, and it is the one thing here you cannot read your way into.
3. Decide reversible things fast, in public, and say out loud that they are reversible.
4. Learn to say “it is a tie, we are doing it my way, I own it.”
5. Let your 1:1s be uncomfortable. Comfortable ones are usually empty.
6. Learn to price technical work in the language of whoever is paying for it.

The Startup CTO’s Handbook is written for CTOs of startups, and I lead one team inside a consultancy. Almost all of it still applied, because the transition it describes has nothing to do with headcount. It is about the moment your output stops being your own. The full text is free on GitHub and it is worth an afternoon.